RDFa Core 1.1

4.1 Conformidad del procesador RDFa

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.

4.2 Conformidad RDFa del lenguaje anfitrión

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.

4.3 Conformidad del documento con XML+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:

1. El documento debe estar bien formado tal y como se establece en [XML10-4e].
2. 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:

1. Existen términos predeterminados (por ejemplo, describedby, license, y role), definidos en http://www.w3.org/2011/rdfa-context/rdfa-1.1.
2. Existen una serie de equivalencias de prefijos predeterminadas (por ejemplo, dc), definidos en http://www.w3.org/2011/rdfa-context/rdfa-1.1.
3. No se define una IRI de vocabulario por defecto.
4. La base puede establecerse utilizando el atributo @xml:base tal y como se define en [XML10-4e].
5. El idioma actual puede establecerse mediante el atributo @xml:lang.

5.1 Papel de los atributos

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.

5.2 Espacios en blanco en los valores de los atributos

Muchos atributos aceptan una lista de elementos separados por espacios en blanco. Esta especificación define como el espacio en blanco:

whitespace      ::=  (#x20 | #x9 | #xD | #xA)+ 

Cuando los atributos aceptan una lista de elementos separados por espacios en blanco, un procesador RDFa debe ignorar cualquier espacio en blanco al principio o al final de la lista.

Esta definición es consistente con la incluída en [XML10].

7.1 Introducción

La evaluación de un documento con tripletas RDFa se lleva a cabo comenzando por el objeto de documento, y visitando a continuación cada uno de sus elementos hijo, en el orden en el que se encuentren en el documento, aplicando las reglas de procesamiento. El proceso es recursivo por lo que para cada elemento hijo el procesador también visita cada uno de sus elementos hijo aplicando las mismas reglas de procesamiento.

En algunos entornos, habrá poca diferencia entre comenzar por el elemento raiz del documento y comenzar por el objeto de documento en sí. Esto explica la causa por la que en algunos entornos existe información importante en el nivel del objeto de documento que no está presente en el elemento raíz.

Según continúa el proceso se aplican las reglas que pueden generar tripletas, y también puede cambiar la información del contexto de evaluación que a continuación se utiliza para procesar los elementos descendientes.

Esta especificación no dice nada acerca de lo que debería suceder con las tripletas generadas, o si pueden generarse más tripletas durante el proceso aquí descrito. Sin embargo, para que un procesador RDFa cumpla la conformidad debe actuar aplicando como mínimo las reglas de esta sección y produciendo un grafo RDF sencillo. Como se describe en la sección Conformidad del procesador RDFa, las tripletas adicionales generadas no deben aparecer en el grafo de salida. Estas pueden estar incluidas en el grafo del procesador.

7.2 Contexto de evaluación

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.

7.3 Encadenamiento

El encadenamiento de declaraciones es una característica de RDFa que permite a los autores enlazar varias declaraciones RDF al mismo tiempo, haciendo innecesario el uso de marcado repetitivo. Por ejemplo, si un autor tuviera que añadir ciertas declaraciones como hijas de un objeto recurso, dichas declaraciones deberían interpretarse como asociadas a dicho recurso:

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <span property="foaf:name">Albert Einstein</span>
  <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
  <div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire">
    <span property="dbp:conventionalLongName">the German Empire</span>
  </div>
</div>

En este ejemplo puede verse que un recurso objeto ('German_Empire'), es el sujeto para las declaraciones anidadas. Este marcado también muestra el patrón de encadenamiento básico de "A tiene un B tiene un C" (en el ejemplo, Einstein tiene un lugar de nacimiento identificado como 'German_Empire', el cual tiene asociado como nombre largo en Inglés "the German Empire").

También es posible que los contenidos de las declaraciones anidadas proporcionen el objeto para contener las declaraciones - esencialmente lo contrario del ejemplo anterior. Para ilustrar esto, puede verse un ejemplo del tipo de encadenamiento descrito, que muestra cómo podría marcarse de modo más eficiente. Para empezar, se marca el hecho de que Albert Einstein tenía, en algún momento de su vida, una residencia tanto en el Imperio alemán como en Suiza:

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <div rel="dbp-owl:residence" resource="http://dbpedia.org/resource/German_Empire"></div>
  <div rel="dbp-owl:residence" resource="http://dbpedia.org/resource/Switzerland"></div>
</div>

Seguidamente, se muestra la misma información, pero creando en esta ocasión una tripleta incompleta desde la parte de residencia y a continuación se utilizan una serie de subjetos adicionales para 'completar' dicha tripleta:

<div about="http://dbpedia.org/resource/Albert_Einstein" rel="dbp-owl:residence">
  <span about="http://dbpedia.org/resource/German_Empire"></span>
  <span about="http://dbpedia.org/resource/Switzerland"></span>
</div>

En este ejemplo, la tripleta incompleta se completa dos veces, una para el Imperio Alemán y otra para Suiza, ofreciendo exactamente la misma información del primer ejemplo:

<http://dbpedia.org/resource/Albert_Einstein>
  dbp-owl:residence <http://dbpedia.org/resource/German_Empire> .
<http://dbpedia.org/resource/Albert_Einstein>
  dbp-owl:residence <http://dbpedia.org/resource/Switzerland> .

En encadenamiento a veces puede involucrar elementos que contengan un marcado relativamente mínimo, por ejemplo mostrando sólo un recurso, o sólo un predicado. En el ejemplo siguiente, el elemento img se utiliza para transportar una imagen de Einstein:

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <div rel="foaf:depiction">
    <img src="http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg" />
  </div>
</div>

Cuando se utilice dicho marcado mínimo, cualquiera de los atributos relacionados con los recursos podría actuar como un sujeto o un objeto en el encadenamiento:

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <div rel="dbp-owl:residence">
    <span about="http://dbpedia.org/resource/German_Empire"></span>
    <span about="http://dbpedia.org/resource/Switzerland"></span>
  </div>
</div>

Debe tenerse en cuenta que, como se ha indicado anteriormente, en muchas situaciones @property y @rel son intercambiables. Esto no sucede así en el encadenamiento. Partiendo del primer ejemplo, si se utilizara de la siguiente forma:

<div about="http://dbpedia.org/resource/Albert_Einstein">
  <span property="foaf:name">Albert Einstein</span>
  <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
  <div property="dbp:birthPlace" resource="http://dbpedia.org/resource/German_Empire">
    <span property="dbp:conventionalLongName">the German Empire</span>
  </div>
</div>

El sujeto para 'German Empire' seguiría siendo Albert Einstein (y esto sería en efecto un error). Esta es la principal diferencia entre @property y @rel: el segundo induce encadenamiento, mientras que el primero por lo general no lo hace.

7.4 Procesamiento de CURIEs e IRIs

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:

IRI

El contenido es una IRI y se utiliza como tal.

SafeCURIEorCURIEorIRI

• 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.

TERMorCURIEorAbsIRI

• 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:

http://dbpedia.org/resource/Albert_Einstein

Esto puede ser abreviado por los autores usando una CURIE para que la información sea más fácil de manejar. En el primer paso el autor crea una asignación de prefijo que vincula un prefijo con algún segmento inicial de la IRI. En RDFa estas asignaciones se expresan utilizando @prefix:

<div prefix="db: http://dbpedia.org/">
  ...
</div>

Una vez que se establece el prefijo, un autor puede utilizarlo para abrevias IRIs del siguiente modo:

<div prefix="db: http://dbpedia.org/">
  <div about="db:resource/Albert_Einstein">
    ...
  </div>
</div>

El autor es libre de dividir el IRI en cualquier momento. Sin embargo, dado que un uso común de las CURIEs es hacer que estén disponibles bibliotecas de términos y valores, el prefijo por lo general se asigna a un segmento común que proporciona la máxima reutilización, a menudo por quienes administran la biblioteca de términos. Por ejemplo, puesto que DBPedia contiene una enorme lista de recursos, es más eficiente crear una asignación de prefijo que utiliza la ubicación de la base de los recursos:

<div prefix="dbr: http://dbpedia.org/resource/">
  <div about="dbr:Albert_Einstein">
    ...
  </div>
  <div about="dbr:Baruch_Spinoza">
    ...
  </div>
</div>

<div prefix="dbr: http://dbpedia.org/resource/">
  <div about="dbr:Albert_Einstein">
    ...
  </div>
</div>
<div prefix="dbr: http://someotherdb.org/resource/">
  <div about="dbr:Albert_Einstein">
    ...
  </div>
</div>

<div about="http://dbpedia.org/resource/Albert_Einstein">
  ...
</div>

<div about="dbr:Albert_Einstein">
  ...
</div>

<div about="[dbr:Albert_Einstein]">
  ...
</div>

<div about="[Albert_Einstein]">
  ...
</div>

<div about="Albert_Einstein">
  ...
</div>

term     ::=  NCNameStartChar termChar*
termChar ::=  ( NameChar - ':' ) | '/'
    

<link rel="license" href="http://example.org/license.html" />
<link rel="xhv:license" href="http://example.org/license.html" />

<> <http://www.w3.org/1999/xhtml/vocab#license> <http://example.org/license.html> .

<link about="_:john" rel="foaf:mbox"
  href="mailto:john@example.org" />
<link about="_:sue" rel="foaf:mbox"
  href="mailto:sue@example.org" />
<link about="_:john" rel="foaf:knows"
  resource="_:sue" />

_:john foaf:mbox <mailto:john@example.org> .
_:sue foaf:mbox <mailto:sue@example.org> .
_:john foaf:knows _:sue .

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:

1. 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.
2. 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:

   sujeto

   base

   predicado

   http://www.w3.org/ns/rdfa#usesVocabulary

   objeto

   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').
3. 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.
4. 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).
5. 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.
   1. 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:

      • 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 actuará como si existiera un atributo @about vacío, y procesado según las reglas indicadas anteriormente para el atributo @about;
      • de lo contrario,
        • 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.
   2. de lo contrario:
      • 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 @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, 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.

