2. Web Semántica - Introducción
El concepto fue propuesto por Tim Berners-Lee, el 17 de mayo del
2001, con un artículo escrito junto a James Hendler y Ora Lassila
en Scientific American: “The Semantic Web: A New Form of Web
Content That Is Meaninguful to Computers Will Unleash a
Revolution of New Possibilities”
En él se planteaba la necesidad de disponer de una web más
inteligente, formada por documentos que fuesen fácilmente
procesables por programas informáticos capaces de actuar con
independencia de operadores humanos.
Se planteaba una red distribuida que no fuese legible o
procesablemente únicamente por personas: los datos deberían
estar expuestos para ser procesables por aplicaciones
informáticas de forma desatendida, sin intervención humana.
3. Web Semántica - Introducción
En su libro “Tejiendo la web”, Berners-Lee se refiere a la web
semántica como:
“una red de datos que pueden ser procesados directa o indirectamente
por las máquinas”.
El grupo W3C Semantic Web Activity que se encarga de su
evolución indica que:
“La Web Semántica ofrece un marco común que permite compartir y
reutilizar datos entre aplicaciones, empresas y entre distintas
comunidades”.
4. Web Semántica
Web Semántica vs. Web convencional
La web semántica se presenta como una extensión de la web
tradicional.
La principal diferencia está en que, si la web tradicional contiene
información destinada a personas, en la semántica se gestionan
contenidos dirigidos a programas informáticos y a agentes software
capaces de interpretarlos y deducir información, datos y conocimiento
a partir de ellos.
En la “web sintáctica”, la responsabilidad de interpretar la información
recae en las personas. En la Web Semántica, se pretende dotar de
esta misma capacidad a los programas informáticos.
La Web Semántica puede verse como una web para agentes
software, programas capaces de actuar de forma independiente
programados para identificar, capturar y procesar información según
unas reglas.
5. Web Semántica
Web Semántica vs. Web convencional
Berners-Lee citaba un ejemplo en el que un agente software busca
un fisioterapeuta en un radio de x millas en torno a un domicilio para
un tratamiento determinado.
Para que los agentes software puedan identificar y procesar la
información en la web, es necesario que ésta esté etiquetada o
marcada de forma normalizada.
Los datos deben estar etiquetados y diferenciados de forma explícita.
En este sentido, la falta de capacidad expresiva del lenguaje HTML
resultaba un obstáculo para el trabajo de los agentes software.
XML permite incorporar etiquetas que dan significado y estructuran la
información disponible en la web.
7. Web Semántica
Web Semántica vs. Web convencional
La idea de Breitman es similar a la de Yu (2011, p. 15), que define la
Web Semántica como:
“una colección de tecnologías y estándares que permiten a las
máquinas entender el significado (semántica) de la información en la
Web”.
Este autor también indica la relación entre la Web Semántica y los
datos enlazados o linked data.
La idea de datos enlazados fue propuesta por Tim Berners-Lee en el
documento Linked Data Principles publicado en 2006.
La aproximación de los datos enlazados tiene como objetivo dar
buenas prácticas sobre cómo se deben exponer y conectar conjuntos
de datos estructurados en la Web.
Los datos enlazados se publican utilizando las tecnologías y
estándares de la Web Semántica.
8. Web Semántica
Fundamentos - URI
Los URI permiten identificar de forma unívoca a los recursos de los
que se mantiene información, y a sus metadatos o propiedades.
Un URI es una cadena de caracteres que identifica un recurso en la
web.
Puede tratase tanto de un recurso físico, tangible, como de una
noción abstracta.
Los URI pueden confundirse con las URL (Uniform Resource Locator)
que identifican y permite acceder a documentos publicados en la
Web.
Pero no son conceptos equivalentes: las URL son un tipo particular de
URI que se utiliza para identificar a los documentos disponibles en la
web.
9. Web Semántica
Fundamentos - URI
La URL se corresponde con una ubicación física de un fichero.
Frente a esto, un URI no se corresponde con la ubicación de un
archivo en la red, sino que actúa como un identificador global que se
asigna a un objeto en el contexto de la Web.
Un URI no tiene por qué tratarse de un documento ni de un recurso
que exista físicamente.
Son ejemplos de URI:
http://www.sedic.es
http://www.sedic.es/curso/inicio.htm
http://www.sedic.es/curso/websemantica
http://www.sedic.es/curso/websemantica#modulo1.
10. Web Semántica
Fundamentos – RDF
RDF es el estándar más relevante para el intercambio e integración
de metadatos en la Web Semántica.
Se define como “un lenguaje para representar información sobre
recursos en la World Wide Web”.
Tiene un propósito general, es decir, es válido para la codificación e
intercambio de cualquier tipo de metadatos en cualquier ámbito de
aplicación.
Se puede afirmar que RDF es para la Web Semántica lo que HTML
es para la web convencional.
RDF es un estándar publicado por el W3C, y puede usarse para
representar información y conocimiento distribuido de forma que las
aplicaciones informáticas lo puedan utilizar y procesar de una forma
escalable.
11. Web Semántica
RDF – Modelo Abstracto
RDF establece un modelo para declarar metadatos sobre recursos.
En RDF, la asignación de valores a los metadatos para un recurso se
realiza en forma de declaraciones RDF (traducimos así el término
inglés “RDF statement”.
A estas declaraciones también se les llama tripletas (triples en inglés),
ya que constan de tres elementos: un sujeto, un predicado y un
objeto.
el sujeto corresponde al recurso para el que se proveen los
metadatos;
el predicado es una propiedad de dicho recurso (el elemento o
metadato);
el objeto es el valor asignado a esa propiedad o metadato..
12. Web Semántica
RDF – Modelo Abstracto
Un recurso sería cualquier cosa que puede describirse mediante
declaraciones RDF.
Por ejemplo, una declaración podría asignar el valor 2012 a la
propiedad fechaPublicacion de un recurso bibliográfico particular.
El recurso bibliográfico sería el sujeto, el metadato fechaPublicacion
el predicado, y el valor 2012 sería el objeto.
Cada declaración RDF asigna valor a un metadato o propiedad
particular para un único recurso.
Si se considera que sujetos y objetos representan o denotan a
recursos existentes, los predicados pueden verse como el nombre de
una relación que conecta a esos dos recursos.
13. Web Semántica
RDF – Modelo Abstracto
Para recoger los metadatos correspondientes a un recurso,
tendríamos varias tripletas o declaraciones RDF para ese mismo
recurso (una para cada metadato o propiedad).
Se dice que RDF facilita un medio para formalizar declaraciones
sobre los recursos.
Una de las características de RDF es el uso de URIref para hacer
referencia a los recursos (sujetos), a las propiedades (predicados), y
en ciertos casos a los valores que se asignan a éstas (objetos).
En el caso del sujeto de una declaración, éste siempre estará
identificado mediante un URIref. De esta forma se garantiza que el
recurso se identifica de forma única en el espacio global de la Web,
donde no pueden existir dos recursos o sujetos con el mismo URI.
14. Web Semántica
RDF – Modelo Abstracto
Sucede lo mismo con los predicados o propiedades: cada metadato
tendrá un URI único, no repetible, que lo identifica globalmente y lo
diferencia de los demás metadatos existentes..
En el caso de los objetos (es decir, de los valores que se asignan a
los metadatos), caben dos posibilidades:
Su valor puede consistir en un literal o en un valor de tipo fecha,
cadena de caracteres, número, etc. Por ejemplo, en el caso de
una fecha de publicación o de un título.
Su valor puede consistir en el URIref de otro recurso existente. Por
ejemplo, si describimos un recurso bibliográfico (que sería el
sujeto), su propiedad (predicado) autor, podría ser un URIref de
otro recurso que corresponda a la persona que ha escrito ese
libro, y para la cual podríamos contar con metadatos y
declaraciones RDF adicionales.
15. Web Semántica
RDF – Modelo Abstracto
Nota: Cuando se dice que RDF es un lenguaje para codificar e
intercambiar metadatos en la web, puede pensarse erróneamente que
RDF es un sistema de metadatos similar a Dublin Core, EAD, MARC,
etc.
En Dublin Core se definen una serie de metadatos para describir
recursos, como title, creator, date, description, etc.
RDF no define metadatos concretos, sino que ofrece un método para
codificar cualquier tipo de metadatos (Dublin Core, MARC, o cualquier
otro), de forma normalizada.
Podríamos decir que RDF ofrece un “sobre” donde podríamos enviar
metadatos tomados de distintos sistemas de metadatos..
16. Web Semántica
RDF – Modelo Abstracto - Ejemplo
Para resumir el modelo abstracto de RDF, y los conceptos de
declaración, sujeto, predicado y objeto, incluimos el siguiente ejemplo:
Disponemos de un recurso en formato electrónico – concretamente un
módulo del curso sobre Web Semántica…
¿Cómo analizaríamos la información en tripletas?
17. Web Semántica
RDF – Modelo Abstracto - Resumen
Como resumen de este apartado recogemos una serie de reglas
propuestas por Yu (2011), en las que se basa RDF:
Regla #1: El conocimiento o la información se expresa mediante una lista
de declaraciones, y cada declaración tiene la forma Sujeto-Predicado-
Objeto, y este orden nunca debe cambiarse.
Regla #2: El nombre de un recurso debe ser global y debería identificarse
mediante un URI (Uniform Resource Identifier).
Regla #3: Es posible hacer cualquier declaración sobre cualquier recurso,
y i se elige un URI existente para identificar al recurso sobre el cual se
hace la declaración, entonces se cumplirá que:
• El recurso al cual nos referimos es el mismo que ya está siendo identificado por ese
mismo URI. Y
• Todo lo que se declare sobre ese recurso se considerará conocimiento o información
adicional sobre él.
18. Web Semántica
RDF – Representación gráfica
Por ejemplo, el siguiente grafo corresponde a dos declaraciones RDF:
20. Web Semántica
RDF – Representaciones alternativas
Los gráficos no son el único método disponible para representar
declaraciones RDF.
Otra aproximación se basa en el uso de texto plano (sin etiquetas
XML), donde cada declaración se representa en líneas aparte
terminadas con un punto.
Esta forma de escribir las declaraciones recibe el nombre de sintaxis
Turtle (Terse RDF Triple Laguage).
En cada declaración se diferencia el sujeto, el predicado y el objeto
mediante espacios en blanco. Los URI se escriben entre los signos
mayor que y menor que, y se puede precisar el tipo de dato de los
objetos:
<http://www.example.org/staffid#85740>
<http://www.example.org/terms#age>
"27"^^<http://www.w3.org/2001/XMLSchema#integer>.
21. Web Semántica
RDF – Representaciones XML
Las declaraciones RDF se pueden agrupar en un único documento
XML, que podrá tener la extensión .xml o .rdf.
Este documento tendrá un elemento raíz rdf:RDF.
Todo el contenido del documento RDF estará contenido entre las
etiquetas de inicio y de fin de este elemento raíz.
El elemento raíz rdf:RDF incluirá uno o más elementos
rdf:Description, normalmente uno para cada recurso del que se
recogen metadatos.
El elemento rdf:Description irá acompañado por un atributo @rdf:about que tomará
como valor el URI que identifica al recurso en cuestión.
Cada elemento rdf:Description contendrá un elemento hijo para cada predicado,
propiedad o metadato.
El nombre de estos elementos será un URI que identificará a cada propiedad, y se
tomará del sistema de metadatos que se esté aplicando.
23. Web Semántica
RDF – Representaciones XML
Otra característica de la serialización de declaraciones RDF en XML
es la forma de recoger los valores para los metadatos, o los objetos
en la terminología RDF.
Cuando el valor de una propiedad es un literal, éste se escribe entre las
etiquetas de inicio y de fin del elemento correspondiente a la propiedad o
predicado.
En estos casos, se podría añadir a la etiqueta de inicio de la propiedad un
o predicado un atributo @xml:lang para indicar el idioma del texto.
Cuando las propiedades toman como valor una referencia a otro recurso,
apuntando al URI o URIref que lo identifica, el elemento XML
correspondiente a la propiedad o predicado será un elemento vacío que
incluirá un atributo @rdf:resource.
El valor de este atributo será el URI del recurso que se le asigna como
valor. En el ejemplo anterior, sucede así con el valor para el metadato
mailbox.
27. Web Semántica
RDF – El elemento rdf:type
Se trata de un elemento que permite indicar el tipo de un recurso.
Se podria utilizar para diferenciar, por ejemplo, entre recursos de tipo
“articulo”, “monografía”, “patente”, o cualquier otro tipo que se precise
usar en cualquier tipo de aplicación.
La importancia de los tipos se describe en el apartado dedicado al
modelado con RDFS.
Inicialmente, es suficiente recordar que se dispone de la posibilidad
de indicar el tipo de los recursos para los que se codifican metadatos.
El uso del elemento rdf:type corresponde a una declaración RDF del
tipo:
Sujeto rdf:type Objeto:.
30. Web Semántica
RDF – El elemento rdf:type
Se dice que los recursos RDF que van acompañados por el elemento
rdf:type son “recursos con tipo” o “tipados”.
Si en lugar de asignar un literal como valor a rdf:type, le asignásemos
el URI de otro recurso, el fragmento y el gráfico equivalentes serían
estos:
34. RDFS - Introducción
RDF ofrece un marco general para codificar cualquier tipo de
metadato sobre cualquier tipo de recurso.
RDF es un lenguaje independiente de dominios de aplicación o
áreas de conocimiento específicas, que se puede utilizar para
codificar cualquier tipo de metadato.
Esta flexibilidad nos lleva a formular la pregunta:
¿qué declaraciones puedo utilizar en un documento RDF?
¿Qué propiedades o predicados puedo utilizar para los distintos tipos
de recursos que son el sujeto de mis declaraciones?
¿Qué valores puedo asignar como valores de cada propiedad?
35. RDFS - Introducción
RDFS permite crear esquemas para dar respuesta a estas preguntas.
Un esquema RDFS indicará:
a) los tipos o clases de entidades de los que se quiere recoger metadatos;
b) los metadatos o propiedades disponibles para cada tipo de recurso;
c) los valores que acepta cada propiedad, etc.
Se puede ver una similitud entre los esquemas RDFS y los modelos
de bases de datos tradicionales, donde se identifican entidades,
campos, tipos de datos, etc.
Sin embargo, el modelado RDFS se diferencia de estos otros modelos
en un aspecto fundamental: RDFS no tiene una aproximación
restrictiva, ya que debe permitir el principio AAA (Anyone can say
Anything about Any topic) de la Web Semántica.
36. RDFS - Introducción
Resulta evidente que RDF debe complementarse con algún método
que permita modelar el área o dominio sobre el que queremos
expresar los metadatos.
Es necesario contar con alguna herramienta para expresar las
condiciones relativas a:
Los tipos de recursos o clases con los que se va a trabajar,
Las propiedades de estos recursos que nos permiten caracterizarlos, y
Las reglas que se deben aplicar a la hora de asignar valores a estas propiedades.
RDF Schema, o RDFS, es un lenguaje que permite crear vocabularios
que se utilizarán en las declaraciones RDF.
RDFS permite declarar tipos de objetos o clases, predicados o
propiedades, e indicar qué predicados pueden usarse con cada tipo
de objeto y qué valores puede tomar cada predicado.
37. RDFS – Clases y propiedades
RDFS da la posibilidad de acotar el vocabulario y los términos que
podrán usarse en las declaraciones RDF.
En RDFS se declaran clases y propiedades.
Estas últimas se podrán utilizar como predicados en las declaraciones
RDF.
Un modelo RDFS se expresa también utilizando la sintaxis de RDF
descrita en el módulo anterior.
Tanto las clases como las propiedades se identifican mediante URI
(recordamos que el uso de URI para identificar cualquier tipo de
elemento es una característica fundamental de la Web Semántica).
38. RDFS – Clases
Una clase representa a todos los recursos que comparten unas
características comunes.
Una clase es una abstracción de los recursos que tienen las
características necesarias para ser considerados miembros de una
clase.
Serían ejemplos de clases: “Persona”, “Alumno”, “Profesor”, “Curso”,
“Temario”, “Examen”, “Manual”, etc.
Los recursos que pertenecen a una misma clase comparten
propiedades comunes.
Las clases se identificarán mediante un URI. Normalmente, se sigue
la pauta de comenzar su nombre con una letra mayúscula.
39. RDFS – Clases
Otra característica de las clases es que pueden organizarse
jerárquicamente, para representar clases más genéricas y más
específicas.
Por ejemplo, la clase Profesor sería una subclase de la clase
Persona, ya que cualquier instancia o miembro de la clase Profesor
es a su vez una instancia o miembro de la clase Persona.
Una clase puede ser una subclase de más de una clase.
Por ejemplo, la clase Libro-e podría ser una subclase de las clases
Monografía y Recurso-e.
40. RDFS – Clases
En los modelos RDFS se pueden establecer así jerarquías de clases,
con tantos niveles como sean necesarios para expresar las
características del dominio con el que se quiere trabajar.
Este mecanismo constituye una de las bases del razonamiento que
permite la Web Semántica.
Nota: En RDF existe una superclase rdf:Resource, que sería la clase
situada en el nivel más alto de la jerarquía, de forma que todos los
demás términos RDFS son subclases de ésta.
43. RDFS – Clases
Para simplificar la declaración de clases en un modelo RDFS, es
posible usar una sintaxis alternativa basada en el elemento rdfs:Class.
Para cada clase tendremos un elemento rdfs:Class.
45. RDFS – Clases
En este ejemplo anterior se puede apreciar cómo, en la
declaración del esquema RDFS, se combinan etiquetas o
marcas del espacio de nombres RDF con etiquetas o marcas
del espacio de nombres RDFS.
Por ejemplo, <rdf:RDF>, @rdf:about, @rdf:Resource
provienen del espacio de nombres RDF, y <rdfs:Class> o
<rdfs:subClassOf> provienen del espacio de nombres RDFS. .
47. RDFS – Propiedades
Las propiedades representan aspectos o características aplicables a
las clases.
Todas las instancias o recursos de una clase compartirán esos
aspectos o características comunes.
Por ejemplo, todas las instancias de la clase Libro-E contarán con
propiedades comunes como el DOI o una URL, todas las instancias
de la clase Monografia contarán con propiedades comunes como el
título, autor, año de publicación, etc.
48. RDFS – Propiedades
Las propiedades también se utilizan en RDF para representar
relaciones existentes entre dos clases.
Por ejemplo, la propiedad esAutor representaría una relación entre las
clases Autor y Monografía; la propiedad editadoPor representaría una
relación entre las clases Monografía y Editor, etc.
Las propiedades – que se corresponderán con los predicados de las
declaraciones RDF -, se identificarán siempre mediante un URI.
Normalmente, se sigue la pauta de comenzar su nombre con una letra
minúscula..
49. RDFS – Propiedades
En RDF se distinguen dos tipos de propiedades, dependiendo de si su
valor es un dato o literal (cadena de caracteres, fecha, número, etc.) o
una referencia a otro recurso.
Por ejemplo, la propiedad numeroPaginas tomaría como valor un
número entero. Sin embargo, la propiedad esAutor tomaría como
valor el URI correspondiente a una instancia de la clase Monografía.
Una propiedad se caracterizará por tener un dominio y un rango.
El dominio de una propiedad es la clase (o clases) a la cual es aplicable. Por
ejemplo, la propiedad imparteCurso es aplicable a la clase Profesor. Dicho de otra
forma, la clase Profesor sería el dominio de la propiedad imparteCurso.
El rango de una propiedad es el conjunto de valores que admite. En propiedades
de tipo “tipo de dato”, el rango será un tipo de dato. En propiedades de tipo objeto,
el rango será una clase existente. Por ejemplo, el rango de la propiedad
imparteCurso sería la clase Curso..
51. RDFS - Propiedades
En RDFS podemos declarar una propiedad sin especificar su
dominio.
De esta forma, la propiedad podría aplicarse con cualquier tipo de
recurso, no estaría restringida a clases o tipos de recursos
específicos.
Igualmente, se podría declarar una propiedad sin indicar su rango.
Otra característica de la declaración de propiedades en RDFS es
que éstas se declaran independientemente de las clases.
Es decir, al declarar una clase no se especifican cuáles son sus
propiedades.
La forma de vincular propiedades y clases es, únicamente,
mediante el dominio de las propiedades.
52. RDFS - Propiedades
Esto debe recordarse ya que en otros lenguajes o métodos de
modelado lo que suele hacerse es declarar las propiedades como
parte de las declaraciones de las clases. RDFS no sigue esta
aproximación.
El siguiente fragmento RDFS incluye la definición de tres clases
(Libro, Autor, Editor) y de dos propiedades asignadas a la clase
Libro: escritoPor e isbn. El valor para la primera propiedad debe
ser una instancia de la clase Autor. El valor de la segunda
propiedad puede ser cualquier cadena de caracteres:.
53. RDFS – Otros elementos RDFS
Además de los elementos utilizados para declarar clases y
propiedades con sus rangos y dominios, RDFS incorpora otros
elementos que se pueden usar en la creación de esquemas
RDFS. Normalmente, se usarán para documentar la estructura del
esquema RDFS. Estos elementos son:
<rdfs:seeAlso>
<rdfs:isDefinedBy>
<rdfs:label>
<rdfs:comment>.
54. RDFS – Otros elementos RDFS
<rdfs:seeAlso> se utiliza para indicar que existe otro recurso
donde se puede encontrar información sobre un recurso en
particular.
Podría utilizarse tanto con clases como con instancias de clases.
Por ejemplo:
55. RDFS – Otros elementos RDFS
<rdfs:isDefinedBy> es similar a <rdfs:seeAlso>, y se utiliza para
hacer referencia a la fuente principal de información sobre un
recurso determinado.
De esta forma, apuntará normalmente a un recurso donde se
puede encontrar información relevante sobre el recurso en
cuestión.
57. OWL y ontologías
Introducción
OWL, Web Ontology Language.
OWL permite diseñar ontologías: vocabularios que modelan el
conocimiento sobre un área de dominio específico, con el fin de
representar datos en la Web Semántica.
OWL es similar a RDFS, y se basa en los mismos conceptos :
clases, propiedades e instancias o individuos.
De hecho, OWL es una extensión de RDFS, al que incorpora
capacidades adicionales para poder crear modelos más precisos
(ontologías)
58. OWL y ontologías
Introducción
Las ontologías son un elemento clave en la Web Semántica.
Se definen como “conceptualización de un dominio o área de
conocimiento”.
Una ontología incluye los conceptos o términos que conforman el
vocabulario utilizado en un área determinada, y las relaciones que
existen entre esos conceptos.
Esta definición nos puede llevar a considerar un glosario (listado
de términos y definiciones) como una ontología.
De hecho, en la literatura sobre el tema se encuentran con
frecuencia referencias a “ontologías de mayor o menor
complejidad”, e incluye un abanico de opciones desde simples
listas de términos hasta representaciones más sofisticadas para el
razonamiento lógico.
59. OWL y ontologías
Introducción
Si se cotejan distintas definiciones, en la mayoría se indica:
la necesidad de que la ontología pueda ser procesable por un
programa informático,
que se pueda utilizar para deducir nuevos conocimientos
aplicando reglas lógicas.
que represente una conceptualización consensuada (es decir,
una representación de la realidad aceptada como correcta por
un grupo de personas).
60. OWL y ontologías
Introducción
“Una ontología es una especificación formal, explícita, de una
conceptualización compartida.
Conceptualización se refiere a un modelo abstracto de un
fenómeno cualquiera, en el que se han identificado los conceptos
relevantes de ese fenómeno.
Explícita significa que el tipo de conceptos que se usan, y las
restricciones que afectan a su uso, se han definido explícitamente.
Formal se refiere al hecho de que la ontología puede ser
procesada por un programa informático.
Compartida refleja el hecho de que la ontología captura
conocimiento consensuado, no propio de un individuo, sino
aceptado por un grupo.” (Studer, 1998).
61. OWL y ontologías
Introducción
Se puede concluir señalando que:
una ontología recoge los conceptos más relevantes de un área de
dominio concreto,
así como las relaciones que se establecen entre ellos y las
restricciones que afectan a las mismas.
Las ontologías son el resultado de un proceso de adquisición y
captura de conocimiento
Reflejan el conocimiento consensuado o común que, sobre esa
área, tiene un grupo de personas.
Deben codificarse de una forma que puedan ser procesadas por un
ordenador.)
62. OWL y ontologías
Elementos de OWL
En una ontología OWL se utilizan: clases, propiedades e
individuos.
También se utilizan los términos categorías, relaciones y objetos
para hacer referencia, respectivamente, a las clases, propiedades
y a las instancias o individuos.
En cualquier caso, los conceptos son equivalentes a los tratados
en RDFS.
En OWL se utiliza el término axioma para hacer referencia a las
declaraciones. Por ejemplo, decir que una instancia es de una
clase o tipo determinado sería un axioma.
Se dice también que una ontología OWL es un conjunto de
axiomas. Un axioma equivaldría a una declaración o statement en
RDF.
63. OWL y ontologías
Elementos de OWL
OWL incorpora términos o elementos reservados para declarar
clases, propiedades e individuos.
Estos términos se agrupan en el espacio de nombres identificado
por el URI: http://www.w3.org/2002/07/owl#
El prefijo para abreviar este espacio de nombres es owl:
La principal diferencia entre OWL y RDFS es que OWL tiene una
mayor capacidad expresiva ya que permite utilizar expresiones
basadas en la intersección, unión, complemento, etc.
Otra diferencia entre OWL y RDFS es que en OWL se pueden
utilizar los identificadores IRI (Internationalized Resource
Identifiers), que son equivalentes a los URI con la salvedad de que
permiten utilizar cualquier carácter Unicode, y no sólo los 127
caracteres ASCII.
64. OWL y ontologías
Elementos de OWL: Clases
Una clase representa a los individuos, objetos o entidades que
comparten unas características comunes.
Una clase es una abstracción de los individuos que tienen las
características necesarias para ser considerados miembros de una
clase. Serían ejemplos de clases conceptos como “Persona”,
“Alumno”, “Profesor”, “Curso”, “Temario”, “Examen”, “Manual”, etc.
Normalmente las clases contarán con un nombre (también es
posible tener en OWL clases abstractas, sin nombrar).
En OWL existe una superclase – de la cual se derivarán todas las
demás – llamada owl:Thing.
También existe una clase llamada owl:Nothing que representa la
nada.
65. OWL y ontologías
Elementos de OWL: Clases
OWL permite definir jerarquías de clases, o decir que una clase es
una sub-clase de otra existente.
Para hacer esto, la sintaxis que usaremos es la siguiente:
66. OWL y ontologías
Elementos de OWL: Propiedades
Las propiedades representan aspectos o características aplicables
a las clases.
También representan relaciones existentes entre dos clases.
Por ejemplo:
la propiedad “imparteCurso” representaría una relación entre las
clases “Profesor” y “Curso”;
la propiedad “matriculadoEnCurso” representaría una relación entre
las clases “Alumno” y “Curso”, etc.
OWL distingue dos tipos de propiedades, dependiendo de si su
valor es un dato (cadena de caracteres, fecha, número, etc.) o un
objeto.
Se habla así de “propiedades tipo de dato” y de “propiedades
objeto”. Por ejemplo, numeroHoras sería una propiedad tipo de
dato, e imparteCurso de tipo objeto.
67. OWL y ontologías
Elementos de OWL: Propiedades
Una propiedad en OWL siempre se caracterizará por tener un
dominio y un rango.
El dominio de una propiedad es la clase a la cual es aplicable. Por
ejemplo, la propiedad imparteCurso es aplicable a la clase
Profesor. Dicho de otra forma, la clase Profesor sería el dominio
de la propiedad imparteCurso.
El rango de una propiedad es el conjunto de valores que admite.
En propiedades de tipo “tipo de dato”, el rango será un tipo de
dato, expresado según los tipos de datos de los esquemas XML.
En propiedades de tipo objeto, el rango será una clase existente.
68. OWL y ontologías
Elementos de OWL: Individuos
Un individuo representa una ocurrencia o instancia particular de
una clase.
Por ejemplo, si Juan López es un profesor de la academia
Estudios S.L., Juan López será una instancia o individuo de la
clase Profesor, y Estudios S.L. será un individuo o instancia de la
clase Academia.
Las instancias o individuos pertenecerán a una clase, y heredarán
todas las propiedades/relaciones de ésta. En OWL, los individuos
se representan mediante el elemento <owl:Thing>, y se
identificarán mediante un URI.
69. OWL y ontologías
Elementos de OWL: Individuos
En OWL no se asume de forma explícita que dos individuos
distintos corresponden a entidades diferentes, incluso si los dos
tienen URI diferentes.
Esta característica hace que, si queremos indicar que dos o más
individuos son diferentes entre sí, debemos indicarlo de forma
explícita como parte de nuestra ontología.
OWL incorpora unos elementos para poder indicar si dos
individuos son los mismos o si son diferentes.
Se trata de los elementos <owl:sameAs> y <owl:differentFrom>.
También es posible indicar que un conjunto de individuos son
todos diferentes entre sí mediante el elemento <owl:AllDifferent>..
70. OWL y ontologías
Definición avanzada de clases
Restricción owl:cardinality
Permite indicar el número de veces que puede usarse una
propiedad con una clase, o el número de ocurrencias de la
propiedad en los individuos de ese tipo.
Por ejemplo, podría limitarse el número de cursos en los que se
puede matricular un alumno estableciendo la cardinalidad de la
propiedad matriculadoEn, o el número de alumnos por curso
fijando una cardinalidad para la propiedad
numeroAlumnosMatriculados.
Para expresar con más precisión la cardinalidad de una propiedad
para una clase específica, OWL también incorpora los elementos
<owl:minCardinality> y <owl:maxCardinality>
71. OWL y ontologías
Definición avanzada de clases - conjuntos
En OWL se pueden declarar nuevas clases mediante operaciones
lógicas (intersección, unión, complemento) sobre otras clases
declaradas previamente.
Para definir una clase como resultado de la intersección de dos o
más clases, OWL incorpora el elemento <owl:intersectionOf>.
Este elemento es equivalente a decir que la nueva clase es una
subclase de otras clases existentes.
El siguiente fragmento declara una clase que representa a los
alumnos con beca que repiten curso:.
72. OWL y ontologías
Definición avanzada de clases - conjuntos
OWL incluye también estas opciones: <owl:oneOf>,
<owl:equivalentClass> y <owl:disjointWith>.
<owl:oneOf> permite definir una clase por su extensión, es decir,
listando todas sus instancias o individuos.
Cada miembro de la clase se añadirá mediante un elemento
<owl:Thing> independiente, entre las etiquetas de inicio y de fin del
elemento <owl:oneOf>
Los elementos <owl:equivalentClass> y <owl:disjointWith>
permiten indicar, respectivamente, que:
Dos clases son equivalentes, es decir, que todas las instancias de una lo serán
también de la otra.
Dos clases son disjuntas, es decir, no comparten ninguna instancia. Si una
instancia o individuo pertenece a una de las clases, no podrá pertenecer a la
otra. Por ejemplo, las clases Hombre y Mujer serían disjuntas.
73. OWL y ontologías
Definición avanzada de propiedades
Entre las propiedades declaradas en la ontología también se
pueden establecer relaciones. Las más habituales son:
owl:subPropertyOf - indica que una propiedad es un caso
particular de otra más general. Por ejemplo, la propiedad
esHijoDe sería una subpropiedad de esFamiliaDe.
owl:equivalentProperty - indica que dos propiedades son
equivalentes o sinónimas.
owl:inverseOf - indica que dos propiedades son inversas. Por
ejemplo, la propiedad imparteCurso sería la inversa de
esImpartidoPor..
74. OWL y ontologías
Definición avanzada de propiedades
Las propiedades pueden tener estas características:
owl:SymmetricProperty – indica que una propiedad establece
una relación que puede leerse en cualquier dirección. Por
ejemplo, la propiedad esVecino.
owl:TransitiveProperty – indica que una propiedad establece
una relación entre clases que es transitiva. Por ejemplo, la
propiedad esDescendiente. Si Juan es descendiente de Luis, y
Luis lo es de Paco, podemos deducir que Juan será
descendiente de Paco.
owl:Functional – una propiedad será funcional cuando su
cardinalidad mínima sea 0 y la máxima sea 1. Esto no quiere
decir que el valor de dicha propiedad no pueda ser el mismo en
distintos individuos. Un ejemplo de propiedad funcional sería la
fecha de nacimiento:
75. OWL y ontologías
Definición avanzada de propiedades
Las propiedades pueden tener estas características:
owl:InverseFunctionalProperty –indica que dos instancias
diferentes no pueden tener el mismo valor en una propiedad
marcada de esta forma (funcional inversa).
Un ejemplo característico serían las direcciones de correo-e (una
dirección de correo-e pertenece a una única persona).
Una propiedad puede ser a la vez funcional y funcional inversa.
Esto sucede por ejemplo con los números de identificación tipo
DNI, pasaporte, o similares.
77. SKOS está orientado a la indización y a la recuperación de
información documental, frente a otros sistemas como OWL
orientados a procesamientos más complejos.
SKOS no debe considerarse únicamente como una forma
de publicar lenguajes de indización, sino como un
mecanismo para representar relaciones entre distintos
esquemas conceptuales.
Iniciativas que han precedido a SKOS
LIMBER (Language Independent Metadata Browsing of European
Resources),
CERES (California Environmental Resources Evaluation System),
GEM (Gateway to Educational Materials),
CALL (Center for Army Lessons Learned) Thesaurus,
ETT (European Treasury Browser) o
KAON/AGROVOC.
SKOSSKOS
78. SKOS está basado en RDF.
Los conceptos de un lenguaje de indización corresponden
a instancias de clase, y las relaciones entre conceptos y sus
descripciones se tratan como declaraciones sobre dichas
instancias.
Los conceptos o “unidades de pensamiento” se identifican
mediante URI, a los que se pueden asignar distintas
etiquetas en lenguaje natural, en uno o en distintos idiomas.
Los conceptos se agrupan en “esquemas de conceptos”.
Permite asociar notas aclaratorias a los conceptos
Permite relacionar los conceptos, mediante las relaciones
jerárquicas y asociativas.
Incorpora funciones avanzadas que permiten establecer
relaciones entre esquemas de conceptos.
SKOSSKOS
79. Los elementos SKOS están definidos en el espacio de
nombres http://www.w3.org/2004/02/skos/core#, para el
que se suele usar el prefijo skos:
Cada concepto se identifica mediante un elemento
<concept>.
Las etiquetas lingüísticas asociadas a los conceptos se
representan mediante elementos <prefLabel>, <altLabel> o
<hiddenLabel>.
La primera señala el término autorizado;
La segunda términos alternativos no autorizados (sinónimos,
cuasi-sinónimos, formas abreviadas o desarrolladas para
siglas, etc.);
La tercera se utiliza para designaciones que se quieren
registrar pero que deben permanecer ocultas para el
usuario del sistema.
SKOSSKOS
80. Las etiquetas asignadas a un concepto irán acompañadas
de un atributo que indicará su idioma (un concepto sólo
podrá tener un único término autorizado en el mismo
idioma).
Sobre las relaciones entre términos, SKOS define los
siguientes elementos:
<broader>
<narrower>
<related>
<broader> dirige desde un concepto a otro con un
significado más genérico.
<narrower> sigue el orden inverso, y dirige de un concepto
a otro más específico.
SKOSSKOS
81. Siguiendo las reglas usadas en la construcción de lenguajes
de indización, las relaciones genéricas o específicas
corresponden a casos en los que exista una relación de tipo
“A es un tipo de B”, “A es una instancia de B”, o “A es parte
de B”, es decir, relaciones genérico-específicas o género-
especie y relaciones parte-todo.
<related> se usará para aquellos conceptos cuyo
significado está relacionado, en aquellos casos en los que
la relación no corresponda con la genérico-específica o
parte-todo.
Para registrar notas de alcance asociadas a los conceptos,
SKOS define los elementos <scopeContent>, <definition>,
<example>, <historyNote>, <editorialNote> y
<changenote>.
SKOSSKOS
82. Los sistemas de conceptos se declaran mediante
<conceptScheme>.
Los sistemas de conceptos se definen o declaran en primer
lugar, y luego se indica la pertenencia de un concepto a
un sistema u otro mediante el atributo @inScheme que
acompaña al concepto.
En SKOS se pueden vincular conceptos a sistemas, pero no
sucede así con las relaciones que existen entre los
conceptos y que no se vinculan a un sistema de conceptos
particular.
Normalmente los sistema de conceptos tendrán una serie
de jerarquías de términos, cada una de ellas con su término
principal que constituye el origen o punto de acceso a la
jerarquía. En SKOS, esto se representa mediante los
elementos <hasTopConcept>.
SKOSSKOS
83. Para indicar las relaciones entre conceptos de distintos
sistemas, SKOS incorpora las propiedades:
exactMatch y closeMatch, que indican distintos niveles de
similitud semántica,
broadMatch, narrowMatch y relatedMatch, que se utilizarán en
aquellos casos en los que un término tenga un significado más o
menos genérico o específico que el de otro concepto definido
en un sistema de conceptos diferente.
SKOS no hace mención a cómo se deben relacionar los
conceptos con los recursos indizados.
SKOSSKOS
84. Descarga un thesauro disponible en esta URL y comprueba
como usan los distintos elementos SKOS:
http://skos.um.es/vocabularios/index.php/
Codifica, mediante etiquetas SKOS, 3 conceptos del
siguiente vocabulario controlado:
www.cedefop.europa.eu/files/3049_en.pdf
Consulta los datasets SKOS disponibles en:
http://www.w3.org/2001/sw/wiki/SKOS/Datasets
SKOS - PrácticaSKOS - Práctica
86. SPARQL
SPARQL es una especificación del W3C para consultar
repositorios de declaraciones RDF.
En la visión de la Web Semántica se espera que existan distintos
repositorios y bases de datos que expongan sus metadatos a
agentes software capaces de acceder a ellos y recolectarlos con
distintos propósitos.
Esta visión necesita otro componente para realizarse en todo su
potencial: un lenguaje de consulta para filtrar y recuperar la
información que necesitan las aplicaciones consumidoras de
metadatos.
87. SPARQL
La función de SPARQL se establece en su especificación:
“SPARQL can be used to express queries across diverse data
sources, whether the data is stored natively as RDF or viewed as
RDF via middleware”.
SPARQL ofrece el lenguaje de consulta, un protocolo de acceso
para transportar las consultas y un formato basado en XML para
enviar los resultados de las consultas.
88. SPARQL
SPARQL soportan distintos modos de consulta o “query modes”:
SELECT – devuelve datos de declaraciones RDF asociados a
variables, en forma de “tabla de variables”.
CONSTRUCT – devuelve un gráfico RDF como resultado, con el
subconjunto de declaraciones que cumplen las condiciones indicadas
en la consulta. Los resultados se serializan en forma de documentos
RDF/XML.
ASK – devuelve un valor booleano que indica si hay al menos una
declaración en el repositorio RDF que cumple las condiciones
indicadas en la consulta.
DESCRIBE – devuelve un gráfico RDF que describe los recursos que
cumplen con las condiciones indicadas en la consulta..
89. SPARQL
El principal es SELECT, que presenta grandes similitudes con el
lenguaje SQL para consulta de bases de datos relacionales.
Una consulta SPARQL incluye cláusulas SELECT, FROM y
WHERE.
Los datos recuperados del repositorio RDF se vinculan a variables
con nombre. La lista de variables que se incluyan en la cláusula
SELECT serían equivalentes a los nombres de columnas que se
usan en una SELECT SQL.
Los datos que se recuperan pueden corresponder al URI del
recurso, URI de propiedades o sus valores (es decir, una consulta
SPARQL puede recuperar tanto los sujetos, como los predicados y
los objetos de las declaraciones RDF).
Consultar ejemplos en: http://bnb.data.bl.uk/flint
93. SKOS
Introducción
Sus principales características son :
Los conceptos o “unidades de pensamiento” se identifican mediante
URI, a los que se pueden asignar distintas etiquetas en lenguaje
natural, en uno o en distintos idiomas.
Los conceptos se agrupan en “esquemas de conceptos”.
Permite asociar notas aclaratorias a los conceptos
Permite relacionar los conceptos, mediante las relaciones
jerárquicas y asociativas características de los lenguajes de
indización..
94. SKOS
Estructura
Los elementos SKOS están definidos en el espacio de nombres
http://www.w3.org/2004/02/skos/core#, para el que se suele usar el
prefijo skos:.
Cada concepto se identifica mediante un elemento <concept>.
Las etiquetas lingüísticas asociadas a los conceptos se
representan mediante elementos <prefLabel>, <altLabel> o
<hiddenLabel>.
Las etiquetas asignadas a un concepto irán acompañadas de un
atributo que indicará su idioma.
Sobre las relaciones entre términos, SKOS define los siguientes
elementos: <broader>, <narrower> y <related>
95. SKOS
Estructura
Para registrar notas de alcance asociadas a los conceptos, SKOS
define los elementos <scopeContent>, <definition>, <example>,
<historyNote>, <editorialNote> y <changenote>.
Las notas también pueden ir acompañadas por un atributo que
indica el idioma en el que se han redactado.
Los sistemas de conceptos se declaran mediante
<conceptScheme>. Los sistemas de conceptos se definen o
declaran en primer lugar, y luego se indica la pertenencia de un
concepto a un sistema u otro mediante el atributo @inScheme que
acompaña al concepto.
En SKOS se vinculan conceptos a sistemas, pero no sucede así
con las relaciones que existen entre los conceptos y que no se
vinculan a un sistema de conceptos particular.
96. SKOS
Estructura
Normalmente los sistemas de conceptos tendrán una serie de
jerarquías de términos, cada una de ellas con su término principal
que constituye el origen o punto de acceso a la jerarquía, y que
estará situado en el nivel superior de la misma. En SKOS, esto se
representa mediante los elementos <hasTopConcept>.
Para indicar las relaciones entre conceptos de distintos sistemas,
SKOS incorpora las propiedades exactMatch y closeMatch,
broadMatch, narrowMatch y relatedMatch
SKOS no hace mención a cómo se deben relacionar los conceptos
con los recursos indizados.
107. Datos enlazados
Introducción
Idea propuesta por el inventor de la Web, Tim Berners-Lee en el
año 2006, y consiste en publicar datos en la Web de forma que
sean procesables por programas informáticos.
Los datos se publicarán en forma de conjuntos de datos o
datasets, que pueden ser enlazados con otros conjuntos de datos
publicados por terceros, estableciendo una red de datos.
En LOD, se utiliza RDF como formato para exponer y publicar los
datasets.
LOD, al igual que la Web Semántica, no está asociada a ningún
área de aplicación particular
En LOD, los objetos de las declaraciones RDF relativas a un sujeto
pueden apuntar a entidades que se han definido en cualquier otro
conjunto de datos..
108. Datos enlazados
Introducción
Se pueden obtener datos relativos al volumen de datos publicados
por la comunidad LOD en la URL:
http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenD
http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenD
Sobre los datasets publicados en formato LOD, habitualmente se
utiliza el gráfico de la siguiente página (creado y mantenido por
Richard Cyganiak y Anja Jentzsch para mostrar los conjuntos de
datos disponibles. El gráfico está accesible en la págin:
http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenD
109. Datos enlazados
Introducción
Las características que debe cumplir un conjunto de metadatos LOD
para ser incorporados en este registro son las siguientes:
Deben estar disponibles a través de URIs con el protocolo http o
https.
Deben estar expuestos en forma de datos RDF, al menos en uno de
los diferentes métodos de serialización para RDF (RDFa, RDF/XML,
Turtle, N-Triples).
El dataset debe incluir al menos 1000 declaraciones RDF.
El dataset debe contener enlaces al menos a uno de los datasets
que figuran en el diagrama. Se comprueba que al menos hay 50
enlaces entre los dos datasets.
Se debe poder acceder al dataset mediante recolección o descarga
de datos RDF o a través de un punto de consulta SPARQL (SPARQL
endpoint).
110. Datos enlazados
Introducción
Los puntos anteriores obligan a configurar ciertas funciones
técnicas del servidor web a través del cual se publiquen los datos
RDF.
Por ejemplo, el servidor debe ser capaz de reconocer peticiones
que soliciten datos RDF mediante el tipo MIME application/rdf+xml.
Estos requisitos son de hecho algunas de las reglas que fueron
propuestas por Tim Berners-Lee en su visión de la web de datos
enlazados:
usar URIs para identificar a las cosas,
usar el protocolo HTTP,
incluir enlaces a otros URI para poder descubrir nuevos datos y
explorar la información enlazada
111. Datos enlazados
Introducción
Participar en la iniciativa LOD se deben facilitar o exponer datos y
enlazarlos con otros datasets existentes.
Para hacer esto:
Se deben seleccionar o crear URI para hacer referencia a los
recursos,
elegir un vocabulario para etiquetar los datos (predicados o
metadatos),
generar las declaraciones RDF correspondientes a nuestros datos,
enlazarlos con datos RDF de otros datasets, y
dar visibilidad a nuestro dataset publicándolo en la Web.
112. Datos enlazados
Introducción
A parte de la DBpedia, una herramienta que se desarrolló en el
contexto académico para comprobar si se habían asignado URIs a
determinadas entidades es el buscador SINDICE, creado por
DERI (Digital Enterprise Research Institute), instituto de la National
University of Ireland, Galway, y que está disponible en:
http://sindice.com
Otra herramienta similar es el sitio web SAMEAS.org, donde se
pueden buscar URIs que sean equivalentes a un URI facilitado
como criterio de búsqueda. SAMEAS.org interactúa con SINDICE
para buscar información.
113. Datos enlazados
Introducción
Además de comprobar URIs antes de asignarlos (o para poder
declarar que nuestro URI corresponde a la misma entidad que
uno ya existente), se debe elegir el vocabulario RDF para
codificar los metadatos.
Un sitio donde podemos encontrar información sobre
vocabularios existentes es el Linked Open Vocabularies (LOV),
disponible en: http://lov.okfn.org/dataset/lov/
LOV incluye un listado de vocabularios donde se indica su URI,
prefijo, y enlaces a las páginas web donde se ofrece la
información detallada.
Otros buscadores donde se pueden recuperar vocabularios:
http://watson.kmi.open.ac.uk/WatsonWUI/
http://swoogle.umbc.edu/
http://ws.nju.edu.cn/falcons/ontologysearch/index.jsp?query=
114. Datos enlazados
Introducción
Además de estos buscadores que permiten buscar en
documentos RDF y en vocabularios y ontologías, también se han
diseñado un tipo de navegador especial para los datos enlazados.
Un listado de estas herramientas se puede consultar en la
página:
http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingO
penData/SemWebClients
Un ejemplo de un navegador para datos enlazados es el
programa SIG.MA, desarrollado por el mismo instituto de
investigación que desarrolló el buscador de URIs SINDICE.
SIG.MA busca en distintos datasets los términos de búsqueda
propuestos, y agrega los datos en una ventana de resultados
dividida en dos secciones: