4. Web Semántica

En el año 2001, Tim Berners-Lee, James Hendler y Ora Lassila publicaron un artículo [9] en la revista Scientific American, en el cual presentaban las bases de la Web Semántica. En los capítulos anteriores de esta guía hemos visto cómo la Web de Documentos evolucionó hacia una Web Programable, y la creciente oferta de aplicaciones que ejecutan tareas de manipulación de datos publicados en los más diversos formatos en este ecosistema de datos que es la Web. La idea de agregarles una semántica a esos datos apunta a facilitar la comprensión e interoperabilidad de los datos en semejante universo de información heterogénea, publicado en una diversidad de formatos y con diferentes protocolos de acceso.

Los bloques básicos que definen a la Web Semántica son los siguientes:

• un modelo de datos estándar;

• un conjunto de vocabularios de referencia;

• un protocolo estándar de consulta.

La Web Semántica procura facilitar el proceso de comunicación entre los diversos participantes del ecosistema, de manera tal de crear un modelo mental común, minimizando la posibilidad de existencia de ambigüedades, facilitando así el trabajo necesario para el desarrollo de aplicaciones que hagan uso de las diversas fuentes de datos.

Las siguientes secciones tienen por fin presentar un panorama general de las diferentes tecnologías utilizadas en el ámbito de la Web Semántica, sus características en términos de conceptos y el papel de cada una de ellas en el ecosistema de datos publicados en la Web. El objetivo de estas secciones no es el de adentrarse en el detalle de cada una de esas tecnologías, que poseen especificaciones bien definidas y una serie de materiales que las describen de una manera bien formal (todas ellas referenciadas con links en la presente guía).

4.1 RDF

La Web, que originalmente fue diseñada para el consumo por parte de usuarios humanos, provee una infraestructura simple y universal para el intercambio de diversos tipos de información. No obstante ello, existe una gran dificultad para que las aplicaciones procesen los datos incluidos en los documentos sin que les sea agregada una información específica, codificada en un formato adecuado. La solución propuesta es la de utilizar metadatos para describir datos publicados en la Web, que sean útiles para localizar y procesar informaciones, ofreciendo descripciones acerca de la estructura, el contenido y otras informaciones relacionadas (licencia de uso, derechos de propiedad intelectual, origen, etc.). Para ello es necesario contar con una base para procesar los metadatos, de manera tal de permitir la interoperabilidad de esas descripciones entre diferentes aplicaciones, respaldadas en estándares sobre la sintaxis y la semántica de los metadatos, además de un conjunto de vocabularios comunes y modos de acceso estandarizados.

1. Modelo de Datos

El Resources Description Framework (RDF) [10] ies una estructura para representar informaciones en la Web. El RDF permite realizar afirmaciones sobre recursos. Cualquier cosa puede ser denominada recurso, tanto cosas concretas como abstractas. Una empresa determinada, una persona, una página Web, constituyen recursos. Un sentimiento, o un color, también son considerados recursos.

El formato de las afirmaciones (statements) es simple. Una afirmación consta de tres elementos (una tripleta), y se atiene a la siguiente estructura: <sujeto> <predicado> <objeto>. Una afirmación RDF expresa una relación entre dos recursos. El sujeto y el objeto representan a esos dos recursos, relacionándolos; el predicado representa la naturaleza de esta relación formulada de manera direccional (del sujeto al objeto), y es llamada en RDF "propiedad". Un objeto puede ser también un literal, definiendo una propiedad para un recurso.

Como forma de ilustrar la idea de la definición de los datos mediante un conjunto de tripletas, vamos a apelar al uso de un modelo de datos conocido: el modelo relacional y su conjunto de tablas relacionadas [11]. Consideremos una tabla en la que se expone información sobre libros (figura 4.1). Cada línea de la tabla incluye informaciones sobre un determinado libro (figura 4.2). Cada uno de esos libros constituye un recurso. Cada columna de la tabla define un tipo de propiedad relacionada a los libros (figura 4.3). Cada célula de la tabla define una tripleta (figura 4.4).

La tabla contiene informaciones sobre recursos del tipo libro:

Las líneas representan los recursos:

Las columnas representan las propiedades de los recursos:

Cada célula de la tabla define una propiedad (columna) de un recurso (línea):

Una tripleta puede ser representada como una especie de grafo dirigido (un grafo RDF) del sujeto hacia el objeto:

Generalizando, tenemos que:

La figura 4.8 presenta el grafo de las tripletas correspondientes a tres propiedades de un mismo recurso de la tabla de la figura 4.7:

En el caso de las tripletas de la tabla de arriba, todas ellas poseen un valor literal. Pero un recurso también puede establecer una relación con otro recurso, lo cual, en un esquema de tablas relacionales, sería representado por otra tabla, y el uso de claves foráneas. En nuestro ejemplo, podríamos tener una tabla de editoriales (publicadoras) (figura 4.9).

La figura 4.10 presenta el grafo RDF considerando la relación de un libro con su editorial.

