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

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.

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

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:

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

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.

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.

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:

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.

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:

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:CollectionSuggest change example to avoid confusin with
parseType="Collection".

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.

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.

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.

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:

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.

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.

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.

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

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.

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.

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.

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

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

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.

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 generates a different RDF graph. See
also the Skolemization section
of the RDF Model Theory[RDF-MODEL] Working Draft.

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.

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.

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.

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.

Set from the ·attributes· as described above. If no value is given
from the attributes, the value is set to the value of the language
accessor on the parent event (either a Root Event or an Element Event), which may be
undefined.

set to the value of the attribute information item property
[normalized value] as specified by [XML] (if an
attribute whose normalized value is a zero-length string, then the
string-value is also a zero-length string).

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

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:

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.

If the RDF/XML is a standalone XML document (known by having been given
the RDF MIME Type) then the grammar starts
with Root Eventdoc.

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

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:

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.

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.

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:

Use property names that cannot be turned into XML namespace-qualified
names.

An XML namespace-qualified name (QName) has
restrictions on the legal characters such that not all property URIs
can be expressed as these names. 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, ensuring that the first character of the name is a Letter or '_'. If the
URI ends in a non-Name character
then throw a "this graph cannot be serialized in RDF/XML" exception or
error.

Use inappropriate reserved names as properties

For example, a property with the same URI as any of the syntaxTerms production.

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

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.

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.

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

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

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.

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

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.

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.

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

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]

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.

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.

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

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.

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 i.e. CONFORMANCE
should be tested without comments; dropping comments was NOT
mandatory.

this issue is closed

to raise a comment on the XQuery/XPath 2.0 data model that it
does not adequately address the handling of namespace prefixes
appearing in attribute values.

On 5th April 2002, the RDFCore WG resolved this issue by approving
test cases white,
black
1 and black
2submitted
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.

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.

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.2 Other
Syntax Schemas (Non-Normative)

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.