4.1 RDFa Processor Conformance

This specification uses the term output graph to mean all of the triples asserted by a document according to the Processing Model section. A conforming RDFa Processor MUST make available to a consuming application a single RDF graph containing all possible triples generated by using the rules in the Processing Model section. The term processor graph is used to denote the collection of all informational, warning, and error triples that MAY be generated by the RDFa Processor to report its status. The output graph and the processor graph are separate graphs and MUST NOT be stored in the same graph by the RDFa Processor. However, processors may permit the two graphs to be retrieved together; see Section 7.6.1 for details.

A conforming RDFa Processor MAY make available additional triples that have been generated using rules not described here, but these triples MUST NOT be made available in the output graph. (Whether these additional triples are made available in one or more additional RDF graphs is implementation-specific, and therefore not defined here.)

A conforming RDFa Processor MUST preserve white space in both plain literals and XML literals. However, it may be the case that the architecture in which a processor operates has made changes to the white space in a document before that document ever reaches the RDFa Processor (e.g., [XMLSCHEMA11-1] processors are permitted to 'normalize' white space in attribute values - see section 3.1.4). To ensure maximum consistency between processing environments, authors SHOULD remove any unnecessary white space in their plain and XML Literal content.

A conforming RDFa Processor MUST examine the media type of a document it is processing to determine the document's Host Language. If the RDFa Processor is unable to determine the media type, or does not support the media type, the RDFa Processor MUST process the document as if it were media type application/xml. See XML+RDFa Document Conformance. A Host Language MAY specify additional announcement mechanisms.

4.2 RDFa Host Language Conformance

Host Languages that incorporate RDFa must adhere to the following:

• All of the facilities required in this specification MUST be included in the Host Language.
• The required attributes defined in this specification MUST be included in the content model of the Host Language.
  Note

  For the avoidance of doubt, there is no requirement that attributes such as @href and @src are used in a conforming Host Language. Nor is there any requirement that all required attributes are incorporated into the content model of all elements. The working group recommends that Host Language designers ensure that the required attributes are incorporated into the content model of elements that are commonly used throughout the content model of the Host Language.

• If the Host Language uses XML Namespaces [XML-NAMES], the attributes in this specification SHOULD be defined in 'no namespace' (e.g., when the attributes are used on elements in the Host Language's namespace, they can be used with no qualifying prefix: <myml:myElement property="license">). When a Host Language does not use the attributes in 'no namespace', they MUST be referenced via the XHTML Namespace (http://www.w3.org/1999/xhtml).
• If the Host Language has its own definition for any attribute defined in this specification, that definition MUST be such that the processing required by this specification remains possible when the attribute is used in a way consistent with the requirements herein.
• The Host Language MAY specify an initial context (e.g., IRI mappings and/or a definition of terms or a default vocabulary IRI). Such an initial context SHOULD be defined using the conventions defined in RDFa Initial Contexts.

4.3 XML+RDFa Document Conformance

This specification does not define a stand-alone document type. The attributes herein are intended to be integrated into other host languages (e.g., HTML+RDFa or XHTML+RDFa). However, this specification does define processing rules for generic XML documents - that is, those documents delivered as media types text/xml or application/xml. Such documents must meet all of the following criteria:

1. The document MUST be well-formed as defined in [XML10-4e].
2. The document SHOULD use the attributes defined in this specification in 'no namespace' (e.g., when the attributes are used on elements they are used with no qualifying prefix: <myml:myElement property="license">).
   Note

   It is possible that an XML grammar will have native attributes that conflict with attributes in this specification. This could result in an RDFa processor generating unexpected triples.

When an RDFa Processor processes an XML+RDFa document, it does so via the following initial context:

1. There are default terms (e.g., describedby, license, and role), defined in http://www.w3.org/2011/rdfa-context/rdfa-1.1.
2. There are default prefix mappings (e.g., dc), defined in http://www.w3.org/2011/rdfa-context/rdfa-1.1.
3. There is no default vocabulary IRI.
4. The base can be set using the @xml:base attribute as defined in [XML10-4e].
5. The current language can be set using @xml:lang attribute.

5.1 Roles of attributes

The RDFa attributes play different roles in a semantically rich document. Briefly, those roles are:

• Syntax attributes: @prefix, @vocab.
• Subject attributes: @about.
• Predicate attributes: @property, @rel, @rev.
• Resource attributes: @resource, @href, @src.
• Literal attributes: @datatype, @content, @xml:lang or @lang.
• Macro attributes: @typeof, @inlist.

5.2 White space within attribute values

Many attributes accept a white space separated list of tokens. This specification defines white space as:

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

When attributes accept a white space separated list of tokens, an RDFa Processor MUST ignore any leading or trailing white space.

7.1 Overview

Evaluating a document for RDFa triples is carried out by starting at the document object, and then visiting each of its child elements in turn, in document order, applying processing rules. Processing is recursive in that for each child element the processor also visits each of its child elements, and applies the same processing rules.

As processing continues, rules are applied which may generate triples, and may also change the evaluation context information that will then be used when processing descendant elements.

7.2 Evaluation Context

During processing, each rule is applied using information provided by an evaluation context. An initial context is created when processing begins. That context has the following members:

• The base. This will usually be the IRI of the document being processed, but it could be some other IRI, set by some other mechanism, such as the (X)HTML base element. The important thing is that it establishes an IRI against which relative paths can be resolved.
• The parent subject. The initial value will be the same as the initial value of base, but it will usually change during the course of processing.
• The parent object. In some situations the object of a statement becomes the subject of any nested statements, and this member is used to convey this value. Note that this value may be a bnode, since in some situations a number of nested statements are grouped together on one bnode. This means that the bnode must be set in the containing statement and passed down.
• A list of current, in-scope IRI mappings.
• A list of incomplete triples. A triple can be incomplete when no object resource is provided alongside a predicate that requires a resource (i.e., @rel or @rev). The triples can be completed when a resource becomes available, which will be when the next subject is specified (part of the process called chaining).
• A list mapping that associates IRIs with lists.
• The language. Note that there is no default language.
• The term mappings, a list of terms and their associated IRIs. This specification does not define an initial list. Host Languages MAY define an initial list.
• The default vocabulary, a value to use as the prefix IRI when a term unknown to the RDFa Processor is used. This specification does not define an initial setting for the default vocabulary. Host Languages MAY define an initial setting.

During the course of processing, new evaluation contexts are created which are passed to each child element. The initial rules described below will determine the values of the items in the context. Then the core rules will cause new triples to be created by combining information provided by an element with information from the evaluation context.

During the course of processing a number of locally scoped values are needed, as follows:

• An initially empty list of IRI mappings, called the local list of IRI mappings.
• An initially empty list of incomplete triples, called the local list of incomplete triples.
• An initially empty language value.
• A skip element flag, which indicates whether the current element can safely be ignored since it has no relevant RDFa attributes. Note that descendant elements will still be processed.
• A new subject value, which once calculated will set the parent subject in an evaluation context, as well as being used to complete any incomplete triples, as described in the next section.
• A value for the current property value, the literal to use when creating triples that have a literal object, or IRI-s in the absence of @rel or @rev.
• A value for the current object resource, the resource to use when creating triples that have a resource object.
• A value for the typed resource, the source for creating rdf:type relationships to types specified in @typeof.
• The local term mappings, a list of terms and their associated IRIs.
• The local list mapping, mapping IRIs to lists
• A local default vocabulary, an IRI to use as a prefix mapping when a term is used.

7.3 Chaining

Statement chaining is an RDFa feature that allows the author to link RDF statements together while avoiding unnecessary repetitive markup. For example, if an author were to add statements as children of an object that was a resource, these statements should be interpreted as being about that resource:

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

In this example we can see that an object resource ('German_Empire'), has become the subject for nested statements. This markup also illustrates the basic chaining pattern of 'A has a B has a C' (i.e., Einstein has a birth place of the German Empire, which has a long name of 'the German Empire').

It's also possible for the subject of nested statements to provide the object for containing statements — essentially the reverse of the example we have just seen. To illustrate, we'll take an example of the type of chaining just described, and show how it could be marked up more efficiently. To start, we mark up the fact that Albert Einstein had, at some point in his life, a residence both in the German Empire and in Switzerland:

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

Now, we show the same information, but this time we create an incomplete triple from the residence part, and then use any number of further subjects to 'complete' that triple, as follows:

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

In this example, the incomplete triple actually gets completed twice, once for the German Empire and once for Switzerland, giving exactly the same information as we had in the earlier example:

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

Chaining can sometimes involve elements containing relatively minimal markup, for example showing only one resource, or only one predicate. Here the img element is used to carry a picture of 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>

When such minimal markup is used, any of the resource-related attributes could act as a subject or an object in the chaining:

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

Note that, as noted above, in many situations the @property and @rel are interchangeable. This is not true for chaining. Taking the first example, if that example was used as follows:

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

The subject for 'the German Empire' would remain Albert Einstein (and that would, of course, be an error). This is the main difference between @property and @rel: the latter induces chaining, whereas the former, usually, does not.

7.4 CURIE and IRI Processing

Since RDFa is ultimately a means for transporting RDF, a key concept is the resource and its manifestation as an IRI. RDF deals with complete IRIs (not relative paths); when converting RDFa to triples, any relative IRIs MUST be resolved relative to the base IRI, using the algorithm defined in section 6.5 of RFC 3987 [RFC3987], Reference Resolution. The values of RDFa attributes that refer to IRIs use three different datatypes: IRI, SafeCURIEorCURIEorIRI, or TERMorCURIEorAbsIRI. All these attributes are mapped, after processing, to IRIs. The handling of these attributes is as follows:

IRI

The content is an IRI, and is used as such.

SafeCURIEorCURIEorIRI

• When the value is surrounded by square brackets, then the content within the brackets is evaluated as a CURIE according to the CURIE Syntax Definition. If it is not a valid CURIE, the value MUST be ignored.
• Otherwise, the value is evaluated as a CURIE. If it is a valid CURIE, the resulting IRI is used; otherwise, the value is processed as an IRI.

Note

A consequence of this is that when the value of an attribute of this datatype is the empty string (e.g., @about=""), that value resolves to an IRI. An IRI of "" is a relative IRI that is interpreted as being the same as the base. In other words, a value of "" will usually resolve to the IRI of the current document.

Note

A related consequence of this is that when the value of an attribute of this datatype is an empty SafeCURIE (e.g., @about="[]"), that value does not result in an IRI and therefore the value is ignored.

TERMorCURIEorAbsIRI

• If the value is a term then it is evaluated as a term according to General Use of Terms in Attributes. Note that this step may mean that the value is to be ignored.
• If the value is a valid CURIE, then the resulting IRI is used.
• If the value is an absolute IRI, that value is used.
• Otherwise, the value is ignored.

Note that it is possible for all values in an attribute to be ignored. When that happens, the attribute MUST be treated as if it were empty.

For example, the full IRI for Albert Einstein on DBPedia is:

http://dbpedia.org/resource/Albert_Einstein

This can be shortened by authors to make the information easier to manage, using a CURIE. The first step is for the author to create a prefix mapping that links a prefix to some leading segment of the IRI. In RDFa these mappings are expressed using @prefix:

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

Once the prefix has been established, an author can then use it to shorten an IRI as follows:

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

The author is free to split the IRI at any point. However, since a common use of CURIEs is to make available libraries of terms and values, the prefix will usually be mapped to some common segment that provides the most re-use, often provided by those who manage the library of terms. For example, since DBPedia contains an enormous list of resources, it is more efficient to create a prefix mapping that uses the base location of the resources:

<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:[email protected]" />
<link about="_:sue" rel="foaf:mbox"
  href="mailto:[email protected]" />
<link about="_:john" rel="foaf:knows"
  resource="_:sue" />

_:john foaf:mbox <mailto:[email protected]> .
_:sue foaf:mbox <mailto:[email protected]> .
_:john foaf:knows _:sue .

7.5 Sequence

Processing would normally begin after the document to be parsed has been completely loaded. However, there is no requirement for this to be the case, and it is certainly possible to use a stream-based approach, such as SAX [SAX] to extract the RDFa information. However, if some approach other than the DOM traversal technique defined here is used, it is important to ensure that Host Language-specific processing rules are applied (e.g., XHTML+RDFa [XHTML-RDFA] indicates the base element can be used, and base will affect the interpretation of IRIs in meta or link elements even if those elements are before the base element in the stream).

At the beginning of processing, an initial evaluation context is created, as follows:

• the base is set to the IRI of the document (or another value specified in a language specific manner such as the HTML base element);
• the parent subject is set to the base value;
• the parent object is set to null;
• the list of incomplete triples is empty;
• the list mapping is empty;
• the language is set to null.
• the list of IRI mappings is empty (or a list defined in the initial context of the Host Language).
• the term mappings is set to null (or a list defined in the initial context of the Host Language).
• the default vocabulary is set to null (or an IRI defined in the initial context of the Host Language).

Processing begins by applying the processing rules below to the document object, in the context of this initial evaluation context. All elements in the tree are also processed according to the rules described below, depth-first, although the evaluation context used for each set of rules will be based on previous rules that may have been applied.

The processing rules are:

1. First, the local values are initialized, as follows:
   • the skip element flag is set to 'false';
   • new subject is set to null;
   • current object resource is set to null;
   • typed resource is set to null;
   • the local list of IRI mappings is set to the list of IRI mappings from the evaluation context;
   • the local list of incomplete triples is set to null;
   • the list mapping is set to (a reference of) the list mapping from the evaluation context;
   • the current language value is set to the language value from the evaluation context.
   • the local term mappings is set to the term mappings from the evaluation context.
   • the local default vocabulary is set to the default vocabulary from the evaluation context.
   Note that some of the local variables are temporary containers for values that will be passed to descendant elements via an evaluation context. In some cases the containers will have the same name, so to make it clear which is being acted upon in the following steps, the local version of an item will generally be referred to as such.
   Note that the local term mappings is always reset to a global value, provided by the initial context. Future versions of this specification may introduce a mechanism whereby the local term mappings can be set dynamically, in which case the local term mappings would inherit from the parent's values.
2. Next the current element is examined for any change to the default vocabulary via @vocab. If @vocab is present and contains a value, the local default vocabulary is updated according to the section on CURIE and IRI Processing. If the value is empty, then the local default vocabulary MUST be reset to the Host Language defined default (if any).
   The value of @vocab is used to generate a triple as follows:

   subject

   base

   predicate

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

   object

   value from @vocab

   A Host Language is not required to define a default vocabulary. In such a case, setting @vocab to the empty value has the effect of setting the local default vocabulary to null.
3. Next, the current element is examined for IRI mappings and these are added to the local list of IRI mappings. Note that an IRI mapping will simply overwrite any current mapping in the list that has the same name;
   Mappings are defined via @prefix. Values in this attribute are evaluated from beginning to end (e.g., left to right in typical documents). For backward compatibility, RDFa Processors SHOULD also permit the definition of mappings via @xmlns. In this case, the value to be mapped is set by the XML namespace prefix, and the value to map is the value of the attribute — an IRI. (Note that prefix mapping via @xmlns is deprecated, and may be removed in a future version of this specification.) When xmlns is supported, such mappings MUST be processed before processing any mappings from @prefix on the same element. Regardless of how the mapping is declared, the value to be mapped MUST be converted to lower case, and the IRI is not processed in any way; in particular if it is a relative path it MUST NOT be resolved against the current base. Authors SHOULD NOT use relative paths as the IRI.
4. The current element is also parsed for any language information, and if present, current language is set accordingly;
   Host Languages that incorporate RDFa MAY provide a mechanism for specifying the natural language of an element and its contents (e.g., XML provides the general-purpose XML attribute @xml:lang).
5. If the current element contains no @rel or @rev attribute, then the next step is to establish a value for new subject. This step has two possible alternatives.
   1. If the current element contains the @property attribute, but does not contain either the @content or @datatype attributes, then
      new subject is set to the resource obtained from the first match from the following rule:

      • by using the resource from @about, if present, obtained according to the section on CURIE and IRI Processing;
      • otherwise, if the element is the root element of the document, then act as if there is an empty @about present, and process it according to the rule for @about, above;
      • otherwise, if parent object is present, new subject is set to the value of parent object.

      If @typeof is present then typed resource is set to the resource obtained from the first match from the following rules:

      • by using the resource from @about, if present, obtained according to the section on CURIE and IRI Processing;
      • otherwise, if the element is the root element of the document, then act as if there is an empty @about present and process it according to the previous rule;
      • otherwise,
        • by using the resource from @resource, if present, obtained according to the section on CURIE and IRI Processing;
        • otherwise, by using the IRI from @href, if present, obtained according to the section on CURIE and IRI Processing;
        • otherwise, by using the IRI from @src, if present, obtained according to the section on CURIE and IRI Processing;
        • otherwise, the value of typed resource is set to a newly created bnode.
        • The value of the current object resource is then set to the value of typed resource.
   2. otherwise:
      • If the element contains an @about, @href, @src, or @resource attribute, new subject is set to the resource obtained as follows:
        • by using the resource from @about, if present, obtained according to the section on CURIE and IRI Processing;
        • otherwise, by using the resource from @resource, if present, obtained according to the section on CURIE and IRI Processing;
        • otherwise, by using the IRI from @href, if present, obtained according to the section on CURIE and IRI Processing;
        • otherwise, by using the IRI from @src, if present, obtained according to the section on CURIE and IRI Processing.
      • otherwise, if no resource is provided by a resource attribute, then the first match from the following rules will apply:
        • if the element is the root element of the document, then act as if there is an empty @about present, and process it according to the rule for @about, above;
        • otherwise, if @typeof is present, then new subject is set to be a newly created bnode;
        • otherwise, if parent object is present, new subject is set to the value of parent object. Additionally, if @property is not present then the skip element flag is set to 'true'.

      • Finally, if @typeof is present, set the typed resource to the value of new subject.

6. If the current element does contain a @rel or @rev attribute, then the next step is to establish both a value for new subject and a value for current object resource:
   new subject is set to the resource obtained from the first match from the following rules:

   • by using the resource from @about, if present, obtained according to the section on CURIE and IRI Processing;

   if the @typeof attribute is present, set typed resource to new subject.

   If no resource is provided then the first match from the following rules will apply:

   • if the element is the root element of the document then act as if there is an empty @about present, and process it according to the rule for @about, above;
   • otherwise, if parent object is present, new subject is set to that.

   Then the current object resource is set to the resource obtained from the first match from the following rules:

   • by using the resource from @resource, if present, obtained according to the section on CURIE and IRI Processing;
   • otherwise, by using the IRI from @href, if present, obtained according to the section on CURIE and IRI Processing;
   • otherwise, by using the IRI from @src, if present, obtained according to the section on CURIE and IRI Processing;
   • otherwise, if @typeof is present and @about is not, use a newly created bnode.

   If @typeof is present and @about is not, set typed resource to current object resource.

   Note that final value of the current object resource will either be null (from initialization) or a full IRI or bnode.

7. If in any of the previous steps a typed resource was set to a non-null value, it is now used to provide a subject for type values;
   One or more 'types' for the typed resource can be set by using @typeof. If present, the attribute may contain one or more IRIs, obtained according to the section on CURIE and IRI Processing, each of which is used to generate a triple as follows:

   subject

   typed resource

   predicate

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

   object

   current full IRI of 'type' from typed resource

8. If in any of the previous steps a new subject was set to a non-null value different from the parent object;
   The list mapping taken from the evaluation context is set to a new, empty mapping.
9. If in any of the previous steps a current object resource was set to a non-null value, it is now used to generate triples and add entries to the local list mapping:
   If the element contains both the @inlist and the @rel attributes the @rel may contain one or more resources, obtained according to the section on CURIE and IRI Processing each of which is used to add an entry to the list mapping as follows:

   • if the local list mapping does not contain a list associated with the IRI, instantiate a new list and add to local list mappings
   • add the current object resource to the list associated with the resource in the local list mapping
   Predicates for the current object resource can be set by using one or both of the @rel and the @rev attributes but, in case of the @rel attribute, only if the @inlist is not present:

   • If present, @rel may contain one or more resources, obtained according to the section on CURIE and IRI Processing each of which is used to generate a triple as follows:

     subject

     new subject

     predicate

     full IRI

     object

     current object resource

   • If present, @rev may contain one or more resources, obtained according to the section on CURIE and IRI Processing each of which is used to generate a triple as follows:

     subject

     current object resource

     predicate

     full IRI

     object

     new subject

10. If however current object resource was set to null, but there are predicates present, then they must be stored as incomplete triples, pending the discovery of a subject that can be used as the object. Also, current object resource should be set to a newly created bnode (so that the incomplete triples have a subject to connect to if they are ultimately turned into triples);
    Predicates for incomplete triples can be set by using one or both of the @rel and @rev attributes:

    • If present, @rel must contain one or more resources, obtained according to the section on CURIE and IRI Processing each of which is added to the local list of incomplete triples as follows:
      • If the element contains the @inlist attribute, then
        • if the local list mapping does not contain a list associated with the IRI, instantiate a new list and add to local list mappings.
        • Add:

          list

          list from local list mapping for this IRI

          direction

          none

      • Otherwise add:

        • predicate

          full IRI

          direction

          forward

    • If present, @rev must contain one or more resources, obtained according to the section on CURIE and IRI Processing, each of which is added to the local list of incomplete triples as follows:

      predicate

      full IRI

      direction

      reverse

11. The next step of the iteration is to establish any current property value;
    Predicates for the current property value can be set by using @property. If present, one or more resources are obtained according to the section on CURIE and IRI Processing, and then the actual literal value is obtained as follows:

    • as a typed literal if @datatype is present, does not have an empty value according to the section on CURIE and IRI Processing, and is not set to XMLLiteral in the vocabulary http://www.w3.org/1999/02/22-rdf-syntax-ns#.

      The actual literal is either the value of @content (if present) or a string created by concatenating the value of all descendant text nodes, of the current element in turn. The final string includes the datatype IRI, as described in [RDF-SYNTAX-GRAMMAR], which will have been obtained according to the section on CURIE and IRI Processing.

    • otherwise, as a plain literal if @datatype is present but has an empty value according to the section on CURIE and IRI Processing.

      The actual literal is either the value of @content (if present) or a string created by concatenating the value of all descendant text nodes, of the current element in turn.

    • otherwise, as an XML literal if @datatype is present and is set to XMLLiteral in the vocabulary http://www.w3.org/1999/02/22-rdf-syntax-ns#.

      The value of the XML literal is a string created by serializing to text, all nodes that are descendants of the current element, i.e., not including the element itself, and giving it a datatype of XMLLiteral in the vocabulary http://www.w3.org/1999/02/22-rdf-syntax-ns#. The format of the resulting serialized content is as defined in Exclusive XML Canonicalization Version 1.0 [XML-EXC-C14N].

      Note

      In order to maintain maximum portability of this literal, any children of the current node that are elements MUST have the current XML namespace declarations (if any) declared on the serialized element. Since the child element node could also declare new XML namespaces, the RDFa Processor MUST be careful to merge these together when generating the serialized element definition. For avoidance of doubt, any re-declarations on the child node MUST take precedence over declarations that were active on the current node.

    • otherwise, as a plain literal using the value of @content if @content is present.
    • otherwise, if the @rel, @rev, and @content attributes are not present, as a resource obtained from one of the following:
      • by using the resource from @resource, if present, obtained according to the section on CURIE and IRI Processing;
      • otherwise, by using the IRI from @href, if present, obtained according to the section on CURIE and IRI Processing;
      • otherwise, by using the IRI from @src, if present, obtained according to the section on CURIE and IRI Processing.
    • otherwise, if @typeof is present and @about is not, the value of typed resource.
    • otherwise as a plain literal.

    Additionally, if there is a value for current language then the value of the plain literal should include this language information, as described in [RDF-SYNTAX-GRAMMAR]. The actual literal is either the value of @content (if present) or a string created by concatenating the text content of each of the descendant elements of the current element in document order.

    The current property value is then used with each predicate as follows:

    • If the element also includes the @inlist attribute, the current property value is added to the local list mapping as follows:
      • if the local list mapping does not contain a list associated with the predicate IRI, instantiate a new list and add to local list mappings
      • add the current property value to the list associated with the predicate IRI in the local list mapping
    • Otherwise the current property value is used to generate a triple as follows:

      subject

      new subject

      predicate

      full IRI

      object

      current property value

12. If the skip element flag is 'false', and new subject was set to a non-null value, then any incomplete triples within the current context should be completed:
    The list of incomplete triples from the current evaluation context (not the local list of incomplete triples) will contain zero or more predicate IRIs. This list is iterated over and each of the predicates is used with parent subject and new subject to generate a triple or add a new element to the local list mapping. Note that at each level there are two lists of incomplete triples; one for the current processing level (which is passed to each child element in the previous step), and one that was received as part of the evaluation context. It is the latter that is used in processing during this step.
    Note that each incomplete triple has a direction value that is used to determine what will become the subject, and what will become the object, of each generated triple:

    • If direction is 'none', the new subject is added to the list from the iterated incomplete triple.
    • If direction is 'forward' then the following triple is generated:

      subject

      parent subject

      predicate

      the predicate from the iterated incomplete triple

      object

      new subject

    • If direction is 'reverse' then this is the triple generated:

      subject

      new subject

      predicate

      the predicate from the iterated incomplete triple

      object

      parent subject

13. Next, all elements that are children of the current element are processed using the rules described here, using a new evaluation context, initialized as follows:
    • If the skip element flag is 'true' then the new evaluation context is a copy of the current context that was passed in to this level of processing, with the language and list of IRI mappings values replaced with the local values;
    • Otherwise, the values are:
      • the base is set to the base value of the current evaluation context;
      • the parent subject is set to the value of new subject, if non-null, or the value of the parent subject of the current evaluation context;
      • the parent object is set to value of current object resource, if non-null, or the value of new subject, if non-null, or the value of the parent subject of the current evaluation context;
      • the list of IRI mappings is set to the local list of IRI mappings;
      • the list of incomplete triples is set to the local list of incomplete triples;
      • the list mapping is set to the local list mapping;
      • language is set to the value of current language.
      • the default vocabulary is set to the value of the local default vocabulary.
14. Finally, if there is one or more mapping in the local list mapping, list triples are generated as follows:
    For each IRI in the local list mapping, if the equivalent list does not exist in the evaluation context, indicating that the list was originally instantiated on the current element, use the list as follows:

    • If there are zero items in the list associated with the IRI, generate the following triple:

      subject

      current subject

      predicate

      full IRI of the local list mapping associated with this list

      object

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

    • Otherwise,
      • Create a new ‘bnode’ array containing newly created bnodes, one for each item in the list
      • For each bnode-(IRI or literal) pair from the list the following triple is generated:

        subject

        bnode

        predicate

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

        object

        full IRI or literal

      • For each item in the ‘bnode’ array the following triple is generated:

        subject

        bnode

        predicate

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

        object

        next item in the ‘bnode’ array or, if that does not exist, http://www.w3.org/1999/02/22-rdf-syntax-ns#nil

      • A single additional triple is generated:

        subject

        current subject

        predicate

        full IRI of the local list mapping associated with this list

        object

        first item of the ‘bnode’ array

7.6 Processor Status

The processing rules covered in the previous section are designed to extract as many triples as possible from a document. The RDFa Processor is designed to continue processing, even in the event of errors. For example, failing to resolve a prefix mapping or term would result in the RDFa Processor skipping the generation of a triple and continuing with document processing. There are cases where knowing each RDFa Processor warning or error would be beneficial to authors. The processor graph is designed as the mechanism to capture all informational, warning, and error messages as triples from the RDFa Processor. These status triples may be retrieved and used to aid RDFa authoring or automated error detection.

If an RDFa Processor supports the generation of a processor graph, then it MUST generate a set of triples when the following processing issues occur:

• An rdfa:Error MUST be generated when the document fails to be fully processed as a result of non-conformant Host Language markup.
• A rdfa:Warning MUST be generated when a CURIE prefix fails to be resolved.
• A rdfa:Warning MUST be generated when a Term fails to be resolved.

Other implementation-specific rdfa:Info, rdfa:Warning, or rdfa:Error triples MAY be generated by the RDFa Processor.

@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 Vocabulary Expansion

Processors MAY perform vocabulary expansion by utilizing limited RDFS and OWL entailment rules, as described in RDFa Vocabulary Expansion.