Figure 4.11 La figura 4.11 presenta el grafo RDF considerando dos libros del mismo publicador.

2. URIs

Para completar este modelo de datos, necesitamos contar con un modo de identificar cada uno de los recursos y cada una de sus propiedades, de manera única y universal, con el fin de establecer una semántica global, no apenas particular, algo que sea comprendido más allá del ámbito de una empresa u organización. El creador de una tabla dentro de una determinada organización le atribuye nombres a las propiedades de manera particular, como por ejemplo, la propiedad "título". Se la podría haber definido como "title", "nombre de la obra", "ttl", etc. En principio, cada organización sabría entender el significado de la propiedad a partir de algún documento interno de la empresa, normas de nomenclatura, uso y costumbre dentro de la empresa, etc. Aún así, sabemos que muchas veces eso no sucede, pudiendo existir ambigüedad en los significados. De la misma forma, si consideramos a cada uno de los recursos, con frecuencia ellos son identificados a través de identificadores únicos, claves primarias, pero su alcance incluye sólo a la tabla en la cual están insertos. Un mismo id, por ejemplo "1243", puede ser utilizado para identificar a una editorial en una tabla, y en una librería en otra tabla. No se trata de identificadores únicos, en términos universales, sino identificadores individuales dentro de tablas de un banco de datos determinado. E inclusive cuando, eventualmente, sean únicos en diversas tablas de una organización, se los debe considerar como el único recurso definido por cualquier entidad, y no exclusivamente en el ámbito de una determinada empresa.

En RDF, la manera de identificar tanto a los recursos como a las propiedades de forma única y universal, se realiza a través de la utilización de URIs, más específicamente, de HTTP URIs [12]. Las URIs son una forma más abarcadora de URL, dado que no están necesariamente vinculadas a la localización del recurso. Tienen el mismo formato que una URL, pero se las utiliza con el objeto de identificar cosas, en tanto que una URL identifica apenas una dirección para recuperar una información o un documento. Una persona, por ejemplo, puede ser identificada a través de una URI (figura 4.12).

Para contar con una semántica más conocida de las propiedades, podemos utilizar vocabularios de referencia para la definición de propiedades de dominios específicos. Veremos algunos de esos vocabularios en el capítulo 6. Como ejemplo, podemos citar la propiedad "name", que normalmente es definida a partir de una propiedad del vocabulario FOAF [13], utilizado para la definición de propiedades referentes a personas. La URI “http://xmlns.com/foaf/0.1/name” identifica la propiedad "nombre" (figura 4.13).

Una cuestión muy importante respecto a la publicación de datos está relacionada al esquema de identificación de los recursos, el esquema de URIs. Se trata de una discusión en curso en el ámbito de los investigadores y publicadores de datos en la Web Semántica. Existen diversos artículos que ofrecen orientaciones sobre los esquemas apropiados para la definición de URIs. Algunos defienden que la identificación de una URI debe ser completamente opaca, es decir, que no debe existir ninguna información en la URI que pueda ser interpretada en relación al recurso que ella identifica, algo semejante a una clave numérica primaria de una tabla relacional. En el ejemplo de persona de la figura 4.7, observamos de alguna forma esa idea. Otros defienden que ciertos esquemas pueden identificar algunas informaciones en las URIs, con el fin de permitir que un usuario pueda intuir otra URI relacionada sin que sea necesario recurrir a otras formas de búsqueda. Por ejemplo, una URI con información sobre el presupuesto federal puede incluir en su formación el año correspondiente a la información que se pretende: http://orcamento.datos.gov.br/doc/2013/ItemDespesa”. En caso de que el usuario desee acceder a la información correspondiente a otro año, le será suficiente con substituir el año en la URI.

Otra precaución importante a observarse cuando se define un esquema de denominación de URIs es garantizar que ese esquema tienda a persistir, o por lo menos, que tenga la máxima duración posible. En el caso de que alguna URI se vuelva obsoleta, debe estar contemplado el modo de informar del hecho y sobre cómo sería posible recuperar la información al usuario. En algunas ocasiones, la información estará disponible en otra ubicación identificada por otra URI. Existen diversos esquemas que buscan garantizar la persistencia de las URIs, entre ellos, el DOI System [14] y el PersId Initiative [15].

Esa discusión es muy amplia y no está ente los objetivos de la presente guía extenderse en el asunto. En caso de que el lector necesite más información, los siguientes artículos, entre otros, cuentas con datos importantes para tomar decisiones sobre esquemas de definición de URIs: Cool URIs for the Semantic Web ” [16], “Cool URIs don't change ” [17].

3. Serializaciones

El RDF es un modelo de datos abstracto, no resultando importante cómo se lo represente, siempre y cuando esta representación sea fiel a sus propiedades abstractas. Existen diversas representaciones sintácticas para el modelo RDF, algunas de ellas más adecuadas para el procesamiento por computador, y otras más comprensibles para las personas.

