Este documento es una traducción al Castellano de la recomendación del W3C "RDFa Core 1.1", publicada el 7 de junio de 2012. La presente traducción se concluyó el 28 de junio de 2013.
La versión original en inglés es el único documento válido y se
encuentra en: http://www.w3.org/TR/2012/NOTE-rdfa-primer-20120607/
Puede ver la última versión del documento en inglés en: http://www.w3.org/TR/rdfa-primer/
Se ha tratado de respetar al máximo el contenido del documento original en inglés, adaptando la expresión al español para ayudar a una mejor comprensión del mismo. Por tanto, esta traducción puede contener errores, en ningún caso achacables a sus autores originales. Cualquier sugerencia de corrección, duda o comentario sobre la misma puede realizarse dirigiéndose a su autor: Juan Antonio Pastor Sánchez.
Consulte la sección de erratas en la que se pueden incluir algunas correcciones de este documento.
Este documento, en su versión inglesa, también está disponible en los siguientes formatos no normativos This document is also available in these non-normative formats: Diferencias con la propuesta de recomendación, versión PostScript, y versión PDF.
La versión en Inglés de esta especificación es la única versión normativa. También pueden estar disponibles traducciones no normativas.
Copyright © 2010-2012 W3C® (MIT, ERCIM, Keio), Todos los derechos reservados. Son aplicables las reglas del W3C sobre obligaciones, marcas registradas y uso de documentos.
La Web actual está formada básicamente por una enorme cantidad de
documentos que han sido creados usando HTML. Estos documentos contienen
cantidades significativas de datos estructurados, que no están
disponibles para herramientas y aplicaciones. Cuando los editores pueden
expresar estos datos de forma más completa, y cuando pueden ser leidos
por herramientas surge un nuevo mundo de funcionalidades para el
usuario, permitiendo a estos transferir datos estructurados entre
aplicaciones y sitios web, y haciendo posible que los navegadores
mejoren la experiencia del usuario: un evento en una página web se puede
importar directamente en una aplicación de escritorio que gestione la
agenda del usuario; es posible detectar la licencia de un documento de
manera que los usuarios puedan ser informados automáticamente sobre sus
derechos de uso; la información sobre el autor de una fotografía, la
configuración de la cámara, la resolución, la ubicación y el tema se
puede publicar con tanta facilidad como la fotografía original en sí,
permitiendo procesos de intercambio y búsqueda estructurados.
RDFa Core es una especificación de atributos para expresar datos
estructurados en cualquier lenguaje de marcado. Los datos incorporados
que ya están disponibles en un lenguaje de marcado (como HTML) a menudo
pueden ser reutilizados mediante el marcado RDFa, por lo que no es
necesario que los editores repitan datos significativos en el contenido
del documento. La representación abstracta subyacente es RDF [RDF-PRIMER],
lo que permite a los editores crear su propio vocabulario, ampliar
otros, y dotarlos de la máxima interoperabilidad a lo largo del tiempo.
La estructura expresada está estrechamente vinculada a los datos, por lo
que los datos intepretados pueden ser copiados y pegados junto con su
estructura correspondiente.
Las reglas para la interpretación de los datos son de carácter genérico,
por lo que no hay necesidad de establecer normas diferentes para
diferentes formatos, permitiendo a los autores y editores de datos
definir sus propios formatos sin tener que actualizar el software,
registrar formatos a través de una autoridad central, o preocuparse de
que dos formatos puedan interferir entre sí.
RDFa comparte algunos objetivos con los microformatos [MICROFORMATS].
Mientras que los microformatos especifican tanto una sintaxis para
incluir datos estructurados en los documentos HTML como un vocabulario
de términos específicos para cada microformato, RDFa sólo especifica una
sintaxis y se basa en la especificación independiente de términos (a
menudo llamados vocabularios o taxonomías) por terceros. RDFa permite
que los términos de múltiples vocabularios desarrollados
independientemente puedan mezclarse libremente y está diseñado de tal
manera que el lenguaje pueda analizarse sin el conocimiento del
vocabulario específico utilizado.
Este documento es una especificación detallada de la sintaxis RDFa,
dirigido a:
Para quienes buscan una introducción al uso de RDFa y algunos ejemplos
en el mundo real, consultar por favor [RDFA-PRIMER].
En primer lugar, si el lector no está familiarizado con RDFa o RDF, y
simplemente se quiere añadir RDFa a su documentos, entonces puede que
el Manual de RDFa [RDFA-PRIMER]
sea una introducción más adecuada.
Si ya está familiarizado con RDFa, y desea examinar las reglas de
procesamiento - tal vez para crear un procesador de RDFa -
entonces probablemente la sección Modelo de
procesamiento sea de mayor interés. Contiene un resumen de cada
una de las etapas de tratamiento, seguido por secciones más
detalladas, una para cada regla.
Si el lector no está familiarizado con RDFa, pero está familiarizado
con RDF, entonces puede encontrar útil la lectura de la Visión
general de la sintaxis, antes de consultar el Modelo
de procesamiento, ya que ofrece una amplia variedad de ejemplos
de marcado que hacen uso de RDFa. Consultar previamente algunos
ejemplos hace más sencilla la lectura de las reglas de procesamiento.
Si no está familiarizado con RDF, entonces es posible que desee echar
un vistazo a la sección sobre la terminología
RDF antes profundizar en RDFa. Aunque RDFa está diseñado para
que sea fácil de usar - sin que los autores deban entender
necesariamente RDF - quien escriba aplicaciones que consuman
RDFa deberá comprender RDF. Hay una gran cantidad de material sobre
RDF en la web, y una creciente gama de herramientas que soportan RDFa.
Este documento únicamente incluye una base suficiente sobre RDF para
hacer más claros los objetivos de RDFa.
RDFa es un modo de expresar relaciones RDF utilizando
atributos sencillos en lenguajes de marcado ya existentes como HTML.
RDF esta totalmente internacionalizado, y permite el uso de
Identificadores Internacionalizados de Recursos o IRIs
(Internationalized Resource Identifiers). El lector observara que el
término "IRI" se utiliza en toda esta especificación. Incluso si no se
está familiarizado con el término IRI, probablemente el lector estará
familizarizado con los términos "URI" o "URL". IRI es una extensión de
la URI, que permite el uso de caracteres ajenos a los del código
ASCII. RDF permite el uso de estos caracteres, y también lo hace RDFa.
Esta especificación ha sido cuidadosa al usar el término correcto,
IRI, para dejar claro que su uso es posible en RDFa.
A pesar de que esta especificación exclusivamente
referencia IRIs, es posible que un lenguaje de marcado anfitrión de
RDFa restrinja la sintaxis de sus atributos a un subconjunto de IRI
(por ejemplo, @href en HTML5). A pesar de las restricciones de
validación en los lenguajes anfitrión, un procesador de RDFa es capaz
de procesar IRI.
Este documento ha sido revisado por miembros del W3C, por desarrolladores de software, y por otros grupos del W3C y partes interesadas, y está respaldada por el Director como una recomendación del W3C. Es un documento estable y puede ser utilizado como material de referencia o de otro documento citado. El papel del W3C al elaborar la recomendación es llamar la atención sobre la especificación y promover su amplio despliegue. Esto mejora la funcionalidad y la interoperabilidad de la Web.
Esta es una revisión del documento sobre la Syntaxis RDFa 1.0 [RDFA-SYNTAX].
Este documento reemplaza a la recomendación
anterior. Hay una serie de diferencias sustanciales entre esta
versión y la anterior, incluyendo:
Está disponible un banco de pruebas de ejemplo. No se pretende que este conjunto de pruebas sea exhaustiva. Los usuarios pueden encontrar que dichas pruebas constituyen ejemplos útiles de uso de RDFa.
Este documento fue publicado por el Grupo de Trabajo de aplicaciones web RDF como una recomendación. Los comentarios sobre este documento deben enviarse a public-rdfa@w3.org (subscribirse, archivos). Todos los comentarios son bienvenidos.
Este documento fue elaborado por un grupo que opera en el marco de la Política de Patentes del W3C del 5 de febrero 2004. El W3C mantiene una lista pública de cualquier patente divulgada realizada en coordinación con la difusión de los resultados del grupo de trabajo; dicha página también incluye instrucciones para la divulgación de una patente. Una persona que tenga conocimiento de una patente que considere que contiene la reivindicación(es) esencial(es) debe revelar la información de conformidad con la sección 6 de la Política de Patentes del W3C.
Esta sección no es normativa
RDF/XML [RDF-SYNTAX] proporciona la suficiente flexibilidad para representar todos los conceptos abstractos de RDF [RDF-CONCEPTS]. Sin embargo, presenta una serie de retos: en primer lugar, es difícil o imposible validar documentos que contengan RDF/XML utilizando esquemas XML o DTD, con lo cual es difícil importar RDF/XML a otros lenguajes de marcado. Por su parte, los nuevos lenguajes para la definición de esquemas como RELAX NG [RELAXNG-SCHEMA] proporcionan una manera de validar los documentos que contengan RDF/XML, por lo que es cuestión de tiempo que obtengan un soporte más amplio.
En segundo lugar, incluso si se pudiera añadir RDF/XML directamente en un dialecto XML, como XHTML, se produciría una importante duplicación de datos entre aquellos que se representan y los estructurados mediante RDF/XML. Sería mucho mejor agregar RDF a un documento sin tener que repetir los datos ya existentes en el mismo. Por ejemplo, en un documento XHTML que incluya explícitamente el nombre de su autor en el texto -tal vez mediante una línea que mencione la autoría en un sitio web de noticias - no debería ser necesario repetir este nombre en la expresión RDF del mismo concepto: debería ser posible complementar el marcado XHTML existente de tal manera que también se pueda interpretar como RDF .
Otra razón para la alineación de los datos visualizados con los datos estructurados es que resulta altamente beneficioso expresar la estructura de los datos web "en su contexto": puesto que los usuarios a menudo quieren transferir datos estructurados de una aplicación a otra, a veces hacia o desde una aplicación no-web, y mejorar de esta manera la experiencia de usuario. Por ejemplo, la información sobre datos específicos visualizados sobre un tema de interés podría mostrarse al usuario pulsando el botón derecho del ratón. Por otra parte, a las organizaciones que generan una gran cantidad de contenido (por ejemplo, las agencias de noticias) les resulta más fácil integrar los datos semánticos en el interior de las páginas que mantenerlos separados.
En el pasado muchos atributos se incluyeron directamente en los lenguajes de marcado para representar conceptos específicos. Por ejemplo, en XHTML 1.1 [XHTML11] y HTML [HTML401] el atributo @cite permite al editor añadir información a un documento para indicar el origen de una cita.
Dichos atributos especiales hacen difícil definir un proceso genérico
para la extracción de metadatos de cualquier documento, puesto que un
procesador RDFa necesitaría conocer cada uno de los atributos
especiales. Una motivación para el desarrollo de RDFa ha sido la
creación de un medio a través del que los documentos puedan enriquecerse
con metadatos a partir de un enfoque general, en vez de utilizar
atributos específicos. Esto se ha conseguido al crear un conjunto fijo
de atributos y reglas de análisis, al tiempo que se permite que esos
atributos contengan cualquier propiedad de la amplia gama de
vocabularios RDF. En muchos casos los valores de dichas
propiedades es información que ya se encuentra en un documento creado
por un editor.
RDFa alivia la presión sobre los diseñadores de lenguajes de marcado con respecto a la anticipación de todos los requisitos estructurales que los usuarios de los mismos pudieran ocasionar, ofreciendo para ello una nueva sintaxis para RDF basada únicamente en atributos. Al adherirse a los conceptos y las reglas de esta especificación, los diseñadores de lenguajes de marcado pueden importar RDFa en su entorno de forma poco compleja, al tiempo que tienen la confianza de que los datos semánticos podrán ser extraídos de sus documentos, ajustándose a los procesadores.
Esta sección no es normativa
Los siguientes ejemplos pretenden ayudar a aquellos lectores que no estén familiarizados con RDFa, de forma que obtengan rápidamente una idea de como funciona. Para una introducción más detallada, por favor lea el Manual de RDFa [RDFA-PRIMER].
En RDF, es común acortar los términos de un vocabulario mediante la abreviación de IRIs, utilizando un "prefijo" y una "referencia". Este mecanismo se explica en detalle en la sección Expresiones compactas de URI Los ejemplos de este documento presuponen que se han definido los siguientes prefijos de vocabulario:
bibo: | http://purl.org/ontology/bibo/ |
cc: | http://creativecommons.org/ns# |
dbp: | http://dbpedia.org/property/ |
dbp-owl: | http://dbpedia.org/ontology/ |
dbr: | http://dbpedia.org/resource/ |
dc: | http://purl.org/dc/terms/ |
ex: | http://example.org/ |
foaf: | http://xmlns.com/foaf/0.1/ |
rdf: | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfa: | http://www.w3.org/ns/rdfa# |
rdfs: | http://www.w3.org/2000/01/rdf-schema# |
xhv: | http://www.w3.org/1999/xhtml/vocab# |
xsd: | http://www.w3.org/2001/XMLSchema# |
En algunos de los ejemplos incluidos más adelante se han
utilizado IRIs con identificadores de fragmentos que son locales al
documento que contiene los identificadores de fragmentos RDFa mostrados
(por ejemplo, 'about="#me"
'). Este lenguaje, que también se
utiliza en RDF/XML [RDF-SYNTAX-GRAMMAR]
y otras serializaciones RDF, proporciona una forma sencilla para
'acuñar' nuevas IRIs para las entidades descritas mediante RDFa y por lo
tanto contribuye considerablemente a incrementar la capacidad expresiva
de RDFa. El significado preciso de IRIs que incluyen identificadores de
fragmentos cuando aparecen en grafos RDF se ofrece en la Sección 7 de [RDF-CONCEPTS].
Para asegurar que tales identificadores de fragmentos puedan
interpretarse correctamente, los registros de tipos de medios para
lenguajes de marcado que incorporen RDFa deben, directa o
indirectamente, hacer referencia a esta especificación.
RDFa hace uso de cierto número de atributos bastante comunes, al
tiempo que proporciona algunos nuevos. Los atributos que ya existen en
lenguajes de marcado ampliamente utilizados (por ejemplo, HTML) tienen
el mismo significado de siempre, aunque su sintaxis se ha modificado
ligeramente en algunos casos. Por ejemplo, en (X)HTML no hay una forma
clara para añadir nuevos valores @rel; RDFa propone resolver explícitamente este
problema, y lo hace permitiendo el uso de IRIs como valores. También
introduce el concepto de terms
y 'Expresiones
compactas
de URI' — denominadas CURIEs en este documento - que permiten
expresar de forma sucinta un valor IRI completo. Para obtener una
lista completa de la denominación y sintaxis de los atributos RDFa,
puede consultarse la sección Atributos y sintaxis.
En (X)HTML los autores pueden incluir metadatos y relaciones
concernientes al documento en el que se encuentren utilizando los
elementos meta
y link
(en estos ejemplos
se utiliza XHTML+RDFa [XHTML-RDFA]).
Por ejemplo, el autor de la página actual junto con las páginas
anteriores y posteriores a la misma puede expresarse utilizando los
siguientes elementos meta y link:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Page 7</title> <meta name="author" content="Mark Birbeck" /> <link rel="prev" href="page6.html" /> <link rel="next" href="page8.html" /> </head> <body>...</body> </html>
RDFa aplica este concepto, mejorándolo con la capacidad de hacer uso de otros vocabularios utilizando IRIs completas:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>My home-page</title> <meta property="http://purl.org/dc/terms/creator" content="Mark Birbeck" /> <link rel="http://xmlns.com/foaf/0.1/topic" href="http://www.example.com/#us" /> </head> <body>...</body> </html>
Dado que el uso de IRIs completas, como las mostradas anteriormente,
puede resultar engorroso, RDFa también permite utilizar expresiones
compactas de URI por lo que un autor puede utilizar un atajo
para referenciar los términos de múltiples vocabularios:
<html xmlns="http://www.w3.org/1999/xhtml" prefix="foaf: http://xmlns.com/foaf/0.1/ dc: http://purl.org/dc/terms/" > <head> <title>My home-page</title> <meta property="dc:creator" content="Mark Birbeck" /> <link rel="foaf:topic" href="http://www.example.com/#us" /> </head> <body>...</body> </html>
RDFa soporta el uso de @rel y @rev en cualquier elemento. Esto resulta incluso más util al añadir dicho soporte para diferentes vocabularios:
This document is licensed under the <a prefix="cc: http://creativecommons.org/ns#" rel="cc:license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" >Creative Commons By-NC-ND License</a>.
No solamente pueden reutilizarse las IRIs del documento para proporcionar metadatos, también puede reutilizarse el contenido textual del documento utilizando @property:
<html xmlns="http://www.w3.org/1999/xhtml" prefix="dc: http://purl.org/dc/terms/" > <head><title>My Home Page</title></head> <body> <h1 property="dc:title">My home-page</h1> <p>Last modified: 16 September 2015</p> </body> </html>
Si algún texto visualizado es diferente del 'valor' actual que representa, se puede añadir un valor más preciso utilizando @content. Opcionalmente, se puede asignar un tipo de dato al valor utilizando @datatype:
<html xmlns="http://www.w3.org/1999/xhtml" prefix="xsd: http://www.w3.org/2001/XMLSchema# dc: http://purl.org/dc/terms/" > <head><title>My Home Page</title></head> <body> <h1 property="dc:title">My home-page</h1> <p>Last modified: <span property="dc:modified" content="2015-09-16T16:00:00-05:00" datatype="xsd:dateTime">16 September 2015</span>.</p> </body> </html>
RDFa permite que un documento contega metadatos con información sobre otros documentos y recursos:
<html xmlns="http://www.w3.org/1999/xhtml" prefix="bibo: http://purl.org/ontology/bibo/ dc: http://purl.org/dc/terms/" > <head> <title>Books by Marco Pierre White</title> </head> <body> I think White's book '<span about="urn:ISBN:0091808189" property="dc:title">Canteen Cuisine</span>' is well worth getting since although it's quite advanced stuff, he makes it pretty easy to follow. You might also like <span about="urn:ISBN:1596913614" property="dc:description" >White's autobiography</span>. </body> </html>
En muchos casos un bloque de marcado contendrá cierto número de propiedades relacionadas con el mismo ítem. Con RDFa es posible indicar el tipo de dicho ítem utilizando @typeof:
<html xmlns="http://www.w3.org/1999/xhtml" prefix="bibo: http://purl.org/ontology/bibo/ dc: http://purl.org/dc/terms/" > <head> <title>Books by Marco Pierre White</title> </head> <body> I think White's book '<span about="urn:ISBN:0091808189" typeof="bibo:Book" property="dc:title">Canteen Cuisine</span>' is well worth getting since although it's quite advanced stuff, he makes it pretty easy to follow. You might also like <span about="urn:ISBN:1596913614" typeof="bibo:Book" property="dc:description" >White's autobiography</span>. </body> </html>
Cuando se trate de pequeñas cantidades marcado, a veces es más fácil utilizar IRIs completas en lugar de CURIEs. El ejemplo anterior también puede escribirse del siguiente modo:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Books by Marco Pierre White</title> </head> <body> I think White's book '<span about="urn:ISBN:0091808189" typeof="http://purl.org/ontology/bibo/Book" property="http://purl.org/dc/terms/title" >Canteen Cuisine</span>' is well worth getting since although it's quite advanced stuff, he makes it pretty easy to follow. You might also like <span about="urn:ISBN:1596913614" typeof="http://purl.org/ontology/bibo/Book" property="http://purl.org/dc/terms/description" >White's autobiography</span>. </body> </html>
Una forma sencilla para definir una porción de un documento utilizando términos de un vocabulario especifico es mediante el uso de @vocab para definir la IRI de un vocabulario por defecto. Por ejemplo, para utilizar los términos de FOAF:
<div vocab="http://xmlns.com/foaf/0.1/" about="#me"> My name is <span property="name">John Doe</span> and my blog is called <a rel="homepage" href="http://example.org/blog/">Understanding Semantics</a>. </div>
El ejemplo anterior produciría las siguientes tripletas que se expresan a continuación en sintaxis Turtle:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . <#me> foaf:name "John Doe" ; foaf:homepage <http://example.org/blog/> .
En casos sencillos la propiedad @property puede utilizarse también en lugar de @rel. En efecto, en caso de que el elemento no contenga @rel, @datatype, o @content, pero si contenga, por ejemplo, el atríbuto @href, el efecto de @property es similar al papel que desempeña @rel. El ejemplo anterior podría haber sido escrito como sigue:
<div vocab="http://xmlns.com/foaf/0.1/" about="#me"> My name is <span property="name">John Doe</span> and my blog is called <a property="homepage" href="http://example.org/blog/">Understanding Semantics</a>. </div>
Esta sección no es normativa
La sección anterior proporciona ejemplos del marcado típico con la finalidad de ilustrar sobre la estructura del marcado RDFa. La expresión "RDFa" es la abreviatura de "RDF en Atributos". Para crear documentos con marcado RDFa no es necesario entender RDF, aunque ciertamente resulta de gran ayuda. Si embargo, si la intención del lector es construir un sistema que consuma la salida RDF de un lenguaje que soporte RDFa, entonces es necesario comprender RDF. Esta sección muestra los conceptos básicos y la terminología de RDF. Para una explicación de RDF más profunda, es conveniente consultar el documentos sobre los conceptos básicos de RDF [RDF-CONCEPTS] y el documento sobre la sintaxis RDF [RDF-SYNTAX].
Los datos estructurados a los que RDFa proporciona acceso es una colección de sentencias (statements). Una sentencia es la unidad básica de información que ha sido construida en un formato específico para facilitar su procesamiento. A su vez, dividiendo grandes conjuntos de información en conjuntos de sentencias, incluso los metadatos más complejos pueden procesarse usando reglas simples.
Para ilustrar lo anterior, consideremos el siguiente conjunto de hechos:
Albert nació el 14 de marzo de 1879, en el Imperio Alemán. Hay un retrato suyo en
la dirección web http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.
Esto podría ser algo difícil de interpretar por parte de una máquina, y ciertamente no se encuentra en un formato que pueda intercambiarse entre aplicaciones de datos. Sin embargo, es posible convertir la información anterior en un conjunto de declaraciones más manejables. Por lo tanto, la misma información podría representarse mediante las siguientes declaraciones más breves:
Albert nació el 14 de marzo de 1879. Albert nació en el Imperio Alemán. Albert tiene un retrato en http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.
Para hacer que esta información sea procesable por máquina, RDF define una estructura para estas sentencias. Una sentencia formalmente se denomina tripleta, lo que significa que está formada por tres componentes. El primero es el sujeto de la tripleta, y es sobre el que se realiza la declaración. En los ejemplos anteriores el subjeto es 'Albert'.
La segunda parte de una tripleta es la propiedad del sujeto que queremos definir. En los ejemplos utilizados, las propiedades serían 'nació el', 'nació en', y 'tiene un retrato en'. Estas propiedades en RDF normalmente se denominan predicados.
Los autores de algunos comentarios indicaron que el uso del término predicado resulta confuso aunque sea correcto. Ellos solicitaron cambiar a lo largo del presente documento dicho término por 'propiedad'. El grupo de trabajo está considerando este cambio, aunque piensa que se trata de un aspecto totalmente editorial.
La parte final de una tripleta se conoce como objeto. En los ejemplos los tres objetos tienen los valores '14 de marzo de 1879', 'el Imperio Alemán', y 'http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg'.
RDFa soporta totalmente el uso de caracteres internacionales. Esto incluye caracteres internacionales en el sujeto, propiedad y localización del objeto.
Dividir la información compleja en unidades manejables ayuda a que
los datos sean más específicos, pero todavía hay cierta ambigüedad.
Por ejemplo, ¿sobre qué 'Albert' estamos hablando? Si otro sistema
tiene más datos sobre 'Albert', ¿cómo es posible saber si son de la
misma persona, y así añadirlos a la lista de hechos que se conocen
acerca de la misma? Si se quisiera encontrar personas nacidas en el
Imperio Alemán, ¿cómo podemos saber que el predicado 'nació en' tiene
el mismo propósito que el predicado 'lugar de nacimiento' que pudiera
existir en algún otro sistema? RDF resuelve este problema mediante la
sustitución de los términos ambiguos con referencias
IRI.
Las referencias IRI suelen utilizarse para identificar las páginas
web, pero RDF las utiliza para proporcionar identificadores únicos
para los conceptos. Por ejemplo, podríamos identificar al sujeto de
todas las declaraciones (la primera parte de cada tripleta) mediante
el uso de DBPedia [http://dbpedia.org],
por lo que el IRI para Albert Einstein, en lugar de la cadena ambigua
'Albert', sería:
<http://dbpedia.org/resource/Albert_Einstein> has the name Albert Einstein. <http://dbpedia.org/resource/Albert_Einstein> was born on March 14, 1879. <http://dbpedia.org/resource/Albert_Einstein> was born in the German Empire. <http://dbpedia.org/resource/Albert_Einstein> has a picture at http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.
Las referencias IRI también se utilizan para identificar de forma
única a los objetos en las declaraciones de metadatos (la tercera
parte de cada tripleta). El retrato de Einstein ya está referenciado
mediante una IRI, pero también podríamos usar una IRI para identificar
de forma única al país 'Imperio Alemán'. Al mismo tiempo, se procede a
indicar que el nombre y fecha de nacimiento son en realidad literales
(y no IRI), al poner comillas alrededor de ellos:
<http://dbpedia.org/resource/Albert_Einstein> has the name "Albert Einstein". <http://dbpedia.org/resource/Albert_Einstein> was born on "March 14, 1879". <http://dbpedia.org/resource/Albert_Einstein> was born in <http://dbpedia.org/resource/German_Empire>. <http://dbpedia.org/resource/Albert_Einstein> has a picture at <http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg>.
Las referencias IRI también se utilizan para garantizar que los predicados no sean ambiguos, y ahora podemos estar seguros de que 'nacido en', 'lugar de nacimiento', 'bithplace' y 'Lieu de naissance' significan lo mismo:
<http://dbpedia.org/resource/Albert_Einstein> <http://xmlns.com/foaf/0.1/name> "Albert Einstein". <http://dbpedia.org/resource/Albert_Einstein> <http://dbpedia.org/property/dateOfBirth> "March 14, 1879". <http://dbpedia.org/resource/Albert_Einstein> <http://dbpedia.org/property/birthPlace> <http://dbpedia.org/resource/German_Empire>. <http://dbpedia.org/resource/Albert_Einstein> <http://xmlns.com/foaf/0.1/depiction> <http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg>.
Aunque las IRI se utilicen siempre para referenciar a los sujetos y los predicados, la parte objeto de una tripleta puede ser una IRI o un literal. En las tripletas del ejemplo, el nombre de Einstein está representado por un literal plano, específicamente una cadena básica con ninguna información sobre su tipo o idioma:
<http://dbpedia.org/resource/Albert_Einstein>
<http://xmlns.com/foaf/0.1/name> "Albert Einstein".
Un literal plano también puede incluir una etiqueta de idioma, que permita expresar texto plano en un lenguaje natural. Por ejemplo, el lugar de nacimiento de Einstein tiene denominaciones distintas en Inglés y en Alemán:
<http://dbpedia.org/resource/German_Empire> rdfs:label "German Empire"@en; rdfs:label "Deutsches Kaiserreich"@de .
Algunos literales, tales como fechas y números, tienen significados
muy específicos, por lo que RDF proporciona un mecanismo para
indicar el tipo de un literal. Un literal
tipado se indica uniendo una IRI al final del literal
plano, y esta IRI indica el tipo de dato del literal. Esta
referencia IRI se basa generalmente en tipos de datos definidos en la
especificación de tipos de datos de XML Schema [XMLSCHEMA11-2].
La siguiente sintaxis se utiliza para expresar inequívocamente la
fecha de nacimiento de Einstein mediante un literal de tipo http://www.w3.org/2001/XMLSchema#date
:
<http://dbpedia.org/resource/Albert_Einstein>
<http://dbpedia.org/property/dateOfBirth>
"1879-03-14"^^<http://www.w3.org/2001/XMLSchema#date>.
En sí mismo RDF no tiene una forma determinada para expresar tripletas, ya que las ideas fundamentales de RDF son la tripleta y el uso de IRIs, y no una sintaxis en particular. Sin embargo, hay una serie de mecanismos para expresar tripletas, como RDF/XML [RDF-SYNTAX-GRAMMAR], Turtle [TURTLE], y por supuesto RDFa. Muchos análisis sobre RDF hacen uso de la sintaxis Turtle para exponer ideas, ya que es bastante compacta. Los ejemplos anteriores ya están utilizando esta sintaxis, y seguirá utilizándose a lo largo de este documento cuando se precise abordar la generación RDF a partir de RDFa. Turtle permite abreviar IRIs largas utilizando el mapeado de IRIs para representar una expresión compacta IRI como sigue:
@prefix dbp: <http://dbpedia.org/property/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . <http://dbpedia.org/resource/Albert_Einstein> foaf:name "Albert Einstein" . <http://dbpedia.org/resource/Albert_Einstein> dbp:birthPlace <http://dbpedia.org/resource/German_Empire> .
En el ejemplo 'dbp:' se ha mapeado con la IRI de DBpedia y 'foaf:' con la IRI del vocabulario 'Friend of a Friend'.
En Turtle cualquier IRI podría abrevisarse de este modo. Esto significa que también se podría haber utilizado la misma técnica para abreviar el identificador de Einstein, así como el indicador del tipo de datos:
@prefix dbp: <http://dbpedia.org/property/> . @prefix dbr: <http://dbpedia.org/resource/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . dbr:Albert_Einstein foaf:name "Albert Einstein"; dbp:birthPlace dbr:German_Empire; dbp:dateOfBirth "1879-03-14"^^xsd:date; foaf:depiction <http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg> . dbr:German_Empire rdfs:label "German Empire"@en; rdfs:label "Deutsches Kaiserreich"@de .
En los ejemplos se utilizará a menudo la siguiente IRI expresada en Turtle:
<>
Esto indica el 'documento actual', es decir, el documento que se está procesando. En realidad siempre habrá una referencia IRI completa basada en la ubicación del documento, pero esta abreviatura sirve para elaborar ejemplos más compactos. Nótese en particular la técnica de abreviar IRIs no es más que una manera de hacer ejemplos más compactos, y las tripletas generadas siempre usarían la forma completa de las IRIs.
Una colección de tripletas se denomina grafo. Todas las tripletas definidas en esta especificación están contenidas en el grafo de salida generado por un procesador RDFa. Para obtener más información sobre los grafos y otros conceptos RDF véase [RDF-CONCEPTS].
Con el fin de permitir expresiones compactas de declaraciones RDF, RDFa permite contraer la mayoría de las referencias IRI mediante una forma denominada "expresión compacta de URI', o CURIE. Un análisis detallado de este mecanismo se encuentra en la sección CURIE y procesamiento de IRIs.
Debe tenerse en cuenta que las CURIEs se utilizan únicamente en el marcado y en los ejemplos Turtle, y que nunca aparecerán en las tripletas generadas que se definen mediante RDF para utilizar referencias IRI.
El creciente uso de metadatos incorporados permite tomar fragmentos de marcado y moverlos de un documento a otro. Esto puede ocurrir a través del uso de herramientas, tales como una función de arrastrar y soltar (drag-and-drop) del navegador, o por medio de fragmentos de código proporcionado a los autores para incluirlos en sus documentos. Un buen ejemplo de esto último es el fragmento de licencias proporcionado por Creative Commons.
Sin embargo, los que participan en la creación de dichos fragmentos (ya sea mediante la creación de herramientas de construcción, o fragmentos de autoría), deben tener en cuenta que esta especificación no dice cómo se procesan los fragmentos. En concreto, el procesamiento de un fragmento 'fuera' del documento completo no está definido porque el procesamiento RDFa se realiza en gran medida a partir del contexto. Las futuras versiones de esta especificación o de otras relacionadas pueden hacer más para definir este comportamiento.
Los desarrolladores de herramientas que procesan fragmentos, o los autores de fragmentos para la inclusión manual, también deberían tener en cuenta qué les podría ocurrir a sus fragmentos una vez que se incluyan en un documento completo. Deberían considerar cuidadosamente la cantidad de información 'contextual' que sería necesaria para una correcta interpretación de dichos fragmentos.
A continuación se incluye una breve descripción de RDFa a partir de la terminología de RDF introducida en esta sección. Puede resultar útil a los lectores con conocimientos de RDF:
Un grafo RDF incluye nodos enlazados mediante relaciones. El propósito de RDFa es permitir la portabilidad de un grafo RDF sencillo a varios tipos de marcado de documentos. La unidad básica de un grafo RDF es una tripleta, en la que un nodo sujeto se enlaza con un nodo objeto a través de un predicato. El nodo sujeto siempre es una referencia IRI o un nodo en blanco (bnode), el predicado siempre es una referencia IRI, y el objeto de una declaración puede ser una referencia IRI, un literal, o un nodo en blanco.
En RDFa, la referencia IRI a un sujeto se indica generalmente usando @about y el predicado se representa mediante @property, @rel, o @rev. Los objetos que son referencias IRI se representa con @resource, @src, o @href, mientras que los objetos que son literales se representan mediante @content o a través del contenido del elemento en cuestión (con un tipo de dato opcional expresado con @datatype y una etiqueta opcional de idioma expresada a través del mecanismo definido por el lenguaje anfitrión de marcado como @xml:lang).
Además de las secciones en las que se indiquen que no son normativas, todas las pautas, esquemas, ejemplos y notas de esta especificación tampoco lo son. Todo lo demás en esta especificación es normativo.
Las palabras clave DEBE (must), NO DEBE (must not), REQUERIDO (required), DEBERÍA (should), NO DEBERÍA (should not), RECOMENDADO (recommended), PUEDE (may), y OPCIONAL (optional) de esta especificación deben interpretarse como se describe en [RFC2119].
Esta especificación utilizar el término grafo de salida para referise a todas las tripletas declaradas por un documento según lo indicado en la sección de Modelo de procesamiento. Un procesador que cumpla la conformidad con RDFa DEBE hacer que esté disponible, para su uso por parte de una aplicación, un grafo RDF simple que contiene todas las posibles tripletas generadas al utilizar las reglas de la sección de Modelo de procesamiento. El término grafo del procesador se usa para denotar el conjunto tripletas con informaciones, avisos y errores que PUEDEN ser generados por el procesador RDFa al informar de su estado. El grafo de salida y el grafo del procesador son grafos separados y NO DEBEN ser almacenados en el mismo grafo por el procesador RDFa.
Un procesador que cumpla la conformidad con RDFa DEBE hacer disponibles tripletas adicionales que hayan sido generadas utilizando reglas no descritas aquí, pero dichas tripletas NO DEBEN estar disponibles en el grafo de salida. (Cuando estas tripletas adicionales estén disponibles en uno o varios grafos RDF adicionales se deberá a que se serán implementaciones específicas, y por lo tanto no se definen es este documento.)
Un procesador que cumpla la conformidad con RDFa DEBE preservar los espacios en blanco tanto en los literales planos como en los literales XML. Sin embargo, puede darse el caso de que la arquitectura en la que funcione un procesador haya realizado cambios en los espacios en blanco de un documento antes de que el documento sea tratado por un procesador RDFa (por ejemplo, [XMLSCHEMA11-1]). Los procesadores están autorizados a "normalizar" espacios en blanco en valores de atributos - véase la sección 3.1.4). A fin de garantizar la máxima coherencia entre los entornos de procesamiento, los autores DEBEN eliminar los espacios en blanco innecesarios en el contenido de los literales planos y XML.
Un procesador que cumpla la conformidad con RDFa DEBE examinar el tipo de medio del documento que
está procesando para determinar el lenguaje anfitrión del mismo. Si el
procesador RDFa no puede determinar el tipo de medio, o no lo
soportara, el procesador RDFa DEBE
procesar el documento como si el tipo de medio fuera application/xml
.
Ver Conformidad del documento con
XML+RDFa. Un lenguaje anfitrión PUEDE
especificar mecanismos adicionales de aviso.
Un procesador que cumpla la conformidad con RDFa PUEDE utilizar mecanismos adicionales (por ejemplo,
DOCTYPE, una extensión de fichero, el elemento raíz, un parámetro
predominante definido por el usuario) para que el lenguaje anfitrión
intente determinar si el tipo de medio no está disponible. Estos
mecanismos no son especificados.
Los lenguajes anfitrión que incorporen RDFa deben cumplir con lo siguiente:
<myml:myElement
property="license">
). Cuando un lenguaje anfitrión no
utilice los atributos en 'no namespace', estos deben referenciarse a través del espacio de
nombres de XHTML (http://www.w3.org/1999/xhtml
).Esta especificación no define un tipo de documento independiente. Los
atributos de este documento están pensados para su integración en
otros lenguajes (por ejemplo, HTML+RDFa o XHTML+ RDFa). Sin embargo,
esta especificación define las reglas de
procesamiento de documentos XML genéricos, es decir, los documentos
entregados bajo el tipo de medio text/xml
o application/xml
.
Estos documentos deben cumplir con cada uno de los siguientes
criterios:
<myml:myElement
property="license">
).
Es posible que una gramática XML tenga atributos nativos que entren en conflicto con los atributos de esta especificación. Esto podría provocar que un procesador RDFa generara tripletas inesperadas.
Cuando un procesador RDFa procesa un documento XML+RDFa, lo hace a través del siguiente contexto inicial:
describedby
,
license
, y role
), definidos en http://www.w3.org/2011/rdfa-context/rdfa-1.1
.dc
), definidos en http://www.w3.org/2011/rdfa-context/rdfa-1.1
.Esta especificación define una serie de atributos y el modo en el que sus valores deben interpretarse para generar tripletas RDF. Esta sección define los atributos y la sintaxis de sus valores.
CDATA
, para proporcionar contenido legible
por máquina para un literal (un 'objeto literal', en terminología
RDF);rel
o property
en el mismo
elemento deber ser añadido a la lista para ese predicado. El valor de
este atributo debe ser
ignorado. La presencia de este atributo causa la creación de una lista
si no existe previamente.NCName ':' ' '+ xsd:anyURI
En todos los casos es posible que los anteriores atributos se utilicen sin ningún valor (por ejemplo, @datatype="") o con un contenido cuya evaluación no devuelva valor alguno al aplicar las reglas de Procesamiento de CURIEs e IRIs (por ejemplo, @datatype="[noprefix:foobar]").
Los atributos RDFa desempeñan papeles diferentes en un documento enriquecido semánticamente. En pocas palabras, estas funciones son:
Muchos atributos aceptan una lista de elementos separados por espacios en blanco. Esta especificación define como el espacio en blanco:
whitespace ::= (#x20 | #x9 | #xD | #xA)+
Cuando los atributos aceptan una lista de elementos separados por espacios en blanco, un procesador RDFa debe ignorar cualquier espacio en blanco al principio o al final de la lista.
Esta definición es consistente con la incluída en [XML10].
El grupo de trabajo está estudiando actualmente las producciones para CURIE a la luz de los recientes comentarios recibidos por el Grupo de Trabajo de RDF y los miembros del Grupo de Trabajo de Aplicaciones RDF. Es posible que en un futuro próximo haya cambios menores en las normas de producción descritas a continuación y que estos cambios sean incompatibles con versiones anteriores. Sin embargo, dicha incompatibilidad se limitará a casos extremos.
El componente clave de RDF es el concepto de IRI, pero estas referencias suelen ser largas y difíciles de manejar. RDFa por tanto, soporta un mecanismo por el cual las IRIs pueden ser abreviadas y que se denominan "expresiones compactas de URI" o simplemente, CURIEs.
Al expandirse, las IRIs resultantes deben formar IRIs sintácticamente válidas [RFC3987]. Para una explicación más detallada debe consultarse la sección Procesamiento de CURIEs e IRIs. El espacio léxico de una CURIE es tal y como se define curie más adelante. El espacio de valores es el conjunto de IRIs.
Una CURIE se compone de dos componentes, un prefijo
y una referencia.
El prefijo está separado de la referencia mediante el símbolo de dos
puntos (:
). En el uso general, es posible omitir el prefijo
y, por tanto, crear una CURIE que haga uso de la equivalencia definida
para el 'prefijo por defecto'; en RDFa el 'prefijo por defecto' es http://www.w3.org/1999/xhtml/vocab#
.
También es posible omitir tanto el prefijo como los dos puntos, y crear
de este modo una CURIE que contenga sólo una referencia que haga uso de
la equivalencia 'sin prefijo' ('no prefix'). Esta especificación no
define la equivalencia para 'sin prefijo'. Los lenguajes anfitrión de
RDFa no deben definir la
equivalencia para 'sin prefijo'.
El 'prefijo por defecto' de RDFa no debe confundirse con el 'espacio de nombres por defecto' (default namespace) definido en [XML-NAMES]. Un procesador RDFa no debe tratar una declaración de un 'espacio de nombre por defecto' XML-NAMES como si se estableciera el 'prefijo por defecto'.
La sintaxis general de una CURIE puede resumirse como sigue:
prefix ::= NCName reference ::= ( ipath-absolute / ipath-rootless / ipath-empty ) [ "?" iquery ] [ "#" ifragment ] (como se define en [RFC3987]) curie ::= [ [ prefix ] ':' ] reference safe_curie ::= '[' [ [ prefix ] ':' ] reference ']'
No se requiere la producción safe_curie
,
incluso en situaciones en las que se permita que el valor de un atributo
sea una CURIE o una IRI: Una IRI que utiliza un esquema que no se
encuentre en el ámbito de una equivalencia no puede confundirse con una
CURIE. El concepto de safe_curie se mantiene por compatibilidad con
versiones anteriores.
Es posible definir una equivalencia para un prefijo CURIE
de tal modo que opacaría un esquema IRI definido. Por ejemplo, un
documento podría definir la equivalencia del prefijo 'mailto' con
'http://www.example.com/addresses/'. Entonces un atributo @resource con el valor
'mailto:user@example.com' podría crear una tripleta con el objeto
'http://www.example.com/addresses/user@example.com'. Además, es
posible, aunque poco probable, que se introduzcan esquemas que en el
futuro entren en conflicto con las equivalencias de prefijos definidas
en el documento (por ejemplo, la nueva propuesta del esquema 'widget' [WIDGETS-URI]).
En ningún caso esta opacidad de RDFa del esquema subyacente alteraría la
manera en la que otros agentes tratarían dicha IRI. Podría ocurrir, sin
embargo, que el uso de CURIE previsto por parte del autor del documento
sea malinterpretado por otro agente, considerándola una IRI. El grupo de
trabajo considera que este riesgo es mínimo.
Una evaluación normal de CURIEs precisaría de la siguiente información:
:p
);p
);_:p
). En RDFa dichos valores se definen del siguiente modo:
Una CURIE es una representación de una IRI completa. Las reglas para determinar dicha IRI son:
prefijo
vacío y una referencia
,
la IRI se obtiene tomando el prefijo por defecto actual y
concatenándolo con la referencia
. Si no existe
equivalencia alguna para el prefijo por defecto actual, entonces no se
trata de una CURIE válida y debe
ignorarse. prefijo
no vacío y una referencia
, y exista una equivalencia en
el ámbito del prefijo
(cuando la comparación sea
insensible a mayúsculas y minúsculas), entonces se creará la IRI
utilizando dicha equivalencia y concatenándola con la referencia
.prefijo
,
entonces en valor obtenido no es una CURIE. Véase la sección Uso general de términos en atributos para consultar acerca del modo en el que los elementos sin dos puntos pueden interpretarse como algún tipo de datos por parte de procesadores RDFa.
Esta sección no es normativa.
En muchos casos, los diseñadores de lenguajes han intentado utilizar QNames como un mecanismo de extensión [XMLSCHEMA11-2]. QNames permite una gestión independiente de la colección de nombres, pudiéndose asignar los nombres a un recurso. Desafortunadamente, los QNames no son adecuados en la mayoría de los casos porque 1) el uso de QNames como identificadores en los valores de atributos y contenidos de elementos es problemático, tal y como se discute en [QNAMES] y 2) la sintaxis de QNames es excesivamente restrictiva y no permite expresar todas las posibles IRIs.
Un ejemplo específico de este problema puede verse al intentar el
nombre de una colección de libros. En un QName, la parte después de
los dos puntos debe ser un nombre de elemento válido, por lo que un
ejemplo como el siguiente no es válido: isbn:0321154991
Este no es un QName válido simplemente porque "0321154991" no es un nombre de elemento válido. Sin embargo, en el ejemplo dado, no se desea definir un nombre de elemento válido de todos modos. Toda la razón para utilizar un QName era para hacer referencia a un elemento de un ámbito específico - el de ISBN. Además, en este ejemplo, se desea que los nombres dentro de ese ámbito sean equivalenes a una IRI que revele el significado de dicho ISBN. Como se puede ver, la definición de QNames y este caso de uso (relativamente frecuente) están en conflicto entre sí.
Esta especificación afronta dicho problema mediante la definición de CURIEs. Sintácticamente, CURIEs son un superconjunto de QNames.
Téngase en cuenta que esta especificación se dirige a diseñadores de lenguajes, no a los autores de documentos. Cualquier diseñador de lenguaje que considere el uso de QNames como una forma de representar IRIs o elementos únicos debe considerar el uso de CURIEs en su lugar:
En esta sección se examina un conjunto genérico de reglas de procesamiento para crear un conjunto de tripletas que representen los datos estructurados existentes en un documento RDFa. El procesamiento no necesita seguir la técnica de recorrido del DOM descrita aquí, aunque el efecto de otras formas de procesamiento será el mismo que si se realizara el procesamiento descrito en esta sección. El modelo de procesamiento se explica utilizando la idea de recorrido del DOM hace que sea más sencilla la descripción (en particular en relación al contexto de evaluación).
La evaluación de un documento con tripletas RDFa se lleva a cabo comenzando por el objeto de documento, y visitando a continuación cada uno de sus elementos hijo, en el orden en el que se encuentren en el documento, aplicando las reglas de procesamiento. El proceso es recursivo por lo que para cada elemento hijo el procesador también visita cada uno de sus elementos hijo aplicando las mismas reglas de procesamiento.
En algunos entornos, habrá poca diferencia entre comenzar por el elemento raiz del documento y comenzar por el objeto de documento en sí. Esto explica la causa por la que en algunos entornos existe información importante en el nivel del objeto de documento que no está presente en el elemento raíz.
Según continúa el proceso se aplican las reglas que pueden generar tripletas, y también puede cambiar la información del contexto de evaluación que a continuación se utiliza para procesar los elementos descendientes.
Esta especificación no dice nada acerca de lo que debería suceder con las tripletas generadas, o si pueden generarse más tripletas durante el proceso aquí descrito. Sin embargo, para que un procesador RDFa cumpla la conformidad debe actuar aplicando como mínimo las reglas de esta sección y produciendo un grafo RDF sencillo. Como se describe en la sección Conformidad del procesador RDFa, las tripletas adicionales generadas no deben aparecer en el grafo de salida. Estas pueden estar incluidas en el grafo del procesador.
Durante el procesamiento, cada regla se aplica utilizando información proporcionada por un contexto de evaluación. Cuando comienza el procesamiento se crea un contexto inicial. Ese contexto tiene los siguientes componentes:
base
de (X)HTML. Lo
importante es que se establece una IRI a partir de la que se pueden
resolver las rutas relativas. Durante el procesamiento, se crean nuevos contextos de evaluación que se transmiten a cada elemento secundario. Las reglas iniciales descritas a continuación determinarán los valores de los elementos en el contexto. Entonces las reglas básicas crearán nuevas tripletas al combinar información proporcionada por un elemento con información proporcionada por el contexto de evaluation.
Durante el procesamiento se precisan una serie de valores de ámbito local:
rdf:type
con tipos especificados en @typeof.
El encadenamiento de declaraciones es una característica de RDFa que permite a los autores enlazar varias declaraciones RDF al mismo tiempo, haciendo innecesario el uso de marcado repetitivo. Por ejemplo, si un autor tuviera que añadir ciertas declaraciones como hijas de un objeto recurso, dichas declaraciones deberían interpretarse como asociadas a dicho recurso:
<div about="http://dbpedia.org/resource/Albert_Einstein"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> <div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire"> <span property="dbp:conventionalLongName">the German Empire</span> </div> </div>
En este ejemplo puede verse que un recurso objeto ('German_Empire'), es el sujeto para las declaraciones anidadas. Este marcado también muestra el patrón de encadenamiento básico de "A tiene un B tiene un C" (en el ejemplo, Einstein tiene un lugar de nacimiento identificado como 'German_Empire', el cual tiene asociado como nombre largo en Inglés "the German Empire").
También es posible que los contenidos de las declaraciones anidadas proporcionen el objeto para contener las declaraciones - esencialmente lo contrario del ejemplo anterior. Para ilustrar esto, puede verse un ejemplo del tipo de encadenamiento descrito, que muestra cómo podría marcarse de modo más eficiente. Para empezar, se marca el hecho de que Albert Einstein tenía, en algún momento de su vida, una residencia tanto en el Imperio alemán como en Suiza:
<div about="http://dbpedia.org/resource/Albert_Einstein"> <div rel="dbp-owl:residence" resource="http://dbpedia.org/resource/German_Empire"></div> <div rel="dbp-owl:residence" resource="http://dbpedia.org/resource/Switzerland"></div> </div>
Seguidamente, se muestra la misma información, pero creando en esta ocasión una tripleta incompleta desde la parte de residencia y a continuación se utilizan una serie de subjetos adicionales para 'completar' dicha tripleta:
<div about="http://dbpedia.org/resource/Albert_Einstein" rel="dbp-owl:residence"> <span about="http://dbpedia.org/resource/German_Empire"></span> <span about="http://dbpedia.org/resource/Switzerland"></span> </div>
En este ejemplo, la tripleta incompleta se completa dos veces, una para el Imperio Alemán y otra para Suiza, ofreciendo exactamente la misma información del primer ejemplo:
<http://dbpedia.org/resource/Albert_Einstein> dbp-owl:residence <http://dbpedia.org/resource/German_Empire> . <http://dbpedia.org/resource/Albert_Einstein> dbp-owl:residence <http://dbpedia.org/resource/Switzerland> .
En encadenamiento a veces puede involucrar elementos que contengan un marcado relativamente mínimo, por ejemplo mostrando sólo un recurso, o sólo un predicado. En el ejemplo siguiente, el elemento img se utiliza para transportar una imagen de Einstein:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<div rel="foaf:depiction">
<img src="http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg" />
</div>
</div>
Cuando se utilice dicho marcado mínimo, cualquiera de los atributos relacionados con los recursos podría actuar como un sujeto o un objeto en el encadenamiento:
<div about="http://dbpedia.org/resource/Albert_Einstein"> <div rel="dbp-owl:residence"> <span about="http://dbpedia.org/resource/German_Empire"></span> <span about="http://dbpedia.org/resource/Switzerland"></span> </div> </div>
Debe tenerse en cuenta que, como se ha indicado anteriormente, en muchas situaciones @property y @rel son intercambiables. Esto no sucede así en el encadenamiento. Partiendo del primer ejemplo, si se utilizara de la siguiente forma:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div property="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire">
<span property="dbp:conventionalLongName">the German Empire</span>
</div>
</div>
El sujeto para 'German Empire' seguiría siendo Albert Einstein (y esto sería en efecto un error). Esta es la principal diferencia entre @property y @rel: el segundo induce encadenamiento, mientras que el primero por lo general no lo hace.
Puesto que RDFa es en definitiva un medio de transporte para RDF, un concepto clave es el de recurso y su manifestación en forma de IRI. RDF trabaja con IRIs completas (no rutas relativas); cuando se convierte el marcado RDFa en tripletas, cualquier IRI relativa debe resolverse en relación con una IRI base, utilizando el algoritmo definido en la sección 6.5 de RFC 3987 [RFC3987], Resolución de referencia. Los valores de los atributos RDFa pueden utilizar tres tipos de datos diferentes al referirse a una IRI: IRI, SafeCURIEorCURIEorIRI o TERMorCURIEorAbsIRI. Todos estos atributos se asignan, tras el procesamiento, a IRIs. La manipulación de estos atributos se realiza del siguiente modo:
Una consecuencia de esto es que cuando el valor de un atributo de este tipo de datos sea una cadena vacía (por ejemplo @about=""), dicho valor se resuelve como una IRI. Una IRI "" (vacía) es una IRI relativa que se interpreta que es igual a la base. En otras palabras, un valor de "" generalmente se resuelve como la IRI del documento actual.
Una consecuencia relacionada con esto es que cuando el valor de un atributo de este tipo de dato es una SafeCURIE vacía (por ejemplo @about="[]"), ese valor no se resuelve como una IRI y por tanto el valor es ignorado.
Debe tenerse en cuenta que es posible que se ignoren para los valores en un atributo. Cuando esto ocurre, el atributo debe tratarse como si estuviera vacío.
Por ejemplo, la IRI completa en DBPedia para Albert Einstein es:
http://dbpedia.org/resource/Albert_Einstein
Esto puede ser abreviado por los autores usando una CURIE para que la información sea más fácil de manejar. En el primer paso el autor crea una asignación de prefijo que vincula un prefijo con algún segmento inicial de la IRI. En RDFa estas asignaciones se expresan utilizando @prefix:
<div prefix="db: http://dbpedia.org/">
...
</div>
Una vez que se establece el prefijo, un autor puede utilizarlo para abrevias IRIs del siguiente modo:
<div prefix="db: http://dbpedia.org/">
<div about="db:resource/Albert_Einstein">
...
</div>
</div>
El autor es libre de dividir el IRI en cualquier momento. Sin embargo, dado que un uso común de las CURIEs es hacer que estén disponibles bibliotecas de términos y valores, el prefijo por lo general se asigna a un segmento común que proporciona la máxima reutilización, a menudo por quienes administran la biblioteca de términos. Por ejemplo, puesto que DBPedia contiene una enorme lista de recursos, es más eficiente crear una asignación de prefijo que utiliza la ubicación de la base de los recursos:
<div prefix="dbr: http://dbpedia.org/resource/"> <div about="dbr:Albert_Einstein"> ... </div> <div about="dbr:Baruch_Spinoza"> ... </div> </div>
Las equivalencias de prefijos CURIE se definen sobre el elemento actual y sus descendientes. Las equivalencias interiores de un prefijo dado tienen prioridad. Por ejemplo, las IRIs expresadas por las siguientes dos CURIEs son diferentes, a pesar del prefijo común, porque las asignaciones de prefijo son de ámbito local:
<div prefix="dbr: http://dbpedia.org/resource/"> <div about="dbr:Albert_Einstein"> ... </div> </div> <div prefix="dbr: http://someotherdb.org/resource/"> <div about="dbr:Albert_Einstein"> ... </div> </div>
En general es una mala práctica redefinir equivalencias de prefijos en un documento. En particular, aunque se permite definir equivalencias de un prefijo con diferentes valores en diferentes lugares en un documento podría resultar confuso. El grupo de trabajo recomienda que los autores de documentos utilicen el mismo prefijo para definir la equivalencia con el mismo vocabulario a lo largo de todo el documento. Muchos vocabularios han recomendado nombres de prefijos. El grupo de trabajo recomienda utilizar dichos nombres siempre que sea posible.
Existen ciertas formas de utilizar CURIEs en los atributos y cuyo tratamiento debe ser diferente en cada caso. Estas son:
Un atributo vacío (por ejemplo, typeof=''
)
todavía es una CURIE y se procesa como tal. Las reglas
para este procesamiento se definen en la sección Secuencia.
Sin embargo, de forma específica el valor de un atributo vacío nunca
es tratado como una IRI relativa por esta especificación.
Un ejemplo de un atributo que puede contener una CURIE o IRI es @about. Una IRI podría expresarse directamente así:
<div about="http://dbpedia.org/resource/Albert_Einstein">
...
</div>
mientras que para expresar la IRI anterior como una CURIE se podría hacer lo siguiente:
<div about="dbr:Albert_Einstein">
...
</div>
El autor también podría utilizar una CURIE segura:
<div about="[dbr:Albert_Einstein]">
...
</div>
Dado que los valores que no sean CURIEs debe ser ignorados, el siguiente valor en el atributo @about no establecería un nuevo sujeto, puesto que @about no permite el uso de TERMINOS, y la CURIE no tiene un separador de prefijo.
<div about="[Albert_Einstein]">
...
</div>
Sin embargo, el marcado del siguiente ejemplo establecería un sujeto, ya que no se trata de una CURIE aunque si es una IRI relativa válida:
<div about="Albert_Einstein">
...
</div>
Ha de tenerse en cuenta que algunos atributos RDFa pueden tomar TERMINOS como valores. Este aspecto es tratado en la siguiente sección.
Algunos atributos RDFa tienen tipos de datos que permiten referenciar términos. RDFa define la sintaxis de un término como:
term ::= NCNameStartChar termChar* termChar ::= ( NameChar - ':' ) | '/'
Para evitar dudas, esta definición entiende por 'term' en RDFa a un NCName XML que también permite el uso del caracter "/", siempre y cuando no esté al inicio de la cadena.
Cuando un atributo RDFa permite el uso de un término, y el valor que se está evaluando coincide con la producción indicada anteriormente para un término, se transforma en un IRI mediante la siguiente lógica:
término
.término
coincide con un elemento en la lista de equivalencias locales de términos.
Primero se compara con la lista sensible a las mayúsculas, y si no
existe ninguna coincidencia entonces se realiza una comparación
insensible a mayúsculas. Si existe alguna coincidencia se utiliza
la IRI asociada.término
no tiene una IRI
asociada y debe ser
ignorado.Un vocabulario local por defecto puede definirse por el Lenguaje Anfitrión como parte del contexto inicial, y puede ser reemplazado con el elemento actual y sus hijos utilizando @vocab.
Las reglas generales mostradas en la sección anterior se aplican a los atributos RDFa de las siguientes formas:
Cualquier valor que coincida con un término definido debe expandirse a su correspondiente IRI. Por ejemplo, en los siguientes casos:
<link rel="license" href="http://example.org/license.html" /> <link rel="xhv:license" href="http://example.org/license.html" />
cada uno de ellos generaría la siguiente tripleta:
<> <http://www.w3.org/1999/xhtml/vocab#license> <http://example.org/license.html> .
En RDFa, es posible establecer relaciones utilizando varios tipos de referencias a recursos, incluidos los nodos en blanco (bnodes). Si un sujeto o un objeto es definido mediante una CURIE, y dicha CURIE nombra explícitamente un nodo en blanco, entonces un procesador que cumpla la conformidad con RDFa debe crear el nodo en blanco cuando es hallado durante el análisis. El procesador RDFa también debe asegurarse de que un nodo en blanco creado automáticamente (por ejemplo, como resultado de un encadenamiento) no tenga un nombre que colisione con otro nodo en blanco definido por una referencia CURIE explícita.
Considérese el siguiente ejemplo:
<link about="_:john" rel="foaf:mbox" href="mailto:john@example.org" /> <link about="_:sue" rel="foaf:mbox" href="mailto:sue@example.org" /> <link about="_:john" rel="foaf:knows" resource="_:sue" />
En el fragmento anterior, se crean explícitamente dos nodos en blanco como sujetos de las tripletas. Dichos nodos son referenciados para desmostrar las relaciones entre las partes. Tras el procesamiento, se generan las siguientes tripletas:
_:john foaf:mbox <mailto:john@example.org> . _:sue foaf:mbox <mailto:sue@example.org> . _:john foaf:knows _:sue .
A nivel interno, los procesadores RDFa utilizan implementaciones que dependen de los identificadores para los nodos en blanco. Cuando se recuperan las tripletas se utilizan nuevos identificadores para los nodos en blanco, que normalmente no suelen tener relación con los identificadores originales. Sin embargo, las implementaciones deben asegurarse que los identificadores generados para los nodos en blanco sean consistentes: cada nodo en blanco debe tener su propio identificador, todas las referencias a un nodo en blanco en particular usarán el mismo identificador y diferentes nodos en blanco deberán tener diferentes identificadores.
Como un caso especial, _:
es también una referencia
válida para un nodo en blanco específico.
El procesamiento normalmente comienza después de que el documento a
analizar se haya cargado completamente. Sin embargo, no hay ningún
requisito para que esto siempre sea así, y sin duda es posible
utilizar un enfoque basado en secuencias, tales como SAX [SAX]
para extraer la información RDFa. Sin embargo, si se utiliza algún
otro enfoque diferente de la técnica de recorrido DOM definida aquí,
es importante asegurarse de que las reglas de procesamiento
específicas del lenguaje anfitrión sean aplicadas (por ejemplo,
XHTML+RDFa [XHTML-RDFA]
indica que el elemento base
puede ser utilizado, y base
afectará a la interpretación de IRIs en los elementos meta
o link
aunque estén delante del elemento base
en
la secuencia).
En esta sección el término 'recurso' se utiliza para referirse a 'IRI or nodo en blanco' Es posible que este término sea reemplazado por algún otro más formal tras consultar con otros grupos. Los cambios en este término no conllevarán cambios en la secuencia de procesamiento.
Al inicio del procesamiento, se crea un contexto inicial de evaluation, como se indica a continuación:
base
de HTML); El procesamiento comienza aplicando al documento objeto las reglas de procesamiento especificadas más adelante, y dentro de este contexto inicial de evaluación. Todos los elementos de la jerarquía también son procesados según las reglas indicadas a continuación, prevaleciendo siempre las reglas locales definidas en cada elemento, aunque el contexto de evaluación utilizado para cada conjunto de reglas se basará en reglas que puedan haber sido aplicadas previamente.
Esta especificación define las reglas de procesamiento para atributos opcionales que puedan no estar presentes en todos los lenguajes anfitrión (como por ejemplo @href). Si estos atributos no son soportados en el lenguaje anfitrión, entonces las reglas de procesamiento correspondiente no serán relevantes para ese lenguaje.
Las reglas de procesamiento son:
si existe un atributo typeof entonces se establece como recurso tipado el recurso obtenido de la primera equivalencia que cumpla la siguiente regla:
Finalmente, si existe un atributo @typeof se establece entonces el valor del recurso tipado con el del nuevo sujeto.
si el atributo @typeof está presente, entonces se asigna el valor del recurso tipado al nuevo sujeto.
Si no se proporciona ningún recurso, entonces se aplicará la primera de las siguientes reglas que se cumpla:
Entonces se establece el valor del recurso objeto actual con el recurso obtenido al cumplirse la primera de las siguientes reglas que se cumpla:
Si @typeof está presente y @about no, se asigna el valor del recurso tipado al recurso objeto actual
Obsérvese que el valor final del recurso objeto actual tendrá un valor nulo (null) asignado en la inicialización, una IRI completa o nodo en blanco.
XMLLiteral
del vocabulario http://www.w3.org/1999/02/22-rdf-syntax-ns#
.
El literal actual puede ser tanto el valor de @content (si está presente) o una cadena creada por la concatenación de los valores de todos los nodos de texto descendientes del propio elemento actual. La cadena final incluye el tipo dato IRI, tal y como se describe en [RDF-CONCEPTS], obtenido según se indica en la sección Procesamiento de IRIs y CURIEs.
El literal actual será el valor de @content (si está presente) o una cadena creada por la concatenación del valor de todos los nodos de texto descendientes del propio elemento actual.
XMLLiteral
en el vocabulario http://www.w3.org/1999/02/22-rdf-syntax-ns#
.
El valor del literal
XML es una cadena creada por la codificación a texto
de todos los nodos descendientes del elemento actual, sin incluir
al propio elemento, y estableciéndolo como tipo de dato XMLLiteral
del vocabulario http://www.w3.org/1999/02/22-rdf-syntax-ns#
.
El formato del contenido codificado se define como se indica
en [XML-EXC-C14N].
Con el fin de mantener la máxima portabilidad de este literal, los hijos del nodo actual que son elementos deben tener las declaraciones actuales del espacio de nombres XML (si los hay) declaradas en el elemento serializado. Puesto que el nodo de elemento hijo también podría declarar nuevos espacios de nombres XML, el procesador RDFa debe tener cuidado al combinarlos cuando se genere la definición del elemento serializado. Para evitar cualquier duda, cualquier re-declaración sobre el nodo hijo debe tener prioridad sobre las declaraciones que estaban activas en el nodo actual.
Adicionalmente, si existe algún valor para el idioma actual entonces el valor del literal plano debería incluir la información de este idioma, tal y como se describe en [RDF-CONCEPTS]. El literal actual sería el valor de @content (si está presente) o una cadena creada concatenando el contenido de texto de cada uno de los elementos descendientes del elemento actual siguiendo el orden en el que se encuentran en el documento.
El valor de la propiedad actual se utilizaría entonces con cada predicado del siguiente modo:
http://www.w3.org/1999/02/22-rdf-syntax-ns#nil
http://www.w3.org/1999/02/22-rdf-syntax-ns#first
http://www.w3.org/1999/02/22-rdf-syntax-ns#rest
http://www.w3.org/1999/02/22-rdf-syntax-ns#nil
Las reglas de procesamiento mostradas en la sección anterior están diseñadas para extraer de un documento la mayor cantidad de tripletas como sea posible. El procesador RDFa está diseñado para continuar con el procesamiento, incluso en el caso de encontrar errores. Por ejemplo, no resolver una asignación de prefijo o término daría como resultado que el procesador RDFa se salte la generación de una tripleta y continúe procesando el documento. Hay casos en los que conocer cada advertencia o error del procesador RDFa podría ser beneficioso para los autores. El grafo del procesador está diseñado como mecanismo para capturar del Procesador de RDFa todos los mensajes informativos, de advertencia y de error en forma de tripletas. Las tripletas de estado pueden ser recuperadas y utilizadas para ayudar en la edición RDFa o en la detección de errores automáticos.
Si un procesador RDFa soporta la generación de grafos de procesador, entonces debe generar un conjunto de tripletas cuando ocurra alguno de los siguientes problemas:
rdfa:Error
debe
generarse cuando falle totalmente el procesamiento de un documento
como resultado de que no cumpla la conformidad del marcado del
lenguaje anfitrión.rdfa:Warning
debe
generarse cuando falle la resolución de un prefijo CURIE.rdfa:Warning
debe
generarse cuando falle la resolución de un término. Otras implementaciones específicas de tripletas rdfa:Info
,
rdfa:Warning
o rdfa:Error
pueden generase por parte del procesador RDFa.
El acceso al grafo del procesador puede llevarse a cabo en una varias formas en función del tipo de procesador RDFa y del método de acceso que utilice el desarrollador.
Procesadores basados en SAX o los procesadores que utilizan funciones o métodos de retrollamadas para informar sobre la generación de tripletas entran dentro de lo que se conoce como Procesadores RDFa basados en eventos. Para este tipo de procesadores, el software debe permitir al desarrollador registrar una función o retrollamada que es invocada cuando se genere una tripleta del grafo del procesador. La retrollamada puede ser la misma que la utilizada para el grafo de salida siempre que pueda determinarse si una tripleta pertenece al grafo del procesador o al grafo de salida.
Un Procesador RDFa de grafos enteros se define como cualquier procesador RDFa que analiza el documento en su totalidad y únicamente permite al desarrollador acceder a las tripletas una vez completado el procesamiento. Los procesadores RDFa encuadrados en esta categoría RDFa suelen expresar la salida a través de llamadas simples utilizando RDF/XML, N3, TURTLE o notación N-Triples. Para estos procesadores, el software debe permitir al desarrollador especificar si desean recuperar el grafo de salida, el grafo del procesador, o ambos combinándolos en un único grafo suministrado por el procesador. Si no se especifica ninguna preferencia sobre el grafo, debe devolverse grafo de salida.
Un Procesador
RDFa basado en un servicio web se define como todo
Procesador RDFa capaz de procesar un documento mediante HTTP GET,
POST o acción similar a través de la IRI de un Procesador RDFa. Para
este tipo de procesadores RDFa, el software debe
permitir que el solicitante especifique si desea recuperar el grafo de
salida, el grafo
del procesador, o ambos combinándolos en un único grafo
suministrado por el servicio web. El parámetro de consulta rdfagraph
debe usarse para especificar
el valor. Los valores permitidos son output
, processor
o ambos valores en cualquier orden, separados por una coma.
Si no se especifica ninguna preferencia sobre el grafo, debe
devolverse grafo
de salida.
Para garantizar la interoperabilidad, se ha definido un núcleo jerárquico de clases para el contenido del grafo del procesador. Los errores o avisos individuales son recursos (normalmente nodos en blanco) de un tipo específico, con propiedades adicionales que ofrecen más detalles sobre las condiciones del error o del aviso. Esta especificación define únicamente el nivel superior de clases y aquellas que se refieren a las condiciones del error o del aviso definidos explícitamente en este documento. Pueden definirse otras implementaciones específicas de subclases por parte del procesador RDFa.
Las clases de nivel superior son rdfa:Error
, rdfa:Warning
,
y rdfa:Info
, definidas como parte del vocabulario
RDFa. Además, se define una propiedad en dichas clases. rdfa:context
,
que proporciona un contexto adicional sobre el error, or ejemplo, la
respuesta http, información XPath, o simplemente la IRI del recurso
RDFa. El uso de esta propiedad es opcional, y puede usarse más de
una tripleta sobre el mismo sujeto. Por último, para los casos de
errores y avisos deberíAN
usarse las propiedades dc:description
y dc:date
.
dc:description
debería proporcionarse una descripción
breve, legible por personas pero cuya implementación dependerá del
error. dc:date
debería indicar el momento en el que se
detectó el error, del modo más preciso posible, para detectar, por
ejemplo, posibles errores en la red.
El siguiente ejemplo muestra el conjunto mínimo de tripletas que
deberían estar presentes en el grafo del procesador como resultado
de un error (el contenido literal del predicado dc:description
dependerá de la implementación):
@prefix rdfa: <http://www.w3.org/ns/rdfa#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix dc: <http://purl.org/dc/terms/> . [] a rdfa:DocumentError ; dc:description "The document could not be parsed due to parsing errors" ; dc:date "2010-06-30T13:40:23"^^xsd:dateTime .
En el siguiente ejemplo, algo más elaborado, se hace uso de la
propiedad rdfa:context
para proporcionar más
información utilizando vocabularios externos para representar
encabezados HTTP o información XPointer (debe tenerse en cuenta que
un procesador no puede tener en todos los casos, es decir, no se
precisa la información de rdfa:context
):
@prefix rdfa: <http://www.w3.org/ns/rdfa#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix dc: <http://purl.org/dc/terms/> . @prefix ptr: <http://www.w3.org/2009/pointers#> . @prefix ht: <http://www.w3.org/2006/http#> . [] a rdfa:DocumentError ; dc:description "The document could not be parsed due to parsing errors" ; dc:date "2010-06-30T13:40:23"^^xsd:dateTime ; rdfa:context <http://www.example.org/doc> ; rdfa:context [ a ptr:Pointer ; # detailed xpointer/xpath information provided here to locate the error ] ; rdfa:context [ a ht:Response ; ht:responseCode <http://www.w3.org/2006/http#404> # The HTTP response headers on the request for the source file. ].
Los procesadores pueden realizar la expansión del vocabulario utilizando de forma limitada reglas de inferencia RDFS y OWL, tal y como se describe en la sección Expansión de vocabularios RDFa.
Esta sección no es normativa
Esta sección proporciona un análisis en profundidad de los pasos de procesamiento descritos en la sección previa. También incluye ejemplos que pueden ayudar a aclarar algunos de dichos pasos.
La clave del procesamiento es que una tripleta se genera siempre que se detecta una combinación predicado/objeto. La tripleta actual generada incluirá un sujeto que debe haberse establecido previamente, por lo que este debe seguirse en el contexto de evaluation actual y se denomina sujeto padre. Puesto que el sujeto por defecto para el documento actual no se establecerá de forma explícita, una combinación predicado/objeto es siempre suficiente para generar una o más tripletas.
Los atributos para establecer un predicado son @rel, @rev y @property, mientras que los atributos para definir un objeto son @resource, @href, @content, y @src. @typeof permite establecer tanto un predicado como un objeto al mismo tiempo (y también un sujeto cuando aparece en ausencia de otros atributos que deberían establecer un sujeto). El contenido de un documento también puede establecer un objeto, si en lugar de @content está presente @property.
Hay muchos ejemplos en esta sección. Todos los ejemplos están escritos utilizando XHTML+RDFa. Sin embargo, las explicaciones son relevantes con independencia del lenguaje anfitrión.
Cuando se crean tripletas serán siempre en relación con un recurso sujeto proporcionado por un nuevo sujeto (si hay reglas sobre el elemento actual que hayan establecido un sujeto) o por un sujeto padre, tal como se paso a través del contexto de evaluación. En esta sección se analizan las formas específicas en las que se establecen estos valores. Ha de tenerse en cuenta que no importa cómo se establece el sujeto, por lo que en esta sección se utiliza la noción de sujeto actual que puede ser un nuevo sujeto o un sujeto padre.
Cuando comienza el análisis, el sujeto
actual será el IRI del documento que se está analizando, o
un valor establecido por un mecanismo proporcionado por el
lenguaje anfitrión (por ejemplo, el elemento base
en
(X)HTML). Esto significa que por defecto todos los metadatos
encontrados en el documento se referirán al documento en sí:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Jo's Friends and Family Blog</title> <link rel="foaf:primaryTopic" href="#bbq" /> <meta property="dc:creator" content="Jo" /> </head> <body> ... </body> </html>
Esto generaría las siguientes tripletas:
<> foaf:primaryTopic <#bbq> . <> dc:creator "Jo" .
Es posible que los datos aparezcan en cualquier lugar del documento:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Jo's Blog</title>
</head>
<body>
<h1><span property="dc:creator">Jo</span>'s blog</h1>
<p>
Welcome to my blog.
</p>
</body>
</html>
lo que generaría la siguiente tripleta:
<> dc:creator "Jo" .
En (X)HTML el valor de base
puede cambiar el valor
inicial del sujeto
actual:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<base href="http://www.example.org/jo/blog" />
<title>Jo's Friends and Family Blog</title>
<link rel="foaf:primaryTopic" href="#bbq" />
<meta property="dc:creator" content="Jo" />
</head>
<body>
...
</body>
</html>
Un procesador RDFa debería generar ahora las siguientes tripletas, con independencia de la IRI del documento:
<http://www.example.org/jo/blog> foaf:primaryTopic <http://www.example.org//jo/blog#bbq> . <http://www.example.org/jo/blog> dc:creator "Jo" .
Según avance el procesamiento, cualquier atributo @about cambiará el sujeto actual.
El valor de @about
es una IRI o una CURIE. Si se trata de una IRI relativa entonces
debe resolverse contra el valor actual de base. Para mostrar como afecta esto a la
sentencia, debe considerarse en este marcado como las propiedades
dentro del elemento body
de (X)HTML se convierten en
parte de un nuevo objeto de evento de calendario, en vez de
referirse al documento tal y como sucede en la cabecera del
documento:
<html xmlns="http://www.w3.org/1999/xhtml" prefix="cal: http://www.w3.org/2002/12/cal/ical#"> <head> <title>Jo's Friends and Family Blog</title> <link rel="foaf:primaryTopic" href="#bbq" /> <meta property="dc:creator" content="Jo" /> </head> <body> <p about="#bbq" typeof="cal:Vevent"> I'm holding <span property="cal:summary"> one last summer barbecue </span>, on <span property="cal:dtstart" content="2015-09-16T16:00:00-05:00" datatype="xsd:dateTime"> September 16th at 4pm </span>. </p> </body> </html>
Con este marcado un procesador RDFa generaría las siguientes tripletas:
<> foaf:primaryTopic <#bbq> . <> dc:creator "Jo" . <#bbq> rdf:type cal:Vevent . <#bbq> cal:summary "one last summer barbecue" . <#bbq> cal:dtstart "2015-09-16T16:00:00-05:00"^^xsd:dateTime .
Pueden utilizarse otro tipo de recursos para establecer el sujeto actual, no sólo las referencias a páginas web. Aunque no se recomienda, las direcciones de correo electrónico podrían usarse para representar a una persona:
John knows <a about="mailto:john@example.org" rel="foaf:knows" href="mailto:sue@example.org">Sue</a>. Sue knows <a about="mailto:sue@example.org" rel="foaf:knows" href="mailto:jim@example.org">Jim</a>.
Esto generaría las siguientes tripletas:
<mailto:john@example.org> foaf:knows <mailto:sue@example.org> . <mailto:sue@example.org> foaf:knows <mailto:jim@example.org> .
Del mismo modo, los autores pueden hacer declaraciones acerca de las imágenes:
<div about="photo1.jpg">
this photo was taken by
<span property="dc:creator">Mark Birbeck</span>
</div>
lo que generaría la siguiente tripleta:
<photo1.jpg> dc:creator "Mark Birbeck" .
@typeof
asigna un tipo determinado a las tripletas. @typeof funciona de un modo diferente a como
se asigna un predicado, puesto que el predicado es siempre rdf:type
,
lo que significa que el procesador solo precisa un atributo: el
valor del tipo. La pregunta es: ¿de qué recursos se obtiene la
información sobre el tipo?
Si el elemento tiene un atributo @about, que crea un nuevo contexto para las declaraciones, la relación del tipo se define en dicho recurso. Por ejemplo, a partir del siguiente código:
<div about="http://dbpedia.org/resource/Albert_Einstein" typeof="foaf:Person">
<span property="foaf:name">Albert Einstein</span>
<span property="foaf:givenName">Albert</span>
</div>
se crea la siguiente tripleta:
<http://dbpedia.org/resource/Albert_Einstein> rdf:type foaf:Person .
El atributo @about es la principal fuente para la asignación de tipos. Si está presente en un elemento, es el que tiene mayor prioridad para determinar el efecto @typeof. Si no está presente @about pero se usa el elemento únicamente para definir un posible recurso sujeto, por ejemplo mediante @resource (es decir, no hay ninguna propiedad @rel, @rev o @property presentes), entonces ese recurso es utilizado el tipado del recurso, justamente como @about.
Si está presente un atributo @rel (sin @about) entonces el objeto explícito definido por @rel es tipado. Por ejemplo, en el caso de:
<div about="http://dbpedia.org/resource/Albert_Einstein"> <div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire" typeof="http://schema.org/Country"> </div> </div>
las tripletas generadas incluirían:
<http://dbpedia.org/resource/German_Empire> rdf:type <http://schema.org/Country> .
Finalmente, @typeof también tiene la característica dicional de crear un nuevo contexto para las declaraciones, en caso de que no lo haga ningún otro atributo. Esto implica crear un nuevo nodo en blanco (más adelante se ofrece información adicional sobre los nodos en blanco, bnodes). Por ejemplo, un autor puede desear crear el marcado para una persona utilizando el vocabulario FOAF, pero sin tener un identificador definido para el elemento:
<div typeof="foaf:Person">
<span property="foaf:name">Albert Einstein</span>
<span property="foaf:givenName">Albert</span>
</div>
Este marcado crearía un nodo
en blanco del tipo foaf:Person
, junto con las
propiedades del nombre (foaf:name
) y el nombre propio
(foaf:givenName
):
_:a rdf:type foaf:Person . _:a foaf:name "Albert Einstein" . _:a foaf:givenName "Albert" .
Este uso "aislado" de @typeof puede verse como una forma abreviada para:
<div resource="_:a" typeof="foaf:Person">
<span property="foaf:name">Albert Einstein</span>
<span property="foaf:givenName">Albert</span>
</div>
De forma similar,
<div about="http://dbpedia.org/resource/Albert_Einstein">
<div rel="dbp:birthPlace" typeof="http://schema.org/Country">
<span property="dbp:conventionalLongName">the German Empire</span>
</div>
</div>
genera:
<http://dbpedia.org/resource/Albert_Einstein"> dbp:birthPlace _:b . _:b dbp:conventionalLongName "the German Empire" .
_:a
puesto que es distinto de _:b
. Sin embargo, al no exponer estos valores a cualquier software externo, es posible tener un control completo sobre el identificador, así como la prevención de nuevos estados que se realizan sobre el elemento.Como se ha enfatizado en la sección de encadenamiento, una de las principales diferencias entre @property y @rel (o @rev) es que el primero no induce al encadenamiento. La única excepción a esta regla se da cuando @typeof también está presente en el elemento. En ese caso el efecto de @property es idéntico al de @rel. Por ejemplo, el ejemplo anterior podría haberse escrito como:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<div property="dbp:birthPlace" typeof="http://schema.org/Country">
<span property="dbp:conventionalLongName">the German Empire</span>
</div>
</div>
generando las mismas tripletas que antes. También en este caso un atributo @typeof sin @about o @resource puede contemplarse como una forma abreviada para un atributo @resource adicional que se refiera al identificador o a un nuevo nodo en blanco.
Como se describe en las dos secciones anteriores, @about siempre tendrá prioridad y marca un
nuevo sujeto, pero si no está disponible un valor para @about entonces @typeof hará la misma tarea, aunque usando un
identificador implícita, es decir, un nodo
en blanco.
Pero si no están presentes @about o @typeof, existen varias formas de que el
subjeto a él. Una de ellos es 'heredar' el sujeto de la
declaración que lo contiene y establecerlo explícita o
implícitamente con el valor heredado.
La forma de herencia más usual para un sujeto es el que se establezce cuando la declaración padre tiene un recurso objeto. Volviendo al ejemplo anterior, en la que se añadió el nombre largo para el Imperio Alemán (German_Empire), se utilizó el siguiente marcado:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire" />
<span about="http://dbpedia.org/resource/German_Empire"
property="dbp:conventionalLongName">the German Empire</span>
</div>
En un ejemplo anterior el sujeto y el objeto para el Imperio Aleman se conectaron mediante la eliminación del atributo @resource, basándose en @about para establecer el objeto:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace">
<span about="http://dbpedia.org/resource/German_Empire"
property="dbp:conventionalLongName">the German Empire</span>
</div>
</div>
pero también es posible que un autor consiga el mismo efecto eliminando @about y manteniendo @resource:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire">
<span property="dbp:conventionalLongName">the German Empire</span>
</div>
</div>
En esta situación, todas las declaraciones 'contenidas' por el
recurso objeto que representa al Imperio Alemán (el valor de @resource) tendrá el mismo sujeto, lo que
facilita el trabajo a los autores para agregar declaraciones
adicionales:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire">
<span property="dbp:conventionalLongName">the German Empire</span>
<span rel="dbp-owl:capital" resource="http://dbpedia.org/resource/Berlin" />
</div>
</div>
En cuanto a las tripletas que un procesador RDFa generaría, puede verse que en realidad hay dos grupos de declaraciones, el primero se establece para referirse al atributo @about que los contiene:
<http://dbpedia.org/resource/Albert_Einstein> foaf:name "Albert Einstein" . <http://dbpedia.org/resource/Albert_Einstein> dbp:dateOfBirth "1879-03-14"^^xsd:date . <http://dbpedia.org/resource/Albert_Einstein> dbp:birthPlace <http://dbpedia.org/resource/German_Empire> .
mientras que el segundo se refiere al atributo @resource que los contiene:
<http://dbpedia.org/resource/German_Empire> dbp:conventionalLongName "the German Empire" . <http://dbpedia.org/resource/German_Empire> dbp-owl:capital <http://dbpedia.org/resource/Berlin> .
Ha de tenerse también en cuenta que los mismos principios descritos aquí se aplican a @src y @href.
Habrá ocasiones en las que el autor quiera conectar el sujeto y
el objeto como se ha mostrado anteriormente, pero no se refieren
al nombre del recurso que es común a las dos declaraciones (es
decir, el objeto de la primera declaración, que es el objeto de
la segunda). Por ejemplo, para indicar que Einstein fue
influenciado por Spinoza podría usarse el siguiente el marcado:
<div about="http://dbpedia.org/resource/Baruch_Spinoza" rel="dbp-owl:influenced"> <div about="http://dbpedia.org/resource/Albert_Einstein"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> </div> </div>
Un procesador RDFa generaría las siguientes tripletas:
<http://dbpedia.org/resource/Baruch_Spinoza> dbp-owl:influenced <http://dbpedia.org/resource/Albert_Einstein> . <http://dbpedia.org/resource/Albert_Einstein> foaf:name "Albert Einstein" . <http://dbpedia.org/resource/Albert_Einstein> dbp:dateOfBirth "1879-03-14"^^xsd:date .
Sin embargo, un autor podría decir con la misma facilidad que Spinoza influenció a algo con el nombre de Albert Einstein, que nació el 14 de marzo de 1879:
<div about="http://dbpedia.org/resource/Baruch_Spinoza" rel="dbp-owl:influenced"> <div> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> </div> </div>
En términología de RDF, el elemento que 'representa' Einstein es anonimo, puesto que no tiene un IRI que lo identifique. Sin embargo, dicho elemento generado automáticamente es un nodo en blanco, y es a este identificador al que añaden todas las declaraciones hijas:
Un procesador RDFa generaría las siguientes tripletas:
<http://dbpedia.org/resource/Baruch_Spinoza> dbp-owl:influenced _:a . _:a foaf:name "Albert Einstein" . _:a dbp:dateOfBirth "1879-03-14"^^xsd:date .
Téngase en cuenta que el div
es supérfluo, y un
procesador RDFa creará el objeto intermedio, incluso si se
elimina el elemento:
<div about="http://dbpedia.org/resource/Baruch_Spinoza" rel="dbp-owl:influenced"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> </div>
Un patrón alternativo es mantener el div
y mover a su interior el atributo @rel:
<div about="http://dbpedia.org/resource/Baruch_Spinoza">
<div rel="dbp-owl:influenced">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
</div>
</div>
Desde el punto de vista del marcado, esta última opción es
preferible, ya que llama la atención sobre el 'rel colgado'.
Pero desde el punto de vista de un procesador RDFa, todas estas
permutaciones deben ser soportadas.
Cuando se calcula un nuevo sujeto, también se utiliza para para completar cualquier tripleta incompleta pendiente. Esta situación surge cuando el autor quiere 'encadenar' cierto número de declaraciones a la vez. Por ejemplo, un autor podría crear una declaración que indique al Albert Einstein Nació en el Imperio Alemán:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire" />
</div>
y luego otra declaración para indicar que el 'nombre largo' para este país es el Imperio Alemán:
<span about="http://dbpedia.org/resource/German_Empire" property="dbp:conventionalLongName">the German Empire</span>
RDFa permite a los autores insertar esta declaración como una unidad auto-contenida en otros contextos:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire" />
<span about="http://dbpedia.org/resource/German_Empire"
property="dbp:conventionalLongName">the German Empire</span>
</div>
Pero también permite a los autores, evitar repeticiones innecesarias y 'normalizar' los identificadores duplicados, en el caso del Imperio Alemán:
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace">
<span about="http://dbpedia.org/resource/German_Empire"
property="dbp:conventionalLongName">the German Empire</span>
</div>
</div>
Cuando esto sucede el atributo @rel para 'lugar de nacimiento' es considerado como un 'rel colgado' porque aún no se ha generado ninguna tripleta, pero estas 'tripletas incompletas' son completadas por el atributo @about cuando aparece en la siguiente línea. Por lo tanto, el primer paso consiste en almacenar las dos partes de la tripleta que el procesador tiene, pero sin un objeto:
<http://dbpedia.org/resource/Albert_Einstein> dbp:birthPlace ? .
Entonces, puesto que continúa el análisis, el procesador RDFa
encuentra el sujeto de la declaración acerca del nombre largo para el
Imperio Alemán, y éste se utiliza de dos maneras. En primer lugar, se
utiliza para completar la 'tripleta incompleta':
<http://dbpedia.org/resource/Albert_Einstein>
dbp:birthPlace <http://dbpedia.org/resource/German_Empire> .
y segundo se usa para generar su propia tripleta:
<http://dbpedia.org/resource/German_Empire> dbp:conventionalLongName "the German Empire" .
Hay que considerar que cada aparición de @about completará cualquier tripleta incompleta. Por ejemplo, para marca el hecho de que Albert Einstein haya residido tanto en el Imperio Alemán como en Suiza, un autor necesita específicar únicamente un valor para @rel que es utilizado con múltiples valores de @about:
<div about="http://dbpedia.org/resource/Albert_Einstein" rel="dbp-owl:residence"> <span about="http://dbpedia.org/resource/German_Empire" /> <span about="http://dbpedia.org/resource/Switzerland" /> </div>
En este ejemplo hay una tripleta incompleta:
<http://dbpedia.org/resource/Albert_Einstein> dbp-owl:residence ? .
Cuando el procesador encuentra cada uno de los valores @about se completa esta tripleta, obteniendo:
<http://dbpedia.org/resource/Albert_Einstein> dbp-owl:residence <http://dbpedia.org/resource/German_Empire> . <http://dbpedia.org/resource/Albert_Einstein> dbp-owl:residence <http://dbpedia.org/resource/Switzerland> .
Estos ejemplos muestran cómo @about completa tripletas, pero hay otras
situaciones que pueden tener el mismo efecto. Por ejemplo, cuando @typeof crea un nuevo nodo
en blanco (como se describe más arriba), que se utilizará para
completar cualquier 'tripleta incompleta'. Por ejemplo, para indicar
que Spinoza influyó tanto en Einstein como en Schopenhauer, se podría
utilizar el siguiente marcado:
<div about="http://dbpedia.org/resource/Baruch_Spinoza"> <div rel="dbp-owl:influenced"> <div typeof="foaf:Person"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> </div> <div typeof="foaf:Person"> <span property="foaf:name">Arthur Schopenhauer</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1788-02-22</span> </div> </div> </div>
Primero se almacenará la siguiente tripleta:
<http://dbpedia.org/resource/Baruch_Spinoza> dbp-owl:influenced ? .
Más adelante, uando el procesador RDFa procese las dos apariciones de
@typeof, cada una genera un nodo
en blanco, que se utiliza tanto para completar la 'tripleta
incompleta' y para establecer el sujeto para declaraciones
posteriores:
<http://dbpedia.org/resource/Baruch_Spinoza"> dbp-owl:influenced _:a . _:a rdf:type foaf:Person . _:a foaf:name "Albert Einstein" . _:a dbp:dateOfBirth "1879-03-14"^^xsd:date . <http://dbpedia.org/resource/Baruch_Spinoza"> dbp-owl:influenced _:b . _:b rdf:type foaf:Person . _:b foaf:name "Arthur Schopenhauer" . _:b dbp:dateOfBirth "1788-02-22"^^xsd:date .
Las tripletas también son 'completadas' si está presente @property, @rel or @rev. Sin embargo, a diferencia del caso en el que estaban presentes @about o @typeof, todos los predicados son adjuntados a un nodo en blanco:
<div about="http://dbpedia.org/resource/Baruch_Spinoza" rel="dbp-owl:influenced"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> <div rel="dbp-owl:residence"> <span about="http://dbpedia.org/resource/German_Empire" /> <span about="http://dbpedia.org/resource/Switzerland" /> </div> </div>
Este ejemplo tiene dos 'rels colgados', y por lo tanto dos casos en los que se crean 'tripletas incompletas'. El procesamiento actúa del siguiente modo; primero se almacena una tripleta incompleta:
<http://dbpedia.org/resource/Baruch_Spinoza> dbp-owl:influenced ? .
A continuación, el procesador RDFa procesa los valores del predicado
de foaf:name
, dbp:dateOfBirth
y dbp-owl:residence
,
pero debe tenerse en cuenta que solo la primera necesita 'completar'
el 'rel colgado'. Por lo tanto se procesa foaf:name
para
generar dos tripletas:
<http://dbpedia.org/resource/Baruch_Spinoza> dbp-owl:influenced _:a . _:a foaf:name "Albert Einstein" .
pero al procesar dbp:dateOfBirth
solo se genera una:
_:a dbp:dateOfBirth "1879-03-14"^^xsd:date .
Al procesar dbp-owl:residence
también se utiliza el
mismo nodo
en blanco, pero hay que considerar que también genera sus
propias 'tripletas incompletas':
_:a dbp-owl:residence ? .
Como en el caso anterior, las dos ocurrencias de @about completa cada una de las 'tripletas incompletas':
_:a dbp-owl:residence <http://dbpedia.org/resource/German_Empire> . _:a dbp-owl:residence <http://dbpedia.org/resource/Switzerland> .
El conjunto completo de tripletas que debería generar un procesador RDFa sería el siguiente:
<http://dbpedia.org/resource/Baruch_Spinoza> dbp-owl:influenced _:a . _:a foaf:name "Albert Einstein" . _:a dbp:dateOfBirth "1879-03-14"^^xsd:date . _:a dbp-owl:residence <http://dbpedia.org/resource/German_Empire> . _:a dbp-owl:residence <http://dbpedia.org/resource/Switzerland> .
Aunque los objetos se han discutido en las secciones anteriores, como
parte de la explicación de la resolución del sujeto, encadenamiento,
contextos de evaluación, etc, en esta sección se analizarán los
objetos con más detalle.
Hay dos tipos de objetos, recursos IRI y literales.
Un objeto literal puede establecerse utilizando @property para expresar un predicado, y entonces, utilizando tanto @content, como el texto marcado del elemento en el que se encuentra @property. Debe tenerse en cuenta que el uso de @content prohíbe la inclusión de marcado enriquecido en el literal. Si el texto marcado de un elemento representa exactamente al objeto, entonces los documentos debería basarse en ello en vez de duplicar los datos utilizando @content.
Un objeto que sea un recurso IRI puede establecerse utilizando @rel o @rev para expresar un predicado, y a continuación, ya sea utilizando @href, @resource o @src para proporcionar explícitamente un recurso objeto, o utilizando técnicas de encadenamiento descritas anteriormente para obtener un objeto a partir de un sujeto anidado o a partir de un nodo en blanco. Alternativamente, @property también puede usarse para definir un recurso IRI, en presencia de @href, @resource, o @src y en ausencia de @rel, @rev, @datatype, o @content.
Un objeto literal se generará cuando esté presente el atributo @property (y no esté presente ningún atributo de recurso). @property proporciona el predicado, y las siguientes secciones describen como se determina el literal actual para su generación.
@content puede usarse para indicar un literal plano, del siguiente modo:
<meta about="http://internet-apps.blogspot.com/"
property="dc:creator" content="Mark Birbeck" />
También puede especificarse un literal plano utilizando el contenido del elemento:
<span about="http://internet-apps.blogspot.com/"
property="dc:creator">Mark Birbeck</span>
Ambos ejemplos producirán la siguiente tripleta:
<http://internet-apps.blogspot.com/> dc:creator "Mark Birbeck" .
El valor de @content tiene prioridad sobre cualquier otro elemento de contenido, por ello, el siguiente ejemplo genera exactamente la misma tripleta que en el ejemplo anterior:
<span about="http://internet-apps.blogspot.com/"
property="dc:creator" content="Mark Birbeck">John Doe</span>
Es posible asignar un tipo de dato a los literales utilizando @datatype.
Esto puede representarse en RDFa del siguiente modo:
<span property="cal:dtstart" content="2015-09-16T16:00:00-05:00"
datatype="xsd:dateTime">
September 16th at 4pm
</span>.
Las tripletas que genera este marcado incluyen el tipo de dato del literal:
<> cal:dtstart "2015-09-16T16:00:00-05:00"^^xsd:dateTime .
Los documentos XML no pueden contener marcado XML en sus atributos, lo que significa que no es posible representar XML en el atributo @content (el siguiente ejemplo generaría un error del analizador XML):
<head>
<meta property="dc:title"
content="E = mc<sup>2</sup>: The Most Urgent Problem of Our Time" />
</head>
Sin embargo, RDFa soporta el uso de marcado normal para expresar literales XML utilizando @datatype:
<h2 property="dc:title" datatype="rdf:XMLLiteral">
E = mc<sup>2</sup>: The Most Urgent Problem of Our Time
</h2>
Esto generaría la siguiente tripleta, preservando el marcado XML en el literal:
<> dc:title "E = mc<sup>2</sup>: The Most Urgent Problem of Our Time"^^rdf:XMLLiteral .
Esto requiere que se haya definido una equivalencia
IRI para el prefijo rdf
.
En los siguientes ejemplos, el elemento sup
forma parte del significado del literal, pero habrá situaciones en
las que el marcado adicional no signifique nada y por lo tanto
pueda ser ignorado. En esta situación la omisión del
atributo @datatype
o dejar en blanco el valor de @datatype puede usarse para crear un
literal plano:
<p>You searched for <strong>Einstein</strong>:</p>
<p about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name" datatype="">Albert <strong>Einstein</strong></span>
(b. March 14, 1879, d. April 18, 1955) was a German-born theoretical physicist.
</p>
Aunque en la representación de esta página se ha destacado el término buscado por el usuario, dejar vacío el atributo @datatype asegura que el dato se interprete como un literal plano, dando como resultado la siguiente tripleta:
<http://dbpedia.org/resource/Albert_Einstein> foaf:name "Albert Einstein" .
El valor de este literal XML es la forma canónica [XML-EXC-C14N] del valor del elemento RDFa.
La mayor parte de las reglas que rigen el tratamiento de los recursos objetos deben ser encontrados en las descripciones de procesamiento dadas anteriormente, ya que son importantes para determinar el sujeto. Esta sección tiene como objetivo poner de relieve los conceptos generales, y todo lo que podría haberse pasado por alto.
Cuando están presentes @rel o @rev se precisan una o más IRIs de objetos. Cada atributo hace que se
generen tripletas cuando se utilizan con @href, @resource
o @src, o con el
valor del sujeto de cualquier declaración anidada si ninguno de
estos atributos está presente.
Si @rel o @rev no están presentes y tampoco @datatype o @content, un atributo @property hará que se generen tripletas cuando se utilice con @href, @resource o @src. (Véase además la sección encadenamiento de @property y @typeof para consultar un caso especial adicional con @property.)
@rel y @rev son esencialmente inversas entre sí; mientras que @rel establece una relación entre el sujeto actual como sujeto, y el recurso objeto actual como objeto, @rev hace exactamente lo contrario y utiliza el recurso objeto actual como sujeto y el sujeto actual como objeto.
RDFa proporciona el atributo @resource como una forma de establecer el sujeto de una declaración. Esto es particularmente útil cuando se hace referencia a los recursos que no son en sí mismos enlaces navegables:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>On Crime and Punishment</title>
<base href="http://www.example.com/candp.xhtml" />
</head>
<body>
<blockquote about="#q1" rel="dc:source" resource="urn:ISBN:0140449132" >
<p id="q1">
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
</p>
</blockquote>
</body>
</html>
El elemento blockquote
genera la siguiente
tripleta:
<http://www.example.com/candp.xhtml#q1> <http://purl.org/dc/terms/source> <urn:ISBN:0140449132> .
Debe tenerse en cuenta que en el ejemplo anterior podría haberse usado @property en vez de @rel, obteniendo la misma tripleta.
Si no está presente un atributo @resource, entonces @href o @src son los siguientes atributos en el orden de prioridad para establecer el objeto.
Cuando un predicado ha sido expresado utilizando @rel, @href o @src en el elemento de la declaración RDFa se usa para identificar el objeto con una referencia IRI. Sus tipos son una IRI:
<link about="mailto:john@example.org"
rel="foaf:knows" href="mailto:sue@example.org" />
También es posible utilizar en un elemento al mismo tiempo tanto @rel como @rev. Esto es particularmente útil cuando dos cosas se colocan en dos relaciones diferentes entre sí, por ejemplo, cuando una foto es tomada por Mark, pero esa imagen también lo muestra a él:
<img about="http://www.blogger.com/profile/1109404"
src="photo1.jpg" rev="dc:creator" rel="foaf:img"/>
que a su vez proporciona dos tripletas:
<photo1.jpg> dc:creator <http://www.blogger.com/profile/1109404> . <http://www.blogger.com/profile/1109404> foaf:img <photo1.jpg> .
Cuando el predicado de una tripleta se ha expresado utilizando @rel o @rev, pero no con @href, @src, o @resource en el mismo elemento, hay un 'rel colgado'. Esto provoca que el sujeto actual y todos los posibles predicados (con un indicador de cuando van delante, por ejemplo los valores de @rel, o cuando no, como los valores de @rev), sean almacenados como 'tripletas incompletas' pendientes del descubrimiento de un sujeto que pueda usarse para 'completar' dichas tripletas.
Este proceso se describe más detalladamente en la sección Completando 'tripletas incompletas'.
Un grafo RDF es una colección de tripletas. Esto también significa que si el grafo contiene dos tripletas que contienen el mismo sujeto y predicado:
<http://www.example.com> <http://www.example.com/predicate> "first object", "second object" ;
No hay manera de que una aplicación se base en el orden relativo de las dos triples para, por ejemplo, consultar una base de datos que contiene estas tripletas. Para la mayoría de las aplicaciones y conjuntos de datos esto no es un problema, pero en algunos casos el orden es importante. Un caso típico es el de las publicaciones: cuando un libro o un artículo tiene varios co-autores, el orden de los autores puede ser importante.
RDF tiene un conjunto de predicados predefinidos que tienen un acordados una semántica con respecto al orden. Por ejemplo, la publicación: "Semantic Annotation and Retrieval", de Ben Adida, Mark Birbeck, e Ivan Herman, podría describirse como tripletas RDF utilizando dichos términos del siguiente modo:
@prefix bibo: <http://purl.org/ontology/bibo/> . @prefix dc: <http://purl.org/dc/terms/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . [ a bibo:Chapter ; dc:title "Semantic Annotation and Retrieval" ; dc:creator [ rdf:first <http://ben.adida.net/#me ; rdf:rest [ rdf:first <http://twitter.com/markbirbeck> ; rdf:rest [ rdf:first <http://www.ivan-herman.net/foaf#me> ; rdf:rest rdf:nil . ] . ] . ] . ... ]
que transmite la noción de "orden" de los tres autores. Es cierto que esto no es muy legible. Sin embargo, Turtle posee una sintaxis que permite abreviar estas estructuras:
@prefix bibo: <http://purl.org/ontology/bibo/> . @prefix dc: <http://purl.org/dc/terms/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . [ a bibo:Chapter ; dc:title "Semantic Annotation and Retrieval" ; dc:creator ( <http://ben.adida.net/#me> <http://twitter.com/markbirbeck> <http://www.ivan-herman.net/foaf#me> ) . ... ]
En efecto, sería posible reproducir la misma estructura en RDFa,
utilizando los predicados rdf:first
, rdf:rest
,
así como el recurso especial rdf:nil
. Sin embargo, para
hacer esto más fácil, RDFa proporciona @inlist. Lo que señala este atributo es que el
objeto generado en ese elemento debería ponerse en una lista; la lista
se utiliza con el predicado y el sujeto comunes. Así es como se
representaría la estructura anterior en RDFa:
<p prefix="bibo: http://purl.org/ontology/bibo/ dc: http://purl.org/dc/terms/ typeof="bibo:Chapter"> "<span property="dc:title">Semantic Annotation and Retrieval</span>" by <a inlist="" property="dc:creator" href="http://ben.adida.net/#me">Ben Adida</span>, <a inlist="" property="dc:creator" href="http://twitter.com/markbirbeck">Mark Birbeck</span>, and <a inlist="" property="dc:creator" href="http://www.ivan-herman.net/foaf#me">Ivan Herman</span>. </p>
Debe tenerse en cuenta que el orden en la lista es determinado por el orden en el documento (el valor de @inlist no es relevante, solo su presencia).
Las listas también puede incluir IRIs y no solo literales. Por ejemplo, dos o tres co-autores podría decidir publicar sus direcciones FOAF en la lista de autores:
<p prefix="bibo: http://purl.org/ontology/bibo/ dc: http://purl.org/dc/terms/ typeof="bibo:Chapter"> "<span property="dc:title">Semantic Annotation and Retrieval</span>", by <span inlist="" property="dc:creator" resource="http://ben.adida.net/#me">Ben Adida</span>, <span inlist="" property="dc:creator">Mark Birbeck</span>, and <span inlist="" property="dc:creator" resource="http://www.ivan-herman.net/foaf#me">Ivan Herman</span>. </p>
produciría:
@prefix bibo: <http://purl.org/ontology/bibo/> . @prefix dc: <http://purl.org/dc/terms/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . [ a bibo:Chapter ; dc:title "Semantic Annotation and Retrieval" ; dc:creator ( <http://ben.adida.net/#me> "Mark Birbeck" <http://www.ivan-herman.net/foaf#me> ) . ... ]
En el ejemplo anterior, podría haberse utilizado @rel obteniendo exactamente las mismas tripletas:
<p prefix="bibo: http://purl.org/ontology/bibo/ dc: http://purl.org/dc/terms/ typeof="bibo:Chapter"> "<span property="dc:title">Semantic Annotation and Retrieval</span>", by <span inlist="" rel="dc:creator" resource="http://ben.adida.net/#me">Ben Adida</span>, <span inlist="" property="dc:creator">Mark Birbeck</span>, and <span inlist="" rel="dc:creator" resource="http://www.ivan-herman.net/foaf#me">Ivan Herman</span>. </p>
Las tripletas incompletas pueden utilizarse junto con las listas cuando todos los elementos de la lista sean recursos y no literales. Para el ejemplo anterior, si los tres autores hacen referencia a su perfil FOAF, podría haberse escrito como:
<p prefix="bibo: http://purl.org/ontology/bibo/ dc: http://purl.org/dc/terms/ typeof="bibo:Chapter"> "<span property="dc:title">Semantic Annotation and Retrieval</span>", by <span rel="dc:creator" inlist=""> <a href="http://ben.adida.net/#me">Ben Adida</a>, <a href="http://internet-apps.blogspot.com/2008/03/my-profile.html#me">Mark Birbeck</a>, and <a href="http://www.ivan-herman.net/foaf#me">Ivan Herman</a>. </span> </p>
Obteniendo:
@prefix bibo: <http://purl.org/ontology/bibo/> . @prefix dc: <http://purl.org/dc/terms/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . [ a bibo:Chapter ; dc:title "Semantic Annotation and Retrieval" ; dc:creator ( <http://ben.adida.net/#me> <http://internet-apps.blogspot.com/2008/03/my-profile.html#me> <http://www.ivan-herman.net/foaf#me> ) . ... ]
Debe tenerse en cuenta que también es posible expresar una lista vacía, sin ningún atributo @inlist, usando:
<span rel="prop" resource="rdf:nil"/>
RDFa permite que los lenguajes anfitrión definan un contexto inicial. Este contexto es una colección de términos, las equivalencias de prefijos, y/o una declaración del vocabulario por defecto. Un contexto inicial, ya sea conocido intrínsicamente por el analizador, o sea cargado y procesado como un documento externo. Estos documentos deben ser definidos en un lenguaje anfitrión RDFa aprobado (actualmente XML+RDFa y XHTML+RDFa [XHTML-RDFA]). También pueden definirse en otros formatos (como por ejemplo, RDF/XML [RDF-SYNTAX-GRAMMAR], o Turtle [TURTLE]). Cuando se procesa un documento de contexto inicial, se evalúa del siguiente modo:
rdfa:prefix
y rdfa:uri
, una equivalencia valor-clave desde el
literal objeto rdfa:prefix
(clave) hacia el literal
objeto rdfa:uri
(valor). Añadir esta equivalencia a
la lista
de equivalencias de IRIs del contexto
inicial de evaluación, después de transformar el componente
'prefijo' a minúsculas.rdfa:term
y rdfa:uri
, una
equivalencia valor-clave desde el literal objeto rdfa:term
(clave) hacia el literal objeto rdfa:uri
(valor). Añadir
esta equivalencia a las equivalencias
de términos del contexto inicial de
evaluación.rdfa:vocabulary
,
el vocabulario
por defecto del contexto inicial de
evaluación para que sea el literal objeto del predicado rdfa:vocabulary
.Cuando se defina un contexto inicial RDFa utilizando una serialización RDF, debe usarse los términos del vocabulario indicados anteriormente para declarar los componentes del contexto.
Se recomienda el almacenamiento en caché de las tripletas relevantes recuperados a través de este mecanismo. Se recomienda la incorporación de definiciones de contextos iniciales RDFa bien conocidos y estables.
El literal objeto del predicado rdfa:uri
debe ser una IRI absoluta. El
literal objeto para el predicado rdfa:term
debe coincidir con la producción para el término.
El literal objeto para el predicado rdfa:prefix
debe
coincidir con la producción para el prefijo. El
literal objeto para el predicado rdfa:vocabulary
debe ser una IRI absoluta. Si uno de los objetos no
es un literal no coincidirá su producción asociada. Si hay más de un
predicado rdfa:vocabulary
o si hay predicados
adicionales rdfa:uri
o rdfa:term
que
compartan el mismo sujeto, el procesador RDFa no
debe crear la equivalencia asociada.
Puesto que RDFa se basa en RDF, la semántica de los vocabularios RDF pueden utilizarse para obtener más conocimiento sobre los datos. Vocabularios, propiedades y clases se identifican mediante IRIs, que permiten que sean descubiertos. Los datos RDF publicados en la ubicación de dichas IRIs pueden ser recuperados y pueden aplicarse las descripciones de las propiedades y clases que utilicen semánticas específicas.
La expansión de vocabularios en RDFa es un paso opcional de procesamiento que puede añadirse una vez completados los pasos descritos en el Modelo de procesamiento. La expansión de vocabularios se basa en un sub-conjunto muy pequeño de inferencia OWL [OWL2-OVERVIEW] para añadir tripletas al grafo de salida basándose en las reglas y relaciones entre propiedades y clases descritas en los vocabularios referenciados. La expansión de vocabularios PUEDE ser realizada como parte de un conjunto mayor de herramientas RDF incluyendo, por ejemplo, un razonador OWL 2 RL. Alternativamente, utilizando datos de vocabularios añadidos al grafo de salida durante el paso 2 de la secuencia de procesamiento, la expansión también puede realizarse utilizando un razonador dedicado separado (por ejemplo, basado en reglas) después de generar el grafo de salida, o como el último paso realizado por el procesador RDFa.
Puede ser muy útil hacer que estén disponibles los datos de forma
generalizada para usos posteriores de los datos incluídos en el código
RDFa mediante la expansión de las declaraciones inferidas mediante esta
semántica. Esto permite que vocabularios existentes que extienden
vocabularios muy conocidos, dispongan de dichas propiedades añadidas al
grafo de salida automáticamente. Por ejemplo, el documento del espacio
de nombres del vocabulario Creative Commons, es decir http://creativecommons.org/ns
,
define cc:license
como una sub-propiedad de dc:license
.
Utilizando el atributo @vocab,
es posible describir información sobre una licencia del siguiente modo:
This document is licensed under the <a vocab="http://creativecommons.org/ns#" rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/"> Creative Commons By-NC-ND License </a>.
que permite obtener el siguiente grafo de salida:
@prefix cc: <http://creativecommons.org/ns#> . @prefix rdfa: <http://www.w3.org/ns/rdfa#> . <> cc:license <http://creativecommons.org/licenses/by-nc-nd/3.0/> ; rdfa:usesVocabulary <http://creativecommons.org/ns#> .
Tras la expansión de vocabulario, el grafo de salida contendría:
@prefix cc: <http://creativecommons.org/ns#> . @prefix rdfa: <http://www.w3.org/ns/rdfa#> . @prefix dc: <http://purl.org/dc/terms/> . <> cc:license <http://creativecommons.org/licenses/by-nc-nd/3.0/>; dc:license <http://creativecommons.org/licenses/by-nc-nd/3.0/> ; rdfa:usesVocabulary <http://creativecommons.org/ns#> .
Otros vocabularios, específicamente destinados a proporcionar relaciones para varios vocabularios, también podrían ser definidos por los editores, permitiendo el uso de términos en un único espacio de nombres, dando lugar a que propiedades y/o clases de otros vocabularios primarias puedan importarse. Esto beneficia a los editores, permitiendo que los datos sean más ampliamente buscados y animando a la práctica de referenciar vocabularios muy conocidos.
Esta sección no es normativa.
Una vez generado el grafo de salida tras las etapas de procesamiento definidas en la secuencia, los procesadores pueden realizar los siguientes pasos de procesamiento en el gráfico de salida. Deben hacerlo sólo si el usuario del procesador lo solicita explícitamente, según lo prescrito la sección sobre el Control de expansión de vocabularios por parte de los procesadores RDFa.
Se crea un grafo
de vocabulario del siguiente modo: Para cada IRI objeto de una
tripleta en el grafo
de salida cuyo sujeto sea la IRI del documento actual (base) y la propiedad sea rdfa:usesVocabulary
,
dicha IRI es derreferenciada. Si la derreferenciación produce la
serialización de un grafo RDF, dicha serialización se analiza y el
grafo resultante se combina con el grafo del vocabulario (un
procesador RDFa capaz de realizar la expansión de vocabularios debe aceptar un grafo RDF serializado mediante
RDFa, y debería aceptar otros
formatos estándar de serialización para RDF como RDF/XML [RDF-SYNTAX-GRAMMAR]
y Turtle [TURTLE]).
Debe tenerse en cuenta que si, en el segundo paso, un vocabulario particular se serializa en RDFa, no se espera que dicho grafo se someta a una ampliación del vocabulario por sí mismo.
La expansión de vocabularios se realiza del siguiente modo:
A efectos de procesamiento de vocabularios, RDFa utiliza un subconjunto muy limitado del vocabulario OWL y está basado en la semántica RDF de OWL [OWL2-RDF-BASED-SEMANTICS]. El vocabulario RDFa para inferencias utiliza los sigiuentes términos:
rdf:type
rdfs:subClassOf
rdfs:subPropertyOf
owl:equivalentClass
owl:equivalentProperty
El vocabulario RDFa para inferencias considera
únicamente aquellas realizadas sobre individuos (es decir, nunca
sobre las relaciones que puedan deducirse sobre las propiedades o
las clases en sí mismas).
Mientras la definición formal de inferencia RDFa se
refiere a la Semántica general de OWL 2, las implementaciones
prácticas pueden basarse en un subconjunto de las inferencias del
perfil OWL 2 RL expresadas en las reglas de la sección
4.3 del documento [OWL2-PROFILES]). Las reglas
relevantes son, utilizando los identificadores utilizados en la sección
4.3 de [OWL2-PROFILES]):
prp-spo1
, prp-eqp1
, prp-eqp2
,
cax-sco
, cax-eqc1
, y cax-eqc2
.
rdfs:range
)
de una propiedad, o utilizando funcionalidades avanzadas ofrecidas,
por ejemplo, por las propiedades de encadenamiento de OWL para la
interconexión de vocabularios adicionales.No es imprescindible que los procesadores que cumplan la conformidad con RDFa proporcionen la funcionalidad de la expansión de vocabularios.
Si un procesador RDFa permite la expansión de vocabularios, no debe llevarse a cabo de forma
predeterminada. En su lugar, el procesador debe
proporcionar una opción, vocab_expansion
, que cuando se
utiliza, indica al procesador RDFa que debe realizar una ampliación
del vocabulario antes de devolver el grafo de salida.
Aunque la expansión de vocabularios se describe en términos de un grafo de un vocabulario y reglas de inferencia RDFS, los procesadores son libres de utilizar cualquier proceso que obtenga resultados equivalentes.
Esta sección no es normativa.
Para los procesadores RDFa se recomienda el almacenamiento en caché de los grafos relevantes obtenidos a través de este mecanismo. El almacenamiento en caché se basa generalmente en las cabeceras de respuesta HTTP, como el tiempo de caducidad, control de caché, etc.
Para los editores de vocabularios, las IRIs de los vocabularios deberían ser derreferenciables, y debería devolver un grafo RDF con las descripciones de vocabularios. Estas descripciones de vocabularios deberían estar disponibles y codificadas en RDFa, y también pueden estar disponibles en otras sintaxis de serialización para RDF (utilizando la negociación de contenido para escoger entre los diferentes formatos). Si es posible, las descripciones de vocabularios deberían incluir declaraciones de subpropiedades y subclases enlazando los términos de los vocabularios con otros vocabulario de uso común. Por último, las respuestas HTTP deberían incluir campos que puedan utilizarse para el control de la caché, por ejemplo, la fecha de caducidad.
Con el fin de facilitar el uso de CURIEs en los lenguajes de marcado,
esta especificación define algunos tipos de datos adicionales en el
espacio de tipos de datos de XHTML (http://www.w3.org/1999/xhtml/datatypes/
).
Los lenguajes de marcado que quieran importar estas definiciones pueden
encontrarlas en el fichero de tipos de datos de la gramática del esquema
correspondiente:
Más concretamente, se definen los siguientes tipos de datos:
Esta sección no es normativa.
La siguiente definición informativa del esquema XML para estos tipos de datos se incluye como un ejemplo:
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/1999/xhtml/datatypes/" xmlns:xh11d="http://www.w3.org/1999/xhtml/datatypes/" targetNamespace="http://www.w3.org/1999/xhtml/datatypes/" elementFormDefault="qualified" > <xs:simpleType name="CURIE"> <xs:restriction base="xs:string"> <xs:pattern value="(([\i-[:]][\c-[:]]*)?:)?(/[^\s/][^\s]*|[^\s/][^\s]*|[^\s]?)" /> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="CURIEs"> <xs:list itemType="xh11d:CURIE"/> </xs:simpleType> <xs:simpleType name="SafeCURIE"> <xs:restriction base="xs:string"> <xs:pattern value="\[(([\i-[:]][\c-[:]]*)?:)?(/[^\s/][^\s]*|[^\s/][^\s]*|[^\s]?)\]" /> <xs:minLength value="3"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="SafeCURIEs"> <xs:list itemType="xh11d:SafeCURIE"/> </xs:simpleType> <xs:simpleType name="TERM"> <xs:restriction base="xs:Name"> <xs:pattern value="[\i-[:]][/\c-[:]]*" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="CURIEorIRI"> <xs:union memberTypes="xh11d:CURIE xsd:anyURI" /> </xs:simpleType> <xs:simpleType name="CURIEorIRIs"> <xs:list itemType="xh11d:CURIEorIRI"/> </xs:simpleType> <xs:simpleType name="SafeCURIEorCURIEorIRI"> <xs:union memberTypes="xh11d:SafeCURIE xh11d:CURIE xsd:anyURI" /> </xs:simpleType> <xs:simpleType name="SafeCURIEorCURIEorIRIs"> <xs:list itemType="xh11d:SafeCURIEorCURIEorIRI"/> </xs:simpleType> <xs:simpleType name='AbsIRI'> <xs:restriction base='xs:string'> <xs:pattern value="[\i-[:]][\c-[:]]+:.+" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="TERMorCURIEorAbsIRI"> <xs:union memberTypes="xh11d:TERM xh11d:CURIE xh11d:AbsIRI" /> </xs:simpleType> <xs:simpleType name="TERMorCURIEorAbsIRIs"> <xs:list itemType="xh11d:SafeCURIEorCURIEorAbsIRI"/> </xs:simpleType> </xs:schema>
Esta sección no es normativa.
La siguiente definición XML DTD informativa para estos tipos de datos se incluyen como un ejemplo:
<!ENTITY % CURIE.datatype "CDATA" > <!ENTITY % CURIEs.datatype "CDATA" > <!ENTITY % CURIEorIRI.datatype "CDATA" > <!ENTITY % CURIEorIRIs.datatype "CDATA" > <!ENTITY % SafeCURIEorCURIEorIRI.datatype "CDATA" > <!ENTITY % SafeCURIEorCURIEorIRIs.datatype "CDATA" > <!ENTITY % TERMorCURIEorAbsIRI.datatype "CDATA" > <!ENTITY % TERMorCURIEorAbsIRIs.datatype "CDATA" >
El vocabulario RDFa tiene tres funciones: contiene el predicado que
define los términos y los prefijos en el contexto inicial de los documentos,
contiene las clases y predicados para los mensajes que un procesador de grafos
pueda contener y, finalmente, contiene los predicados necesarios para el
procesamiento del vocabulario. La IRI del vocabulario RDFa es http://www.w3.org/ns/rdfa#
;
el prefijo utilizado normalmente en este documento es rdfa
.
Esta especificación del vocabulario está disponible en los formatos XHTML+RDFa 1.1, Turtle, y RDF/XML.
El vocabulario incluye las siguientes definiciones de términos (se muestran a continuación en formato Turtle [TURTLE]):
@prefix dc: <http://purl.org/dc/terms/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdfa: <http://www.w3.org/ns/rdfa#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . <http://www.w3.org/ns/rdfa#> a owl:Ontology . rdfa:PrefixOrTermMapping a rdfs:Class, owl:Class ; dc:description "The top level class for prefix or term mappings." . rdfa:PrefixMapping dc:description "The class for prefix mappings." . rdfs:subClassOf rdfa:PrefixOrTermMapping . rdfa:TermMapping dc:description "The class for term mappings." . rdfs:subClassOf rdfa:PrefixOrTermMapping . rdfa:prefix a rdf:Property, owl:DatatypeProperty ; rdfs:domain rdfa:PrefixMapping ; dc:description "Defines a prefix mapping for an IRI; the value is supposed to be a NMTOKEN." . rdfa:term a rdf:Property, owl:DatatypeProperty ; rdfs:domain rdfa:TermMapping ; dc:description "Defines a term mapping for an IRI; the value is supposed to be a NMTOKEN." . rdfa:uri a rdf:Property, owl:DatatypeProperty ; rdfs:domain rdfa:PrefixOrTermMapping ; dc:description """Defines the IRI for either a prefix or a term mapping; the value is supposed to be an absolute IRI.""" . rdfa:vocabulary a rdf:Property, owl:DatatypeProperty ; dc:description """Defines an IRI to be used as a default vocabulary; the value is can be any string; for documentation purposes it is advised to use the string ‘true’ or ‘True’.""" .
Estos predicados pueden utilizarse para definir el contexto inicial para un determinado lenguaje anfitrión.
Estos predicados son utilizados para 'emparejar' cadenas de IRIs con su uso en forma de un prefijo y/o un término como parte de, por ejemplo, un nodo en blanco. Un ejemplo podría ser el siguiente:
[] rdfa:uri "http://xmlns.com/foaf/0.1/name" ; rdfa:prefix "foaf" .
que define un prefijo para la IRI de foaf.
El vocabulario incluye las siguientes definiciones de términos (se muestran a continuación en formato Turtle [TURTLE]):
@prefix dc: <http://purl.org/dc/terms/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdfa: <http://www.w3.org/ns/rdfa#> . rdfa:PGClass a rdfs:Class, owl:Class; dc:description "The top level class of the hierarchy." . rdfa:Error dcterms:description "The class for all error conditions."; rdfs:subClassOf rdfa:PGClass . rdfa:Warning dcterms:description "The class for all warnings."; rdfs:subClassOf rdfa:PGClass . rdfa:Info dcterms:description "The class for all informations."; rdfs:subClassOf rdfa:PGClass . rdfa:DocumentError dc:description "An error condition to be used when the document fails to be fully processed as a result of non-conformant host language markup."; rdfs:subClassOf rdfa:Error . rdfa:VocabReferenceError dc:description "A warning to be used when the value of a @vocab attribute cannot be dereferenced, hence the vocabulary expansion cannot be completed."; rdfs:subClassOf rdfa:Warning . rdfa:UnresolvedTerm dc:description "A warning to be used when a Term fails to be resolved."; rdfs:subClassOf rdfa:Warning . rdfa:UnresolvedCURIE dc:description "A warning to be used when a CURIE prefix fails to be resolved."; rdfs:subClassOf rdfa:Warning . rdfa:context a owl:ObjectProperty, rdf:Property; dc:description "Provides extra context for the error, e.g., http response, an XPointer/XPath information, or simply the IRI that created the error."; rdfs:domain rdfa:PGClass .
El vocabulario incluye las siguientes definiciones de términos (se muestran a continuación en formato Turtle [TURTLE]):
@prefix dc: <http://purl.org/dc/terms/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfa: <http://www.w3.org/ns/rdfa#> . rdfa:usesVocabulary a owl:ObjectProperty, rdf:Property; dc:description "Provides a relationship between the host document and a vocabulary defined using the @vocab facility of RDFa1.1." .
Esta sección no es normativa
Esta especificación introduce una serie de características nuevas y extiende el ámbito de algunas ya existentes en la versión anterior. El siguiente resumen puede ser de utilidad para los desarrolladores de procesadores RDFa, aunque no pretende ser exhaustivo.
Si bien esta especificación se esfuerza por ser compatible hacia atrás con [RDFA-SYNTAX] tanto como sea posible, los cambios anteriores significan que hay algunas circunstancias en las que es posible generar diferentes tripletas RDF cuando se procesa un mismo documento con un procesador RDFa 1.0 o un procesador RDFa 1.1. Con el fin de minimizar estas diferencias, los autores de documentos pueden hacer lo siguiente:
XHTML+RDFa 1.0
en el elemento html
.datatype='rdf:XMLLiteral'
.datatype=''
.Durante la creación de documentos XHTML+RDFa 1.1 es posible reducir las incompatibilidades con procesadores que sean conformes a RDFa 1.0 haciendo lo siguiente:
XHTML+RDFa 1.0
en el elemento html
.datatype='rdf:XMLLiteral'
.datatype=''
.Esta sección no es normativa.
En el momento de la publicación de este documento, los miembros activos del Grupo de Trabajo de Aplicaciones Web RDF eran: