RDF/XML Syntax Specification (Revised)

W3C Working Draft 25 March 2002

This version:

http://www.w3.org/TR/2002/WD-rdf-syntax-grammar-20020325

Latest version:

http://www.w3.org/TR/rdf-syntax-grammar

Previous version:

http://www.w3.org/TR/2001/WD-rdf-syntax-grammar-20011218

Editor:

Dave Beckett (University of Bristol)

Copyright ©2002 W3C^® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

Abstract

This specification defines an XML syntax for the Resource Description Framework (RDF) as amended and clarified by the RDF Core Working Group from that originally described in RDF Model & Syntax. The syntax is updated to be specified in terms of the XML Information Set with new support for XML Base. For each part of the syntax, it defines the mapping rules for generating the RDF graph as defined in the RDF Model Theory. This is done using the N-Triples graph serializing test format which enables more precise recording of the mapping in a machine processable and testable form. These tests are gathered and published in the RDF Test Cases.

Status of this Document

This is a W3C RDF Core Working Group Working Draft produced as part of the W3C Semantic Web Activity (Activity Statement). It incorporates decisions made by the Working Group updating the XML syntax for RDF from the original RDF Model & Syntax [RDF-MS] document in terms of the XML Information Set [INFOSET] including new support in this draft for XML Base [XML-BASE].

This document is being released for review by W3C Members and other interested parties to encourage feedback and comments, especially with regard to how the changes affect existing implementations and content. The current state is that it represents the majority of the syntax as described in the grammar section of the original document, with some removed parts (see rdfms-abouteach) and the mapping to the RDF graph is considered complete. The detailed changes from the previous 18 December 2001 draft are described in the Changes section however the main changes are as follows: the completion of the rules for generating the graph for rdf:bagID, handling xml:lang with literals, handling XML Literals (not yet complete), the addition of XML Base support, an updated introduction with new examples and other changes after RDF Core Working Group decisions made since the last draft.

This is a public W3C Working Draft and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

Comments on this document are invited and should be sent to the public mailing list www-rdf-comments@w3.org. An archive of comments is available at http://lists.w3.org/Archives/Public/www-rdf-comments/.

1 Introduction

This document describes the XML [XML] syntax for RDF as originally defined in the RDF Model & Syntax [RDF-MS] W3C Recommendation. Subsequent implementations of this syntax and comparison of the resulting RDF graphs have shown that there was ambiguity - implementations generated different graphs and certain syntax forms were not widely implemented. These issues were generally made as either feedback to the www-rdf-comments@w3.org (archive) or from discussions on the RDF Interest Group list www-rdf-interest@w3.org (archive) .

The RDF Core Working Group is chartered to respond to the need for a number of fixes, clarifications and improvements to the specification of RDF's abstract graph and XML syntax. The Working Group invites feedback from the developer community on the effects of its proposals on existing implementations and documents.

Several decisions including amendments and deletions to the grammar are referred to below. The definitive record of the decisions is the RDF Core Working Group issues list.

This document re-represents the original EBNF grammar in terms of the XML Information Set [INFOSET] items which moves from the rather low-level details, such as particular forms of empty elements. This allows the grammar to be more precisely recorded and the mapping from the XML syntax to the RDF graph more clearly shown. The mapping to the RDF graph is done by emitting statements in the form defined in the N-Triples section of RDF Test Cases [RDF-TESTS] Working Draft which creates an RDF graph, that has semantics defined by RDF Model Theory [RDF-MODEL] Working Draft.

This document illustrates one way to create the N-Triples from the XML - any other method that results in the same N-Triples (RDF graph) may be used.

In particular:

• The N-Triples may be generated in any order
• Duplicates may be eliminated at any point
• There is no requirement to support N-Triples in any way

2 An XML syntax for RDF

The RDF Model Theory [RDF-MODEL] provides a formal description of RDF. This can be thought of as a graph consisting of nodes and arcs. The nodes can be labeled with URIs, literals or are blank and denote resources. The arcs connect the nodes and are all labeled with URIs. This graph is more precisely called a directed edge-labeled graph; each edge is an arc with a direction (an arrow) connecting two nodes. These edges can be described as triples of subject node, at the blunt end of the arrow/arc, property arc and an object node at the sharp end of the arrow/arc. The property arc can also be also interpreted as either a relationship between two resources or as defining an attribute value (object node) for some resource subject node. .

In order to encode the graph in XML, the nodes and arcs are turned into XML elements, attributes, element content and attribute values. The URI labels for properties and object nodes are written in XML via XML Namespaces [XML-NS] which gives a namespace URI for a short prefix along with namespace-qualified elements and attributes names called local names. The (namespace URI, local name) pair are chosen such that concatenating them forms the original node URI. The URIs labeling subject and object nodes are stored in XML attribute values. The nodes labeled by string literals (which are always object nodes) become element text content or attribute values.

This transformation turns paths in the graph of the form Node, Arc, Node, Arc, Node, Arc, ... into sequences of elements inside elements. This results in a striping when the elements are written down; alternating between node elements and property elements. The Node at the start of the sequence is always a subject node and turns into a containing element called an rdf:Description that is written at the top level of RDF/XML, below the XML document element (in this case rdf:RDF). So the chains of stripes start at the top of an RDF/XML document and always begin with nodes.

For example, Figure 1 below a graph written as ASCII saying: there exists a document (this one) with a title, "RDF/XML Syntax Specification (Revised)" and this document has an editor, the editor has a name "Dave Beckett" and a home page http://purl.org/net/dajobe/.

Figure 1: Graph for RDF/XML Example (SVG version)

Where the nodes are represented as ovals and contain their URI if it is known, the properties such as "has an editor" have been given URIs and these have been used to label the appropriate arc, and the strings have been written in rectangles.

If we take the path through the graph shown in Figure 2:

Figure 2: One Path Through the Graph (SVG version)

This corresponds to the node/arc stripes:

1. Node [http://www.w3.org/TR/rdf-syntax-grammar]
2. Arc -[http://example.org/stuff/1.0/editor]->
3. Node []
4. Arc -[http://example.org/stuff/1.0/homePage]->
5. Node [http://purl.org/net/dajobe/]

In RDF/XML this sequence of 5 nodes and arcs corresponds to 5 XML elements shown in Example 1:

Which consists of some nodes with known URIs that can be filled in and others that remain blank, as shown in Example 2:

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <ex:editor>
    <rdf:Description>
      <ex:homePage>
        <rdf:Description rdf:about="http://purl.org/net/dajobe/">
        </rdf:Description>
      </ex:homePage>
    </rdf:Description>
  </ex:editor>
</rdf:Description>

There are several abbreviations that can be used to make very common uses more easy to write down. It is typical for the same resource to be described with multiple properties and values at the same time, so multiple child elements can be put inside rdf:Description, all of which are properties of that node as shown in Example 3 (here adding dc:format not shown in the graphs above):

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <dc:title>RDF/XML Syntax Specification (Revised)<dc:title>
  <dc:format>text/html<dc:format>
    ...
</rdf:Description>

When the property value is a string it can be encoded more simply as an XML attribute and value, as an attribute of the node element. This is known as a property attribute and shown in Example 4:

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
                 dc:title="RDF/XML Syntax Specification (Revised)"
                 dc:format="text/html">
  ...
</rdf:Description>

Another very common use is when a node is an instance of a class with rdf:type relationship, usually called a typed node. This shorthand is done by removing the rdf:type property and value and replacing the rdf:Description element name with the namespaced-element corresponding to the URI of the value of the type relationship as shown in Example 5 (using a different graph to those above):

<rdf:Description rdf:about="http://example.org/thing">
  <rdf:type rdf:resource="http://example.org/stuff/1.0/document"/ >
  ...
</rdf:Description>

<ex:document rdf:about="http://example.org/thing">
  ...
</ex:document>

The above forms the basis of the RDF/XML syntax and although there are some other abbreviated forms not covered here at this time includes generating the RDF list properties and for skipping having to write down a blank element node. The latter breaks the striping but is useful for, amongst other uses, encoding properties with multiple-values.

The original example above filled out and completed, using some abbreviations gives Example 6:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
    <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
    <ex:editor rdf:parseType="Resource">
      <ex:fullName>Dave Beckett</ex:fullName>
      <ex:homePage rdf:resource="http://purl.org/net/dajobe/" />
    </ex:editor>
  </rdf:Description>
</rdf:RDF>

For a longer introduction to the RDF/XML striped syntax with a historical perspective, see RDF: Understanding the Striped RDF/XML Syntax [STRIPEDRDF].

3 Data Model

This syntax operates on an XML document as a sequence of nodes in document order in the style of [XPATH]  Information Set Mapping serialized into a sequence called document order which is defined in Section 3.2 Information Set Mapping. The resulting nodes are intended to be similar to the events that are produced by the [SAX2] XML API. This model is conceptual only and does not mandate any implementation method; in particular the use of [XPATH] or [SAX2] is not required.

The syntax does not support non-well-formed XML documents, nor documents that otherwise don't have an XML Information Set; for example, that don't conform to XML Namespaces [XML-NS].

The Infoset requires supports for XML Base [XML-BASE] which generates information item properties [base URI] below. The use this property in RDF/XML is discussed in section 3.10

This specification requires an information set as defined in [INFOSET] which supports at least the following information items and properties for RDF/XML:

Document Information Item

[document element], [children], [base URI]

Element Information Item

[local name], [namespace name], [children], [attributes], [parent], [base URI]

Attribute Information Item

[local name], [namespace name], [normalized value], [owner element]

Character Information Item

[character code]

Processing Instruction Information Item

Not used

Unexpanded Entity Reference Information Item

Not used

Comment Information Item

Not used

Document Type Declaration Information Item

Not used

Unparsed Entity Information Item

Not used

Notation Information Item

Not used

Namespace Information Item

Not used

3.1 Nodes

There are six types of node defined in the following subsections. Most nodes are constructed from an Infoset information item (except for Identifier). The effect of a node constructor is to create a new node with a unique identity, distinct from all other nodes. Nodes have properties, and all have the string-value property that may be part of the node or computed from the string-value of contained nodes.

3.1.1 Root Node

Created from an Document Information Item and takes the following properties and their values from the element information item: document-element, children and base-uri. The property language is set to the empty string.

3.1.2 Element Node

Created from an Element Information Item and takes the following properties and their values from the element information item: local-name, namespace-name, children, attributes, parent and base-uri. When this node is created from such values, the URI property is defined with a string value of the concatenation of the value of the namespace-name property and the value of the local-name property. On creation the li-counter and bag-li-counter properties are added with initial integer values 1.

On creation, if the ·attributes· property contains an attribute node xml:lang (that is, the local-name property of the attribute has value "lang" and the namespace-name property of the attribute has value "http://www.w3.org/XML/1998/namespace") then that attribute is removed from the list of attributes and the property ·language· on the element node is set to the string-value of the attribute. If no such attribute is present, the language property on the element node is set to the value of the language property on the parent node. All other attributes beginning with xml are removed (that is, with namespace-name properties values beginning with "http://www.w3.org/XML/1998/namespace"). Note: this does not include xml:base which is already present in the Infoset as the base-uri property.

The subject property may be added and takes the value of an Identifier node. This is used on elements that deal with one node in the RDF graph, this generally being the subject of a statement.

3.1.3 End Element Node

Takes no properties but marks the end of the containing element in the sequence.

3.1.4 Attribute Node

Created from an Attribute Information Item and takes the properties local-name, namespace-name and owner element and their values from respective element information item properties. When this node is created from such values, two properties and values are defined. Firstly the string-value property is defined with the normalized value as specified by [XML]. An attribute whose normalized value is a zero-length string is not treated specially: it results in an attribute node whose string-value is a zero-length string. Secondly the ·URI· property is defined with a string value of the concatenation of the value of the namespace-name property and the value of the local-name property.

3.1.5 Text Node

Created from a sequence of one or more consecutive Character Information Items. Has the single property ·string-value· which has the value of the string made from concatenating the character code property of each of the character information items. [NOTE: Identical to XPath.]

3.1.6 Identifier Node

A node for a typed identifier which can have the following three properties: ·identifier·, ·identifier-type· and ·string-value·. These nodes are created by giving two values for the ·identifier· and ·identifier-type· properties. The identifier property takes a string value and the identifier-type property can take values "URI" or "bnodeID".

The ·string-value· property is defined from the other properties as follows: If ·identifier-type· is "URI" then the value is the concatenation of "<", the value of the ·identifier· property and ">". If ·identifier-type· is "bnodeID" then the value is the concatenation of "_:" and the value of the ·identifier· property.

For further information on identifiers in the RDF graph, see section 3.5.

3.1.7 Literal Node

A node for a literal which can have the following three properties: literal-value, literal-language and ·string-value·. These nodes are created by giving two values for the ·literal-value· and ·literal-language· properties which both take string values.

The ·string-value· property is defined from the other properties as follows: If ·literal-language· is empty then the value is the concatenation of """ (1 double quote), the value of the ·literal-value· property and """ (1 double quote). Otherwise the value is the concatenation of """ (1 double quote), the value of the ·literal-value· property ""-" (1 double quote and a '-'), and the value of the ·literal-language· property. Note that the double-quoted literal-value string must use the N-Triples string escapes for escaping certain characters such as ".

3.1.8 XML Literal Node

A node for an XML literal which can have the following three properties: ·literal-value·, ·literal-language· and ·string-value·. These nodes are created by giving two values for the ·literal-value· and ·literal-language· properties which both take string values.

The ·string-value· property is defined from the other properties as follows: If ·literal-language· is empty then the value is the concatenation of "xml"" ('x', 'm', 'l', and 1 double quote), the value of the ·literal-value· property and """ (1 double quote). Otherwise the value is the concatenation of "xml"" ('x', 'm', 'l', and 1 double quote), the value of the ·literal-value· property ""-" (1 double quote and a '-'), and the value of the ·literal-language· property. Note that the double-quoted literal-value string must use the N-Triples string escapes for escaping certain characters such as ".

3.2 Information Set Mapping

To transform the Infoset into the sequence of nodes in document order, each information item is transformed as described above to generate a tree of nodes with properties and values. Each element node is then replaced as described below to turn the tree of nodes into a sequence in document order.

1. The original element node
2. The value of the children property, a possibly empty ordered list of nodes.
3. An end element node

3.3 RDF MIME type, file extension and Macintosh file type

The Internet Media Type / MIME type for RDF is "application/rdf+xml" - see RFC 3032 (RFC-3023) section 8.18. The W3C will register this type when this working draft is more stable.

It is recommended that RDF files have the extension ".rdf" (all lowercase) on all platforms.

It is recommended that RDF files stored on Macintosh HFS file systems be given a file type of "rdf " (all lowercase, with a space character as the fourth letter).

3.4 The RDF Namespace

The RDF Namespace URI is http://www.w3.org/1999/02/22-rdf-syntax-ns# and is typically used in XML with the prefix rdf although other prefix strings may be used. The namespace contains the following names only:

RDF Description
ID about bagID parseType resource
li

The above terms are only used in the syntax and are not concepts in the graph.

Seq Bag Alt Statement Property
subject predicate object
type value
_n

where n is a non-negative integer. These are either RDF Classes (first 5) or Properties (remainder) in the graph.

Any other names are not defined and SHOULD generate a warning when encountered in an application, but should otherwise behave normally, and treated as properties and/or classes as appropriate for their use.

Throughout this document the terminology rdf:name will be used to indicate name is from the RDF namespace and it has a URI of the concatenation of the RDF Namespace URI and name. For example, rdf:type has the URI http://www.w3.org/1999/02/22-rdf-syntax-ns#type

3.5 Identifiers

The RDF graph uses three types of identifiers (or labels) for nodes and arcs:

URI references (labeling nodes and arcs)

The URI references can be either given as absolute URIs, relative URIs that have to be resolved to the in-scope base URI as described in section section 3.6, constructed from XML Namespace-qualified element and attributes names (QNames) or from rdf:ID and rdf:bagID attribute values.

XML QNames give URIs by concatenating the namespace URI and the XML local name. For example, if the XML Namespace prefix foo has URI http://example.org/somewhere/ then the QName foo:bar would correspond to the URI http://example.org/somewhere/bar. Note that this restricts which URIs can be made and the same URI can be given in multiple ways.

The rdf:ID and rdf:bagID values generate URIs by considering them as equivalent to the relative URI "#" concatenated with the attribute value. This can then be resolved relative to the in-scope base URI as described in section section 3.6.

Literals (labeling object arcs)

These are Unicode strings or XML content.

Warning: The RDF Core Working Group has generally decided the outline of RDF literals but all the cases have not been entirely resolved at this time. See in particular the following issues: rdf-charmod-literals, rdfms-xml-literal-namespaces

Blank node Identifiers (labeling nodes)

These are given local identifiers in the N-Triples serialization which must match the name production in N-Triples.

Note: In the past, some RDF applications have handled these nodes (then called anonymous nodes) by generating arbitrary URIs. This MUST NOT be done - applications MUST be able to distinguish URI references from blank nodes.

3.6 Base URIs

RDF/XML supports XML Base [XML-BASE] by being based on the XML Information Set [INFOSET]. This defines a ·base-uri· property for each ·root node· and ·element node·.

RDF/XML uses URI-references throughout and applies the in-scope Base URI to resolve both URI document references of the form "#frag" and self document references of the form "".

An empty same document reference "" resolves against the URI part of the Base URI; any fragment part is ignored. See Uniform Resource Identifiers (URI) [URIS] section 4.2

4 Notation

4.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].

4.2 Grammar Notation

The following notation is used for describing the nodes and grammar EBNF. The RDF/XML grammar is defined here in terms of its information set nodes, using statements of the form:

number node-type node-content

action...

N-Triples

where the node-content is an expression, which may refer to other node-types (as defined in Section 3.1), using constructs of the form given in the following table. The number is used for reference purposes. The action may include generating N-Triples into the model.

5 RDF/XML Grammar

5.0 Grammar summary

5.1 Grammar start

If the RDF/XML is a standalone XML content, then the grammar starts with Root Node  doc.

If the content is known to be RDF/XML by context, such as when RDF/XML is embedded inside other XML content, then the grammar can either start at Element Node  RDF (only when an element is legal at that point in the XML) or at production nodeElementList (only when element content is legal, since this is a list of elements). For such embedded RDF/XML, the ·base-uri· value on the outermost element must be initialized from the containing XML since no Root Node  will be available. Note that if such embedding occurs, the grammar may be entered several times but no state is expected to be preserved.

5.2 Production doc

5.3 Production RDF

5.4 Production nodeElementList

5.5 Production nodeElement

For element e, the processing of some of the attributes have to be done before other work such as dealing with children nodes or other attributes. These can be processed in any order:

• If there is an attribute a with a.URI = rdf:ID, then e.subject := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI").
• If there is an attribute a with a.URI = rdf:about then e.subject := identifier(identifier=a.string-value, identifier-type="URI").
• If e.subject is empty, generate a local blank node identifier i and n := identifier(identifier=i, identifier-type="bnodeID"). e.subject := n.

The following can then be performed in any order:

• S1 If e.URI != rdf:Description then the following statement is added to the model:

  e.subject.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <e.URI> .

• S2 If there is an attribute a in propertyAttr with a.URI = rdf:type then the following statement is added to the model:

  e.subject.string-value <a.URI> <a.string-value> .

• S3 For each attribute a matching propertyAttr (and not rdf:type) then o := literal(literal-value=a.string-value, literal-language=e.language) and the following statement is added to the model:

  e.subject.string-value <a.URI> o.string-value .

• S4 Handle the propertyEltList children nodes in document order.

If an attribute a with a.URI = rdf:bagID is present, n := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI") then in any order:

• S5 Add the following statement to the model:

  n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag> .

• For the generated statements above (excluding S5) in the following order

  1. S1
  2. Statements from S2 and S3 in any order
  3. Statements generated by the propertyEltList children by S4 in document order

  If the statement was generated by S4 from a propertyElt and has an existing identifier e.subject then s := e.subject. Otherwise generate a local blank node identifier i and s := identifier(identifier=i, identifier-type="bnodeID")

  Then reify the statement with node s using the reification rules in section 5.26 and apply the bag expansion rules in section 5.28 on node n to give a URI u. Then the following statement is added to the model:

  n.string-value <u.string-value> s.string-value .

5.6 Production ws

5.7 Production propertyEltList

5.8 Production propertyElt

If element e has e.URI = rdf:li then apply the list expansion rules on element e.parent in section 5.27 to give a new URI u and e.URI := u.

5.9 Production resourcePropertyElt

For element e, and the single contained nodeElement n the following statement is added to the model:

If the rdf:ID attribute a is given, the above statement is reified with i := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI") using the reification rules in section 5.26 and e.subject := i

5.10 Production literalPropertyElt

For element e, and the text node t then o := literal(literal-value=t.string-value, literal-language=e.language) and the following statement is added to the model:

If the rdf:ID attribute a is given, the above statement is reified with i := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI") using the reification rules in section 5.26 and e.subject := i.

5.11 Production parseTypeLiteralPropertyElt

For element e and the literal l, then o := xml(literal-value=l.string-value, literal-language=e.language) and the following statement is added to the model:

If the rdf:ID attribute a is given, the above statement is reified with i := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI") using the reification rules in section 5.26 and e.subject := i.

5.12 Production parseTypeResourcePropertyElt

For element e with possibly empty element content c.

Generate a local blank node identifier i and n := identifier(identifier=i, identifier-type="bnodeID").

Add the following statement to the model:

If the rdf:ID attribute a is given, the statement above is reified with i := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI") using the reification rules in section 5.26 and e.subject := i.

If the element content c is not an empty, then use node n to create a new sequence of nodes as follows:

Then process the resulting sequence using production nodeElement.

5.13 Production parseTypeOtherPropertyElt

All rdf:parseType attribute values other than the strings "Resource" or "Literal" are treated as if the value was "Literal". Processing MUST continue at production parseTypeLiteralPropertyElt. No extra triples are generated for other rdf:parseType values.

5.14 Production emptyPropertyElt

• If there are no attributes or only the optional rdf:ID attribute i then o := literal(literal-value="", literal-language=e.language) and the following statement is added to the model:

  e.parent.subject.string-value <e.URI> o.string-value .

  and then if i is given, the above statement is reified with identifier(identifier=concat(e.base-uri, "#", i.string-value), identifier-type="URI") using the reification rules in section 5.26.

  Test: Indicated by test002.rdf and test002.nt

  Test: Indicated by test005.rdf and test005.nt

• Otherwise

  • If rdf:resource attribute i is present, then r := identifier(identifier=i.string-value, identifier-type="URI")
  • Otherwise, generate a local blank node identifier i and r := identifier(identifier=i, identifier-type="bnodeID")

  If optional rdf:bagID attribute b is given, n := identifier(identifier=concat(e.base-uri, "#", b.string-value), identifier-type="URI")

  The following can then be done in any order:

  • Add the following statement to the model:

    e.parent.subject.string-value <e.URI> r.string-value .

    and then if rdf:ID attribute i is given, the above statement is reified with identifier(identifier=concat(e.base-uri, "#", i.string-value), identifier-type="URI") using the reification rules in section 5.26.

  • For all propertyAttr a (in any order)

    • If a.URI = rdf:type then the following statement is added to the model:

      r.string-value <a.URI> <a.string-value> .

    • Otherwise o := literal(literal-value= a.string-value, literal-language= e.language) and the following statement is added to the model:

      r.string-value <a.URI> o.string-value .

    If node n is given then generate a local blank node identifier i and s := identifier(identifier=i, identifier-type="bnodeID"). Each statement above is then reified with node s using the reification rules in section 5.26 and the bag expansion rules in section 5.28 is applied on node n to give URI u. Then the following statement is added to the model:

    n.string-value <u.string-value> s.string-value; .

    Test: Indicated by test013.rdf and test013.nt

    Test: Indicated by test014.rdf and test014.nt

  • If node n was created, add the following statement to the model:

    n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag> .

5.15 Production idAttr

5.16 Production aboutAttr

5.17 Production bagIdAttr

5.18 Production propertyAttr

5.19 Production resourceAttr

5.20 Production parseLiteral

5.21 Production parseResource

5.22 Production parseOther

5.23 Production URI-reference

5.24 Production literal

5.25 Production rdf-id

5.26 Reification Rules

For a statement with terms s, p and o corresponding to the N-Triples:

add the following statements to the model using the given Identifier Node r:

5.27 List Expansion Rules

For the given element e, generate a new URI u := concat("http://www.w3.org/1999/02/22-rdf-syntax-ns#_", e.li-counter), increment the e.li-counter property by 1 and return u.

5.28 Bag Expansion Rules

For the given element e, generate a new URI u := concat("http://www.w3.org/1999/02/22-rdf-syntax-ns#_", e.bag-li-counter), increment the e.bag-li-counter property by 1 and return u.

6 Serializing an RDF Graph to RDF/XML

It is not possible for all graphs that can be expressed in the RDF Model Theory [RDF-MODEL] to be encoded in this syntax. If you do a round trip from RDF/XML to RDF graph and then back to RDF/XML the meaning will be the same (the graphs) but the RDF/XML that comes out may not be exactly the same.

There are two different approaches to serializing RDF.

The basic approach uses the basic RDF syntax from [RDF-MS]. In this:

• All blank nodes are assigned arbitrary URIs.
• Each resource is listed in turn as the subject of a top-level rdf:Description element, using an rdf:about attribute.
  For each triple, with this resource as subject, an appropriate property element production is used, with either string content (possibly empty) or an rdf:resource attribute specifying the object of the triple.

The basic serialization is recommended for applications in which the output RDF/XML is to be used only in further RDF processing. Where the intent is for the output RDF/XML file to be read by people, the basic serialization proves unsatisfactory. The basic serialization does not conform to more restricted sub-dialects of RDF, such as [RSS] or [CC/PP]. Hence, it is not appropriate for such applications, for which dialect specific serializers are needed.

If more human readable output is needed the following factors should be considered:

• There are many choices, with many RDF/XML documents corresponding to identical RDF graphs. Individual triples can be represented in numerous ways. High quality RDF serialization requires that these choices are considered by the serializing code. Some are more appropriate than others in an application dependent fashion.
• The triples in the graph need to be considered in an appropriate order. There are many choices of order, some being more appropriate than others in an application dependent fashion.

It is not possible to use the RDF/XML serialization for serializing an RDF graph in which any triple has a property label which cannot be expressed as a XML namespace-qualified name (QName). It is recommended that implementors of RDF serializers in order to break a URI into a namespace name and a local name, split it after the last XML non-Name character. If the URI ends in a non-Name character then throw a "this graph cannot be serialized in RDF 1.0" exception or error.

An approach to serializing RDF/XML using the full grammar in a top-down recursive descent fashion is discussed in [UNPARSING].

7 Acknowledgments (Informative)

The following people provided valuable contributions to the document:

• Dan Brickley, W3C/ILRT
• Jeremy Carroll, HP Labs Bristol

8 References

Normative References

[RDF-MS]

Resource Description Framework (RDF) Model and Syntax Specification, O. Lassila and R. Swick, Editors. World Wide Web Consortium. 22 February 1999. This version is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest version of RDF M&S is available at http://www.w3.org/TR/REC-rdf-syntax.

[XML]

Extensible Markup Language (XML) 1.0, Second Edition, T. Bray, J. Paoli, C.M. Sperberg-McQueen and E. Maler, Editors. World Wide Web Consortium. 6 October 2000. This version is http://www.w3.org/TR/2000/REC-xml-20001006. latest version of XML is available at http://www.w3.org/TR/REC-xml.

[XML-NS]

Namespaces in XML, T. Bray, D. Hollander and A. Layman, Editors. World Wide Web Consortium. 14 January 1999. This version is http://www.w3.org/TR/1999/REC-xml-names-19990114. The latest version of Namespaces in XML is available at http://www.w3.org/TR/REC-xml-names.

[INFOSET]

XML Information Set, J. Cowan and R. Tobin, Editors. World Wide Web Consortium. 24 October 2001. This version is http://www.w3.org/TR/2001/REC-xml-infoset-20011024. The latest version of XML Information set is available at http://www.w3.org/TR/xml-infoset.

[URIS]

RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding and L. Masinter, IETF, August 1998. This document is http://www.isi.edu/in-notes/rfc2396.txt.

[RDF-TESTS]

RDF Test Cases, A. Barstow and D. Beckett, Editors. Work in progress. World Wide Web Consortium, 15 November 2001. This version of the RDF Test Cases is http://www.w3.org/TR/2001/WD-rdf-testcases-20011115/. The latest version of the RDF Test Cases is at http://www.w3.org/TR/rdf-testcases.

[KEYWORDS]

RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF. March 1997. This document is http://www.ietf.org/rfc/rfc2119.txt.

[RFC-3023]

RFC 3032 - XML Media Types, M. Murata, S. St.Laurent, D.Kohn, IETF. January 2001. This document is http://www.ietf.org/rfc/rfc3023.txt.

[XML-BASE]

XML Base, J. Marsh, Editor, W3C Recommendation. World Wide Web Consortium, 27 June 2001. This version of XML Base is http://www.w3.org/TR/2001/REC-xmlbase-20010627/. The latest version of XML Base is at http://www.w3.org/TR/xmlbase/.

Informational References

[CHARMOD]

Character Model for the World Wide Web 1.0, M. Dürst, F. Yergeau, R. Ishida, M. Wolf, A. Freytag, T Texin, Editors, World Wide Web Consortium Working Draft, work in progress, 20 February 2002. This version of the Character Model is http://www.w3.org/TR/2002/WD-charmod-20020220/. The latest version of the Character Model is at http://www.w3.org/TR/charmod/.

[RDF-MODEL]

RDF Model Theory, P. Hayes, Editor. Work in progress. World Wide Web Consortium, 14 February 2002. This version of the RDF Model Theory is http://www.w3.org/TR/2002/WD-rdf-mt-20020214. The latest version of the RDF Model Theory is at http://www.w3.org/TR/rdf-mt/.

[RDF-PRIMER]

RDF Primer, F. Manola, E. Miller, Editors, World Wide Web Consortium W3C Working Draft, work in progress, 19 March 2002. This version of the RDF Primer is http://www.w3.org/TR/2002/WD-rdf-primer-20020319/. The latest version of the RDF Primer is at http://www.w3.org/TR/rdf-primer/.

STRIPEDRDF

RDF: Understanding the Striped RDF/XML Syntax, D. Brickley, W3C, 2001. This document is http://www.w3.org/2001/10/stripes/.

XPATH

XML Path Language (XPath) Version 1.0, J. Clark and S. DeRose, Editors. World Wide Web Consortium, 16 November 1999. This version of XPath is http://www.w3.org/TR/1999/REC-xpath-19991116. The latest version of XPath is at http://www.w3.org/TR/xpath.

SAX2

SAX Simple API for XML, version 2, D. Megginson, SourceForge, 5 May 2000. This document is http://sax.sourceforge.net/.

RSS

RDF Site Summary (RSS) 1.0, G. Beged-Dov, D. Brickley, R. Dornfest, I. Davis, L. Dodds, J. Eisenzopf, D. Galbraith, R.V. Guha, K. MacLeod, E. Miller, A. Swartz, E. van der Vlist, 2000. This document is http://purl.org/rss/1.0/spec.

CC/PP

Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies, G. Klyne, F. Reynolds, C. Woodrow, H. Ohto, World Wide Web Consortium Working Draft, work in progress, 15 March 2001. This version is http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/. The latest version of CC/PP structure and Vocabularies is available at http://www.w3.org/TR/CCPP-struct-vocab.

UNPARSING

Unparsing RDF/XML, J. J. Carroll, HP Labs Technical Report, HPL-2001-294, 2001. This document is available at http://www.hpl.hp.com/techreports/2001/HPL-2001-294.html.

RELAXNG

RELAX NG Specification, James Clark and MURATA Makoto, editors, OASIS, 3 December 2001. This version of RELAX NG is http://www.oasis-open.org/committees/relax-ng/spec-20011203.html. The latest is at http://relaxng.org/.

RELAXNG-NX

RELAX NG Non-XML Syntax, James Clark, 3 December 2001. This document is http://www.thaiopensource.com/relaxng/nonxml/.

XML Schema Part 0: Primer

XML Schema Part 0: Primer - W3C Recommendation, World Wide Web Consortium, 2 May 2001.

XML Schema Part 1: Structures

XML Schema Part 1: Structures - W3C Recommendation, World Wide Web Consortium, 2 May 2001.

XML Schema Part 2: Datatypes

XML Schema Part 2: Datatypes - W3C Recommendation, World Wide Web Consortium, 2 May 2001.

Schematron

Schematron, Rick Jelliffe, Academia Sinica Computing Centre, Taibei.

Appendix A: Issues affecting RDF/XML Syntax (Non-Normative)

This section records local issues to be resolved and issues that were reported to the RDF Core Working Group related to the XML syntax and their disposition. This section is not the definitive list or description of the latter - see the RDF Core Working Group issues list. Decided issues may also have associated test cases which can be found in the RDF Test Cases W3C Working Draft.

A.1: Document Issues / Tasks (Non-Normative)

task-infoset

(Feedback on 2001-12-18 draft): Consider basing on Infoset rather than SAX

task-renaming

(Feedback on 2001-12-18 draft): Consider changing nodeset terms to be, for example, events to prevent confusion with RDF graph nodes.

task-intro

(Feedback on 2001-12-18 draft): Better introduction text with respect to RDF model, graph, model theory, N-Triples.

A.2: RDF Core Working Group Open Issues affecting RDF/XML Syntax (Non-Normative)

rdf-charmod-literals

Does the treatment of literals conform to charmod ? [CHARMOD]

Action: ?

rdf-charmod-uris

Does the treatment of uri-references conform with charmod? [CHARMOD]

Action: ?

A.3: RDF Core Workign Group Decided Issues affecting RDF/XML Syntax (Non-Normative)

rdf-ns-prefix-confusion

On 25th May 2001, the WG decided that ALL attributes must be namespace qualified. There is a description of the decision, including detail on the grammar productions affected and a collection of test cases

Action: Removal of original grammar productions 6.6, 6.7, 6.8, 6.9, 6.11, 6.18, 6.32, 6.33

rdfms-abouteachprefix

On 1st June 2001, the WG decided that aboutEachPrefix would be removed from the RDF Model and Syntax Recommendation on the grounds that there is a lack of implementation experience, and it therefore should not be in the recommendation. A future version of RDF may consider support for this feature.

Action: Removal of original grammar production 6.8

rdf-containers-syntax-ambiguity
rdf-containers-syntax-vs-schema

On 29th June 2001, the WG decided that containers will match the typed node production in the grammar (production 6.13) and that the container specific productions (productions 6.25 to 6.31) and any references to them be removed from the grammar. rdf:li elements will be translated to rdf:_nnn elements when they are found matching either a propertyElt (production 6.12) or a a typedNode (production 6.13). The decision includes a set of test cases.

Action: Removal of original grammar productions 6.25, 6.26, 6.27, 6.28, 6.29, 6.30, 6.31

rdfms-empty-property-elements

On 8th June 2001 the WG decided how empty property elements should be interpreted. The decision is fully represented by the test cases.

Action: Inserted pointers to the the test cases into the grammar at the places where empty property elements are recognized.

rdfms-aboutEach-on-object

On 29th June 2001, the WG decided that rdf:aboutEach attributes are not allowed on an rdf:Description (or typed node) element which is the object of a statement.

Action: None needed - rdf:aboutEach removed from the language on 7th December 2001.

rdfms-syntax-desc-clarity

The language describing the syntax is unclear [in section 6]

On 26th October 2001, the WG decided that this issue is closed by the new approach to defining the syntax in this document.

Action: A main goal of this document is to make the syntax clearer and more precise. In particular the grammar section and the pointers to schemas for XML validation help address this.

rdfms-formal-grammar

A formal grammar for RDF.

On 26th October 2001, the WG decided that this issue is closed by the new approach to defining the syntax in this document.

Action: A main goal of this document is to make the syntax clearer and more precise. In particular the grammar section and the pointers to schemas for XML validation help address this.

rdfms-validating-embedded-rdf

On 9th November 2001, the RDFCore WG resolved to postpone the issue "for later consideration on the grounds that it is out of scope of its current charter to change the current RDF/XML syntax to the extent necessary to address it."

Action: None required.

rdfms-rdf-names-use

On 30th November 2001, the WG decided that this issue was closed by the following resolution.

The use of rdf:RDF, rdf:ID, rdf:about, rdf:resource, rdf:bagID, rdf:parseType, rdf:aboutEach and rdf:li except as reserved names as specified in the grammar is an error. [Later rdf:aboutEach was removed from the language on 7th December 2001]

On 25th February 2002, the WG further resolved that:.

The WG reaffirmed its decision not to restrict names in the RDF namespaces which are not syntactic. The WG decided that an RDF processor SHOULD emit a warning when encountering names in the RDF namespace which are not defined, but should otherwise behave normally.

Action: Added note to section 3.4 RDF Namespace

rdfms-abouteach

processing rdf:aboutEach requires a processing of sub-property relations.

On 7th December 2001, the WG resolved to remove rdf:aboutEach from the language.

Action: Removed from the grammar.

rdfms-propElt-id-with-dr

On 7th December 2001, the WG decided to remove rdf:aboutEach from the language and consequently this issue was closed.

Action: None needed.

rdfms-difference-between-ID-and-about

What is the difference between using and ID attribute to 'create' a new resource and an about attribute to refer to it?

On 14th December 2001, the WG decided that this document resolves the issue.

Action: See section on Identifiers for details.

rdfms-qname-uri-mapping

On 11th January 2002, the WG resolved ( revised) "to not change the algorithm for mapping qnames to uris and close this issue on the grounds:

1. Such a change would be a major change to the mapping of RDF/XML syntax to the model and would be beyond our charter.
2. It would cause the same RDF/XML to generate a different graph from existing versus revised implementations
3. Existing code may generate wrong (illegal) graphs for some RDF/XML."

Action: None needed.

rdfms-reification-required

On 11th January 2002, the WG resolved ( revised) "that a parser is not required to create bags of reified statements for all rdf:Description elements, only those which are explicitly reified using an rdf:ID on a propertyElt or by an rdf:bagID on the rdf:Description.

Existing test cases such as rdf-ns-prefix-confusion test0001 ( test0001.rdf, test0001.nt) demonstrate this resolution."

Action: None needed - matches the existing syntax description.

rdfms-replace-value

On 11th January 2002, the WG resolved ( revised) "to not change the name of this property at this time on the grounds:

• insufficient reasons to make this change
• will cause existing uses to be illegal - such as examples in M&S.

and resolves to recast the issue as a need to clarify the semantics of rdf:value."

Action: None needed.

mime-types-for-rdf-docs

On 18th January 2002, the WG authorized the removal of this issue from this document by the adding a new section with the wording proposed now included in the RDF MIME type section.

When the WG is ready (documents are stable), the MIME content-type registration for application/rdf+xml will proceed.

Action: Added RDF MIME type section.

rdfms-xml-base

On 18th January 2002, the WG decided that "xml:base be allowed, and honored, anywhere in an RDF document".

On 25th February 2002, the WG decided (1) that xml:base applies to RDF's use of document references (fragments)
(2) that xml:base hierarchical URIs without a path component shall have it set to /.
(3) the scope of xml:base attributes should be taken into account when checking for duplicate rdf:ID values

Action: Added details in Section 3 Data Model near introduction of Infoset and added new Section 3.6 Base URIs

rdfms-nested-bagIDs

What triples are generated for nested description elements with bagIDs?

On 25th February 2002, the WG decided that this issue was closed by the following resolution.

A bagID reifies the property attributes on the same element as the bagid, the type node and statements immediately arising from property elements that are immediate children of the element containing the bagId. In particular a property element whose statement is part of the bag, which has property attributes, those statements are not part of the bag.

Action: bagID algorithm added to nodeElement emptyPropertyElt.

rdfms-not-id-and-resource-attr

The propertyElt production 6.12 of the grammar does not allow both an ID attribute and a resource attribute to be specified.

On 25th February 2002, the WG decide that this issue was closed by making rdf:ID always specify the ID of the reified statement (parent node, property element, node).

Action: Updated 5.14 Production emptyPropertyElt and Relax NG schema to reflect decision.

rdfms-xml-literal-namespaces

How should a parser process namespaces in a literal which is XML markup?

On 15th March 2002, the WG decided that this issue was closed by the following resolution.

• The exact form of the string value corresponding to any given XML Literal within RDF/XML is implementation dependent.
• the string value is well-balanced XML
• taking the exclusive canonicalization of both the original XML Literal in its containing document, and the string value of the literal produce the same character string. This will be used as the basis for test cases.
• The canonicalization above is without comments
• CONFORMANCE should be tested without comments; dropping comments was NOT mandatory.

Action: FIXME - This resolution is not yet folded into the document.

A.4: RDF Core Working Group Postponed Issues affecting RDF/XML Syntax (Non-Normative)

rdfms-quoting

The syntax needs a more convenient way to express the reification of a statement.

On 26th October 2001, the WG decided that this issue was postponed for consideration by a future Working Group.

Action: None required.

rdfms-qnames-cant-represent-all-uris

The RDF XML syntax cannot represent all possible Property URI's.

On 26th October 2001, the WG decided that this issue was postponed for consideration by a future Working Group.

Action: None required.

rdfms-qnames-as-attrib-values

Suggestion that Qnames should be allowed as values for attributes such as rdf:about.

On 26th October 2001, the WG decided that this issue was postponed for consideration by a future Working Group.

Action: None required.

rdfms-syntax-incomplete

The RDF/XML syntax can't represent an an arbritary graph structure.

On 26th October 2001, the WG decided that this issue was postponed for consideration by a future Working Group.

Action: None required.

B Syntax Schemas (Non-Normative)

Two schema language authors submitted schemas for RDF/XML based on the revised grammar in the previous version of this draft. We include pointers to these schemas for information purposes and an example schema; they are not part of this specification.

B.1 RELAX NG Schema - Non XML (Non-Normative)

This is an example schema in RELAX NG's non-XML format (for ease of reading) but applications should use the standard XML version. These formats are described in RELAX NG ([RELAXNG]) and RELAX NG Non-XML Syntax ([RELAXNG-NX]).

#
# RELAX NG Schema (non-XML) for RDF/XML Syntax
#
# This schema is for information only and NON-NORMATIVE
#
# It is based on one originally written by James Clark in
# http://lists.w3.org/Archives/Public/www-rdf-comments/2001JulSep/0248.html
# and updated with later changes.
#

namespace local = ""
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"

start = doc
doc = 
  RDF

RDF =
  element rdf:RDF { nodeElementList }

nodeElementList = 
  nodeElement*

  # Should be something like:
  #  ws* , (  nodeElement , ws* )*
  # but RELAXNG does this by default, ignoring whitespace separating tags.

nodeElement =
  element * - (local:*
               |rdf:RDF
           |rdf:ID|rdf:about
           |rdf:bagID|rdf:parseType|rdf:resource
               |rdf:li ) {
      (idAttr | aboutAttr )?, bagIdAttr?, propertyAttr*, propertyEltList
  }

  # It is not possible to say "and not things
  # beginning with _ in the rdf: namespace" in RELAX NG.

ws = 
  " "

  # Not used in this RELAX NG schema; but should be any legal XML
  # whitespace defined by http://www.w3.org/TR/2000/REC-xml-20001006#NT-S


propertyEltList = 
  propertyElt*

  # Should be something like:
  #  ws* , ( propertyElt , ws* )*
  # but RELAXNG does this by default, ignoring whitespace separating tags.

propertyElt = 
  resourcePropertyElt | 
  literalPropertyElt | 
  parseTypeLiteralPropertyElt |
  parseTypeResourcePropertyElt |
  parseTypeOtherPropertyElt |
  emptyPropertyElt

resourcePropertyElt = 
  element * - (local:*
           |rdf:RDF|rdf:Description
           |rdf:ID|rdf:about
           |rdf:bagID|rdf:parseType|rdf:resource) {
      idAttr?, nodeElement
  }

literalPropertyElt =
  element * - (local:*
               |rdf:RDF|rdf:Description
           |rdf:ID|rdf:about
           |rdf:bagID|rdf:parseType|rdf:resource) {
      idAttr?, text 
  }

parseTypeLiteralPropertyElt = 
  element * - (local:*
               |rdf:RDF|rdf:Description
               |rdf:ID|rdf:about
               |rdf:bagID|rdf:parseType|rdf:resource) {
      idAttr?, parseLiteral, literal 
  }

parseTypeResourcePropertyElt = 
  element * - (local:*
               |rdf:RDF|rdf:Description
               |rdf:ID|rdf:about
               |rdf:bagID|rdf:parseType|rdf:resource) {
      idAttr?, parseResource, propertyEltList
  }

parseTypeOtherPropertyElt = 
  element * - (local:*
               |rdf:RDF|rdf:Description
               |rdf:ID|rdf:about
               |rdf:bagID|rdf:parseType|rdf:resource) {
      idAttr?, parseOther, any
  }

emptyPropertyElt =
   element * - (local:*
                |rdf:RDF|rdf:Description
                |rdf:ID|rdf:about
        |rdf:bagID|rdf:parseType|rdf:resource) {
       idAttr?, resourceAttr?, bagIdAttr?, propertyAttr* 
   }

idAttr = 
  attribute rdf:ID { 
      IDsymbol 
  }

aboutAttr = 
  attribute rdf:about { 
      URI-reference 
  }

bagIdAttr = 
  attribute rdf:bagID {
      IDsymbol
  }

propertyAttr = 
  attribute * - (local:* 
                 |rdf:RDF|rdf:Description
                 |rdf:ID|rdf:about
         |rdf:bagID|rdf:parseType|rdf:resource
         |rdf:li) {
      string
  }

resourceAttr = 
  attribute rdf:resource {
      URI-reference 
  }

parseLiteral = 
  attribute rdf:parseType {
      "Literal" 
  }

parseResource = 
  attribute rdf:parseType {
      "Resource" 
  }

parseOther = 
  attribute rdf:parseType {
      text
  }

URI-reference = 
  string

literal =
  any

IDsymbol = 
  xsd:NMTOKEN

any =
  mixed { element * { attribute * { text }*, any }* }

B.2 Other Syntax Schemas (Non-Normative)

Two schema language authors submitted schemas for RDF/XML based on the new grammar in the previous version of this draft. We include pointers to these schemas for information purposes; they are not part of this specification.

• Non-XML Relax NG schema by James Clark - see [RELAXNG] and section B.1
• Schematron schema by Rick Jellife - see [Schematron]
• XML Schema by the editor of this spec (not working yet) - see [XML Schema Part 0: Primer], [XML Schema Part 1: Structures] and [XML Schema Part 2: Datatypes].

C Changes

Changes since the 18 December 2001 working draft

(Newest at top)

• Updated status and abstract for this WD
• Updated table of contents to include substructure of section 5
• Require that URIs MUST NOT be generated for blank identifiers
• Specify syntax/non-syntax parts of RDF namespace
• Use RDF graph rather than RDF model throughout
• Sections Literal Node, and XML Literal Node that N-Triple string escape rules are required when generating N-Triple strings
• Remove xml* attributes that are not used (we use xml:lang, Infoset uses xml:base)
• Added references to RDF Primer [RDF-PRIMER] working draft
• Section 2: Added more examples to illustrate some (not all) syntax abbreviations
• Added xml:lang support by adding a new element property, using it throughout to generate literal() or xml() literals
• Added a grammar summary section (experimental)
• Added an explicit constraint on rdf:ID and rdf:bagID values, and with respect to the base URI
• Updated notation for A:=B assignment, string literal and xml literals
• Removed note on propertyElt about potential future parseTypes values
• Correct the illegal rdf:* names on node and property elements
• List all infoitems indicating ones that are not used; and note that all infoitems must be preserved inside parseTypeLiteral
• In rdf-id production, kept rdf:ID as XML Nmtoken
• Added style from XSD for term definition and reference
• Introduction gained pictures taken from draft primer
• Added Nodes for all SAX-like nodes
• Added rdf:bagID rules in nodeElement and emptyPropertyElt
• Added Section 3.6 Base URIs for XML Base support, updated other sections and added to references
• emptyPropertyElt: Allow rdf:ID and rdf:resource together; updated Relax NG schema to match
• Section 3.4: Noted unknown rdf: names generate a warning
• Section 5.3: Made parseType only take "Resource", "Literal" and other values are always the same as "Literal"
• Added Section 3.75 RDF MIME Type to note proposed mime type
• Updated issues list to record closed and postponed issues
• Removed original grammar ( Appendix C), updated grammar ( Appendix D) sections

Changes since the 06 September 2001 working draft

• Most of the document is new
• Original document grammar sections moved to appendices
• Expressed in more detail the use of the XML Infoset as used here in a SAX-like manner
• Grammar updated to remove rdf:aboutEach - see rdfms-abouteach for details.
• Added the mapping to the RDF Model as expressed by N-Triples
• Added the non-normative RELAX NG schema
• Added Issue sections
• Added serialization section
• Added introduction to the RDF/XML syntax