Entre las notaciones más utilizadas podemos citar RDF/XML [18], Turtle [19], N-Triples [20] y el JSON-LD [21]. La primera notación utilizada fue el RDF/XML, estandarizada por el W3C, y su uso inicial presentaba como ventaja el hecho de que los lenguajes de programación tuvieren más soporte para XML. Además de eso, también es posible hacer uso de namespaces XML para evitar el uso de URIs completas, lo cual permitía que las mismas fueran menos extensas. Sin embargo, la lectura de la codificación en RDF/XML es bastante difícil para los usuarios humanos.

En esta sección, como modo de ilustrar las serializaciones, presentaremos una descripción general de la notación Turtle (Terse RDF Triple Language), una de las de comprensión más simple para las personas. Entenderla facilita comprender en general la idea de las serializaciones. Los detalles de la sintaxis en cada una de las notaciones están descriptos en las referencias de cada una de las especificaciones. Para comprender las otras notaciones alcanza con entender la sintaxis específica de cada una, pues los conceptos abstractos de todas ellas son los mismos: los del modelo de datos RDF. Además, también se presentará una descripción general de JSON-LD, que ha gozado de amplia aceptación por parte de la comunidad de desarrolladores de software.

En el ejemplo de Turtle, será utilizado el grafo RDF de la figura 4.8. Además del vocabulario FOAF, citado anteriormente, utilizaremos tres propiedades del vocabulario Dublin Core vocabulary [22] para identificar el ISBN (International Standard Book Number), al creador de la obra, y para relacionar la obra con la editorial.

La sintaxis de Turtle está conformada por sentencias con los tres elementos que definen una afirmación en RDF. Esas sentencias deben finalizar con el signo ".". La figura 4.14 muestra las cuatro tripletas de la obra "Gabriela, Clavo y Canela", representadas en Turtle.

Como manera de hacer menos extensa la descripción en Turtle, es posible agrupar definiciones de múltiples propiedades de un mismo recurso informando la URI del recurso una única vez y utilizando un signo ";" entre las diferentes definiciones de propiedades (figura 4.15).

Como modo de hacer aún más legible la definición de las tripletas, es posible definir un conjunto de prefijos, que se corresponden con los namespaces de los vocabularios utilizados (figura 4.16).

La figura 4.17 presenta la serialización en Turtle del grafo de la figura 4.11.

Una serialización de RDF que ha tenido un creciente uso en la Web Semántica es JSON-LD (Javascript Object Notation for Linked Data), un formato de serialización de tripletas RDF que tiene como objetivo constituir un modo de representación más legible para las personas, utilizando el modelo JSON de conjuntos de pares atributo-valor para representar al conjunto de tripletas.

Uno de los elementos centrales de JSON-LD es la idea de contexto. Cuando dos personas se comunican en un ámbito compartido, existe un contexto de conocimiento mutuo que permite que los individuos utilicen términos abreviados, un vocabulario propio para comunicarse más rápidamente y sin perder significación. Un contexto en JSON-LD funciona de la misma manera. JSON-LD permite que dos aplicaciones utilicen términos abreviados, particulares, para comunicarse entre sí con mayor eficiencia y sin perder precisión. Esa fue una necesidad percibida por los desarrolladores de la especificación de JSON-LD (una recomendación del W3C), derivada de la dificultad de entendimiento de las largas URIs que representan los recursos RDF. De cierta forma, se trata del retorno a un vocabulario más simplificado, más particular, compartido por una comunidad con dominio de las aplicaciones.

Las figuras 4.18 a 4.21 ilustran el pasaje de una representación de tres pares de atributo-valor en JSON, sin una referencia universal, a la especificación de un código JSON-LD, en la cual los mismos tres pares tienen asociados a ellos un contexto que define la semántica universal de los términos.

La figura 4.18 presenta tres propiedades de una persona, en formato JSON:

• “name” – nombre (literal)

• “homepage” – página personal (URL)

• “image” – imagen (URL)

La figura 4.19 substituye los términos (del vocabulario particular de la comunidad) por las URIs de las propiedades de los vocabularios de referencia. Por ejemplo, "name" es substituido por la URI “http://schema.org/name”. Además, se informa si el valor de la propiedad del atributo constituye otro recurso (@id). La introducción de las URIs hace que el texto sea de lectura más dificultosa.

La figura 4.20 presenta la definición de un contexto en el cual los nombres abreviados de la figura 4.18 están asociados a las URIs en la figura 4.19. La asociación de las abreviaturas con las definiciones semánticas universales (contexto) queda separada de las definiciones de los pares de atributo-valor. Eso permite que las abreviaciones vuelvan a ser utilizadas. El contexto funciona como un mapeo entre el vocabulario particular y el vocabulario de referencia.

