Se analiza cómo y en qué grado se aplica el modelo RDF en las principales colecciones digitales españolas de materiales patrimoniales. Se introduce este modelo y también las iniciativas de Datos Abiertos y Datos Enlazados. A continuación se examinan 51 repositorios digitales y de cada uno de ellos se determina si expresan sus registros en RDF, ofrecen un punto de consulta SPARQL consultable por agentes externos y si usan referencias como valor de las propiedades. A partir de los resultados se describen los modelos EDM de
The article discusses how and to what extent the RDF data model is applied in major Spanish digital collections of heritage materials. This model, as well as Open Data and Linked Data initiatives, are introduced. Fifty-one digital repositories were analysed to determine whether they expressed their records in RDF, offered SPARQL query points searchable by external agents, and used references as property values. The Europeana EDM and OntoWeb models are also described. It is concluded that the use of RDF is unequal and excessively conditioned by the use of applications that automatically convert records into RDF triples. Few of the collections analysed give SPARQL points for external queries. Also, the use of references is linked to applications using different models: EDM or OntoWeb. Collections should enrich their data and define aggregation levels for generated RDF data in order to be disseminated, made accessible, and adapted to the semantic web.
Las bibliotecas, archivos y museos y, más concretamente, sus depósitos digitales, atesoran generalmente ingentes cantidades de datos (organizados en forma de documentos) y metadatos (organizados en registros bibliográficos y de autoridad), que presentan altos niveles de estructuración, de tratamiento desde el punto de vista semántico y de interoperabilidad. Más allá de objetivos vinculados a la conservación y preservación de sus fondos, estos tres tipos de instituciones necesitan darlos a conocer y hacerlos más accesibles a otras instituciones similares, pero sobre todo a sus usuarios, sean particulares, instituciones o empresas. Todos estos factores resultan especialmente interesantes para la web semántica, y, más específicamente, la web de datos y su propósito de hacer los contenidos más accesibles (leíbles y comprensibles) para las máquinas.
La web semántica pone a disposición de bibliotecas, archivos y museos un modelo de datos para la representación de información en la Web, el Resource Description Framework, RDF
Una declaración RDF constituye la forma más simple de expresión de un metadato, mediante grafos de tripletas compuestas por un sujeto –la cosa, el recurso, sobre el que se declara algo–, un predicado –el aspecto que se describe– y un objeto –el valor de lo que se describe sobre el sujeto–. Los recursos que constituyen el sujeto y el predicado tienen que ser designados por identificadores uniformes de recursos, URI
Por otro lado, la estructura de grafo permite el procesamiento de la información existente independientemente de que sea completa o detallada o del grado de estructuración de sus fuentes. Al ser una estructura simple, no está sujeta a los cambios de esquema o de formato habituales en las actualizaciones de bases de datos relacionales, y permite el fácil intercambio de datos entre sistemas o versiones diferentes, sin pérdida de datos.
Existen diferentes formatos, o sintaxis, que permiten la codificación de las tripletas que constituyen un grafo RDF y su publicación como datos enlazados. Son los llamados formatos de serialización de RDF, algunos de los cuales han sido normalizados por el W3C.
Sintaxis XML para RDF, o, simplemente, RDF/XML
Terse RDF Triple Language, abreviado Turtle, que permite expresar un grafo RDF en una forma textual compacta. TriG es una extensión de Turtle para representar conjuntos de datos RDF completos
RDFa que permite incorporar datos estructurados y semánticamente enriquecidos de acuerdo con el modelo RDF en código HTML y XHTML, mediante un conjunto de atributos
A priori, la elección de un patrón específico de publicación de datos enlazados determina la preferencia por un formato de serialización específico. Así, en los casos en que la provisión de los datos se realiza incrustados en ficheros HTML, RDFa es la solución idónea. Para el resto de patrones de publicación, entre los que podemos situar la descarga de ficheros (
Más allá de los formatos de serialización, se han generado otros modelos de datos diferentes a RDF, que permiten representar información estructurada y semánticamente rica sobre los datos. Entre los que mayor éxito han alcanzado encontramos los Microdatos y JSON-LD, ambos impulsados y normalizados por la W3C. A priori, ambos pueden contemplarse como competidores del modelo RDF en la consecución de la web de datos semánticamente enriquecidos.
Los Microdatos
JSON-LD
Podemos concluir que la selección de modelos de datos diferentes, aunque muy próximos, a RDF, como son Microdatos y JSON-LD, para el desarrollo de aplicaciones de datos enlazados está profundamente vinculada a preferencias de contextos y comunidades de uso. Lo que pareciera, a priori, una amenaza puede verse como una oportunidad de expansión, apoyada por la posibilidad de transformación entre todos los modelos de datos y formatos de serialización.
Para la publicación –y, por lo tanto, también el consumo– de datos RDF resultan fundamentales dos iniciativas complementarias: Datos Abiertos (Open Data) y Datos Enlazados (Linked Data)
La modificación del marco normativo de los Datos Abiertos en España va a tener implicaciones relevantes en relación con el desarrollo de esta iniciativa para las Administraciones y organismos del sector público, en general, y, especialmente, para las bibliotecas, archivos y museos.
Por un lado, los nuevos textos normativos abren explícitamente el marco de actuación de los Datos Abiertos tanto a los documentos —o datos— como los metadatos que estos tienen vinculados. En lo que se refiere a los formatos, establecen que, siempre que sea posible, tanto los datos como los metadatos deben ser proporcionados en formatos abiertos y legibles por máquina, y deben cumplir estándares y normas abiertas. Además, los metadatos deben ofrecerse con los niveles más elevados de precisión y desagregación.
Por otro lado, es importante tener en cuenta que una motivación fundamental para la incorporación de estas instituciones al marco normativo de los Datos Abiertos es la constatación de que sus fondos, y, especialmente, los que resultan de proyectos de digitalización, son clave para el desarrollo de productos y servicios en diferentes sectores empresariales (se citan, concretamente, el aprendizaje y el turismo). De hecho, el proyecto de ley española insta a las Administraciones Públicas a velar por la reutilización de los datos para fines tanto comerciales como no comerciales (artículo 4.2), e incorpora medidas de impulso y flexibilización del régimen administrativo de la reutilización de los datos y metadatos (diversificación de las modalidades de reutilización, limitación de las condiciones incorporadas en las licencias, etc.)
Especialmente relevante, en relación con el impulso de la reutilización de datos y metadatos, es el requerimiento a las instituciones a adoptar una actitud proactiva en lo que se refiere a los mecanismos de búsqueda y recuperación de los datos por parte de los usuarios finales. En concreto, el artículo 4.5 del proyecto de ley española prevé medidas que comprometen a todas las Administraciones y organismos del sector público: la creación de sistemas de gestión documental enlazados con sistemas ofrecidos por otras administraciones que faciliten la recuperación de los datos por parte de los ciudadanos, y la provisión de herramientas de búsqueda de datos abiertos para su reutilización. Adicionalmente, ordena a la Administración General del Estado mantener “un catálogo de información pública reutilizable, correspondiente al menos al ámbito de la Administración General del Estado y a sus organismos públicos vinculados o dependientes.” (
La segunda iniciativa a la que hemos hecho referencia, Datos Enlazados, aborda la perspectiva técnica de la interoperabilidad y es una apuesta clara por el modelo de datos RDF y por otras dos tecnologías de la web semántica: los URI y el lenguaje de búsqueda en datos RDF denominado SPARQL
Deben utilizarse URI para identificar los recursos en cada uno de los componentes de las declaraciones RDF: en el sujeto, en la propiedad y, con prioridad sobre la alternativa de los literales, en el objeto.
Deben utilizarse URI creados de acuerdo con el protocolo HTTP, de forma que puedan ser consultados y desreferenciados en la web por las personas y, sobre todo, por los sistemas automáticos.
Debe proporcionarse información útil sobre los recursos identificados con los URI desreferenciables, para cuando alguien los consulte. Con esta finalidad, es necesario utilizar estándares de la web semántica, como RDF y SPARQL.
Deben establecerse enlaces con otros recursos (utilizando sus URI) en el momento de publicar datos en la web, de forma que se puedan descubrir más datos.
La publicación de datos enlazados significa la creación de conjuntos de datos (
Enlazarse, en origen, con datos RDF de otros depósitos digitales e incluso de otros conjuntos de datos ajenos a las colecciones documentales.
Ser enlazados por conjuntos de datos externos que quieran ser enriquecidos.
Ser consumidos directamente por aplicaciones que los necesiten para la generación de nuevos recursos y servicios, mediante descargas masivas (
Los beneficios de la aplicación del modelo de Datos Abiertos Enlazados
El modelo se ha venido aplicando y se ha impuesto como paradigma en la comunidad que trabaja en bibliotecas digitales. Como ejemplos, a parte de los de centros españoles que se comentan más adelante, se puede citar el
Existen diferentes iniciativas orientadas a facilitar la exploración de las oportunidades y beneficios de publicar datos de repositorios como datos enlazados.
El ciclo de vida de los datos enlazados comprende un conjunto de fases cíclicas, que incluyen la creación de datos, el enlace (reconciliación) con datos RDF externos, el modelado mediante vocabularios/ontologías, y la publicación para facilitar su consumo. Diferentes metodologías han sido propuestas para concretar y sistematizar dichas fases. En paralelo a la definición del ciclo de vida, se ha desarrollado un sector de herramientas informáticas para la gestión y automatización de fases aisladas, o de varias de ellas de forma conjunta. Una fuente interesante para la identificación y selección de estos tipos de herramientas es Semantic Web Development Tools
Open Refine
En el ámbito específico de las bibliotecas y los museos, cabe destacar ALIADA
Además de estas herramientas, es importante tener en cuenta casos de uso representativos de diferentes recetas de publicación de datos enlazados a partir de colecciones de bibliotecas, archivos y museos. Ya el W3C Library Linked Data Incubator Group realizó una recopilación de estos casos de uso que se incluye en su informe final
Dadas la relevancia de las tecnologías de la web semántica, su relación con los Datos Enlazados y su importancia para las colecciones digitales de entidades patrimoniales, cabe preguntarse cuál es su grado de utilización actual en bibliotecas, archivos y museos. Este trabajo pretende analizar la aplicación del modelo de datos para metadatos RDF en las principales colecciones digitales españolas con una orientación patrimonial y, con ello, ofrecer una visión panorámica del grado de implementación de esta tecnología en las colecciones digitales españolas y, por consiguiente, de su mayor o menor adaptación a la web semántica.
Para evaluar el nivel de aplicación de las tecnologías de la web semántica se ha examinado un conjunto de repositorios con el objetivo de determinar en qué medida expresan sus registros en RDF, ofrecen un punto de consulta SPARQL consultable por agentes externos, y usan referencias como valor de las propiedades, ya sea mediante un URI local o uno externo. En primer lugar, se ha identificado qué programa se emplea en cada repositorio para gestionar la colección digital, ya que el software puede condicionar el modelo de datos. A continuación, se ha averiguado si los registros se expresan en RDF y, en caso afirmativo, si el repositorio ofrece alguna forma de consulta. Por último, se han analizado los resultados de las consultas para describir los modelos mediante los cuales se articulan los datos.
Para la selección de colecciones digitales se han seguido los mismos criterios de selección que en Sulé y otros,
La obtención de los datos de las colecciones digitales se ha realizado aplicando diferentes métodos de análisis según la información que se quería recopilar. La identificación del programa de gestión del repositorio se ha llevado a cabo, principalmente, por medio del análisis directo del sitio web. Cuando esto no ha sido suficiente, se ha enviado un correo electrónico a su responsable solicitando dicha información.
La confirmación, o no, de que los datos contenidos en las colecciones se expresan también según el modelo de datos para metadatos RDF y la identificación de su forma de consulta (OPAC, API o SPARQL) se ha realizado también por medio de la combinación de la observación directa de los repositorios y del envío de correos electrónicos a los responsables de las colecciones. También se han consultado catálogos de datos abiertos de las administraciones públicas –como son
Por último, los detalles sobre el modelo de datos, las clases y las propiedades utilizados por las colecciones que expresan sus datos en RDF se han obtenido produciendo, cuando así ha sido posible, el fichero RDF/XML correspondiente, generando su DTD con XMLSpy XML Editor
A continuación, se presentan los resultados del estudio y su valoración, comentando los programas utilizados en la gestión, si expresan los datos en RDF y cómo pueden consultarse. Se muestran los modelos de datos utilizados, concretamente EDM y OntoWeb, de los cuales se describen las clases y propiedades, para pasar a una evaluación global de la aplicación de estos modelos.
Los programes empleados para gestionar las 51 colecciones digitales seleccionadas son, ordenados según el número de colecciones que los usan:
DIGIBIB: 17
DSpace: 14
CONTENTdm: 4
Pandora: 4
Fedora: 2
Invenio: 1
Nubarchiva
Microsoft Access: 1
Desarrollo propio: 5
Desconocido
Como se ve, hay un claro predominio de DIGIBIB
Por su parte, DSpace es un programa de código abierto orientado a la gestión de colecciones digitales con una gran implementación internacional en repositorios institucionales. Basado en Dublin Core, DSpace es compatible también con OAI-PMH y desde la versión 5.0 permite convertir y almacenar los datos en RDF, así como publicarlos por medio de un punto de consulta SPARQL o serializados en RDF/XML, Turtle o N-Triples
En relación con la expresión de los datos en RDF, los resultados obtenidos son:
Expresan sus registros en RDF: 26
No expresan sus registros en RDF: 16
Sin respuesta: 9
De las 26 colecciones que expresan sus registros en RDF, la distribución según el programa de gestión es la siguiente:
DIGIBIB: 17
DSpace: 7
Fedora: 2
Es decir, todas las colecciones gestionadas con DIGIBIB permiten expresar sus registros bibliográficos en RDF, mientras que de las que son gestionadas con DSpace únicamente hemos tenido constancia de siete que lo hacen (de las siete restantes, tres han confirmado que no, y de otras cuatro no hemos obtenido respuesta). Las dos colecciones gestionadas con Fedora
En relación a los catálogos de datos abiertos de las administraciones públicas (
Respecto a la forma de consulta de los datos expresados en RDF, los resultados obtenidos son:
SPARQL endpoint: 1
API (GET method): 21
OPAC: 3
Sin respuesta: 1
En este caso, la única colección donde hemos podido constatar que dispone de un punto de consulta SPARQL es el
En cuanto a las 21 colecciones que facilitan la consulta de todos sus datos expresados en RDF a través de una API, el resultado es un fichero XML obtenido mediante una petición “verb=ListRecords” según los parámetros del protocolo OAI-PMH
Por último, hay que mencionar que tres de las colecciones que expresan sus datos en RDF únicamente permiten consultarlos desde el mismo OPAC y de forma individual, es decir, registro por registro. Se trata de tres colecciones gestionadas con DIGIBIB que no disponen de las funcionalidades de publicación en Linked Open Data y en EDM.
Así pues, el análisis de los modelos de datos, las clases y las propiedades de los registros expresados en RDF de las colecciones digitales españolas se ha tenido que limitar a las 21 que lo hacen a través de una API con el método GET. En el resto de casos, como se ha comentado, no hemos obtenido respuesta de la institución, no hemos podido acceder a los datos (SPARQL con claves de acceso) o sólo se pueden consultar los registros individualmente uno por uno (lo que imposibilita garantizar unos resultados exhaustivos para toda la colección).
En relación con el modelo en que son expresados los datos, el análisis de los ficheros obtenidos con las consultas GET, realizadas en los meses de mayo y junio de 2015, muestra que la mayoría de las colecciones, 17 de 21, siguen el Europeana Data Model (EDM): 14 de ellas gestionadas con DIGIBIB y tres con DSpace. Las cuatro restantes, gestionadas con DSpace, siguen el extinto modelo OntoWeb
Puesto que ambos modelos establecen especificaciones de clases y de propiedades que pueden ser empleadas de forma diferente, pasamos a analizarlos de forma separada.
Como se ha mencionado, son 17 las colecciones que expresan sus datos siguiendo Europeana Data Model. EDM establece tres clases básicas (
dc:title o dc:description
dc:language para objetos textuales
dc:subject o dc:type o dc:coverage o dcterms:spatial
edm:type
A continuación se muestra en la
La primera evidencia es que hay seis propiedades que aparecen en todas las colecciones (columna “No” igual a 0): dc:creator, dc:description, dc:language, dc:title, dc:type y edm:type. De estos seis elementos, cinco corresponden a las propiedades obligatorias mencionadas anteriormente, mientras que dc:creator no. Esta coincidencia viene en gran medida determinada porque cumplir con las especificaciones de EDM es un requisito para que las colecciones puedan integrarse en
Si nos fijamos ahora en la naturaleza de los valores de las propiedades, y más concretamente en la de aquellas que EDM especifica que puede ser una referencia, vemos que de las 26 posibles únicamente once propiedades se dan en uno o más repositorios con un URI local, destacando por su frecuencia dc:creator, dc:subject, dcterms:spatial, dc:contributor, dcterms:isPartOf y dc:publisher. En algunos casos (dc:creator, dcterms:spatial y dc:Publisher) la mayoría de los repositorios expresan los valores tanto con un URI local o con un literal, dependiendo ello de si el concepto tiene asociado en el catálogo un registro de autoridad o no.
Mención especial merece el caso de la propiedad dc:language en la
Además de las clases básicas, EDM incluye también cuatro clases contextuales (
Esta clase aparece en 15 de los 17 repositorios que siguen el modelo EDM. En estas 15 colecciones, la propiedad skos:prefLabel aparece en todas ellas (columna “No” igual a 0), hecho que concuerda con la recomendación de EDM. Tras ella, las más utilizadas son owl:sameAs (nueve colecciones), skos:altLabel (ocho colecciones) y skos:note (seis colecciones). El resto aparecen en tres o menos colecciones.
Por lo que hace a las propiedades que EDM establece que su valor ha de ser una referencia, vemos que su uso no está muy extendido en las colecciones analizadas: owl:sameAs se da únicamente en nueve de ellas y edm:isRelatedTo en tres. En el caso de edm:isRelatedTo los valores son en todos siempre URI locales (referencias a otros agentes de la misma colección). Por el contrario, en la propiedad owl:sameAs hemos encontrado URI externos que referencian al mimo agente en otras bases de datos. En la
Como se puede observar en la
En este caso, la clase contextual Place aparece en catorce de las 17 colecciones analizadas. El análisis también refleja un uso mucho menor de las propiedades establecidas por EDM. De hecho, excepto skos:prefLabel, que se encuentra en las catorce colecciones, el uso de las otras propiedades se reduce a cuatro o menos colecciones.
En las tres colecciones que hemos encontrado la propiedad owl:sameAs, en dos de ellas se referencia a la
La clase edm:TimeSpan es, con mucha diferencia, el elemento de EDM con menor presencia en las colecciones analizadas. Únicamente se encuentra en dos de ellas. Además, en estos dos casos la única propiedad que se incluye es skos:prefLabel.
La última clase analizada es skos:Concept que se encuentra en 15 de las 17 colecciones analizadas. Como se puede ver en la
skos:closeMatch, la propiedad que permite dar el URI de un concepto similar de otra base de datos, se encuentra en siete repositorios: en cinco de ellos se referencia a la
Como se ha comentado en el apartado 4.4, hay cuatro colecciones (todas ellas gestionadas con DSpace) que siguen el modelo de datos OntoWeb. OntoWeb Ontology fue diseñada en el marco del proyecto “OntoWeb: ontology-based information exchange for knowledge management and electronic commerce”, financiado por la Unión Europea a través del programa IST (
En su forma original, algunos de los componentes de OntoWeb son utilizados por DSpace en el diseño de una tabla de equivalencias para facilitar la inclusión de datos formalizados en RDF en la exposición de metadatos estructurados a través de OAI-PMH. En este mecanismo se utiliza la clase ow:Publication para enmarcar el registro de metadatos descriptivos de los objetos, que se expresan mediante propiedades de Dublin Core.
En ninguna de las cuatro colecciones analizadas en este apartado hemos encontrado clases de contexto (edm:Agent, edm:Place, edm:TimeSpan o skos:Concept), por lo que en la
Como se puede apreciar hay seis propiedades que aparecen en las cuatro colecciones: dc:date, dc:description, dc:rights, dc:type, dc:title y dc:identifier. El resto lo hace con menor frecuencia.
Vale la pena destacar que, en este caso, el valor de todas las propiedades en todas las colecciones es literal, es decir, en ningún caso hemos encontrado un URI (local o externo).
La principal conclusión que se extrae de estos resultados es que la aplicación del modelo de datos RDF en las colecciones digitales analizadas es muy desigual y, en general, poco desarrollada. Únicamente 26 de las 42 colecciones analizadas expresan sus datos en RDF, y de estas 26 la mayoría (17) están gestionadas con DIGIBIB, lo que nos da una idea de hasta qué punto la publicación de datos en RDF puede estar condicionada al uso de aplicaciones que incorporen, ya de serie, funcionalidades para convertir de manera automática sus registros en tripletas RDF.
Un segundo resultado que demuestra el poco desarrollo de la aplicación de tecnologías de la web semántica es la casi inexistencia de puntos de consulta SPARQL con los que permitir que agentes externos puedan consultar y recuperar de manera automática los datos RDF de las colecciones. Únicamente nos consta que una colección, el
Un tercer criterio de evaluación es el uso de referencias como valor de las propiedades, ya sea en forma de URI local o externo. En este caso hay una primera y clara diferencia según el modelo de datos empleado, ya sea éste EDM u OntoWeb. EDM establece para ciertas propiedades que su valor ha de ser o puede ser una referencia, mientras que OntoWeb no establece ningún criterio en este sentido. Esta diferencia de modelos de datos determina que en las cuatro colecciones OntoWeb ninguna propiedad contenga en ningún caso una referencia como valor (siempre es un literal), mientras que en las 17 de EDM encontramos en diversas propiedades valores en forma de URI.
Por lo que concierne al enriquecimiento de los registros con enlaces externos a otras bases de datos, la valoración tampoco es muy positiva. De las 17 colecciones EDM, únicamente nueve dan un URI externo como valor de la propiedad owl:sameAs de la clase edm:Agent, tres en la clase edm:Place y ninguna en la clase edm:TimeSpan. En la clase skos:Concept sólo siete colecciones dan un URI externo como valor de la propiedad skos:closeMatch.
Por todo ello, valoramos que las colecciones digitales españolas deberían hacer un doble esfuerzo enriqueciendo sus datos RDF con enlaces externos y creando puntos de consulta SPARQL para, de esta forma, reforzar sus actuales objetivos de difusión y accesibilidad de las colecciones y, a su vez, desarrollar nuevas metas en el marco de los Datos Abiertos Enlazados.
También sería conveniente determinar los niveles de agregación (local, nacional, europeo) de los datos RDF generados por cada colección. A priori, sería posible considerar únicamente los niveles de la propia colección o del conjunto de las colecciones de una institución, pero, desde nuestro punto de vista, también sería conveniente considerar niveles superiores, como los agregadores nacionales (
La versión actualmente vigente es RDF 1.1, cuya especificación está formada por un conjunto de recomendaciones y otros documentos no normativos disponibles en:
Todos los documentos normativos de estas tecnologías y otros documentos informativos para el seguimiento de su evolución pueden consultarse en:
En la versión RDF 1.1 se incorpora otro modelo de identificador,
En rigor, el sujeto y el objeto también admiten nodos en blanco (
Las especificaciones de estos lenguajes y otros documentos informativos pueden ser consultados en:
Esta sintaxis de serialización ha sido definida por la recomendación
Las recomendaciones de W3C que definen estos dos formatos de serialización son, respectivamente,
Las recomendaciones de W3C que definen este lenguaje de serialización son, para XHTML,
Por ejemplo, el formato JSON de RDF (RDF/JSON), cuya sintaxis ha sido definida por la recomendación
La especificación de W3C que define el mecanismo de Microdatos en HTML es HTML Microdata: W3C Working Group Note 29 October 2013.
Véase, por ejemplo,
La especificación de W3C que lo define es
En concreto, la propiedad de JSON-LD que facilita esta operativa es @context. Más información y ejemplos pueden localizarse en Mitchell (
Este tipo de tripleta es denominada “generalized RDF triple”.
Todos los documentos normativos de estas tecnologías y otros documentos informativos para el seguimiento de su evolución pueden consultarse en:
Unión Europea. Directiva 2003/98/CE del Parlamento Europeo y del Consejo, de 17 de noviembre de 2003, relativa a la reutilización de la información del sector público.
España. Ley 37/2007, de 16 de noviembre, sobre reutilización de la información del sector público.
Unión Europea. Directiva 2013/37/UE del Parlamento Europeo y del Consejo de 26 de junio de 2013 por la que se modifica la Directiva 2003/98/CE relativa a la reutilización de la información del sector público.
España. Congreso de los Diputados. “Proyecto de Ley por la que se modifica la Ley 37/2007, de 16 de noviembre, sobre reutilización de la información del sector público”.
La versión actualmente vigente de SPARQL es 1.1. La especificación de este lenguaje y otros documentos informativos, pueden ser consultados en:
Es el resultado de la confluencia de Datos Abiertos (interoperabilidad legal) y Datos Enlazados (interoperabilidad técnica).
Library Linked Data Incubator Group (
Una extensión de Alfresco.
No se pudo averiguar por la consulta directa del repositorio ni la organización respondió al correo que enviamos solicitando esta información.
Kim, H. H. (