6. 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:
   se establece como nuevo sujeto el recurso obtenido de la primera equivalencia que cumpla la siguiente regla:

   • utilizando el recurso del atributo @about si está presente, obtenido como se indica en la sección Procesamiento de IRIs y CURIEs;

   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:

   • 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 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:

   • 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, 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.

7. 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:

   sujeto

   recurso tipado

   predicado

   http://www.w3.org/1999/02/22-rdf-syntax-ns#type

   objeto

   IRI completa actual del 'tipo' obtenida a partir del recurso tipado

8. 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.
9. 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:

     sujeto

     nuevo sujeto

     predicado

     IRI completa

     objeto

     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:

     sujeto

     recurso objeto actual

     predicado

     IRI completa

     objeto

     nuevo sujeto

10. 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ñadir:

          lista

          a partir de la lista local de equivalencias para esta IRI

          dirección

          ninguna

      • De lo contrario:
        

        • predicado

          IRI completa

          dirección

          avanzar

    • 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:

      predicado

      IRI completa

      direction

      retroceder

11. 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:

      sujeto

      nuevo sujeto

      predicado

      IRI completa

      objeto

      valor de la propiedad actual

12. 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

      sujeto padre

      predicado

      el predicado de la tripleta incompleta iterada

      objeto

      nuevo sujeto

    • If dirección es 'atrás' ('reverse') entonces se genera la siguiente tripleta:

      sujeto

      nuevo sujeto

      predicado

      el predicado de la  tripleta incompleta iterada

      objeto

      sujeto padre