Los contextos pueden definirse en forma conjunta con los pares atributo-valor, o pueden ser referenciados por URIs. De esa manera, un determinado contexto conocido por una comunidad puede informarse al comienzo de la definición de los datos, y puede utilizarse el vocabulario abreviado. El contexto de la figura 4.20 podría ser considerado como el contexto de la definición de una persona. La figura 4.21 ilustra de qué modo el código utilizaría las abreviaturas, incluyendo una referencia a un contexto definido de manera externa.

4.2 RDFS

El modelo de datos RDF ofrece un modo de hacer afirmaciones sobre recursos, pero no hace suposiciones sobre la semántica de los recursos identificados por las URIs. No existe ningún constructor en RDF que especifique que un recurso sea una propiedad, es decir, un libro, una persona, etc. En la práctica, el RDF es habitualmente utilizado en combinación con vocabularios que proveen informaciones semánticas sobre tales recursos.

El Resource Description Framework Schema (RDFS) [23] es un vocabulario que extiende RDF e introduce una capa que especifica algunas características que le agregan semántica a datos definidos en RDF. El RDFS cuenta con constructores que permiten, por ejemplo, especificar que determinadas URIs indican propiedades de recursos, o que determinados recursos identificados por URIs pertenecen a una determinada clase. Utilizando el ejemplo de la figura 4.13, a través del RDFS es posible especificar que el recurso identificado por la URI “http://xmlns.com/foaf/0.1/name” es una propiedad; o que el recurso identificado por la URI “http://example.org/#gabriela-clavo-canela” pertenece a la clase "Libro".

El RDFS utiliza la noción de clase para especificar categorías que pueden utilizarse para clasificar recursos. La relación entre una instancia y su clase está indicada por la propiedad "type" de RDF. Con RDFS pueden crearse jerarquías de clases y subclases, y jerarquías de propiedades y subpropiedades. Las restricciones de tipos pueden definirse sobre los sujetos y los objetos de las tripletas, a través de la especificación de dominios y contradominios para cada uno de los tipos. En el ejemplo anterior de los libros, podríamos declarar que el dominio de la relación "tiene_editorial" es del tipo "Libro", y que el contradominio es del tipo "Editorial".

Es sumamente importante resaltar que la idea de tipos, dominios y contradominios de una propiedad son diferentes a aquellos del modelo orientado a objetos (OO). En el modelo OO, una clase abstrae las propiedades y los métodos de un determinado conjunto de instancias. Si un objeto es declarado como perteneciente a un determinado tipo (una clase), se asume que posee un conjunto de propiedades que están asociadas a dicho tipo. En el caso del RDFS, la declaración de una propiedad no restringe su uso por parte de ningún recurso, cualquiera sea su tipo. La declaración de propiedades está expresada de manera separada e independiente de las declaraciones de clases. La declaración de un dominio y de un contradominio permite solamente que pueda hacerse una inferencia del posible tipo de un recurso, aunque ese tipo no esté declarado explícitamente a través de una tripleta. En el día a día, los humanos hacen eso constantemente. A partir de ciertas propiedades observadas en los objetos, personas, etc., los humanos infieren los tipos a los cuales esos recursos pueden pertenecer. Se trata de un modo habitual de inferencia en los seres humanos.

Volviendo al RDFS, en el ejemplo de los libros, supongamos que sean declaradas las clases "Libro" y "Editorial", y que el dominio de la relación "tiene_editorial" es de recursos de la clase "Libro", y que el contradominio es de recursos de la clase "Editorial". Aunque no se declare una tripleta en la cual se afirme explícitamente que el recurso “http://example.org/#gabriela-clavo-canela” pertenece a la clase “Libro” y que el recurso “http://example.org/#companhia-das-letras” pertenece a la clase "Editorial", si fuese declarada la existencia de una relación "tiene_editorial" entre esos dos recursos, las clases de los recursos habrán de ser inferidas por la declaración del dominio y del contradominio de la propiedad. De esa forma, es posible concluir sobre más tripletas que aquellas efectivamente declaradas.

La inferencia es una de las características introducidas por el uso de las tecnologías de la Web Semántica. Estas inferencias permiten hacer declaraciones de las informaciones de tamaño más reducido. Por ejemplo, en un conjunto de tripletas sobre personas, no es necesario declarar explícitamente las tripletas con las relaciones del tipo "tío", que pueden sí inferirse a partir de otras relaciones. El RDFS introduce unos pocos tipos de inferencia, expandidas con mayor amplitud con el uso de OWL, como será mostrado en la sección 4.3.

Otro tipo de inferencias introducido por el RDFS es el relativo a la declaración de subclases y de subpropiedades. Si un determinado recurso des del tipo de una determinada subclase, será inferido que dicho recurso también pertenece al tipo de la clase correspondiente. Lo mismo ocurre en relación a las subpropiedades.

La figura 4.22 ilustra la introducción de algunos constructores de RDFS en el ejemplo de la figura 4.17. Para la definición de la clase "Libro, utilizamos la ontología bibo ontology [24] relativa a la definición de informaciones bibliográficas. La palabra clave "a" es una abreviatura para el predicado "rdf:type", que indica la clase de un recurso.

4.3 OWL

RDF especifica un modelo de datos que representa informaciones mediante un conjunto de tripletas que definen propiedades de recursos, así como la relación entre esos diferentes recursos. RDFS expande el RDF, haciendo posible la definición de jerarquías de clases, jerarquías de propiedades y la definición de dominios y contradominios para las propiedades, permitiendo así un primer conjunto de restricciones sobre las tripletas definidas, además de inferencias de deducen tripletas no declaradas de manera explícita.

¿Cuál es el objeto de definir restricciones? Una de las formas de entender lo que es la semántica es la de pensar que lo que hace que diferentes personas puedan entender un mismo significado acerca de un contenido en particular es el hecho de restringir el número de distintas interpretaciones posibles respecto de ese contenido. Lo ideal sería que existiese sólo una potencial interpretación.

Ontology Web Language [25] es un lenguaje que extiende RDF y RDFS, ofreciendo un conjunto mucho más amplio de tipos de restricciones al conjunto de tripletas definidas. Además de ello, el lenguaje ofrece una serie de diversos constructores que permiten, entre otras posibilidades, la construcción de clases complejas a partir de otras definiciones de clases, y el encadenamiento de propiedades. Una de las principales bases del OWL es Description Logics (DLs) [26], una familia de lenguajes de representación de conocimiento ampliamente utilizados en el modelado de ontologías. Una ontología es la especificación de un concepto dentro de un determinado dominio de interés. Como su nombre lo sugiere, las DLs son lógicas y poseen una semántica formal: una especificación precisa de significado. Esta semántica formal permite que los seres humanos y los sistemas de computadores puedan intercambiar ontologías DL sin ambigüedad respecto de su significado, y también hace posible utilizar la deducción lógica para inferir informaciones adicionales de los hechos expuestos explícitamente en una ontología.

Las ontologías ofrecen recursos para dar forma a las relaciones entre las entidades en un dominio de interés. En OWL existen tres tipos de entidades:

• Instancias – representan los recursos (también se las llama "individuos").

• Clases – definen conjuntos de instancias, de individuos.

• Propiedades – representan relaciones binarias entre dos instancias (object property) o entre una instancia y un literal (datatype property).

Una ontología especificada en OWL consiste en un conjunto de afirmaciones (axiomas), separadas en tres grupos: Tbox (Terminological), Abox (Assertion) y Rbox (Role).

Tbox describe relaciones entre clases. Por ejemplo, la afirmación de que la clase "Person" es equivalente a la clase "Human" significa que ambas clases poseen el mismo conjunto de individuos. Abox captura conocimiento sobre los individuos, es decir, las clases a las cuales ellos pertenecen o cómo ellos se relacionan entre sí. Por ejemplo, podemos hacer una afirmación de que el individuo "Mary" pertenece a la clase "Person"; es decir, que "Mary" es una instancia de la clase "Person". Si uniésemos esto con el ejemplo de Tbox, en el que la clase "Person" está definida como equivalente a la clase "Human", puede inferirse que "Mary" también es una instancia de la clase "Human":

En Tbox también pueden definirse relaciones entre los individuos. Por ejemplo, podemos definir que "Mary" es la esposa de "John":

El Rbox contiene las afirmaciones sobre las propiedades, es decir, las metapropiedades, como por ejemplo, transitividad, simetría, etc. Estas afirmaciones nos pueden permitir realizar inferencias sobre la base de tripletas definidas de manera explícita:

Los ítems a continuación ofrecen un resumen de los diversos constructores incluidos en el lenguaje OWL:

• Classes are defined in RDFS through the RDF property type:

• Las clases son definidas en RDFS mediante propiedades "type" de RDF:

• La clase de una determinada instancia puede declararse en forma explícita, o inferirse, como por ejemplo, a partir de la definición de subclases o de dominio y contradominio:

• Es posible definir que dos nombres de individuos representan al mismo individuo; es decir, el grafo RDF del recurso será la sumatoria de las afirmaciones sobre cada uno de los individuos:

• Las clases equivalentes poseen el mismo conjunto de instancias:

• Las clases disjuntas indican que una instancia que pertenezca a una de ellas no puede pertenecer también a la otra:

• Una propiedad puede tener un valor literal (datatype property) o establecer una relación entre dos instancias (object property):

• Las clases complejas pueden construirse a partir de otras clases, a través de intersección, unión, complemento y enumeración:

• Las propiedades pueden tener una cardinalidad, que indica el número (máximo, mínimo o exacto) de triplas:

• Las propiedades pueden ser inversas:

• Las propiedades pueden ser simétricas (la inversión de la propiedad es la misma propiedad; por ejemplo: cónyuge):

• Las propiedades pueden ser asimétricas (la propiedad inversa no puede constituirse en la misma propiedad; por ejemplo, una persona no puede ser hija de su propio hijo):

• Las propiedades pueden definirse como encadenamientos de otras propiedades (ejemplo: el abuelo es el padre del padre):

