Source: http://skos.um.es/TR/2012/REC-rdfa-core-20120607/
Timestamp: 2018-12-17 16:38:10+00:00

Document:
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.
Sintaxis y reglas de procesamiento para incorporar RDF mediante atributos
Recomendación del W3C de 7 de junio de 2012
http://www.w3.org/TR/2012/PR-rdfa-core-20120508/
Versión 1.0 anterior de la recomendación:
Juan Antonio Pastor Sánchez (Universidad de Murcia)
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:
aquellos que buscan crear un procesador RDFa, y que por lo tanto necesitan una descripción detallada de las reglas de análisis;
aquellos que buscan la integración de RDFa en un nuevo lenguaje de marcado;
aquellos que buscan recomendar el uso de RDFa dentro de su organización, y que les gustaría crear algunas pautas para sus usuarios;
cualquiera que esté familiarizado con RDF, y que quiere entender más acerca de lo que está ocurriendo "bajo el capó", cuando se ejecuta un procesador RDFa.
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.
Esta sección describe el estado de este documento en el momento de su publicación. Otros documentos pueden reemplazar a este documento. Una lista de las publicaciones vigentes del W3C y la última revisión de este informe técnico se puede encontrar en el índice de informes técnicos del W3C en http://www.w3.org/TR/.
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:
La eliminación de las normas específicas para XHTML - estos se definen ahora en XHTML + RDFa [ XHTML-RDFA ]
Una expansión de los tipos de datos de algunos atributos RDFa términos, CURIES, o IRIs absolutos.
Se permiten lenguajes anfitrión para definir colecciones de términos por defecto, mapeado de prefijos por defecto y un vocabulario por defecto.
La capacidad de definir un vocabulario predeterminado que se utilizará para los términos no definidos.
Se requieren que la comparación de términos sea insensible al uso de mayúsculas o minúsculas.
Un comportamiento más rico del atributo de @property, que puede reemplazar en muchos casos al atributo @rel.
Un manejo ligeramente diferente del atributo @typeof, permitiendo una mejor adaptación a su uso práctico.
Hay una lista más completa de las cambios realizados.
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.
2. Introducción a la sintaxis de RDFa
2.1 Atributos RDFa
3. Terminología RDF
3.1 Sentencias (Statements)
3.2 Tripletas
3.3 Referencias IRI
3.4 Literales planos
3.5 Literales tipados
3.7 Grafos
3.8 Expresiones compactas de URI
3.9 Fragmentos de marcado y RDFa
3.10 Descripción de RDFa a partir de RDF
4.1 Conformidad del procesador RDFa
4.2 Conformidad RDFa del lenguaje anfitrión
4.3 Conformidad del documento con XML+RDFa
5. Atributos y sintaxis
5.1 Papel de los atributos
5.2 Espacios en blanco en los valores de los atributos
6. Definición de la sintaxis CURIE
6.1 ¿Por qué CURIEs y no QNames?
7. Modelo de procesamiento
7.2 Contexto de evaluación
7.3 Encadenamiento
7.4 Procesamiento de CURIEs e IRIs
7.4.1 Ámbito de asignaciones de prefijos
7.4.2 Uso general de CURIEs en atributos
7.4.3 Uso general de términos en atributos
7.4.4 Uso de CURIEs en atributos específicos
7.4.5 Referencias a nodos en blanco
7.5 Secuencia
7.6 Estado del procesador
7.6.1 Acceso al grafo del procesador
7.6.2 Términos del grafo del procesador
7.7 Expansión de vocabularios
8. Procesamiento RDFa en detalle
8.1 Modificación del contexto de evaluación
8.1.1 Establecimiento del sujeto actual
8.1.1.1 El documento actual
8.1.1.2 Uso de @about
8.1.1.3 Recursos tipados con @typeof
8.1.1.3.1 Encadenamientos con @property y @typeof
8.1.1.4 Determinación del sujeto sin utilizar @about ni @typeof
8.1.1.4.1 Herencia del sujeto a partir de @resource
8.1.1.4.2 Herencia de sujetos anónimos
8.2 Completando tripletas incompletas
8.3 Resolución del objeto
8.3.1 Resolución del objeto para el atributo @property
8.3.1.1 Literales planos
8.3.1.1.1 Etiquetas de idioma
8.3.1.2 Literales tipados
8.3.1.3 Literales XML
8.3.2 Resolución de IRIs de objetos
8.3.2.1 Uso de @resource para determinar el objeto
8.3.2.2 Uso de @href o @src para determinar el subjeto
8.3.2.3 Tripletas incompletas
8.4 Generación de listas
9. Contextos iniciales en RDFa
10. Expansión del vocabularios en RDFa
10.1 Detalles de la expansión de vocabularios en RDFa
10.1.1 Vocabulario RDFa para inferencias
10.2 Control de expansión de vocabularios por parte de los procesadores RDFa
10.2.1 Notas sobre la implementación y publicación de vocabularios con RDFa
A. Tipos de datos CURIE
A.1 Definición mediante XML Schema
A.2 Definición mediante XML DTD
B. El vocabulario RDFa
B.1 Asignación de términos y prefijos
B.2 Informes del procesador de grafos
B.3 Términos para expansión de vocabularios
C.1 Principales diferencias con la sintaxis de RDFa 1.0
E.1 Referencias normativas
E.2 Referencias informativas
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.
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:
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:
RDFa aplica este concepto, mejorándolo con la capacidad de hacer uso de otros vocabularios utilizando IRIs completas:
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:
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:
No solamente pueden reutilizarse las IRIs del documento para proporcionar metadatos, también puede reutilizarse el contenido textual del documento utilizando @property:
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:
RDFa permite que un documento contega metadatos con información sobre otros documentos y recursos:
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:
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:
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:
El ejemplo anterior produciría las siguientes tripletas que se expresan a continuación en sintaxis Turtle:
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:
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 ].
3.1 Declaraciones (Statements)
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
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:
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:
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:
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:
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:
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:
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:
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:
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:
Todos los servicios requeridos en esta especificación deben ser incluidos en el lenguaje anfitrión.
Todos los atributos requeridos definidos en esta especificación deben estar incluidos en el modelo de contenido del lenguaje anfitrión.
Para evitar cualquier duda, no hay ningún requisito de que atributos como @href y @src sean usados en un lenguaje anfitrión que cumpla la conformidad con RDFa. Tampoco hay ningún requisito de que todos los atributos requeridos se incorporen en el modelo de contenido de todos los elementos. El grupo de trabajo recomienda que los diseñadores de lenguajes anfitrión se aseguren de que los atributos necesarios se incorporan en el modelo de contenido de los elementos que se utilizan comúnmente en el lenguaje anfitrión.
Si el lenguaje anfitrión utiliza espacios de nombres XML [ XML-NAMES ], los atributos en esta especificación deberían definirse en 'no namespace' (por ejemplo, cuando los atributos usados en los elementos del espacio de nombres del lenguaje anfitrión, aquellos pueden usarse sin ningún prefijo cualificador:<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).
Si el lenguaje anfitrión tiene su propia definición para cualquier atributo definido en esta especificación, dicha definición debe hacerse de tal forma que el procesamiento requerido por esta especificación sea posible cuando se utilicen los atributos de una manera consistente con los requisitos aquí indicados.
El lenguaje anfitrión puede especificar un contexto inicial (por ejemplo, las asignaciones del IRI y/o una definición de los términos o una IRI de un vocabulario predeterminado). Dicho contexto inicial debe ser definido según las convenciones definidas en contextos iniciales RDFa.
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:
El documento debe estar bien formado tal y como se establece en [ XML10-4e ].
El documento debería usar los atributos definidos en esta especificación en 'no namespace' (por ejemplo, cuando los atributos utilizados en los elementos se usen sin ningún prefijo cualificador: <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:
Existen términos predeterminados (por ejemplo, describedby, license, y role), definidos en http://www.w3.org/2011/rdfa-context/rdfa-1.1.
Existen una serie de equivalencias de prefijos predeterminadas (por ejemplo, dc), definidos en http://www.w3.org/2011/rdfa-context/rdfa-1.1.
No se define una IRI de vocabulario por defecto.
La base puede establecerse utilizando el atributo @xml:base tal y como se define en [ XML10-4e ].
El idioma actual puede establecerse mediante el atributo @xml:lang.
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.
Una SafeCURIEorCURIEorIRI, utilizada para indicar el recurso al que se refieren los datos (un 'sujeto' en terminología RDF);
una cadena CDATA, para proporcionar contenido legible por máquina para un literal (un 'objeto literal', en terminología RDF);
una TERMorCURIEorAbsIRI que representa un tipo de dato, para expresar el tipo de dato de un literal;
href (opcional)
una IRI navegable para expresar el recurso asociado a una relación (un 'objeto recurso', en terminología RDF);
Un atributo utilizado para indicar que un objeto asociado mediante un atributo 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.
una lista separada por espacios en blanco con pares de nombre-de-prefijo e IRIs con la forma
una lista de TERMorCURIEorAbsIRIs separadas por espacios en blanco, utilizada para expresar relaciones entre un sujeto y un objeto recurso o bien con un texto literal ('predicado');
una lista de TERMorCURIEorAbsIRIs separadas por espacios en blanco, utilizada para expresar relaciones entre dos recursos ('predicados' en terminología RDF);
Una SafeCURIEorCURIEorIRI, utilizada para indicar el recurso asociado a una relación que no tiene intención de ser navegable, es decir, un enlace sobre el que se pueda hacer "clic" ('objeto');
una lista de TERMorCURIEorAbsIRIs separadas por espacios en blanco, utilizada para expresar relaciones inversas entre dos recursos ('predicados');
una IRI para expresar el recurso asociado a una relación donde el recurso está embebido ('objeto recurso');
una lista de TERMorCURIEorAbsIRIs separadas por espacios en blanco que indica el tipo o tipos RDF asociados con un subjeto;
Una IRI que define la equivalencia a utilizar cuando se referencie un TERMINO como valor de un atributo. Véase el uso general de términos en atributos y la sección sobre la Expansión de Vocabularios.
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:
Atributos de Sintaxis: @prefix, @vocab.
Atributos para Sujetos: @about.
Atributos para Predicados: @property, @rel, @rev.
Atributos para Recursos: @resource, @href, @src.
Atributos para Literales: @datatype, @content, @xml:lang or @lang.
Atributos Macro: @typeof, @inlist.
Muchos atributos aceptan una lista de elementos separados por espacios en blanco. Esta especificación define como el espacio en blanco:
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:
[ "?" iquery ] [ "#" ifragment ] (como se define en [ RFC3987 ])
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:
un conjunto de equivalencias de los prefijos con sus respectivas IRIs;
una equivalencia a utilizar con el prefijo por defecto (por ejemplo, :p);
una equivalencia a utilizar cuando no exista prefijo (por ejemplo, p);
una equivalencia para utilizar con el prefijo '_', utilizado para generar identificadores únicos (por ejemplo, _:p).
En RDFa dichos valores se definen del siguiente modo:
el conjunto de equivalencias de los prefijos con sus respectivas IRIs es proporcionado por las declaraciones en el ámbito actual del prefijo del elemento actual durante el análisis;
la equivalencia a utilizar con el prefijo por defecto es la equivalencia del prefijo por defecto actual;
la equivalencia a utilizar cuando no exista prefijo no está definida;
la equivalencia para utilizar con el prefijo '_', no se establece explícitamente, puesto que se utiliza para generar nodos en blanco, su implementación ha de ser compatible con la definición y reglas de RDF indicadas en la sección de Referencias a nodos en blanco. Un documento no debería definir una equivalencia para el prefijo '_'. Un procesador que cumpla la conformidad con RDFa debe ignorar cualquier definición de equivalencia para el prefijo '_'.
Una CURIE es una representación de una IRI completa. Las reglas para determinar dicha IRI son:
Si una CURIE consiste de un 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.
En el caso de que una CURIE esté formada por un 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.
Finalmente, si no existe una equivalencia en el ámbito del 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:
Las CURIEs están diseñadas desde el principio para ser utilizadas en los valores de los atributos. QNames están diseñados para nombrar de forma inequívoca los elementos y atributos.
Las CURIEs se expanden como IRIs, y cualquier IRI puede ser representada mediante tal expansión. Los QNames son tratados como pares de valores, pero incluso si estos pares se combinan en una cadena, solo es posible representar un subconjunto de IRIs.
Las CURIEs se pueden utilizar en gramáticas distintas de XML, e incluso se puede utilizar en lenguajes que no admiten espacios de nombres XML. QNames se limitan a espacios de nombres y aplicaciones XML.
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).
Téngase en cuenta que en esta sección, las explicaciones sobre el modelo de procesamiento u orientaciones a los desarrolladores se incluyen en bloques como este.
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:
La base. Normalmente se trata de la referencia IRI del documento que está siendo procesado, pero podría ser cualquier otra IRI, establecida por cualquier otro mecanismo, como el elemento base de (X)HTML. Lo importante es que se establece una IRI a partir de la que se pueden resolver las rutas relativas.
El sujeto padre. El valor inicial será el mismo que el valor inicial de base, aunque normalmente cambiará durante el procesamiento.
El objeto padre. En algunas situaciones el objeto de una declaración se convierte en el sujeto de declaraciones anidadas y se utiliza para transmitir este valor. Obsérvese que este valor puede ser un nodo en blanco, puesto que en algunas circunstancias, determinadas declaraciones anidadas se agrupan en un único nodo en blanco. Esto significa que dicho nodo en blanco se debe establecer en la declaración que lo contiene y transmitirlo.
Una lista de las asignaciones actuales de IRIs en el ámbito a procesar.
Una lista de tripletas incompletas. Una tripleta puede estar incompleta cuando no se ha proporcionado ningún objeto recurso junto a un predicado que requiere un recurso (como @rel o @rev). Las tripletas pueden completarse cuando un recurso esté disponible, lo que ocurrirá cuando se especifique el próximo subjeto (esta parte del proceso se denomina encadenamiento).
Una lista de asignaciones que asocia IRIs con listas.
El idioma. Nótese que no existe un idioma por defecto.
Las asignaciones de términos, una lista de términos con sus correspondientes IRIs. Esta especificación no defne una lista inicial, aunque los lenguajes anfitrión pueden definir dicha lista.
El vocabulario por defecto, un valor para usar como IRI del prefijo cuando se utilice un termino sin definir. Esta especificación no define una configuración inicial para el vocabulario por defecto. Los lenguajes anfitrión pueden definir una configuración inicial.
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:
Una lista inicialmente vacía de correspondencias de IRIs, denominada lista local de correspondencias de IRIs.
Una lista de tripletas incompletas inicialmente vacía, denominada lista local de tripletas incompletas.
Una valor para el idioma inicialmente vacío.
Un registro de elemento de salto, que indica cuando el elemento actual puede ignorarse ya que no tiene atributos RDFa relevantes. Debe tenerse en cuenta que los elementos descendientes seguirán procesándose.
Un valor de sujeto nuevo, que una vez calculado establecerá la propiedad del sujeto padre en un contexto de evaluación, además de ser utilizado para completar cualquier tripleta incompleta, tal y como se describe en la siguiente sección.
Un valor para el valor de propiedad actual, el literal a usar durante la creación de tripletas que tengan un objeto literal, o IRIs en ausencia de @rel o @rev.
Un valor para el recurso objeto actual, el recurso a usar durante la creación de tripletas que tengan un objeto recurso.
Un valor para el recurso tipado, utilizado para definir relaciones rdf:type con tipos especificados en @typeof.
Las equivalencias locales de términos, una lista de términos y sus IRIs asociadas.
Las equivalencias de listas locales, equivalencias de IRIs con listas.
Un vocabulario local por defecto, una IRI para utilizar como una equivalencia de prefijo cuando se utilice un término.
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:
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:
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:
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:
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:
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:
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:
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:
El contenido es una IRI y se utiliza como tal.
Cuando el valor se especifica entre corchetes, entonces el contenido se evalua como una CURIE acorde a la Definición de la Sintaxis CURIE. Si no es una CURIE válida, el valor debe ser ignorado.
De lo contrario, el valor se evalúa como una CURIE. Si es una CURIE válida se utiliza la IRI obtenida, de lo contrario, el valor se procesa como un IRI.
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.
Si el valor es un término entonces se evalua como un término acorde al Uso General de Términos en Atributos. Debe tenerse en cuenta que este paso puede implicar que se ignore el valor.
Si el valor es una CURIE válida, entonces se utiliza la IRI resultante.
Si el valor es una IRI absoluta, se utiliza ese valor.
En caso contrario, 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:
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:
Una vez que se establece el prefijo, un autor puede utilizarlo para abrevias IRIs del siguiente modo:
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:
Debe tenerse en cuenta que se considera una mala idea utilizar rutas relativas en declaraciones de prefijos. Al ser posible que un autor pueda ignorar esta recomendación, es posible además que la IRI obtenida a partir de una CURIE sea relativa. Sin embargo, puesto que todas las IRIs deben resolverse considerándose relativas a la base antes de utilizarse para crear tripletas, el uso de rutas relativas no debería tener ningún efecto en el procesamiento.
7.4.1 Ámbito de asignaciones de prefijo
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:
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 puede permitir una mezcla de TÉRMINOS, CURIEs e IRIs absolutas.
Un atributo puede permitir uno o más valores que sean una mezcal de CURIEs e IRIs. En este caso cualquier valor que no sea una CURIE, tal y como se especifica en la sección Definición de la sintaxis CURIE, se procesará como una IRI.
Si el valor está entre corchetes, entonces dicho contenido se evalua siempre según las reglas indicadas en la sección Definición de la sintaxis CURIE - y si este contenido no es una CURIE entonces debe ser ignorado.
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í:
mientras que para expresar la IRI anterior como una CURIE se podría hacer lo siguiente:
El autor también podría utilizar una CURIE segura:
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.
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:
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:
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:
Si hay un vocabulario local por defecto la IRI se obtiene concatenando dicho valor con el término.
En caso contrario, se comprueba si el 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.
De lo contrario, el 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:
@about y @resource suportan el tipo de dato SafeCURIEorCURIEorIRI - permitiendo el uso de una SafeCURIE, una CURIE o una IRI.
@href y @src se definen en el lenguaje anfitrión (por ejemplo, XHTML), y solo soportan el uso de una IRI.
@vocab soporta el uso de una IRI.
@datatype soporta el tipo de dato TERMorCURIEorAbsIRI - y permite utilizar un único término, una CURIE o una IRI absoluta.
@property, @typeof, @rel, y @rev soportan el tipo de dato TERMorCURIEorAbsIRIs - permitiendo uno o varios términos, CURIEs o IRIs absolutas.
Cualquier valor que coincida con un término definido debe expandirse a su correspondiente IRI. Por ejemplo, en los siguientes casos:
cada uno de ellos generaría la siguiente tripleta:
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.
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:
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.
7.5 Sequencia
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:
la base se inicializa con la IRI del documento (u otro valor especificado con un mécanismo específica del lenguaje, como el elemento base de HTML);
el sujeto padre se inicializa con el valor de la base;
el objeto padre toma un valor nulo (null);
la lista de tripletas incompletas está vacía;
la lista de equivalencias está vacía;
el idioma toma un valor nulo.
la lista de equivalencias de IRIs está vacía (o es una lista definida en el contexto inicial del lenguaje anfitrión).
las equivalencias de términos se inicializan con un valor nulo (o es una lista definida en el contexto inicial del lenguaje anfitrión).
el vocabulario por defecto se inicializa con un valor nulo (o una IRI definida en el contexto inicial del lenguaje anfitrión).
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:
Primero, los valores locales se inicializan del siguiente modo:
el elemento de salto toma el valor falso ('false');
se asigna al sujeto nuevo un valor nulo ('null');
se asigna al recurso objeto actual un valor nulo;
se asigna al recurso tipado un valor nulo;
la lista local de equivalencias de IRIs se inicializa con la lista de equivalencias IRIs tomada del contexto de evaluación;
la lista local de tripletas incompletas toma un valor nulo;
la lista de equivalencias se inicializa con los valores de la lista de equivalencias del contexto de evaluation;
el idioma actual toma el valor del idioma del contexto de evaluación.
las equivalencias de términos locales se inicializan con las equivalencias de término del contexto de evaluación.
el vocabulario local por defecto se inicializa con el vocabulario por defecto del contexto de evaluación.
Debe tenerse en cuenta que algunas de las variables locales son contenedores temporales para los valores que se pasarán a los elementos descendientes a través de un contexto de evaluación. En algunos casos, los contenedores tienen el mismo nombre, para dejar claro que se está actuando sobre él en los pasos siguientes, mientras que la versión local de un elemento generalmente se referirá como tal.
A continuación se examina el elemento actual en busca de cualquier cambio en el vocabulario por defecto mediante @vocab. Si @vocab está presente y contiene un valor, el vocabulario local por defecto se actualiza según se establece en la sección Procesamiento de CURIEs e IRIs. Si el valor está vacío, entonces el vocabulario local por defecto debe restablecerse al definido por defecto por el lenguaje anfitrión (si lo hubiese).
El valor de @vocab se utiliza para generar una tripleta del siguiente modo:
valor de @vocab
No es preciso que un lenguaje anfitrión defina un vocabulario por defecto. En tal caso, el valor de @vocab debe establecerse como vacío, teniendo el mismo efecto que si se estableciera el vocabulario local por defecto como nulo ('null').
A continuación, se examina el elemento actual en búsqueda de equivalencias de IRIs y estas son añadidas a la lista local de equivalencias de IRIs. Debe tenerse en cuenta que una equivalencia IRI será simplemente reemplazada si previamente existía en la lista una equivalencia con el mismo nombre;
Las equivalencias deben definirse mediante @prefix. Los valores en este atributo se evalúan desde el principio hasta el fin (por ejemplo, de izquierda a derecha en documentos típicos). Para la compatibilidad con versiones anteriores, los procesadores RDFa deberían permitir también la definición de equivalencias utilizando @xmlns. En este caso, el valor de la equivalencia se establece a través del prefijo del espacio de nombres XML (XML namespace) y la equivalencia es el valor del atributo — una IRI. (Obsérvese que las equivalencia de prefijo definidas mediante @xmlns son obsoletas y pueden retirarse en futuras versiones de esta especificación). Cuando se soporte el uso de xmlns, dichas equivalencias deben procesarse antes de cualquier equivalencia definida con @prefix en el mismo elemento. Independientemente de cómo se declare la equivalencia, el valor debe convertirse, sin que se realice ningún tipo de procesamiento sobre la IRI; en particular, si se trata de una ruta relativa no debe resolverse utilizando la base actual. Los autores no deberían utilizar IRIs como rutas relativas.
Los elementos actuales también son analizados en busca de cualquier información de idioma, y si está presente se establece oportunamente el lenguaje actual;
Los lenguajes anfitrión que incorporan RDFa pueden proporcionar un mecanismo para especificar el lenguaje natural de un elemento y su contenido (por ejemplo, XML ofrece el atributo de propósito general @xml:lang).
Si el elemento actual no contiene nigún atributo @rel o @rev, entonces el siguiente paso es establecer un valor para el nuevo sujeto. Este paso tiene dos alternativas posibles.
Si el elemento actual contiene el atributo @property, pero no contiene ningún atributo @content o @datatype, entonces:
se establece como nuevo sujeto el recurso obtenido de la primera equivalencia que cumpla la siguiente regla:
utilizando el recurso indicado por el atributo @about si está presente, obtenido como se indica en la sección Procesamiento de IRIs y CURIEs;
de lo contrario, si el elemento es el elemento raiz del documento, entonces se debe actuar como si existiera un atributo @about vacío, y procesado según las reglas indicadas anteriormente para el atributo @about;
de lo contrario, si existe un objeto padre se asigna su valor al nuevo sujeto.
si existe un atributo typeof entonces se establece como recurso tipado el recurso obtenido de la primera equivalencia que cumpla la siguiente regla:
de lo contrario, si el elemento es el elemento raiz del documento, entonces se actuará como si existiera un atributo @about vacío, y procesado según las reglas indicadas anteriormente para el atributo @about;
utilizando el recurso indicado por el atributo @resource si está presente, obtenido como se indica en la sección Procesamiento de IRIs y CURIEs;
de lo contrario, utilizando la IRI del atributo @href si está presente, obtenido como se indica en la sección Procesamiento de IRIs y CURIEs;
de lo contrario, utilizando la IRI del atributo @src si está presente, obtenido como se indica en la sección Procesamiento de IRIs y CURIEs;
de lo contrario, el establece el valor del recurso tipado con el del nodo en blanco (bnode) recién creado.
El valor del recurso objeto actual se establece entonces con el valor del recurso tipado.
si el elemento contiene un atributo @about, @href, @src, o @resource se establece como nuevo sujeto el recurso obtenido del siguiente modo:
utilizando el recurso del atributo @about si está presente, obtenido como se indica en la sección Procesamiento de IRIs y CURIEs;
de lo contrario, utilizando el recurso del atributo @resource si está presente, obtenido como se indica en la sección Procesamiento de IRIs y CURIEs;
de lo contrario, utilizando la IRI del atributo @src si está presente, obtenido como se indica en la sección Procesamiento de IRIs y CURIEs.
de lo contrario, si no se proporciona un recurso por un atributo, entonces se aplicará la primera de las siguientes reglas que se cumpla:
si el elemento es el elemento raiz del documento, entonces se actuará como si existiera un atributo @about vacío, y procesado según las reglas indicadas anteriormente para el atributo @about;
de lo contrario, si existe un atributo @typeof, entonces se asocia el nuevo sujeto con un nodo en blanco (bnode) recién creado;
de lo contrario, si existe un objeto padre se asigna su valor al nuevo sujeto. Adicionalmente, si la propiedad @property no está presente entonces se asigna el valor 'verdadero' (true) al registro del elemento de salto.
Finalmente, si existe un atributo @typeof se establece entonces el valor del recurso tipado con el del nuevo sujeto.
Si el elemento actual contiene un atributo @rel o @rev, entonces el siguiente paso es establecer sendos valores para el nuevo sujeto y para el recurso objeto actual:
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:
de lo contrario, si existe un objeto padre se establece como nuevo sujeto el valor de dicho objeto.
Entonces se establece el valor del recurso objeto actual con el recurso obtenido al cumplirse la primera de las siguientes reglas que se cumpla:
de lo contrario, si @typeof está presente y @about no, se usa el nodo en blanco (bnode) recién creado.
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.
Si en cualquiera de los pasos anteriores a un recurso tipado se le asigna un valor no nulo (non-null), entonces es utilizado para proporcionar un sujeto para los valores con tipo;
Pueden establecerse uno o más tipos para el recurso tipado utilizando el atributo @typeof. Si está presente, el atributo puede contener una o más IRIs, obtenidas como se indica en la sección Procesamiento de IRIs y CURIEs, cada una de las cuales se utiliza para generar una tripleta como la siguiente:
recurso tipado
IRI completa actual del 'tipo' obtenida a partir del recurso tipado
Si en cualquiera de los pasos anteriores se establece un nuevo sujeto con un valor no nulo diferente del objeto padre;
La lista de equivalencias tomada del contexto de evaluación se inicializa con una lista vacía.
Si en cualquiera de los pasos anteriores se establece un recurso objeto actual con un valor no nulo, entonces es utilizado para generar tripletas y añadir una entrada a la lista local de equivalencias:
Si el elemento contiene ambos atributos, @inlist y @rel, este último puede contener uno o más recursos, obtenidos como se indica en la sección Procesamiento de IRIs y CURIEs, cada uno de los cuales es utilizado para añadir una entrada en la lista de equivalencias del siguiente modo:
si la lista local de equivalencias no contiene una lista asociada con las IRIs hay que instanciar una nueva lista y añadirla a la lista local de equivalencias
añadir el recurso objeto actual a la lista asociada con el recurso en la lista local de equivalencias
Los predicados del recurso objeto actual puede establecerse usando algún atributo @rel o @rev , pero únicamente podrá utilizarse @rel si no está presente @inlist:
El atirbuto @rel puede contener si está presente uno o más recursos, obtenidos como se indica en la sección Procesamiento de IRIs y CURIEs, cada uno de los cuales es utilizado para general una tripleta del siguiente modo:
nuevo sujeto
IRI completa
recurso objeto actual
Si está presente el atributo @rev este puede contener uno o más recursos, obtenidos como se indica en la sección Procesamiento de IRIs y CURIEs, cada uno de los cuales es utilizado para general una tripleta del siguiente modo:
Sin embargo, si el recurso objeto actual se estableció como nulo, pero existen predicados, entonces estos deben almacenarse como tripletas incompletas, a la espera de descubrir un subjeto que pueda utilizarse como objeto. Además, el recurso objeto actual debería asignarse a un nodo en blanco de nueva creación (de modo que las tripletas incompletas tienen un subjeto al que conectarse si en última instancia se convirtieran en tripletas);
Los predicados para tripletas incompletas puede establecerse utilizando un atributo @rel o @rev:
Si está presente, el atributo @rel debe contener uno o más recursos, obtenidos como se indica en la sección Procesamiento de IRIs y CURIEs, cada uno de los cuales se añade a la lista local de tripletas incompletas del siguiente modo:
Si el elemento contiene el atributo @inlist, entonces
si la lista local de equivalencias no contiene una lista asociada con el IRI, instanciar una nueva lista y añadirla a la lista local de equivalencias.
a partir de la lista local de equivalencias para esta IRI
Si está presente, el atributo @rev debe contener uno o más recursos, obtenidos como se indica en la sección Procesamiento de IRIs y CURIEs, cada uno de los cuales se añade a la lista local de tripletas incompletas del siguiente modo:
El siguiente paso de la iteración es establecer el valor de la propiedad actual;
El predicado para el valor de la propiedad actual puede establecerse utilizando el atributo @property. Si existen, uno o más recursos son obtenidos como se indica en la sección Procesamiento de IRIs y CURIEs, y entonces el valor literal actual se obtiene del siguiente modo:
como literal tipado si existe un atributo @datatype, este no tiene un valor vacío según la sección Procesamiento de IRIs y CURIEs, y no se identifica como un 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.
de lo contrario, como literal plano si el atributo @datatype está presente, tendrá un valor vacío acorde a 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.
de lo contrario, como literal XML si @datatype está presente, se identificará como un 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.
de lo contrario, como un literal plano se usará, si está presente, el valor de @content.
de lo contrario, si los atributos @rel, @rev, y @content no están presentes, como un recurso obtenido de alguna de las siguientes formas:
usando el recurso indicado por el atributo @resource si está presente, obtenida acorde a la sección Procesamiento de IRIs y CURIEs;
de lo contrario, utilizando la IRI del atributo @href si está presente, obtenida según se indica en la sección Procesamiento de IRIs y CURIEs;
de lo contrario, utilizando la IRI del atributo @src si está presente, obtenida según se indica en la sección Procesamiento de IRIs y CURIEs.
de lo contrario, si el atributo @typeof está presente y no existe ningún atributo @about, se utilizará el valor del recurso tipado.
de lo contrario como un literal plano.
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:
Si el elemento también incluye el atributo @inlist, el valor de la propiedad actual se añade a la lista local de equivalencias como sigue:
si la lista local de equivalencias no contiene una lista asociada con las IRIs de los predicados, debe instanciarse una nueva lista y añadirla a la lista local de equivalencias
añadir el valor de la propiedad actual a la lista asociada con la IRI del predicado en la lista local de equivalencias
De lo contrario se debe utilizar el valor de la propiedad actual para generar una tripleta de la siguiente forma:
valor de la propiedad actual
Si el registro del elemento de salto tiene un valor 'falso' ('false'), y se asignó un valor no nulo al nuevo sujeto, entonces podría completarse cualquier tripleta incompleta en el contexto actual:
La lista de tripletas incompletas del contexto de evaluación actual (no la lista local de tripletas incompletas) contendrá cero o más IRIs de predicados. De forma iterativa, cada uno de los predicados de esta lista se utilizan con un sujeto padre y un nuevo sujeto para generar una tripleta o añadir un nuevo elemento a la lista local de equivalencias. Debe tenerse en cuenta que en cada nivel hay dos listas de tripletas incompletas; una para el nivel actual de procesamiento (que se transmite a cada elemento hijo del paso anterior), y otra recibida como parte del contexto de evaluación. Es esta última la que se utiliza en el procesamiento durante este paso.
Obsérvese que cada tripleta incompleta tiene un valor de dirección que es usado para determinar el sujeto y el objeto de cada tripleta generada:
Si dirección es 'ninguna' ('none') el nuevo sujeto se añade a la lista a partir de la tripleta incompleta iterada.
Si dirección es 'adelante' ('forward') entonces se general la siguiente tripleta:
sujeto padre
el predicado de la tripleta incompleta iterada
If dirección es 'atrás' ('reverse') entonces se genera la siguiente tripleta:
A continuación, todos los elementos que sean descendientes del elemento actual son procesados utilizados las reglas descritas aquí, utilizando un nuevo contexto de evaluación, inicializado del siguiente modo:
Si el registro del elemento de salto es verdadero ('true') entonces el nuevo contexto de evaluación es una copia del contexto actual transmitido a este nivel de procesamiento, con los valores de idioma y de la lista de equivalencias de IRIs reemplazados con los valores locales;
En caso contrario, los valores son:
la base se inicializa con el valor de la base del contexto de evaluación inicial;
el sujeto padre se inicializa con el valor del nuevo sujeto, si no es nulo, o el valor del sujeto padre del contexto de evaluación actual;
el objeto padre se inicializa con el valor del recurso objeto actual, si no es nulo, o el valor del nuevo sujeto, si no es nulo, o el valor del sujeto padre del contexto de evaluación actual;
la lista de equivalencias de IRIs se inicializa con la lista local de equivalencias de IRIs;
la lista de tripletas incompletas se inicializa con la lista local de tripletas incompletas;
la lista de equivalencias se inicializa con la lista local de equivalencias;
el idioma se inicializa con el valor del idioma actual.
el vocabulario por defecto se inicializa con el valor del vocabulario local por defecto.
Finalmente, si hay una o más equivalencias en la lista local de equivalencias, la lista de tripletas se genera del siguiente modo:
Para cada IRI de la lista local de equivalencias, si no existe dicha asignación en el contexto de evaluación, indicando que la lista fue originalmente instanciada en el elemento actual, debe utilizarse la lista del siguiente modo:
Si hay cero items en la lista asociada con la IRI, se generará la siguiente tripleta:
sujeto actual
la IRI de la lista local de equivalencias asociada con esta lista
Crear un array de nuevos nodos en blanco (‘bnode’) conteniendo nodos en blanco recién creados, uno para elemento de la lista
Para cada par (nodo en blanco, IRI / literal) de la lista se generará la siguiente tripleta:
nodo en blanco
IRI completa o literal
Para cada elemento del array de nodos en blanco se general la siguiente tripleta:
el siguiente elemento del array de nodos en blanco, o si este no existe http://www.w3.org/1999/02/22-rdf-syntax-ns#nil
Se genera una única tripleta adicional:
la IRI completa de la lista local de equivalencias asociada con esta lista
el primer elemento del array de nodos en blanco
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:
Una tripleta 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.
Una tripleta rdfa:Warning debe generarse cuando falle la resolución de un prefijo CURIE.
Una tripleta 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):
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):
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 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í:
Esto generaría las siguientes tripletas:
Es posible que los datos aparezcan en cualquier lugar del documento:
lo que generaría la siguiente tripleta:
En (X)HTML el valor de base puede cambiar el valor inicial del sujeto actual:
Un procesador RDFa debería generar ahora las siguientes tripletas, con independencia de la IRI del documento:
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:
Con este marcado un procesador RDFa generaría las siguientes tripletas:
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:
Del mismo modo, los autores pueden hacer declaraciones acerca de las imágenes:
@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:
se crea la siguiente tripleta:
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:
las tripletas generadas incluirían:
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:
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):
Este uso "aislado" de @typeof puede verse como una forma abreviada para:
Un nodo en blanco es simplemente un identificador único que sólo está disponible para el procesador, no para cualquier software externo. Mediante la generación de valores internos, el procesador es capaz de realizar un seguimiento de las propiedades de _: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.
8.1.1.3.1 Encadenamiento con @property y @typeof
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:
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.
8.1.1.4 Determinando el sujeto sin utilizar @about o @typeof
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:
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:
pero también es posible que un autor consiga el mismo efecto eliminando @about y manteniendo @resource:
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:
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:
mientras que el segundo se refiere al atributo @resource que los contiene:
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:
Un procesador RDFa generaría las siguientes tripletas:
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:
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:
Téngase en cuenta que el div es supérfluo, y un procesador RDFa creará el objeto intermedio, incluso si se elimina el elemento:
Un patrón alternativo es mantener el div y mover a su interior el atributo @rel:
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:
y luego otra declaración para indicar que el 'nombre largo' para este país es el Imperio Alemán:
RDFa permite a los autores insertar esta declaración como una unidad auto-contenida en otros contextos:
Pero también permite a los autores, evitar repeticiones innecesarias y 'normalizar' los identificadores duplicados, en el caso del Imperio Alemán:
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:
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':
y segundo se usa para generar su propia tripleta:
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:
En este ejemplo hay una tripleta incompleta:
Cuando el procesador encuentra cada uno de los valores @about se completa esta tripleta, obteniendo:
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:
Primero se almacenará la siguiente tripleta:
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:
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:
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:
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:
pero al procesar dbp:dateOfBirth solo se genera una:
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':
Como en el caso anterior, las dos ocurrencias de @about completa cada una de las 'tripletas incompletas':
El conjunto completo de tripletas que debería generar un procesador RDFa sería el siguiente:
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:
También puede especificarse un literal plano utilizando el contenido del elemento:
Ambos ejemplos producirán la siguiente tripleta:
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:
8.3.1.1.1 Etiquetas de idiomas
RDF permite que los literales planos tengan una etiqueta de idioma, tal y como se muestra en el siguiente ejemplo tomado de [ RDF-TESTCASES ]:
En RDFa el lenguaje anfitrión puede proporcionar mecanismos para establecer la etiqueta de idioma. Por ejemplo, en XHTML+RDFa [ XHTML-RDFA ] se utiliza el atributo @xml:lang de XML o el atributo @lang para añadir esta información, en el caso de que el literal plano sea especificado por @content o por el texto marcado del elemento:
Ha de tenerse en cuenta que el valor del idioma puede ser heredado tal y como se define en [ XML10-4e ], por lo tanto, la sintaxis del siguiente ejemplo generará la misma tripleta que en el caso anterior:
<title xml:lang="es">Example</title>
Es posible asignar un tipo de dato a los literales utilizando @datatype.
Esto puede representarse en RDFa del siguiente modo:
Las tripletas que genera este marcado incluyen el tipo de dato del literal:
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):
Sin embargo, RDFa soporta el uso de marcado normal para expresar literales XML utilizando @datatype:
Esto generaría la siguiente tripleta, preservando el marcado XML en el literal:
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:
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:
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.
8.3.2.1 Uso de @resource para establecer el 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:
El elemento blockquote genera la siguiente tripleta:
Debe tenerse en cuenta que en el ejemplo anterior podría haberse usado @property en vez de @rel, obteniendo la misma tripleta.
8.3.2.2 Uso de @href o @src para establecer el sujeto
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:
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:
que a su vez proporciona dos tripletas:
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:
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:
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:
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:
href="http://ben.adida.net/#me">Ben Adida</span>,
href="http://twitter.com/markbirbeck">Mark Birbeck</span>, and
href="http://www.ivan-herman.net/foaf#me">Ivan Herman</span>.
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:
En el ejemplo anterior, podría haberse utilizado @rel obteniendo exactamente las mismas tripletas:
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:
Debe tenerse en cuenta que también es posible expresar una lista vacía, sin ningún atributo @inlist, usando:
9. Contextos iniciales RDFa
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:
Analizar el contenido (acorde a las reglas de procesamiento para ese tipo de documento) y extraer las tripletas a una colección asociada con esa IRI: Nota: Esas tripletas NO DEBEN combinarse con las tripletas extraídas a partir de cualquier otra IRI.
Crear, para cada subjeto con un par de predicados con los valores 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.
Crear, para cada subjeto con un par de predicados con los valores 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.
Definir, para una tripleta extraída cuyo predicado sea 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.
10. Expansión de vocabularios en RDFa
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:
que permite obtener el siguiente grafo de salida:
Tras la expansión de vocabulario, el grafo de salida contendría:
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.
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:
El procesador interviene en la combinación del grafo por defecto y del grafo del vocabulario utilizando el vocabulario RDFa para inferencias.
Se añaden las nuevas tripletas inferidas del grafo de salida utilizando esta inferencia para el grafo de salida (expandido). El procesador no debería añadir las tripletas que aparezcan únicamente en el grafo de vocabulario.
El objetivo del segundo paso es evitar añadir los "axiomas", por ejemplo, las definiciones de sub-propiedades al grafo de salida. Las aplicaciones normalmente no precisan nada de esta información adicional.
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:
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.
El tipo de inferencia descrita en esta sección es el nivel mínimo de utilidad para RDFa. Por supuesto, los procesadores pueden escoger seguir regímenes de inferencia más potentes, por ejemplo, mediante la inclusión de inferencias completas de RDFS [ RDF-MT ] o de OWL [ OWL2-OVERVIEW ]. Usando dichas aplicaciones de inferencia se pueden realizar validaciones de tipos de datos mediante la comprobación del rango (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.
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:
Una única curie
Una lista de CURIEs separadas por espacios en blanco
Una única CURIE o IRI
Una lista CURIEorIRIs separadas por espacios en blanco
Una única safe_curie
Una única SafeCURIE o CURIEorIRI
Una lista de SafeCURIEorCURIEorIRIs separadas por espacios en blanco
Un único término
Un TERM o una CURIEorIRI
Una lista de TERMorCURIEorAbsIRIs separados por espacios en blanco
La siguiente definición informativa del esquema XML para estos tipos de datos se incluye como un ejemplo:
La siguiente definición XML DTD informativa para estos tipos de datos se incluyen como un ejemplo:
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 ]):
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:
que define un prefijo para la IRI de foaf.
C.1 Principales diferencias con la Sintaxis RDFa 1.0
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.
Las reglas específicas sobre XHTML se han trasladado a una especificación complementaria: [ XHTML-RDFA ].
Las equivalencias de prefijos pueden declararse ahora utilizando @prefix además de @xmlns. El uso de @xmlns ha quedado obsoleto.
Ahora se requiere convertir a minúsculas los nombres de prefijo en el momento de la definición de la equivalencia. Los prefijos se comprobarán en modo insensible a mayúsculas y minúsculas durante la expansión de CURIEs.
Ahora se pueden utilizar IRIs absolutas en todas partes, ya que anteriormente únicamente podían usarse CURIEs (por ejemplo, en el valor de @datatype).
Ahora se utiliza el concepto de término. Este concepto ha reemplazado el de 'palabra reservada'. Es posible que ahora se use 'término' en muchos lugares donde anteriormente se usaba una CURIE.
Es posible definir una equivalencia de prefijo por defecto (mediante @vocab) que será utilizada en términos no definidos.
Cuando una tripleta incluya un objeto literal, y no hay ningún atributo de tipo de datos explícito, el objeto literal será ahora un 'literal plano'. En la versión 1.0, hubiera sido un 'XMLLiteral'.
El atributo @inlist puede utilizarse ahora para indicar al procesador que genere listas de recursos RDF en vez de tripletas individuales.
Ahora el efecto del atributo @src es idéntico al de @href en lugar del de @about de la versión 1.0.
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:
Utilizar el tipo de documento XHTML+RDFa 1.0 tal y como se define en [ RDFA-SYNTAX ].
Incluir un atributo @version con el valor XHTML+RDFa 1.0 en el elemento html.
En aquellos lugares del documento en el que un objeto literal debe ser un XMLLiteral, usar datatype='rdf:XMLLiteral'.
En aquellos lugares del documento en el que un objeto literal debe ser un literal plano, usar datatype=''.
En aquellos lugares del documento donde se utilice el atributo @src debe añadirse un atributo @about (a menos que ya esté presente) con la misma IRI.
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:
NO utilizar @vocab.
NO confíe únicamente en el lenguaje anfitrión para las equivalencias por defecto de IRIs.
NO usar IRIs absolutas en lugar de CURIEs.
Usar @xmlns y @prefix cuando se declaren prefijos para equivalencias.
NO usar términos en los atributos @datatype, @property, o @typeof.
Cuando se usen términos en los atributos @rel y @rev, utilizar únicamente aquellos que se encuentran definidos en [ RDFA-SYNTAX ].
Incluir un atributo version con el valor XHTML+RDFa 1.0 en el elemento html.
En el momento de la publicación de este documento, los miembros activos del Grupo de Trabajo de Aplicaciones Web RDF eran:
Marcos Cáceres. Widget URI Scheme. . W3C Note. URL: http://www.w3.org/TR/2011/WD-widgets-uri-20110927

References: Resolución 
 Resolución 
 Resolución 
 Resolución 
 resolución 
 resolución 
 resolución