bwm's substantive comments are in strong purple. Please interpret these as errors. Suggested replacement text is normal purple.
bwm's editorial comments are in strong green Please interpret these as suggestions to be adopted or not at the editors discretion. Suggested replacement text is normal green.
Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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 XML, XML Namespaces, the XML Information Set with new support for XML Base. For each part of the RDF/XML syntax, it gives an example of how it works and in grammar defines actions for generating the triples that form the RDF graph as defined in the RDF Concepts and Abstract Data Model Working Draft. 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 Working Draft.
This is the editors version of 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 for
XML Base, RDF
datatyping, rdf:nodeID
for referencing blank nodes and
rdf:parseType="Collection"
for expressing a closed collection of
nodes.
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 all 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 25 March 2002
draft are described in the Changes section
however the main changes are as follows: Section 2
An XML syntax for RDF expanded with many more examples covering all of
the syntax, support for RDF datatyped literals using
rdf:datatype
was added, rdf:nodeID
was added to
allow referencing of blank nodes, rdf:parseType="Collection"
was
added for creating closed collections of nodes and many other more minor
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/.
There are no known patent or IPR constraints associated with this Working Draft. The RDF Core Working Group Patent Disclosure page contains details, in conformance with W3C policy requirements.
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
2 An XML syntax for RDF
2.1 Introduction
2.2 Node
Elements and Property Elements
2.3 Multiple
Property Elements
2.4 Empty
Property Elements
2.5 Property
Attributes
2.6 Completing the
Document - Document Element and XML Declaration
2.7 Languages -
xml:lang
2.8 XML Literals -
rdf:parseType="Literal"
2.9 Datatyped
Literals - rdf:datatype
2.10 Identifying Blank
Nodes - rdf:nodeID
2.11 Omitting Blank
Nodes - rdf:parseType="Resource"
2.12 Omitting Blank
Nodes - Property Attributes on an empty Property Element
2.13 Typed Nodes
2.14 Abbreviating URIs -
rdf:ID
and xml:base
2.15 List elements -
rdf:li
and rdf:_
n
2.16 Closed
Collections - rdf:parseType="Collection"
2.17 Reifying Statements -
rdf:bagID
and rdf:ID
2.18 More Information
3 Terminology
4 RDF MIME type, file extension and Macintosh
file type
5 Global Issues
5.1 The RDF Namespace
5.2 Identifiers
5.3 Base URIs
5.4 Constraints
6 Syntax Data Model
6.1 Events
6.2 Information Set
Mapping
6.3 Grammar
Notation
7 RDF/XML Grammar
7.1 Grammar Summary
7.2 Grammar
Productions
7.3 Reification Rules
7.4 List Expansion Rules
7.5 Bag Expansion Rules
8 Serializing an RDF Graph to RDF/XML
9 RDF/XML in HTML
10 Acknowledgments
11 References
A Issues affecting
RDF/XML Syntax (Non-Normative)
A.1 Document Issues / Tasks
(Non-Normative)
A.2 RDF Core Working Group Open
Issues affecting RDF/XML Syntax (Non-Normative)
A.3 RDF Core Working Group
Decided Issues affecting RDF/XML Syntax (Non-Normative)
A.4 RDF Core Working Group
Postponed Issues affecting RDF/XML Syntax (Non-Normative)
B Syntax Schemas (Non-Normative)
B.1 RELAX NG Compact
Syntax Schema (Non-Normative)
B.2 Other Syntax Schemas
(Non-Normative)
C Changes (Non-Normative)
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 revises the original RDF/XML grammar in terms of XML Information Set [INFOSET] Information Items which moves away from the rather low-level details of XML, 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.
The complete specification of RDF consists of a number of documents:
The RDF Concepts and Abstract Data Model [RDF-CONCEPTS] defines the RDF Graph data model (Section 2.4.1) and the RDF Graph syntax (Section 3). Along with the RDF Model Theory [RDF-MODEL] this provides an abstract syntax with a formal semantics for it. This What graph. No specific graph has been identified.graph has nodes and labelled directed arcs. The nodes can be labeled with URIs should be RDF URI References, literals or are blank and denote resources Its not clear what denotes resources. This could be interpreted as literals denote resources. Is there any need to talk about resources and denotation at all here? This doc is just about syntax. Suggest: Nodes may be blank or may be labelled with an RDF URI Reference [@@Ref] or a literal. [@@ref]. The arcs connect the nodes and are all labeled with URIs RDF URI References. 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, property arc and an object node at the sharp end of the arrow/arc. The property arc can also be also 2 also's 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 have to be represented by XML element names, attribute names, element content and attribute content. The URI labels for properties and object nodes are written in XML via XML Namespaces [XML-NS] which allows a namespace URI to be given a short prefix that is used to namespace-qualify elements and attributes names with local names. RDF/XML uses (namespace URI, local name) pairs such that concatenating them forms the original URI that is required. This shortens the URIs used for property names. URIs labeling subject and object nodes are stored as XML attribute values. Nodes labeled by string literals (which are always object nodes) become element text content or attribute values. Suggest this text could be clarified a bit. The RDF/XML syntax uses XML qnames [@@ref] to represent RDF URI References. The namespace prefix part of all qnames is associated with an an RDF URI Reference as defined in XML Namespaces [XML-NS]. The RDF URI Reference represented by a qname is determined by appending the local name part of the qname to the RDF URI Reference associated with the namespace prefix part of the qname. For clarity, convenience and brevity, the qname form of writing an RDF URI Reference is also used in this document.
A graph can be considered a sequence of paths of the form Node, Arc, Node, Arc, Node, Arc, ... which walk the entire graph. In RDF/XML these turn into sequences of elements inside elements which alternate between elements for Nodes and Arcs. This has been called a series of Node/Arc stripes. The Node at the start of the sequence turns into the outermost element The outermost element is often <rdf:RDF>, the next arc turns into a child element, and so on. The stripes generally start at the top of an RDF/XML document and always begin with nodes.
The sentence
There is a resource (this one) with a title, "RDF/XML Syntax Specification (Revised)" and it has an editor, the editor has a name "Dave Beckett" and a home page
http://purl.org/net/dajobe/
.
can be written as the RDF graph in Figure 1 where the nodes are represented as ovals and contain their URI where they have them, 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 rectangular nodes. Is this necessary. This doc is supposed to be about syntax.
If we follow the Node, Arc ... path through the graph shown in Figure 2:
This corresponds to the Node/Arc stripes:
[http://www.w3.org/TR/rdf-syntax-grammar]
-[http://example.org/stuff/1.0/editor]->
[]
-[http://example.org/stuff/1.0/homePage]->
[http://purl.org/net/dajobe/]
In RDF/XML the sequence of 5 nodes and arcs for the arcs in Figure 2 corresponds to 5 XML elements shown in Example 1:
Namespace decls are missing. Having just introduced the mechanism, I suggest its needed here. Oh, the rdf:about's are missing too. Colour coding is confusing. Fig 2 has red arcs as well. Best to sync them up. Suggest blue arcs? Hmm, maybe using colour to convey info is not a good plan. What happens when its printed out. Use bold and italic maybe? I origninally had some of this comment in purple, but later realised what was going on.. You are explaining striping, not the details of the syntax. So this is asuggestion to delay explaining striping till more of the basics are in place.
There are two
types of XML elements in the striping in Example 1 corresponding to the nodes and arcs in the
graph which are conventionally called Node Elements and Property
Elements respectively. Here, rdf:Description
is the node
element (used 3 times for the three nodes) and ex:editor
and
ex:homePage
are the 2 property elements.
The Figure 2 graph consists of some nodes labelled
with URIs (others that remain blank) and this can be added to the RDF/XML
using the rdf:about
attribute on node elements to give the
result 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>
Adding the other two paths through the Figure 1 graph gives the result in Example 3:
<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> <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"> <ex:editor> <rdf:Description> <ex:fullName>Dave Beckett</ex:fullName> </rdf:Description> </ex:editor> </rdf:Description> <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"> <dc:title>RDF/XML Syntax Specification (Revised)</dc:title> </rdf:Description>
There are several abbreviations that can be used to make very common uses
more easy to write down. In particular, it is very common that a resource is
being described with multiple property / value pairs as in this example. The
resource http://www.w3.org/TR/rdf-syntax-grammar
has two arcs
and the blank node resource also has two arcs.
This can be abbreviated by using multiple child property elements inside the node element describing the resource which then become properties of that node. This is shown in Example 4: Suggest it would be clearer to start with multiple properties in a description element and then add nesting.
<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> <ex:fullName>Dave Beckett</ex:fullName> </rdf:Description> </ex:editor> <dc:title>RDF/XML Syntax Specification (Revised)</dc:title> </rdf:Description>
When an arc points to a node with
grammar: that has no further arcs, which appears in RDF/XML
as an empty node element sequence such as the pair <rdf:Description
rdf:about="...">
</rdf:Description>
, this form
can be shortened. This is done by using the URI of the node as the value of
an XML attribute rdf:resource
on the containing property element
and making the property element empty.
In this example, the property element ex:homePage
contains an
empty node element with the URI http://purl.org/net/dajobe/
.
This can be replaced with the empty property element form giving the result
shown in Example 5: Suggest that the other stuff in this example
obscures the difference. The reader has to hunt for it. It would better to
have a specific example to hilite just this point.
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"> <ex:editor> <rdf:Description> <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/> <ex:fullName>Dave Beckett</ex:fullName> </rdf:Description> </ex:editor> <dc:title>RDF/XML Syntax Specification (Revised)</dc:title> </rdf:Description>
When a property's value is a literal string untyped literal (which means we may have to
have introduced notions of typed and untyped literals by now.
(not a resource) it can be encoded in a shorter form as an
XML attribute and value of the node element. This can be done only if the
property is not repeated, which is required by XML - attribute names are
unique on an XML element. This abbreviation is known as a Property
Attribute and can be applied to any node Not all nodes right? (or see
below, rdf:parseType="Resource"
form). This from can also be
used (as a special case) when the property element is rdf:type
,
which always takes a resource node the
value of the attribute is interpretted as a URI reference. We are in XML
syntax space here, not graph syntax. value.
In our example, there are two property elements with literal string
values, the dc:title
and ex:fullName
property
elements. These can be replaced with property attributes giving the result
shown in Example 6:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar" dc:title="RDF/XML Syntax Specification (Revised)"> <ex:editor> <rdf:Description ex:fullName="Dave Beckett"> <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/> </rdf:Description> </ex:editor> </rdf:Description>
To create a complete RDF/XML document, the graph must That's not strictly true is it? It could be
contained inside an element other than rdf:RDF. be contained
inside an rdf:RDF
XML element which becomes the top-level XML
document element. It is conventionally the element on which the XML
namespaces that are used are defined, although that is not required.
Additionally, the XML declaration should also be put at the top of the
document with the XML version and possibly the XML content encoding (this is
optional but recommended).
This could be done for any of the complete graph examples from Example 3 onwards but taking the smallest Example 6 and adding the final components, gives the complete RDF/XML representation of the original Figure 1 graph in Example 7:
This is the first example that will go through the validator, right? I don't like this approach,but if this is the way its done, then I suggest we say further back that we are building up an example and that the early ones are incomplete.
I suggest it would be better to start with a very small complete example, and then drop out the namespace the outer element stuff etc for clarity.
<?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)"> <ex:editor> <rdf:Description ex:fullName="Dave Beckett"> <ex:homePage rdf:resource="http://purl.org/net/dajobe/" /> </rdf:Description> </ex:editor> </rdf:Description> </rdf:RDF>
xml:lang
RDF/XML uses XML's xml:lang
attribute as defined by 2.12 Language
Identification of XML 1.0 [XML] to allow the identification of content language.
This can be added to any XML element to indicate that the included content is
in the given language. The most specific in-scope language present (if any)
is applied to literal property element or property attribute values. The
xml:lang=""
form is used to indicate absence of language. need to show how this relates to the abstract
syntax, i.e. that literals have a lang component.
Some examples of marking content languages for RDF properties are shown in Example 8:
<?xml version="1.0" encoding="iso-8859-1"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
<dc:title xml:lang="en">RDF/XML Syntax Specification (Revised)</dc:title>
<dc:title xml:lang="en-US">RDF/XML Syntax Specification (Revised)</dc:title>
<dc:description xml:lang="it">Il Pagio di Web Fuba</dc:description> That
does not look like a very good translation?
</rdf:Description>
<rdf:Description rdf:about="http://example.org/buchen/baum" xml:lang="de">
<dc:title>Das Baum</dc:title>
<dc:description>Das Buch ist au@?ergewöhnlich</dc:description>
<dc:title xml:lang="en">The Tree</dc:title>
</rdf:Description>
</rdf:RDF>
rdf:parseType="Literal"
RDF allows XML
Literals ([RDF-CONCEPTS] Section 3.2.2) to
be given as the value of arcs. These are written in RDF/XML as content of a
property element (not property attribute) and indicated using the
rdf:parseType="Literal"
attribute on the containing property
element.
An example of writing an XML literal is given in Example 9 where there is a single RDF triple with the
subject node labelled with URI http://example.org/thingy
, the
arc labelled with URI http://example.org/stuff/1.0/prop
(from
ex:prop
) and the object node labelled with XML content beginning
a:Collection
Suggest change example to avoid confusin with
parseType="Collection".
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/stuff/1.0/"> <rdf:Description rdf:about="http://example.org/thingy"> <ex:prop rdf:parseType="Literal" xmlns:a="http://example.org/a#"> <a:Collection required="true"> <a:widget size="10" /> <a:grommit id="23" /> </a:Collection> </ex:prop> </rdf:Description> </rdf:RDF>
rdf:datatype
RDF allows Datatyped Literals to be given as the value of arcs. These
consist of a literal string (with optional language) and a datatype URI.
This is handled by using the same syntax syntax for literal string nodes in
the property element form (not property attribute) but with an additional
rdf:datatype="
datatypeURI"
attribute on
the property element. Any URI can be used in the attribute.
Editors Note: I cannot yet point at Datatyped Literals in the latest published RDF Concepts and Abstract Data Model Working Draft.
An example of an RDF datatyped literal is given in Example 10 where there is a single RDF triple with the
subject node labelled with URI http://example.org/thingy
, the
arc labelled with URI http://example.org/stuff/1.0/size
(from
ex:size
) and the object node with the datatype ("123",
http://www.w3.org/2001/XMLSchema#int
, no language) intending to
be interpreted as a W3C XML
Schema datatype int.
Suggest simplify the example. drop the xml and rdf elements. use rdf:value. drop the about attribute. None of these are needed to illustrate the point being made.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/stuff/1.0/"> <rdf:Description rdf:about="http://example.org/thingy"> <ex:size rdf:datatype="http://www.w3.org/2001/XMLSchema#int">123</ex:size> </rdf:Description> </rdf:RDF>
rdf:nodeID
Blank nodes in the RDF graph are distinct but have no URI label. It is
sometimes required that the same blank node is refered to in the
serialization in multiple places, such as at the subject and object of
several RDF triples. In this case, a Blank Node Identifier (or
bnodeID) can be given to the blank node for identifying it in the document.
This identifier does not exist outside a particular RDF/XML document or
serialization. To use a bnodeID for a blank node, it can be used on a node
element to replace rdf:about="
URI"
or on a
property element to replace
rdf:resource="
URI"
.
Taking Example 7 and explicitly giving a bnodeID
of abc to the blank node in it gives the result shown in Example 11. The second rdf:Description
property element is about the blank node.
<?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)"> <ex:editor rdf:nodeID="abc"/> </rdf:Description> <rdf:Description rdf:nodeID="abc" ex:fullName="Dave Beckett"> <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/> </rdf:Description> </rdf:RDF>
rdf:parseType="Resource"
Blank nodes (no resource URI) appear often in RDF graphs and there is a an
abbreviation that allows the extra <rdf:Description>
</rdf:Description>
pair to be omitted. This is done by
putting an attribute on the containing property element
rdf:parseType="Resource"
that turns the property element into a
property and node element, which can now have properties (property elements
or property attributes). This causes the node-arc striping to be broken,
which can make the resulting RDF/XML difficult to read.
Taking the earlier Example 7, the contents of the
ex:editor
property element could be alternatively done in this
fashion to give the abbreviation shown in Example
12:
<?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)"> <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>
If all the property elements on a blank node have string Suggest: untyped literal
values (or at most one is rdf:type
), these can be abbreviated by
moving them to be property attributes on the containing property element
which is made an empty element.
Taking the earlier Example 7, the contents of the
ex:editor
property element are two properties. Only one is
suitable here for using in this form, so the ex:homePage
property element is being ignored here. The abbreviated form where
the ex:fullName
property element moves to be a property
attribute on the ex:editor
property element, the blank node is
implicit. The result is shown in Example 13.
<?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)"> <ex:editor ex:fullName="Dave Beckett" /> <!-- Note the ex:homePage property has been ignored for this example --> </rdf:Description> </rdf:RDF>
It is very common for RDF graphs to have rdf:type
arcs from
nodes. These are conventionally called Typed Nodes and have a
shorthand in RDF/XML to allow this to be expressed more consisely. This is
done by replacing the rdf:Description
node element name with the
namespaced-element corresponding to the URI of the value of the type
relationship. There may, of course, be multiple rdf:type
arcs
but only one can be used in this way, the others must remain as property
elements or property attributes.
This form is also commonly used in RDF/XML with the built-in classes in The RDF Namespace: rdf:Seq
,
rdf:Bag
, rdf:Alt
, rdf:Statement
,
rdf:Property
and rdf:List
.
For example, the RDF/XML in Example 14 could be written as shown in Example 15.
<?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://example.org/thing"> <rdf:type rdf:resource="http://example.org/stuff/1.0/Document"/> <dc:title>A marvelous thing</dc:title> </rdf:Description> </rdf:RDF>
<?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/"> <ex:Document rdf:about="http://example.org/thing"> <dc:title>A marvelous thing</dc:title> </ex:Document> </rdf:RDF>
rdf:ID
and xml:base
RDF/XML allows further abbreviating URIs in XML attributes in two ways.
The XML Infoset provides a base URI attribute xml:base
that sets
the base URI for resolving relative URIs. This applies to all RDF attributes
that deal with URIs which are rdf:about
,
rdf:resource
and rdf:datatype
.
We need a section here explaining the relative absolute URI transform in general.
The rdf:ID
attribute on a node element (not property element,
that has another meaning) can be used instead of rdf:about
and
gives a URI equivalent to #
concatenated with the
rdf:ID
attribute value. So for example if
rdf:ID="name"
, that would be equivalent to
rdf:about="#name"
. This provides an additional check since the
same name can only appear once in a single RDF/XML document, so is
useful for defining a set of distinct, related terms relative to the same
URI.
Example 16 shows abbreviating the node URI of
http://example.org/here/#snack
using an xml:base
of
http://example.org/here/
and an rdf:ID
on the
rdf:Description
node element. The value of the
ex:prop
property element is also relative to the
xml:base
value, and the resulting URI is
http://example.org/here/fruit/apple
.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/stuff/1.0/" xml:base="http://example.org/here/"> <rdf:Description rdf:ID="snack"> <ex:prop rdf:resource="fruit/apple"/> </rdf:Description> </rdf:RDF>
rdf:li
and rdf:_
nRDF has a set of list We have a name
for these: container membership properties properties that
are mostly used with the rdf:Seq
, rdf:Bag
and
rdf:Alt
classes actually
instances of the classes, written as typed nodes typcially.
The list properties are rdf:_1
, rdf:_2
etc. and can
be written out explicitly like that as property elements or attributes like
in Example 17. There is a grammar: an
rdf:li
special property element that can handle the counting
automatically, turning into rdf:_1
, rdf:_2
in
order. The equivalent graph to Example 17 written
in this form is shown in Example 18.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Seq rdf:about="http://example.org/favourite-fruit"> <rdf:_1 rdf:resource="http://example.org/banana"/> <rdf:_2 rdf:resource="http://example.org/apple"/> <rdf:_3 rdf:resource="http://example.org/pear"/> </rdf:Seq> </rdf:RDF>
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Seq rdf:about="http://example.org/favourite-fruit"> <rdf:li rdf:resource="http://example.org/banana"/> <rdf:li rdf:resource="http://example.org/apple"/> <rdf:li rdf:resource="http://example.org/pear"/> </rdf:Seq> </rdf:RDF>
rdf:parseType="Collection"
RDF/XML allows a closed set of nodes to be given as the value of a
property by using the rdf:parseType="Collection"
attribute on a
property element. The value is the collection of nodes given inside. This reads like it breaks the abstract syntax.
The object or value of any property is a single node, not a collection of
nodes. The exact graph generated is described in detail in
Section 7.2.17 Production
parseTypeCollectionPropertyElt.
Example 19 shows a collection of three nodes in a
collection at the end of the ex:hasFruit
property element.
rdf:parseType="Collection"
(example19.rdf)<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/stuff/1.0/"> <rdf:Description rdf:about="http://example.org/basket"> <ex:hasFruit rdf:parseType="Collection"> <rdf:Description rdf:about="http://example.org/banana"/> <rdf:Description rdf:about="http://example.org/apple"/> <rdf:Description rdf:about="http://example.org/pear"/> </ex:hasFruit> </rdf:Description> </rdf:RDF>
rdf:bagID
and rdf:ID
The rdf:ID
attribute can be used on a property element to
reify Suggest provide ref to description
of reification in concepts doc. the triple that it generates
(See section 7.3 Reification Rules for the
full details). The identifer for the triple Should be reified statement
is constructed as a relative URI RDF
uses absolute URI's of #
concatenated with the
rdf:ID
attribute value. So for example if
rdf:ID="triple"
, that would be equivalent to the URI
#triple
. Each such rdf:ID
identifier has to be
unique in the RDF/XML document (from the same set of identifiers as
rdf:bagID
).
Example 20 shows a rdf:ID
being used
to reify a triple made from the ex:prop
property element giving
the reified triple the URI
http://example.org/triples/#triple1
.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/stuff/1.0/" xml:base="http://example.org/triples/"> <rdf:Description rdf:about="http://example.org/"> <ex:prop rdf:ID="triple1">blah</ex:prop> </rdf:Description> </rdf:RDF>
The rdf:bagID
attribute can be used on a node element to give
an identifier for a rdf:Bag
that lists contains the reifications of
the statements
generated by the property elements not
just property elements inside the node element. This allows
statements to be made about that bag. The identifer is constructed as a
relative URI RDF uses absolute URI's
of #
concatenated with the
rdf:bagID
attribute value, like rdf:ID
. So for
example if rdf:bagID="bag"
, that would be equivalent to the URI
#bag
. Each such rdf:bagID
identifier has to be
unique in the RDF/XML document (from the same set of identifiers as
rdf:ID
).
Example 21 shows a rdf:Bag
with URI
http://example.org/bags/#bag1
being made of the triples from
inside the rdf:Description
node element.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ex="http://example.org/stuff/1.0/" xml:base="http://example.org/bags/"> <rdf:Description rdf:about="http://example.org/" rdf:bagID="bag1"> <ex:prop1>blah</ex:prop1> <ex:prop2 rdf:resource="http://example.org/elsewhere/"/> </rdf:Description> </rdf:RDF>
The RDF Core Working Group has developed an RDF Primer [RDF-PRIMER] that goes into detail introducing RDF and its applications.
For a longer introduction to the RDF/XML striped syntax with a historical perspective, see RDF: Understanding the Striped RDF/XML Syntax [STRIPEDRDF].
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].
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).
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
Seq Bag Alt Statement Property List
subject predicate object type value first rest
_
n
where n is a non-negative integer.
nil
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
Note: In the 18 December
2001 Working Draft the names aboutEach
and
aboutEachPrefix
were removed from the language and the RDF
namespace by the RDF Core Working Group. See the resolution of issues rdfms-abouteach and rdfms-abouteachprefix for further
information.
Note: In this version of the working draft, the names
List
, first
, rest
and nil
were added to the RDF namespace by the RDF Core Working Group. See the
resolution of issues rdfms-seq-representation for further
information. Group).
Note: The Working Group invites feedback from the community on the effects of the removals and additions of these terms on existing implementations and documents and on the costs and benefits of adopting a new namespace URI to reflect this change (currently not proposed by the Working Group).
The RDF graph (RDF Concepts and Abstract Data Model Section 3) uses three types of identifiers (or labels) for nodes and arcs:
URI references (RDF Concepts and Abstract Data Model Section 3.1) 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 5.3, 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 5.3.
RDF Literals (RDF Concepts and Abstract Data Model 3.2) are either Strings Literals (ibid 3.2.1), XML Literals (ibid 3.2.2) or Datatype Literals
Editors Note: I cannot yet point at Datatyped Literals in the latest published RDF Concepts and Abstract Data Model Working Draft.
Note: In the past, some RDF applications have handled these nodes (then called anonymous nodes) by generating arbitrary URIs. This generates a different RDF graph. See also the Skolemization section of the RDF Model Theory [RDF-MODEL] Working Draft.
RDF/XML supports XML Base [XML-BASE] by being specified in terms of the XML Information Set [INFOSET]. This defines a ·base-uri· accessor for each ·root event· and ·element event·.
RDF/XML uses URI-references throughout and applies the in-scope Base URI to resolve both same document references of the forms "#frag" and "".
Test: Indicated by test001.rdf and test001.nt
Test: Indicated by test004.rdf and test004.nt
Test: Indicated by test008.rdf and test008.nt
Test: Indicated by test013.rdf and test013.nt
Test: Indicated by test016.rdf and test016.nt
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
Test: Indicated by test013.rdf and test013.nt
Implementor Note: When using a hierarchical base URI that has no path component (/), it must be added before using as a base URI for resolving.
Test: Indicated by test011.rdf and test011.nt
The names used as values of rdf:ID and rdf:bagID attributes must be unique in a single RDF/XML document since they come from the same set of names. This applies with respect to the in-scope ·base-uri· accessor of the current element; so the same value can appear on different elements in the same document but only if the in-scope base-uri values were different.
The syntax of the names must match the rdf-id production
Test: Indicated by test014.rdf and test014.nt
The names used as values of rdf:nodeID come from a set of names that are independent of those of rdf:ID and rdf:bagID. The syntax of the names must match the rdf-id production
This syntax is defined in terms of the XML Information Set represented as objects called Events in the style of the [XPATH] Information Set Mapping. The order of the sequence is XML document order defined below in Section 6.2 Information Set Mapping. The sequence of events formed are intended to be similar to the sequence of events produced by the [SAX2] XML API from the same XML. These events are then mapped into the RDF Graph written as N-Triples.
This model is conceptual only and illustrates one way to create the N-Triples from the XML. It does not mandate any implementation method - any other method that results in the same N-Triples (RDF graph) may be used.
In particular:
The syntax does not support non-well-formed XML documents, nor documents that otherwise do not have an XML Information Set; for example, that do not conform to XML Namespaces [XML-NS].
The Infoset requires support for XML Base [XML-BASE] which generates information item properties [base URI] below. The use of this property in RDF/XML is discussed in section 5.3
This specification requires an XML Information Set[INFOSET] which supports at least the following information items and properties for RDF/XML:
There is no mapping of the following items to data model events:
Other information items and properties have no mapping to syntax data model events.
Open Issue: The handling of XML content inside parseTypeLiteralPropertyElt requires some other Information Items, yet to be determined but based on the requirements for Exclusive XML Canonicalization W3C Candidate Recommendation.
This section is intended to satisfy the requirements for Conformance in the [INFOSET] specification. It specifies the information items and properties that are needed to implement this specification.
There are six types of event defined in the following subsections. Most events are constructed from an Infoset information item (except for Identifier, Literal and XML Literal). The effect of an event constructor is to create a new event with a unique identity, distinct from all other events. Events have accessor operations on them. and all have the string-value accessor that may be a static value or computed.
Constructed from an Document Information Item and takes the following accessors and values.
Constructed from an Element Information Item and takes the following accessors and values:
Set to the value of element information item property [attributes].
If the value contains an attribute event xml:lang (that is, the ·local-name· accessor of the attribute has value "lang" and the ·namespace-name· accessor of the attribute has value "http://www.w3.org/XML/1998/namespace"), it is removed and from the list of attributes and the ·language· accessor is set to the string-value of the attribute.
All other attributes beginning with xml are then removed (that is, all attributes with ·namespace-name· accessors 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· accessor.
Has no accessors. Marks the end of the containing element in the sequence.
Constructed from an Attribute Information Item and takes the following accessors and values:
Constructed from a sequence of one or more consecutive Character Information Items. Has the single accessor:
A node for a typed identifier which has the following accessors:
The value of this is calculated from the other accessors based on the ·identifier-type· value as follows.
When "URI", the value is the concatenation of "<", the value of the ·identifier· accessor and ">"
Otherwise ("bnodeID"), the value is the concatenation of "_:" and the value of the ·identifier· accessor.
These events are constructed by giving two values for the for the ·identifier· and ·identifier-type· accessors.
For further information on identifiers in the RDF graph, see section 5.2.
An event for a text literal which can have the following accessors:
The value is calculated from the other accessors as follows.
If ·literal-language· is empty then the value is the concatenation of """ (1 double quote), the value of the 2 ·literal-value· accessor and """ (1 double quote).
Otherwise the value is the concatenation of """ (1 double quote), the value of the ·literal-value· accessor ""@" (1 double quote and a '@'), and the value of the ·literal-language· accessor.
If ·literal-datatype· is not empty then append to the value calculated above "^^<" concatenated with the value of the ·literal-datatype· accessor concatenated with ">".
Note that the double-quoted ·literal-value· string must use the N-Triples string escapes for escaping certain characters such as ".
These events are constructed by giving values for the ·literal-value· and ·literal-language· accessors.
Note: Literals beginning with a Unicode combining character are allowed however they may cause interoperability problems. See [CHARMOD] for further information.
An event for an XML literal which can have the following accessors:
The value is calculated from the other accessors 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· accessor 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· accessor ""@" (1 double quote and a '@'), and the value of the ·literal-language· accessor.
Note that the double-quoted literal-value string must use the N-Triples string escapes for escaping certain characters such as ".
These events are constructed by giving values for the ·literal-value· and ·literal-language· accessors.
Note: Literals beginning with a Unicode combining character are allowed however they may cause interoperability problems. See [CHARMOD] for further information.
To transform the Infoset into the sequence of events in document order, each information item is transformed as described above to generate a tree of events with accessors and values. Each element event is then replaced as described below to turn the tree of events into a sequence in document order.
The following notation is used for matching the sequence of events generated as described in Section 6 and describing the actions to perform for the matches. The RDF/XML grammar is defined here in terms of its data model events, using statements of the form:
number event-type event-content
action...
where the event-content is an expression, which may refer to other event-types (as defined in Section 6.1), using constructs of the form given in the following table. The number is used for reference purposes. The action may include generating new triples to the graph, written in N-Triples format.
General Notation | |
---|---|
Notation | Meaning |
event.accessor | The value of an event accessor. |
rdf:X | A URI as defined in section 5.1. |
"ABC" | A string of characters A, B, C in order. |
concat(A, B, ..) | A string created by concatenating the terms in order. |
Notation for Matching Events | |
Notation | Meaning |
A == B | A is equal to B. |
A != B | A is not equal to B. |
A | B | ... | The A, B, ... terms are alternatives. |
A - B | The term A but not the term B. |
anyURI. | Any legal URI. |
anyString. | Any string. |
list(item1, item2, ...); list() | An ordered list of events. An empty list. |
set(item1, item2, ...); set() | An unordered set of events. An empty set. |
* | Zero or more of preceding term. |
? | Zero or one of preceding term. |
+ | One or more of preceding term. |
root(acc1 == value1, acc2 == value2, ...) |
Match a Root Event with accessors. |
start-element(acc1 == value1, acc2 == value2, ...) children end-element() |
Match a sequence of Element Event with accessors, a possibly empty list of events as element content and an End Element Event. |
attribute(acc1 == value1, acc2 == value2, ...) |
Match an Attribute Event with accessors. |
text() | Match a text event. |
Notation for Grammar Actions | |
Notation | Meaning |
A := B | Assigns A the value B. |
event.accessor := value | Sets an event accessor to the given value. |
identifier(identifier := value, identifier-type := value, ...) |
Create a new Identifier Event. |
literal(literal-value := string, literal-language := language, ...) |
Create a new Literal Event. |
xml(literal-value := string, literal-language := language, ...) |
Create a new XML Literal Event. |
If the RDF/XML is a standalone XML document (known by having been given the RDF MIME Type) then the grammar starts with Root Event 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 Event 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 Event will be available. Note that if such embedding occurs, the grammar may be entered several times but no state is expected to be preserved.
rdf:RDF | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
These are the core terms from the RDF Namespace in section 5.1 that are part of the RDF/XML syntax and never handled as RDF properties or classes.
anyURI - ( syntaxTerms | rdf:li )
The URIs that are allowed on node elements.
anyURI - ( syntaxTerms | rdf:Description | rdf:nil)
The URIS that are allowed on property elements.
anyURI - ( syntaxTerms | rdf:Description | rdf:li | rdf:nil)
The URIs that are allowed on property attributes.
root(document-element == RDF,
children ==
list(RDF))
start-element(URI ==
rdf:RDF,
attributes == set())
nodeElementList
end-element()
ws* (nodeElement ws* )*
start-element(URI == nodeElementURIs
attributes == set((idAttr | nodeIdAttr | aboutAttr )?, bagIdAttr?,
propertyAttr*))
propertyEltList
end-element()
For element e, the processing of some of the attributes have to be done before other work such as dealing with children events or other attributes. These can be processed in any order:
If e.subject is empty, generate a local blank node identifier i and n := identifier(identifier := i, identifier-type:="bnodeID"). Then e.subject := n.
The following can then be performed in any order:
e.subject.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <e.URI> .
e.subject.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <a.string-value> .
e.subject.string-value <a.URI> o.string-value .
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 graph:
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
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 event s using the reification rules in section 7.3 and apply the bag expansion rules in section 7.5 on event n to give a URI u. Then the following statement is added to the graph:
n.string-value <u> s.string-value .
White space as defined by [XML] definition White Space Rule [3] S in section Common Syntactic Constructs
ws* (propertyElt ws* ) *
If element e has e.URI = rdf:li then apply the list expansion rules on element e.parent in section 7.4 to give a new URI u and e.URI := u.
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?))
ws* nodeElement ws*
end-element()
For element e, and the single contained nodeElement n the following statement is added to the graph:
e.parent.subject.string-value <e.URI> n.subject.string-value .
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 7.3 and e.subject := i
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
Note: The empty literal case is defined in production emptyPropertyElt
For element e, and the text event t. If the rdf:datatype attribute d is given then o := literal(literal-value := t.string-value, literal-language := e.language, literal-datatype := a.string-value) otherwise o := literal(literal-value := t.string-value, literal-language := e.language) and the following statement is added to the graph:
e.parent.subject.string-value <e.URI> o.string-value .
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 7.3 and e.subject := i.
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, parseLiteral))
literal
end-element()
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 graph:
e.parent.subject.string-value <e.URI> o.string-value .
Test: Empty literal case indicated by test009.rdf and test009.nt
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 7.3 and e.subject := i.
Open Issue: The result of a literal from rdf:parseType="Literal" content has been generally decided by the RDF Core Working Group but all the cases have not been entirely resolved at this time. The solution will be based on serializing the XML element content in l to a string in a form defined by Exclusive XML Canonicalization W3C Candidate Recommendation.
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, parseResource))
propertyEltList
end-element()
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 graph:
e.parent.subject.string-value <e.URI> n.string-value .
Test: Indicated by test004.rdf and test004.nt
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 7.3 and e.subject := i.
If the element content c is not an empty, then use event n to create a new sequence of events as follows:
start-element(URI :=
rdf:Description,
subject :=
n,
attributes := set())
c
end-element()
Then process the resulting sequence using production nodeElement.
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, parseCollection))
nodeElementList
end-element()
For element event e with possibly empty nodeElementList l. Set s:=list().
For each element event f in l, generate a local blank node identifier i, n := identifier(identifier := i, identifier-type:="bnodeID") and append n to s to give a sequence of identifier events.
If s is not empty, n is the first event identifier in s and the following statement is added to the graph:
e.parent.subject.string-value <e.URI> n.string-value .
otherwise the following statement is added to the graph:
e.parent.subject.string-value <e.URI> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .
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 7.3.
If s is empty, no further work is performed.
For each identifier event n in s, the following statement is added to the graph:
n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#List> .
For each identifier event n in s and the corresponding element event f in l, the following statement is added to the graph:
n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> f.string-value .
For each consecutive, overlapping pairs of identifier events (n, o) in s, the following statement is added to the graph:
n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> o.string-value .
If s is not empty, n is the last event identifier in s, the following statement is added to the graph:
n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, parseOther))
propertyEltList
end-element()
All rdf:parseType attribute values other than the strings "Resource", "Literal" or "Collection" are treated as if the value was "Literal". Processing MUST continue at production parseTypeLiteralPropertyElt. No extra triples are generated for other rdf:parseType values.
start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, bagIdAttr?, propertyAttr*))
end-element()
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 graph:
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 7.3.
Test: Indicated by test002.rdf and test002.nt
Test: Indicated by test005.rdf and test005.nt
Otherwise
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 graph:
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 7.3.
For all propertyAttr attributes a (in any order)
If a.URI == rdf:type then the following statement is added to the graph:
r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <a.string-value> .
Otherwise o := literal(literal-value := a.string-value, literal-language := e.language) and the following statement is added to the graph:
r.string-value <a.URI> o.string-value .
If Identifier event n was created, then generate a local blank node identifier i and s := identifier(identifier := i, identifier-type:="bnodeID"). Each statement above is then reified with event s using the reification rules in section 7.3 and the bag expansion rules in section 7.5 is applied on event n to give URI u. Then the following statement is added to the graph:
n.string-value <u> s.string-value; .
Test: Indicated by test013.rdf and test013.nt
Test: Indicated by test014.rdf and test014.nt
If Identifier event n was created, add the following statement to the graph:
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> .
attribute(URI ==
rdf:ID,
string-value == rdf-id)
Constraint:: constraint-id applies to the values of rdf:ID attributes
attribute(URI ==
rdf:nodeID,
string-value == rdf-id)
Constraint:: constraint-nodeID applies to the values of rdf:nodeID attributes
attribute(URI ==
rdf:about,
string-value == URI-reference)
attribute(URI ==
rdf:bagID,
string-value == rdf-id)
Constraint:: constraint-id applies to the values of rdf:bagID attributes
attribute(URI == propertyAttributeURIs,
string-value == anyString)
attribute(URI ==
rdf:resource,
string-value == URI-reference)
attribute(URI ==
rdf:datatype,
string-value == URI-reference)
attribute(URI ==
rdf:parseType,
string-value == "Literal")
attribute(URI ==
rdf:parseType,
string-value == "Resource")
attribute(URI ==
rdf:parseType,
string-value == "Collection")
attribute(URI ==
rdf:parseType,
string-value == anyString - ("Resource" | "Literal") )
An attribute ·string-value· interpreted as a URI reference defined in Uniform Resource Identifiers (URI) [URIS] BNF production URI-reference.
Any XML element content that is allowed according to [XML] definition Content of Elements Rule [43] content. in section 3.1 Start-Tags, End-Tags, and Empty-Element Tags
An attribute ·string-value· matching any legal [XML] token Nmtoken
For a statement with terms s, p and o corresponding to the N-Triples:
s p o .
add the following statements to the graph using the given Identifier Event r:
r.string-value
<http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> s
.
r.string-value
<http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate> p
.
r.string-value
<http://www.w3.org/1999/02/22-rdf-syntax-ns#object> o
.
r.string-value
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement> .
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.
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.
There are some RDF graphs as defined in the RDF Concepts and Abstract Data Model Working Draft. that cannot be serialized in RDF/XML. These are those that:
A more detailed discussion of the issues of serializing the RDF graph to
RDF/XML is given in [UNPARSING]. This describes
using the original syntax without the subsequently added
rdf:nodeID
attribute that now allows all graphs with blank nodes
to be serialized.
If RDF/XML is embedded inside HTML or XHTML this can add many new elements and attributes, many of which will not be in the appropriate DTD. This causes validation against the DTD to fail. The obvious solution of changing or extending the DTD is not practical for most uses. This problem has been analysed extensively by Sean B. Palmer in RDF in HTML: Approaches[RDF-IN-XHTML] and it concludes that there is no single embedding method that satisfies all applications and remains simple.
The recommended approach is to not embed RDF/XML in HTML/XHTML but rather to use <link> element in the <head> element of the HTML/HTML to point at a separate RDF/XML document. This has been used for several years by the Dublin Core Metadata Initiative (DCMI) on its Web site.
To use this technique, the <link> element href should point at the URI of the RDF/XML content and the type attribute should be used with the value of "application/rdf+xml", the proposed MIME Type for RDF/XML, see Section 4
The value of the rel attribute may also be set to indicate the relatioship; this is an application dependent value. The DCMI has used and recommended rel="meta" when linking in RFC 2731 - Encoding Dublin Core Metadata in HTML[RFC-2731] however rel="alternative" may also be appropriate. See HTML 4.01 link types and XHTML Modularization - LinkTypes for further information.
The following people provided valuable contributions to the document:
This document is a product of extended deliberations by the RDF Core working group, whose members have included: Art Barstow (W3C) Dave Beckett (ILRT), Dan Brickley (W3C/ILRT), Dan Connolly (W3C), Jeremy Carroll (Hewlett Packard), Ron Daniel (Interwoven Inc), Bill dehOra (InterX), Jos De Roo (AGFA), Jan Grant (ILRT), Graham Klyne (Clearswift and Nine by Nine), Frank Manola (MITRE Corporation), Brian McBride (Hewlett Packard), Eric Miller (W3C), Stephen Petschulat (IBM), Patrick Stickler (Nokia), Aaron Swartz (HWG), Mike Dean (BBN Technologies / Verizon), R. V. Guha (Alpiri Inc), Pat Hayes (IHMC), Sergey Melnik (Stanford University), Martyn Horner (Profium Ltd).
This specification also draws upon an earlier RDF Model and Syntax document edited by Ora Lassilla and Ralph Swick, and RDF Schema edited by Dan Brickley and R. V. Guha. RDF and RDF Schema Working group members who contributed to this earlier work are: Nick Arnett (Verity), Tim Berners-Lee (W3C), Tim Bray (Textuality), Dan Brickley (ILRT / University of Bristol), Walter Chang (Adobe), Sailesh Chutani (Oracle), Dan Connolly (W3C), Ron Daniel (DATAFUSION), Charles Frankston (Microsoft), Patrick Gannon (CommerceNet), RV Guha (Epinions, previously of Netscape Communications), Tom Hill (Apple Computer), Arthur van Hoff (Marimba), Renato Iannella (DSTC), Sandeep Jain (Oracle), Kevin Jones, (InterMind), Emiko Kezuka (Digital Vision Laboratories), Joe Lapp (webMethods Inc.), Ora Lassila (Nokia Research Center), Andrew Layman (Microsoft), Ralph LeVan (OCLC), John McCarthy (Lawrence Berkeley National Laboratory), Chris McConnell (Microsoft), Murray Maloney (Grif), Michael Mealling (Network Solutions), Norbert Mikula (DataChannel), Eric Miller (OCLC), Jim Miller (W3C, emeritus), Frank Olken (Lawrence Berkeley National Laboratory), Jean Paoli (Microsoft), Sri Raghavan (Digital/Compaq), Lisa Rein (webMethods Inc.), Paul Resnick (University of Michigan), Bill Roberts (KnowledgeCite), Tsuyoshi Sakata (Digital Vision Laboratories), Bob Schloss (IBM), Leon Shklar (Pencom Web Works), David Singer (IBM), Wei (William) Song (SISU), Neel Sundaresan (IBM), Ralph Swick (W3C), Naohiko Uramoto (IBM), Charles Wicksteed (Reuters Ltd.), Misha Wolf (Reuters Ltd.), Lauren Wood (SoftQuad).
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.
None.
None.
The RDF/XML syntax can't represent an an arbritary graph structure.
On 26th July 2002, the WG decided to re-open this issue and accept the proposal (as amended) to add an rdf:nodeID to the syntax for specifying blank nodes in triple subject and object positions.
On 26th October 2001, the WG decided that this issue was postponed for consideration by a future Working Group.
Action: Added constraint constraint-nodeID and Production nodeIdAttr, and amended productions syntaxTerms, nodeElement and emptyPropertyElt to take rdf:nodeID.
Should the rdf: and/or rdfs: namespace URI refs be changed?
On 17th June 2002, the RDFCore WG resolved to modify the existing RDF and RDFS namespaces rather than create new ones and seek implementor feedback on this decision.
Action: None needed.
The ordinal property representation of containers does not support recursive processing of containers in languages such as Prolog.
On 31st May 2002 the WG resolved:
Action: Added 7.2.17 Production parseTypeCollectionPropertyElt, 7.2.28 Production parseCollection and updated 7.2.12 Production propertyElt to use this.
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
may a container have duplicate containerMembership properties?
On 3rd May 2002, the WG resolved:
<rdf:Bag rdf:about="http://example.org/foo"> <rdf:_1 rdf:resource="http://example.org/a" /> <rdf:_1 rdf:resource="http://example.org/b" /> </rdf:Bag>
is syntactically legal RDF.
Action: None needed.
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
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
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.
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.
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.
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.
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 needed.
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 5.1 RDF Namespace
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.
On 7th December 2001, the WG decided to remove rdf:aboutEach from the language and consequently this issue was closed.
Action: None needed.
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.
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":
Action: None needed.
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.
On 11th January 2002, the WG resolved (revised) "to not change the name of this property at this time on the grounds:
and resolves to recast the issue as a need to clarify the semantics of rdf:value."
At the February 2002 face to face meeting, the RDFCore WG resolved:
Action: None needed.
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.
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 6 Data Model near introduction of Infoset and added new Section 5.3 Base URIs
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.
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 7.2.19 Production emptyPropertyElt and Relax NG schema to reflect decision.
Why isn't xml:lang information represented within the RDF data model?
On 25th February 2002, the WG decided that this issue was closed by the following resolution.
A literal consists of three components:
Action: Added the language node term from the value of xml:lang attributes, added sections Literal Node, and XML Literal Node and updated parseTypeOtherPropertyElt for parseType.
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.
Action: Discussed in RDF Concepts and Abstract Data Model [RDF-CONCEPTS] Section 3.2.2 XML Literals and Section 4.1 Character normalization
Does the treatment of literals conform to charmod ? [CHARMOD]
On 5th April 2002, the RDFCore WG resolved this issue by approving test cases white, black 1 and black 2 submitted for consideration. The grey test cases were not approved; instead the WG decided to add text to the syntax specification pointing out that literals beginning with a combining character may not be serializable in RDF/XML, depending on the outcome of [CHARMOD], and may cause interoperability problems.
Action: Notes added: 1, 2
Discussed in RDF Concepts
and Abstract Data Model [RDF-CONCEPTS] Section 4.1
Character normalization
Does the treatment of uri-references conform with charmod? [CHARMOD]
On 26th April 2002, the WG decided to:
Action: leave URI references as un-escaped Unicode
and approved test cases, later moved into the rdf-charmod-literals test cases area.
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 needed.
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 needed.
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 needed.
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.
This is an example schema in RELAX NG Compact (for ease of reading) but applications can also use the RELAX NG XML version. These formats are described in RELAX NG ([RELAXNG]) and RELAX NG Compact ([RELAXNG-COMPACT]).
# # 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 }* }
Two schema language authors submitted schemas for RDF/XML based on the new grammar in previous versions of this draft. The pointers to these schemas are included here for information purposes only; they are not part of this specification.
Changes since the 25 March 2002 working draft
(Newest at top)
rdf:nodeID
allows many more
graphs to be serialized.Changes since the 18 December 2001 working draft
(Newest at top)
Changes since the 06 September 2001 working draft