• Las propiedades pueden ser reflexivas (una persona es pariente de sí misma):

• Las propiedades pueden ser funcionales (sólo existe un elemento en el contradominio para un elemento del dominio; por ejemplo, madre):

• Las propiedades pueden ser inversamente funcionales (sólo existe un elemento en el dominio para un elemento del contradominio; por ejemplo, hijo):

• Properties can be inversely functional (there is only one element in the domain for an element from the codomain, for example, children):

4.4 SPARQL

Los dados son representados en la Web Semántica utilizando el modelo de datos conceptual de RDF, en conjunto con las extensiones de RDFS y OWL, Dichos datos pueden estar almacenados, por ejemplo, en un banco de datos de tripletas (triple store), un banco de datos relacional con un esquema de mapeo para RDF, etc.

SPARQL (SPARQL Protocol and Query Language) [27] es el lenguaje de consulta de la Web Semántica. Podemos hacer aquí una analogía entre SPARQL y el lenguaje SQL de consulta de bancos de datos relacionales, considerando que SPARQL posee una sintaxis adecuada para realizar consultas de datos representados como conjuntos de tripletas RDF.

Por ejemplo, consideremos un banco de tripletas con el siguiente contenido:

La consulta

devolvería:

Las variables SPARQL comienzan con un carácter "?" y pueden ser definidas en cualquiera de las tres posiciones de una tripleta (sujeto, predicado, objeto) en el conjunto de datos RDF. Los estándares de tripletas de la cláusula SELECT tienen la misma forma que las tripletas normales, excepto que cualquiera de las tres partes de la tripleta puede ser substituida por una variable. La cláusula SELECT devuelve una tabla de variables con los valores que satisfacen la consulta.

En otro ejemplo, consideremos un banco de tripletas con el siguiente contenido:

La consulta:

devolvería:

SPARQL admite una serie de filtros y operadores que permiten hacer consultas complejas al conjunto de tripletas almacenadas. Diversos bancos de datos de tripletas ofrecen puntos de acceso por vía Web (URLs), que aceptan el protocolo SPARQL y su lenguaje de consulta. Esos puntos de acceso reciben el nombre de SPARQL endpoints. Un SPARQL endpoint acepta consultas y devuelve los resultados vía HTTP. Los endpoints genéricos ejecutan consultas sobre cualquier dato RDF con acceso posible por vía Web (especificado como parámetro). Los endpoints específicos ejecutan consultas solamente en conjuntos de datos particulares, determinados por la aplicación. Las listas de algunos SPARQL endpoints existentes en la Web están agrupadas en SPARQLES [28], W3C SPARQL endpoints [29] and Mondeca [30]. Openlink [31], ofrece un endpoint genérico, a través del cual es posible realizar consultas a partir de la especificación de la localización del grafo RDF que contiene el conjunto de tripletas a ser consultado.

La cláusula SELECT acepta que sea especificado el grafo RDF que habrá de ser consultado, a través de la utilización de la palacra clave FROM. En el ejemplo siguiente (figuras 4.23 y 4.24), son devueltas las homepages de las personas conocidas (“foaf:knows”) por Tim Berners-Lee, en el grafo RDF localizado en http://dig.csail.mit.edu/2008/webdav/timbl/foaf.rdf.

Las consultas SPARQL no devuelven conjuntos de tripletas. El resultado es un conjunto de tuplas (similares a líneas de una tabla), que puede retornar en diferentes formatos, como HTML, XML, JSON, CSV, etc. Ese formato es especificado como uno de los parámetros de la consulta. La figura 4.25 presenta el resultado en JSON de la consulta anterior:

Además del comando SELECT, SPARQL acepta los comandos DESCRIBE, CONSTRUCT y ASK. El comando DESCRIBE devuelve un grafo RDF simple, conteniendo los datos RDF sobre los recursos especificados en el comando. Los datos devueltos son determinados por el procesador de la consulta SPARQL, y no por el cliente que realiza la consulta. Pueden devolverse tripletas en las cuales el recurso aparece como sujeto, predicado u objeto; tripletas en las cuales el recurso aparece como sujeto u objeto, o bien tripletas en las que el recurso aparece solamente como sujeto.

El acceso a las tripletas de un recurso también puede realizarse a través de una desreferenciación (a partir de la definición de una URI), que es uno de los principios de Datos Conectados en la Web (sección 5.1). El resultado de una desreferenciación, así como el resultado de un comando DESCRIBE, devuelve un conjunto de tripletas de recursos. El portal DBpedia contiene tripletas extraídas de las cajas de información de artículos de la Wikipedia. La desreferenciación de la URI de la DBpedia que identifica Tim Berners-Lee puede ser observada en http://dbpedia.org/page/Tim_Berners-Lee [32]. Esa página es devuelta por defecto en HTML, pero es posible obtener el resultado en otros formatos, como por ejemplo en JSON [33].