13. 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.
14. 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

      sujeto actual

      predicado

      la IRI de la lista local de equivalencias asociada con esta lista

      objeto

      http://www.w3.org/1999/02/22-rdf-syntax-ns#nil

    • De lo contrario,
      • 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:

        sujeto

        nodo en blanco

        predicado

        http://www.w3.org/1999/02/22-rdf-syntax-ns#first

        objeto

        IRI completa o literal

      • Para cada elemento del array de nodos en blanco se general la siguiente tripleta:

        sujeto

        nodo en blanco

        predicado

        http://www.w3.org/1999/02/22-rdf-syntax-ns#rest

        objeto

        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:

        sujeto

        sujeto actual

        predicado

        la IRI completa de la  lista local de equivalencias asociada con esta lista

        objeto

        el primer elemento del array de nodos en blanco

7.6 Estado del procesador

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.

@prefix rdfa:    <http://www.w3.org/ns/rdfa#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix dc:      <http://purl.org/dc/terms/> .
[] a rdfa:DocumentError ;
   dc:description "The document could not be parsed due to parsing errors" ;
   dc:date "2010-06-30T13:40:23"^^xsd:dateTime .

@prefix rdfa:    <http://www.w3.org/ns/rdfa#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix dc:      <http://purl.org/dc/terms/> .
@prefix ptr:     <http://www.w3.org/2009/pointers#> .
@prefix ht:      <http://www.w3.org/2006/http#> .
 
[] a rdfa:DocumentError ;
   dc:description "The document could not be parsed due to parsing errors" ;
   dc:date "2010-06-30T13:40:23"^^xsd:dateTime ;
   rdfa:context <http://www.example.org/doc> ;
   rdfa:context [
      a ptr:Pointer ;
      # detailed xpointer/xpath information provided here to locate the error
   ] ;
   rdfa:context [
      a ht:Response ;
      ht:responseCode <http://www.w3.org/2006/http#404>
      # The HTTP response headers on the request for the source file.
   ].

7.7 Expansión de vocabularios

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.