La figura 4.26 presenta un ejemplo del comando DESCRIBE en una consulta al endpoint de la DBpedia [34]. FigurLa figura 4.27 expresa parte de los resultados. Puede observarse que se listan tripletas en las cuales el recurso (“:Tim_Berners-Lee”) aparece como sujeto y como objeto.

De manera análoga a SQL, existe la posibilidad de manipular el conjunto de datos devuelto por una consulta SPARQL:

• LIMIT – limita el número de líneas.

• DISTINCT – excluye las líneas duplicadas.

• ORDER – ordena el resultado.

• OFFSET – permite efectuar paginación.

• FILTER – aplica filtros sobre los valores buscados en las propiedades.

SPARQL ofrece también una serie de funciones preconstruidas, utilizadas en la especificación de las consultas, que incluyen operadores lógicos (“!”, “&&”, “||” ), operadores matemáticos (“+”, “-”, “*”, “/”), operadores comparativos (“=,” “>”, “<”, ...), operadores de testeo (“isLiteral”, isURI”, ...), funciones de manipulación de cadenas de caracteres (“STRLEN”, “SUBSTR”, “UCASE”, “CONCAT”, ...), etc.

CONSTRUCT es un comando del lenguaje SPARQL que permite que, a partir de un resultado de búsqueda, pueda construirse un conjunto de tripletas. La figura 4.28 presenta un ejemplo del comando CONSTRUCT en una consulta al endpoint de la DBpedia. La figura 4.29 expone los resultados.

Además de la especificación del lenguaje de consulta en sí, existen otros diferentes estándares relacionados al SPARQL, definidos por el W3C, que especifican, por ejemplo, un lenguaje para la manipulación y actualización de grafos RDF SPARQL 1.1 Update [35]), consultas federadas a diversos grafos RDF SPARQL 1.1 Federated Query [36]), etc.

4.5 Metadatos Embutidos en Páginas

En las secciones anteriores, presentamos el modelo de datos conceptual del RDF, con su conjunto de tripletas de recursos identificados por URIs, además de la explicación de extensiones mediante RDFS y OWL, que permiten la construcción de ontologías más complejas, con un mayor número de restricciones y posibilidades de inferencia. Presentamos también el lenguaje SPARQL para la consulta a grafos RDF.

Dichas tecnologías están más orientadas a los grafos almacenados en los servidores Web. Existe, sin embargo, un universo de datos semánticamente descriptos, ubicados en diferentes páginas Web, que contienen una mezcla del contenido a ser consumido por las personas y el que puede ser consumido por las aplicaciones. Existe una creciente inclusión de datos semánticos en dichas páginas, efectuado por parte de desarrolladores de portales, interesados en satisfacer las demandas de las aplicaciones. La inclusión de datos semánticos en un portal de ventas, por ejemplo, puede ayudar al motor de búsqueda de Google a exponer, de una manera más precisa y objetiva, los resultados de la búsqueda de un producto determinado.

La sección 2.5 sobre metadatos, expuso la forma inicial de la introducción de éstos en una página Web, a través del tag de HTML. Estos metadatos están relacionados con la página Web, como un todo. Pueden, por ejemplo, ofrecer informaciones sobre el autor de la página, palabras clave, descripción, fecha de publicación, etc. En las siguientes secciones, presentamos tres formatos utilizados para la inclusión de metadatos en páginas Web, que pueden ser aplicados también a la descripción individual de los datos incluidos en las páginas.

El objetivo de aquellas secciones es el de describir, de manera resumida, esas tres técnicas de embutido de datos en páginas Web. Lo importante e comprender que esa es una de las formas de definir metadatos para la construcción de una Web de Datos más semántica, complementaria a lo que fuera presentado en las secciones anteriores.

4.5.1 Microformato

Microformato [37] fue la primera iniciativa realizada con el objeto de agregar informaciones extra al código HTML, de manera tal de que fuese posible incluir tipos específicos de datos (entidades), como por ejemplo, personas, productos, eventos, etc. Cada uno de esos tipos posee un conjunto particular de propiedades y una sintaxis específica. Por ejemplo, una persona puede tener las propiedades: nombre, dirección, empresa, cargo, e-mail, etc.

La interpretación de un código HTML para efectos de exhibición de datos al usuario, ignora cualquier tag desconocido de la especificación HTML. En general, los microformatos utilizan los atributos de clase en tags HTML (con frecuencia, <span> o <div>) para atribuir nombres a entidades y sus propiedades.

El ejemplo de las figuras 4.30 y 4.31 ilustra el modo en que pueden mezclarse informaciones que habrán de ser filtradas por el navegador para la exhibición de la página e informaciones que serán filtradas por las aplicaciones para la comprensión del contenido.

A continuación, se listan algunas de las propiedades que pueden ser definidas para una entidad del tipo persona:

• fn – nombre completo, obligatorio

• n – nombre estructurado:

• given-name – primer nombre

• additional-name – segundo nombre

• family-name – apellido

• title – cargo

• org – compañía, organización

• photo – foto, ícono, avatar

• email – e-mail

• tel – teléfono

• adr – dirección estructurada:

• street-address – calle

• locality – ciudad

• region – estado

• postal-code – código postal

• country-name – país

Cada microformato específico posee un conjunto particular de propiedades (vocabulario). Los microformatos son fáciles de utilizar, debido a su simplicidad, pero ofrecen escasa capacidad de extensión, no contando con una forma estándar de representación para los vocabularios. Además de ello, sólo es posible especificar metadatos para un pequeño conjunto de tipos de datos. Microformats2 [38] busca marcar una evolución en el concepto de microformatos, y crear una sintaxis común independiente de vocabularios, y una estandarización mayor en la nomenclatura de las entidades y de las propiedades.

4.5.2 RDFa

Al igual que los microdatos, RDFa [39] permite que los metadatos sean embutidos en páginas Web, pero utiliza una sintaxis más genérica para especificar las tripletas RDF, independientemente del tipo de datos al cual pertenece el recurso y del vocabulario utilizado. Las informaciones de las tripletas están especificadas en forma de atributos dentro de los tags del HTML:

• vocab – URI del vocabulario (namespace)

• about, src, href y resource – URI del recurso

• typeof – tipo del recurso

• rel – relación con otro recurso

• rev – relación inversa con otro recurso

• property – nombre de la propiedad (el valor de la propiedad es el texto que aparece entre los tags con los cuales se define el atributo)

• content – substituye el valor de la propiedad que aparece entre los tags con los cuales se define el atributo

• datatype – tipo del dato de la propiedad

Como modo de ilustrar algunos de esos atributos, se presentarán dos ejemplos (con sus respectivas figuras) extraídos de la especificación RDFa specification [40] del W3C. En la figura 4.32 se definen tripletas referentes a ambos recursos. Las figuras 4.33 y 4.34 presentan los grafos RDF de dichas tripletas y ayudan a entender la forma en la que ellas están definidas mediante el RDFa embutido en el código HTML.

El ejemplo de la figura 4.35 demuestra el uso del atributo "rel", que define una relación entre dos recursos; en este caso, la relación “foaf:knows” (alguien conocido por una determinada persona). En el ejemplo, los recursos que son objetos de estas tripletas son del tipo “foaf:Person”, y para cada uno de ellos se define un “foaf:name” y una “foaf:homepage”. Lo que el navegador le exhibirá al usuario serán los links a las homepages de Bob, Eve y Ana.

4.5.3 Microdatos

Los Microdatos [41] son una forma más reciente de embutir metadatos en páginas Web. Ha gozado de una utilización creciente, convirtiéndose en una de las formas preferidas de los motores de búsqueda, como Google. A pesar de poder utilizar cualquier vocabulario para la definición de sus recursos, los creadores de páginas que utilizan microdatos hacen mucho uso del conjunto de vocabularios definidos por la iniciativa Schema.org (sección 6.4).

Del mismo modo que en RDF, la sintaxis de los microdatos no depende de los tipos de datos de los recursos definidos, ni tampoco del vocabulario utilizado para su descripción. La forma de embutir las informaciones es también a través de la definición de atributos en los tags HTML. El modelo de microdatos consiste en grupos de pares nombre-valor, conocidos como ítems. Cada ítem puede tener un tipo, un identificador global y una lista de pares nombre-valor. Cada nombre del par nombre-valor es conocido como una propiedad, y cada propiedad tiene uno o más valores. Cada valor es un ítem o un literal. Los atributos básicos de los microdatos son:

• itemscope – define el recurso

• itemid – define una URI para el recurso

• itemtype – define el tipo del recurso (vocabulario)

• itemprop – define una propiedad del recurso

La figura 4.36 muestra un ejemplo de microdatos para una persona, utilizando el tipo de datos Person data type [42] de Schema.org, que posee una serie de propiedades definidas, como por ejemplo, "name", "image", "jobTitle", "telephone", "email", "colleague", entre otras; todas con una semántica bien definida. En el ejemplo, es simple percibir que la propiedad "address" puede ser una propiedad que apunta a otro recurso ("itemscope"), que tiene otro tipo de datos, "PostalAddress".

De el mismo modo que en RDF, el modelo de datos de microdatos, en sí, no cuenta con el mérito del significado de cada uno de los vocabularios. La sintaxis para su uso como metadato es única, independiente de vocabularios, y la elección y el uso adecuado de cada uno de ellos y de sus propiedades requieren de una consideración específica por parte del usuario.

La semántica agregada a los datos está materializada por la utilización de las sintaxis presentadas (RDF, RDFS, OWL, microformatos, RDFa, microdatos), junto con ontologías propias, desarrolladas para casos específicos, y los vocabularios de referencia, que se establecen por el uso y la costumbre. En el capítulo 6 se hace la presentación de ejemplos de algunos de los vocabularios más utilizados.