This editors version of a
W3C Working Draft revises the specification of the XML syntax
of RDF as originally described in
RDF Model & Syntax.
This document presents the syntax as amended and clarified by the
RDF Core Working Group
with the specification now based on the
XML Information Set
along with mapping rules for creating RDF models as described in the
RDF Model Theory
W3C Working Draft.
This section describes the status of this document at the time
of its publication. Other documents may supersede this document. The
latest status of this document series is maintained at the W3C.
This is the editors working draft of the W3C Working Draft for the
RDF Core Working Group
produced as part of the W3C
Semantic Web Activity.
It incorporates decisions made by the Working Group
updating the XML syntax for RDF from the original
RDF Model & Syntax ([RDFMS]) document
and includes a re-representing of the syntax in terms
of the
XML Information Set
with rules for generation of RDF models.
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. This is the current state of an ongoing work on the
syntax and mapping process and may not yet record all of the work
in the
grammar section
of the original document.
This is a draft document and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use it as reference
material or to cite as other than "work in progress". A list of current
W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.
Comments on this document are invited and should be sent to the
public mailing list
www-rdf-comments@w3.org.
An archive of comments is available at
http://lists.w3.org/Archives/Public/www-rdf-comments/.
This document describes the
XML
([XML])
syntax for RDF as
originally defined in the
RDF Model & Syntax ([RDFMS]) W3C
Recommendation. Subsequent implementations of this syntax and
comparison of the resulting RDF models have shown that there was
ambiguity - implementations generated different models 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 model 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 WG issues list.
This document re-represents the original EBNF grammar in terms of
the XML Information Set
([INFOSET]) items which moves
from the rather low-level details, such as particular forms of empty
elements. This allows the grammar to be more precisely recorded and
the mapping from the XML syntax to the RDF model more clearly shown.
The mapping to the RDF model 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 model, that has semantics defined by
RDF Model Theory ([RDF-MODEL]) Working Draft.
This document illustrates one way to create the N-Triples from the
XML - any other method that results in the same N-Triples (RDF model)
may be used.
In particular:
- The N-Triples may be generated in any order
- Duplicates may be eliminated at any point
- There is no requirement to support N-Triples in any way
The
RDF Model Theory ([RDF-MODEL]) provides a formal description
of RDF. This can be thought of as a graph consisting of nodes
and arcs. The node
describe resources that can be labelled with URIs, string literals
or are blank. The arcs connect the nodes and are all
labelled with URIs. This graph is more precisely called a directed
edge-labelled graph; each edge is an arc with a direction (an arrow)
connecting two nodes. These edges can be described as triples of
subject node, at the blunt end of the arrow/arc,
property arc and an object node at the sharp end of
the arrow/arc. The property arc is also interpreted as an attribute,
relationship or predicate of the resource with a value given by the
object node content.
In order to encode the graph in XML, the nodes and arcs are turned
into XML elements, attributes, element content and attribute values.
The URI labels for properties and object nodes are written in XML via
XML Namespaces ([XML-NS])
which gives a namespace URI for a short prefix
along with namespace-qualified elements and attributes names
called local names. The (namespace URI, local name) pair
are chosen such that concatenating them forms the original node URI.
The URIs labelling subject nodes are stored in XML attribute values.
The nodes labelled by string literals (which are always
object nodes) become element text content or attribute values.
This transformation turns paths in the graph of the form
Node, Arc, Node, Arc, Node, Arc, ...
into sequences of elements inside elements. This
results in a striping when the elements are written down;
alternating between node elements and
property elements. The Node at the
start of the sequence is always a subject node and turns into
a containing element called an rdf:Description that
is written at the top level of RDF/XML, below the XML document element
(in this case rdf:RDF). So the chains of stripes
start at the top of an RDF/XML document and always begin with nodes.
For example, Figure 1 below a graph written as ASCII saying:
there exists a document (this one) with a title, "RDF/XML Syntax Specification
(Revised)" and this document has an editor, the editor has a name
"Dave Beckett" and a home page http://purl.org/net/dajobe/.
Where the nodes are represented as ovals and contain
their URI if it is known,
the properties such as "has an editor" have been given URIs
and these have been used to label the appropriate arc,
and the strings have been written in rectangles.
If we take the path through the graph shown in
Figure 2:
This corresponds to the node/arc stripes:
- Node
[http://www.w3.org/TR/rdf-syntax-grammar]
- Arc
-[http://example.org/stuff/1.0/editor]->
- Node
[]
- Arc
-[http://example.org/stuff/1.0/homePage]->
- Node
[http://purl.org/net/dajobe/]
In RDF/XML this sequence of 5 nodes and arcs corresponds to 5
XML elements:
<rdf:Description>
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description>
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
Which consists of some nodes with known URIs that can be filled in
and others that remain blank:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description rdf:about="http://purl.org/net/dajobe/">
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
There are several abbreviations that can be used to make very
common uses more easy to write down. It is typical for the same
resource to be described with multiple properties and values at the
same time, so multiple child elements can be put inside
rdf:Description, all of which are properties of that
node.
When the property value is a string it can be encoded more simply
as an XML attribute and value, as an attribute of the node element.
This is known as a property attribute.
Another very common use is when a node is an instance of a class
with rdf:type relationship, usually called a typed
node. This shorthand is done by replacing the
rdf:Description element name with the namespaced-element
corresponding to the URI of the value of the type relationship.
The above forms the basis of the RDF/XML syntax and although there
are some other abbreviated forms, such as for generating the RDF list
properties and for skipping having to write down a blank element
node, which breaks the striping but is useful for, amongst other
uses, encoding properties with multiple-values.
The example above filled out and completed, using some
abbreviations gives:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
<ex:editor rdf:parseType="Resource">
<ex:fullName>Dave Beckett</ex:fullName>
<ex:homePage rdf:resource="http://purl.org/net/dajobe/" />
</ex:editor>
</rdf:Description>
</rdf:RDF>
For a longer introduction to the RDF/XML striped syntax
with a historical perspective, see RDF: Understanding the Striped RDF/XML Syntax ([STRIPEDRDF]).
Note:
This section is still under development and the working group
is working on an RDF primer document.
This syntax operates on an XML document as a sequence of nodes
in document order in the style of
[XPATH]
Information Set Mapping
serialised into document-order.
The resulting nodes are intended to be similar to the events that are
produced by the [SAX2] XML API.
This model is conceptual only and does not mandate any
implementation method; in particular the use
of [XPATH] or [SAX2]
is not required.
The syntax does not support non-well-formed XML documents, nor
documents that otherwise don't have an XML Information Set; for
example, that don't conform to
XML Namespaces
W3C Recommendation ([XML-NS]).
The Infoset requires supports for
XML Base[XML-BASE]
which generates information item properties [base URI] below.
The use this property in RDF/XML is discussed in
section 3.10
This specification requires an information set as defined in
[INFOSET]
which supports at least the following information items and
properties for RDF/XML:
- Document Information Item
- [document element], [children], [base URI]
- Element Information Item
- [local name], [namespace name], [children], [attributes], [parent], [base URI]
- Attribute Information Item
- [local name], [namespace name], [normalized value], [owner element]
- Character Information Item
- [character code]
- Processing Instruction Information Item
- Not used
- Unexpanded Entity Reference Information Item
- Not used
- Comment Information Item
- Not used
- Document Type Declaration Information Item
- Not used
- Unparsed Entity Information Item
- Not used
- Notation Information Item
- Not used
- Namespace Information Item
- Not used
There are six types of node defined in the following subsections.
Most nodes are constructed from an Infoset information item (except
for Identifier). The effect
of a node constructor is to create a new node with a unique identity,
distinct from all other nodes. Nodes have properties, and all have
the string-value property that may be part of the node or
computed from the string-value of contained nodes.
Created from an
Document Information Item
and takes the following properties and their values from the element
information item:
document-element,
children and
base-uri.
The property
language is
set to the empty string.
Created from an
Element Information Item
and takes the following properties and their values from the element
information item: local-name, namespace-name, children,
attributes,
parent and base-uri.
When this node is created from such values, the
URI property
is defined with a string value of the concatenation of the
value of the namespace-name property and the value of the
local-name property.
On creation the
li-counter
and
bag-li-counter
properties are added with initial integer values 1.
On creation, if the
·attributes·
property contains an attribute node xml:lang (that is,
the local-name property of the attribute has value "lang" and
the namespace-name property of the attribute has value
"http://www.w3.org/XML/1998/namespace")
then that attribute is removed from the list of attributes and the property
·language·
on the element node is set to the string-value of the attribute. If
no such attribute is present, the property language on the element
node is set to the value of the language property on the parent
node.
The
subject
property may be added and takes the value of an
Identifier node.
This is used on elements that deal with one node in the RDF model,
this generally being the subject of a statement.
Takes no properties but marks the end of the containing element in
the sequence.
Created from an
Attribute Information Item
and takes the properties
local-name, namespace-name and owner element
and their values from respective element information item properties.
When this node is created from such values, two properties and values
are defined. Firstly the
string-value
property
is defined with the normalized value as specified by
[XML]. An attribute whose normalized
value is a zero-length string is not treated specially: it results in
an attribute node whose string-value is a zero-length string.
Secondly the
·URI· property
is defined with a string value of the concatenation of the
value of the namespace-name property and the value of the
local-name property.
Created from a sequence of one or more consecutive
Character Information Items.
Has the single property
·string-value·
which has the value of the string made from concatenating the
character code property of each of the character information items.
[NOTE: Identical to XPath.]
A node for a typed identifier which can have the following three properties:
·identifier·,
·identifier-type· and
·string-value·.
These nodes are created by giving two values
for the ·identifier· and
·identifier-type· properties.
The
identifier
property takes a string value and the
identifier-type
property can take values "URI" or "bnodeID".
The ·string-value· property
is defined from the other properties as follows: If
·identifier-type· is "URI"
then the value is the concatenation of "<",
the value of the
·identifier· property
and ">". If
·identifier-type· is "bnodeID"
then the value is the concatenation of "_:" and
the value of the ·identifier·
property.
For further information on identifiers in the RDF model, see
section 3.9.
A node for a literal which can have the following three properties:
literal-value,
literal-language and
·string-value·.
These nodes are created by giving two values
for the ·literal-value· and
·literal-language· properties
which both take string values.
The ·string-value· property
is defined from the other properties as follows: If
·literal-language· is empty
then the value is the concatenation of """,
the value of the
·literal-value· property
and """. Otherwise
the value is the concatenation of """,
the value of the
·literal-value· property
""-",
and the value of the
·literal-language· property.
A node for an XML literal which can have the following three properties:
·literal-value·,
·literal-language· and
·string-value·.
These nodes are created by giving two values
for the ·literal-value· and
·literal-language· properties
which both take string values.
The ·string-value· property
is defined from the other properties as follows: If
·literal-language· is empty
then the value is the concatenation of "xml"",
the value of the
·literal-value· property
and """. Otherwise
the value is the concatenation of "xml"",
the value of the
·literal-value· property
""-",
and the value of the
·literal-language· property.
To transform the Infoset into the sequence of nodes, each
information item is transformed as described above to generate a
tree of nodes with properties and values. Each element node is
then replaced as described below to turn the tree of nodes
into a sequence in document order.
- The original element node
- The value of the
children
property, a possibly empty ordered list of nodes.
- An end element node
The Internet Media Type / MIME type for RDF is
"application/rdf+xml" -
see RFC 3032
(RFC3023) 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
this is not required. The namespace contains the following names only:
RDF Description
ID about bagID parseType resource
subject predicate object
Seq Bag Alt Statement Property
type value
li _n
where n is a non-negative integer.
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
Implementors Note:
The names aboutEach and aboutEachPrefix were removed
from the language by the RDF Core WG - see the issues
rdfms-abouteach and
rdfms-abouteachprefix
for further information.
The RDF model uses three types of identifiers (or labels) for
nodes and arcs in the graph - absolute URI references, literals and
unlabelled or blank nodes. The latter are given local identifiers
in the N-Triples serialisation of the model in order to represent
the graph correctly. These identifiers can be generated and must
match the name
production in
N-Triples.
The URI references can be either given as absolute URIs, relative
URIs that have to be resolved to the in-scope base URI
as described in section section 3.10,
or constructed.
The constructed URIs in RDF are either made from XML Namespace
qualified element or attributes names (QNames) or from the value of
rdf:ID or rdf:bagID attribute values.
XML QNames give URIs by concatenating the namespace URI and
the XML local name. For example, if the XML Namespace prefix
foo has URI http://example.org/somewhere/ then the QName
foo:bar would correspond to the URI
http://example.org/somewhere/bar. Note that this restricts which
URIs can be made and the same URI can be given in multiple ways.
The rdf:ID and rdf:bagID values generate URIs by considering them
as equivalent to the relative URI "#" concatenated with the attribute
value. This can then be resolved relative to the in-scope base URI
as described in section section 3.10.
RDF/XML supports
XML Base[XML-BASE]
by being based on the
XML Information Set
([INFOSET]).
This defines a
·base-uri·
property for each
·root node· and
·element node·.
NOTE: RDF/XML uses URI-references throughout
and applies the in-scope Base URI to resolve both URI
document references of the form "#frag"
and self document references of the form "".
NOTE: An empty same document reference ""
resolve against the URI part of the Base URI; any fragment part
is ignored. See
Uniform Resource Identifiers (URI) ([URIS]) section 4.2
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.
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 following notation is used for describing the nodes and grammar EBNF.
Notation for nodes and grammar EBNF.
| Notation |
Meaning |
| A = B |
A is equal to B |
| A != B |
A is not equal to B |
| A := B |
Assigns A the value B |
| node.property |
Returns the value of the given node property |
root(prop1=value1,
prop2=value2, ...) |
A root node with properties
|
start_element(prop1=value1,
prop2=value2, ...)
children
end_element() |
A sequence of
element node with properties,
a possibly empty list of nodes as element content and an
end element node
|
attribute(prop1=value1,
prop2=value2, ...) |
An attribute node
with properties |
identifier(prop1=value1,
prop2=value2, ...) |
An identifier node
with properties |
| text() |
A text node |
literal(prop1=value1,
prop2=value2, ...) |
A literal node with properties |
xml(prop1=value1,
prop2=value2, ...) |
An XML literal node with properties |
| list(item1, item2, ...); list() |
An ordered list of items in document order; an empty list |
| set(item1, item2, ...); set() |
An unordered set of items; an empty set |
| * |
Zero or more of preceding term |
| ? |
Zero or one of preceding term |
| + |
One or more of preceding term |
| A | B | ... |
The A, B, ... terms are alternatives. |
| A - B |
The term A but not the term B |
| "ABC" |
A string of characters A, B, C in order. |
| concat(A, B, ..) |
A string created by concatenating the terms in order. |
| anyURI |
Any legal URI. |
| anyString |
Any string. |
| rdf:X |
See section 3.4 |
The following notation forms are used to indicate
A grammar production over a sequence of nodes derived from the
Infoset
in the notation described in section
4.2.
A sequence of lines of
N-Triples output
from a grammar production adding to an RDF model.
| 5.2 doc | root(document-element=RDF,
children=list(RDF)) |
| 5.3 RDF | start_element(URI = rdf:RDF,
attributes=set())
nodeElementList
end_element() |
| 5.4 nodeElementList | ws* (nodeElement ws* )* |
| 5.5 nodeElement | start_element(URI=anyURI - ( rdf:RDF | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource | rdf:li )
attributes=set((idAttr | aboutAttr )?, bagIdAttr?, propertyAttr*))
propertyEltList
end_element() |
| 5.6 ws | White space as defined by
[XML] definition White Space
Rule [3] S
in section
Common Syntactic Constructs |
| 5.7 propertyEltList | ws* (propertyElt ws* ) * |
| 5.8 propertyElt | resourcePropertyElt |
literalPropertyElt |
parseTypeLiteralPropertyElt |
parseTypeResourcePropertyElt |
parseTypeOtherPropertyElt |
emptyPropertyElt |
| 5.9 resourcePropertyElt | start_element(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource ),
attributes=set(idAttr?))
ws* nodeElement ws*
end_element() |
| 5.10 literalPropertyElt | start_element(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource ),
attributes=set(idAttr?))
text()
end_element() |
| 5.11 parseTypeLiteralPropertyElt | start_element(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource ),
attributes=set(idAttr?, parseLiteral))
literal
end_element() |
| 5.12 parseTypeResourcePropertyElt | start_element(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource ),
attributes=set(idAttr?, parseResource))
propertyEltList
end_element() |
| 5.13 parseTypeOtherPropertyElt | start_element(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource ),
attributes=set(idAttr?, parseOther))
propertyEltList
end_element() |
| 5.14 emptyPropertyElt | start_element(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource ),
attributes=set(idAttr? resourceAttr?, bagIdAttr?, propertyAttr*))
end_element() |
| 5.15 idAttr | attribute(URI = rdf:ID,
string-value=rdf-id) |
| 5.16 aboutAttr | attribute(URI = rdf:about,
string-value=URI-reference) |
| 5.17 bagIdAttr | attribute(URI = rdf:bagID,
string-value=rdf-id) |
| 5.18 propertyAttr | attribute(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource | rdf:li ),
string-value=anyString) |
| 5.19 resourceAttr | attribute(URI = rdf:resource,
string-value=URI-reference) |
| 5.20 parseLiteral | attribute(URI = rdf:parseType,
string-value="Literal") |
| 5.21 parseResource | attribute(URI = rdf:parseType,
string-value="Resource") |
| 5.22 parseOther | attribute(URI = rdf:parseType,
string-value=anyString - ("Resource" | "Literal") ) |
| 5.24 literal | 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 |
If the RDF/XML is a standalone XML content, then
the grammar starts with Root Node
doc.
If the content is known to be RDF/XML by context, such as when
RDF/XML is embedded inside other XML content, then the grammar
can either start
at Element Node
RDF
(only when an element is legal at that point in the XML)
or at production nodeElementList
(only when element content is legal, since this is a list of elements).
For such embedded RDF/XML, the
·base-uri·
value on the outermost element must be initialised from the containing
XML since no
Root Node will be available.
Note that if such embedding occurs, the grammar may be entered
several times but no state is expected to be preserved.
For element e, the processing of some of the attributes
have to be done before other work such as dealing with children nodes
or other attributes. These can be processed in any order:
The following can then be performed in any order:
If an attribute a with
a.URI = rdf:bagID
is present,
n := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI")
then in any order:
S5 Add the following statement to the model:
n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag> .
-
For the generated statements above
(excluding S5)
in the following order
- S1
- Statements from S2 and S3 in any order
- Statements generated by the propertyEltList children by S4 in document order
If the statement was generated by
S4 from a
propertyElt
and has an existing identifier
e.subject
then s := e.subject.
Otherwise generate a local blank node identifier i
and s := identifier(identifier=i, identifier-type="bnodeID")
Then reify the statement with node s using the reification
rules in section 5.26
and apply the bag expansion rules in
section 5.28
on node n to give a URI u. Then
the following statement is added to the model:
If element e has e.URI =
rdf:li then apply the list expansion rules on element e.parent in
section 5.27
to give a new URI u and
e.URI := u.
For element e, and the single contained nodeElement n
the following statement is added to the model:
If the rdf:ID attribute a is given, the above
statement is reified with
i := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI")
using the reification rules in
section 5.26
and e.subject := i
start_element(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource ),
attributes=set(idAttr?))
text()
end_element()
For element e, and the text node t
then o := literal(literal-value=t.string-value, literal-language=e.language)
and the following statement is added to the model:
If the rdf:ID attribute a is given, the above
statement is reified with
i := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI")
using the reification rules in
section 5.26
and e.subject := i.
For element e and the literal l,
then o := xml(literal-value=l.string-value, literal-language=e.language)
and the following statement is added to the model:
If the rdf:ID attribute a is given, the above
statement is reified with
i := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI")
using the reification rules in
section 5.26
and e.subject := i.
Open Issue:
The result of a literal from
rdf:parseType="Literal" content has been generally decided by the RDF
Core WG but all the cases have not been entirely resolved at this
time. The solution will be based on serialising the XML element
content in l to a string in a form defined by
Exclusive XML Canonicalisation W3C Candidate Recommendation
For element e with possibly empty element content c.
Generate a local blank node identifier i
and n := identifier(identifier=i, identifier-type="bnodeID").
Add the following statement to the model:
If the rdf:ID attribute a is given, the
statement above is reified with
i := identifier(identifier=concat(e.base-uri, "#", a.string-value), identifier-type="URI")
using the reification rules in
section 5.26
and e.subject := i.
If the element content c is not an empty, then use node
n to create a new sequence of nodes as follows:
Then
process the resulting sequence using production
nodeElement.
rdf:parseType attribute values other than the strings
"Resource" or "Literal" are treated as if the value was
"Literal". Processing MUST continue at production
parseTypeLiteralPropertyElt.
-
If there are no attributes or only the
optional rdf:ID attribute i
then o := literal(literal-value="", literal-language=e.language)
and the following statement is added to the model:
and then if i is given, the above statement is reified with
identifier(identifier=concat(e.base-uri, "#", i.string-value), identifier-type="URI")
using the reification rules in
section 5.26.
-
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 model:
and then if rdf:ID attribute i is given, the above statement is
reified with
identifier(identifier=concat(e.base-uri, "#", i.string-value), identifier-type="URI")
using the reification rules in
section 5.26.
-
For all propertyAttr a (in any order)
If node n is given then
generate a local blank node identifier i
and s := identifier(identifier=i, identifier-type="bnodeID").
Each statement above is then reified with node s
using the reification rules in
section 5.26
and the bag expansion rules in
section 5.28
is applied on node n to give URI u. Then
the following statement is added to the model:
If node n was created, add the following statement to the model:
n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag> .
Constraint:
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 property 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.
attribute(URI=anyURI - ( rdf:RDF | rdf:Description | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource | rdf:li ),
string-value=anyString)
For a statement with terms s, p and o
corresponding to the N-Triples:
add the following statements to the model using the given
Identifier Node r:
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.
It is not possible for all graphs that can be expressed in the
RDF Model Theory ([RDF-MODEL]) to be encoded
in this syntax. If you do a round trip from RDF/XML to RDF graph
and then back to RDF/XML the meaning will be the same but don't
expect the RDF/XML that comes out to be exactly the same.
There are two different approaches to serialising RDF.
The basic approach uses the basic RDF syntax from
[RDFMS]. In this:
- All blank nodes are assigned arbitrary URIs.
- Each resource is listed in turn as the subject of a top-level
rdf:Description element, using an rdf:about
attribute.
For each triple, with this resource as subject, an appropriate
property element production is used, with either string content
(possibly empty) or an rdf:resource attribute specifying
the object of the triple.
The basic serialisation is recommended for applications in which
the output RDF/XML is to be used only in further RDF processing.
Where the intent is for the output RDF/XML file to be read by people, the
basic serialisation proves unsatisfactory.
The basic serialisation does not conform to more restricted
sub-dialects of RDF, such as RSS[RSS] or
CC/PP[CC/PP].
Hence, it is not appropriate for such applications, for which dialect
specific serialisers are needed.
If more human readable output is needed the following factors
should be considered:
- There are many choices, with many RDF/XML documents corresponding
to identical RDF graphs. Individual triples can be represented in
numerous ways. High quality RDF serialisation requires that these
choices are considered by the serialising code. Some are more
appropriate than others in an application dependent fashion.
- The triples in the graph need to be considered in an appropriate
order. There are many choices of order, some being more appropriate
than others in an application dependent fashion.
It is not possible to use the RDF/XML serialisation for
serialising an RDF graph in which any triple has a property label
which cannot be expressed as a XML namespace-qualified name
(QName).
It is recommended that implementors of RDF serializers in order to
break a URI into a namespace name and a local name, split it after
the last XML non-Name
character. If the URI ends in a
non-Name
character then throw a "this graph cannot be serialized in RDF
1.0" exception or error.
An approach to serialising RDF/XML using the full grammar in a
top-down recursive descent fashion is discussed in
[UNPARSING].
7 Acknowledgments (Informative)
The following people provided valuable contributions to the document:
- Dan Brickley, W3C/ILRT
- Jeremy Carroll, HP Labs Bristol
8 References
Normative References
-
[RDFMS]
-
Resource Description Framework (RDF) Model and Syntax Specification, O. Lassila and R. Swick, Editors. World Wide Web Consortium. 22 February 1999. This version is http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. The latest version of RDF M&S is available at http://www.w3.org/TR/REC-rdf-syntax.
-
[XML]
-
Extensible Markup Language (XML) 1.0, Second Edition, T. Bray, J. Paoli, C.M. Sperberg-McQueen and E. Maler, Editors. World Wide Web Consortium. 6 October 2000. This version is http://www.w3.org/TR/2000/REC-xml-20001006. latest version of XML is available at http://www.w3.org/TR/REC-xml.
-
[XML-NS]
-
Namespaces in XML, T. Bray, D. Hollander and A. Layman, Editors. World Wide Web Consortium. 14 January 1999. This version is http://www.w3.org/TR/1999/REC-xml-names-19990114. The latest version of Namespaces in XML is available at http://www.w3.org/TR/REC-xml-names.
-
[INFOSET]
-
XML Information Set, J. Cowan and R. Tobin, Editors. World Wide Web Consortium. 24 October 2001. This version is http://www.w3.org/TR/2001/REC-xml-infoset-20011024. The latest version of XML Information set is available at http://www.w3.org/TR/xml-infoset.
-
[URIS]
- RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding and L. Masinter, IETF, August 1998. This document is http://www.isi.edu/in-notes/rfc2396.txt.
-
[RDF-TESTS]
- RDF Test Cases, A. Barstow and D. Beckett, Editors. Work in progress. World Wide Web Consortium, 15 November 2001. This version of the RDF Test Cases is http://www.w3.org/TR/2001/WD-rdf-testcases-20011115/. The latest version of the RDF Test Cases is at http://www.w3.org/TR/rdf-testcases.
-
[RDF-MODEL]
-
RDF Model Theory, P. Hayes, Editor. Work in progress. World Wide Web Consortium, 14 February 2002. This version of the RDF Model Theory is http://www.w3.org/TR/2001/WD-rdf-mt-20010925. The latest version of the RDF Model Theory is at http://www.w3.org/TR/rdf-mt/.
-
[KEYWORDS]
-
RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF. March 1997. This document is http://www.ietf.org/rfc/rfc2119.txt.
-
[RFC3023]
-
RFC 3032 - XML Media Types, M. Murata, S. St.Laurent, D.Kohn, IETF. January 2001. This document is http://www.ietf.org/rfc/rfc3023.txt.
-
[XML-BASE]
-
XML Base, J. Marsh, Editor, W3C Recommendation. World Wide Web Consortium, 27 June 2001. This version of XML Base is http://www.w3.org/TR/2001/REC-xmlbase-20010627/. The latest version of XML Base is at http://www.w3.org/TR/xmlbase/.
-
[CHARMOD]
-
Character Model for the World Wide Web 1.0, M. Dürst, F. Yergeau, R. Ishida, M. Wolf, A. Freytag, T Texin, Editors, World Wide Web Consortium Working Draft, work in progress, 20 February 2002. This version of the Character Model is http://www.w3.org/TR/2002/WD-charmod-20020220/. The latest version of the Character Model is at http://www.w3.org/TR/charmod/.
Informational References
-
STRIPEDRDF
- RDF: Understanding the Striped RDF/XML Syntax, D. Brickley, W3C, 2001. This
document is http://www.w3.org/2001/10/stripes/.
-
XPATH
- XML Path Language (XPath) Version 1.0, J. Clark and S. DeRose, Editors. World Wide Web Consortium, 16 November 1999. This version of XPath is http://www.w3.org/TR/1999/REC-xpath-19991116. The latest version of XPath is at http://www.w3.org/TR/xpath.
-
SAX2
- SAX Simple API for XML, version 2, D. Megginson, SourceForge, 5 May 2000. This document is http://sax.sourceforge.net/.
-
RSS
- RDF Site Summary (RSS) 1.0, G. Beged-Dov, D. Brickley, R. Dornfest, I. Davis, L. Dodds, J. Eisenzopf, D. Galbraith, R.V. Guha, K. MacLeod, E. Miller, A. Swartz, E. van der Vlist, 2000. This document is http://purl.org/rss/1.0/spec.
-
CC/PP
- Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies, G. Klyne, F. Reynolds, C. Woodrow, H. Ohto, World Wide Web Consortium Working Draft, work in progress, 15 March 2001. This version is http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/. The latest version of CC/PP structure and Vocabularies is available at http://www.w3.org/TR/CCPP-struct-vocab.
-
UNPARSING
- Unparsing RDF/XML, J. J. Carroll, HP Labs Technical Report, HPL-2001-294, 2001.
This document is available at http://www.hpl.hp.com/techreports/2001/HPL-2001-294.html.
-
RELAXNG
- RELAX NG Specification, James Clark and MURATA Makoto, editors, OASIS, 3 December 2001. This version of RELAX NG is http://www.oasis-open.org/committees/relax-ng/spec-20011203.html. The latest is at http://relaxng.org/.
-
RELAXNG-NX
- RELAX NG Non-XML Syntax, James Clark, 3 December 2001. This document is http://www.thaiopensource.com/relaxng/nonxml/.
-
XML Schema Part 0: Primer
-
XML Schema Part 0: Primer - W3C Recommendation, World Wide Web Consortium, 2 May 2001.
-
XML Schema Part 1: Structures
-
XML Schema Part 1: Structures - W3C Recommendation, World Wide Web Consortium, 2 May 2001.
-
XML Schema Part 2: Datatypes
-
XML Schema Part 2: Datatypes - W3C Recommendation, World Wide Web Consortium, 2 May 2001.
-
Schematron
- Schematron, Rick Jelliffe, Academia Sinica Computing Centre, Taibei.
This section records local issues to be resolved
and issues that were reported to the RDF Core WG
related to the XML syntax and their disposition. This section is not
the definitive list or description of the latter - see the
RDF Core WG issues list.
Decided issues may also have associated test cases which can be
found in the RDF Test Cases
W3C Working Draft.
- task-striping
-
Add more an introductory section on how the syntax works including
examples (graph, XML elements) based on
the descriptive version in Dan Brickley's
RDF: Understanding the Striped RDF/XML Syntax
- task-infoset
-
(Feedback on 2001-12-18 draft): Consider basing on Infoset rather than SAX
- task-renaming
-
(Feedback on 2001-12-18 draft): Consider changing nodeset terms to be, for example, events
to prevent confusion with RDF graph nodes.
- task-intro
-
(Feedback on 2001-12-18 draft): Better introduction text
with respect to RDF model, graph, model theory, N-Triples.
- rdf-charmod-uris
-
Does the treatment of literals conform to charmod ? [CHARMOD]
Action:
?
- rdf-charmod-uris
-
Does the treatment of uri-references conform with charmod? [CHARMOD]
Action:
?
- rdf-ns-prefix-confusion
-
On 25th May 2001, the WG decided that ALL attributes must be namespace qualified. There is a description of the decision, including detail on the grammar productions affected and a collection of test cases
Action:
Removal of original grammar productions 6.6, 6.7, 6.8, 6.9, 6.11, 6.18, 6.32, 6.33
- rdfms-abouteachprefix
-
On 1st June 2001, the WG decided that aboutEachPrefix would be
removed from the RDF Model and Syntax Recommendation on the grounds
that there is a lack of implementation experience, and it therefore
should not be in the recommendation. A future version of RDF may
consider support for this feature.
Action:
Removal of original grammar production 6.8
- rdf-containers-syntax-ambiguity
rdf-containers-syntax-vs-schema
-
On 29th June 2001, the WG decided that containers will match the typed node production in the grammar (production 6.13) and that the container specific productions (productions 6.25 to 6.31) and any references to them be removed from the grammar. rdf:li elements will be translated to rdf:_nnn elements when they are found matching either a propertyElt (production 6.12) or a a typedNode (production 6.13). The decision includes a set of test cases.
Action:
Removal of original grammar productions 6.25, 6.26, 6.27, 6.28, 6.29, 6.30, 6.31
- rdfms-empty-property-elements
-
On 8th June 2001 the WG decided how empty property elements should be interpreted. The decision is fully represented by the test cases.
Action:
Inserted pointers to the the test cases into the grammar at the
places where empty property elements are recognised.
- rdfms-aboutEach-on-object
-
On 29th June 2001, the WG decided that rdf:aboutEach attributes
are not allowed on an rdf:Description (or typed node) element which
is the object of a statement.
Action:
None needed - rdf:aboutEach removed from the language on 7th December 2001.
- rdfms-syntax-desc-clarity
-
The language describing the syntax is unclear [in section 6]
On 26th October 2001, the WG
decided that this issue is closed by the new approach
to defining the syntax in this document.
Action:
A main goal of this document is to make the syntax clearer and
more precise. In particular
the grammar section and the
pointers to schemas for XML validation
help address this.
- rdfms-formal-grammar
-
A formal grammar for RDF.
On 26th October 2001, the WG
decided that this issue is closed by the new approach
to defining the syntax in this document.
Action:
A main goal of this document is to make the syntax clearer and
more precise. In particular
the grammar section and the
pointers to schemas for XML validation
help address this.
- rdfms-validating-embedded-rdf
-
On 9th November 2001, the RDFCore WG resolved to postpone
the issue "for later consideration on the grounds that it is out of
scope of its current charter to change the current RDF/XML syntax to
the extent necessary to address it."
Action:
None required.
- rdfms-rdf-names-use
-
On 30th November 2001, the WG
decided that this issue was closed by the following resolution.
The use of rdf:RDF, rdf:ID, rdf:about, rdf:resource, rdf:bagID,
rdf:parseType, rdf:aboutEach and rdf:li except as reserved names as
specified in the grammar is an error. [Later rdf:aboutEach was
removed from the language on 7th December 2001]
On 25th February 2002, the WG further
resolved that:.
The WG reaffirmed its decision not to restrict names in the RDF
namespaces which are not syntactic. The WG decided that an RDF
processor SHOULD emit a warning when encountering names in the RDF
namespace which are not defined, but should otherwise behave
normally.
Action:
Added note to section 3.4 RDF Namespace
- rdfms-abouteach
-
processing rdf:aboutEach requires a processing of sub-property relations.
On 7th December 2001, the WG
resolved
to remove rdf:aboutEach from the language.
Action:
Removed from the grammar.
- rdfms-propElt-id-with-dr
-
On 7th December 2001, the WG
decided
to remove rdf:aboutEach from the language and consequently
this issue was closed.
Action:
None needed.
- rdfms-difference-between-ID-and-about
-
What is the difference between using and ID attribute to 'create' a new resource and an about attribute to refer to it?
On 14th December 2001, the WG
decided that this document resolves the issue.
Action:
See section on Identifiers for details.
- rdfms-qname-uri-mapping
-
On 11th January 2002, the WG
resolved (revised) "to not change the algorithm for mapping qnames to uris and close this issue on the grounds:
- Such a change would be a major change to the mapping of
RDF/XML syntax to the model and would be beyond our charter.
- It would cause the same RDF/XML to generate a different
graph from existing versus revised implementations
- Existing code may generate wrong (illegal) graphs for some RDF/XML."
Action:
None needed.
- rdfms-reification-required
-
On 11th January 2002, the WG
resolved (revised) "that a parser is not required to create bags of reified statements for all rdf:Description elements, only those which are
explicitly reified using an rdf:ID on a propertyElt or by an rdf:bagID
on the rdf:Description.
Existing test cases such as rdf-ns-prefix-confusion
test0001 (test0001.rdf, test0001.nt)
demonstrate this resolution."
Action:
None needed - matches the existing syntax description.
- rdfms-replace-value
-
On 11th January 2002, the WG
resolved (revised) "to not change the name of this property at this time on the grounds:
- insufficient reasons to make this change
- will cause existing uses to be illegal - such as examples in M&S.
and resolves to recast the issue as a need to clarify the
semantics of rdf:value."
Action:
None needed.
- mime-types-for-rdf-docs
-
On 18th January 2002, the WG
authorised
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 based on the
Draft for RDF Media Type
registration by Aaron Swartz.
Action:
Added RDF MIME type section.
- rdfms-xml-base
-
On 18th January 2002, the WG
decided
that "xml:base be allowed, and honoured, anywhere in an RDF document".
On 25th February 2002, the WG decided
(1)
that xml:base applies to RDF's use of document references (fragments)
(2)
that xml:base hierarchical URIs without a path component shall have it
set to /.
(3)
the scope of xml:base attributes should be taken into account when checking
for duplicate rdf:ID values
Action:
Added details in
Section 3 Data Model
near introduction of Infoset and added new
Section 3.10 Base URIs
- rdfms-nested-bagIDs
-
What triples are generated for nested description elements with bagIDs?
On 25th February 2002, the WG
decided that this issue was closed by the following resolution.
A bagID reifies the property attributes on the same element as the
bagid, the type node and statements immediately arising from property
elements that are immediate children of the element containing the
bagId. In particular a property element whose statement is part of
the bag, which has property attributes, those statements are not part
of the bag.
Action:
bagID algorithm added to nodeElement
emptyPropertyElt.
- rdfms-not-id-and-resource-attr
-
The propertyElt production 6.12 of the grammar does not allow both an ID attribute and a resource attribute to be specified.
On 25th February 2002, the WG
decide that this issue was closed by making rdf:ID always specify the ID of the reified statement (parent node, property element, node).
Action:
Updated 5.14 Production emptyPropertyElt
and Relax NG schema
to reflect decision.
- rdfms-xml-literal-namespaces
-
How should a parser process namespaces in a literal which is XML markup?
On 15th March 2002, the WG
decided that this issue was closed by the following resolution.
- The exact form of the string value corresponding to any given XML
Literal within RDF/XML is implementation dependent.
- the string value is well-balanced XML
- taking the exclusive canonicalization of both the original XML
Literal in its containing document, and the string value of the
literal produce the same character string. This will be used as
the basis for test cases.
- The canonicalization above is without comments
- CONFORMANCE should be tested without comments; dropping
comments was NOT mandatory.
Action:
FIXME - todo
- rdfms-quoting
-
The syntax needs a more convenient way to express the
reification of a statement.
On 26th October 2001, the WG
decided that this issue was postponed for consideration by
a future working group.
Action:
None required.
- rdfms-qnames-cant-represent-all-uris
-
The RDF XML syntax cannot represent all possible Property URI's.
On 26th October 2001, the WG
decided that this issue was postponed for consideration by
a future working group.
Action:
None required.
- rdfms-qnames-as-attrib-values
-
Suggestion that Qnames should be allowed as values for attributes such as rdf:about.
On 26th October 2001, the WG
decided that this issue was postponed for consideration by
a future working group.
Action:
None required.
- rdfms-syntax-incomplete
-
The RDF/XML syntax can't represent an an arbritary graph structure.
On 26th October 2001, the WG
decided that this issue was postponed for consideration by
a future working group.
Action:
None required.
B Syntax Schemas (Non-Normative)
Two schema language authors submitted schemas for RDF/XML based on
the revised grammar in the previous version of this draft. We
include pointers to these schemas for information purposes and an
example schema; they are not part of this specification.
B.1
RELAX NG Schema - Non XML (Non-Normative)
This is an example schema in RELAX NG's
non-XML format (for ease of reading)
but applications should use the standard XML version.
These formats are described in
RELAX NG ([RELAXNG])
and RELAX NG
Non-XML Syntax ([RELAXNG-NX]).
#
# RELAX NG Schema (non-XML) for RDF/XML Syntax
#
# This schema is for information only and NON-NORMATIVE
#
# It is based on one originally written by James Clark in
# http://lists.w3.org/Archives/Public/www-rdf-comments/2001JulSep/0248.html
# and updated with later changes.
#
namespace local = ""
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
start = doc
doc =
RDF
RDF =
element rdf:RDF { nodeElementList }
nodeElementList =
nodeElement*
# Should be something like:
# ws* , ( nodeElement , ws* )*
# but RELAXNG does this by default, ignoring whitespace separating tags.
nodeElement =
element * - (local:*
|rdf:RDF
|rdf:ID|rdf:about
|rdf:bagID|rdf:parseType|rdf:resource
|rdf:li ) {
(idAttr | aboutAttr )?, bagIdAttr?, propertyAttr*, propertyEltList
}
# It is not possible to say "and not things
# beginning with _ in the rdf: namespace" in RELAX NG.
ws =
" "
# Not used in this RELAX NG schema; but should be any legal XML
# whitespace defined by http://www.w3.org/TR/2000/REC-xml-20001006#NT-S
propertyEltList =
propertyElt*
# Should be something like:
# ws* , ( propertyElt , ws* )*
# but RELAXNG does this by default, ignoring whitespace separating tags.
propertyElt =
resourcePropertyElt |
literalPropertyElt |
parseTypeLiteralPropertyElt |
parseTypeResourcePropertyElt |
parseTypeOtherPropertyElt |
emptyPropertyElt
resourcePropertyElt =
element * - (local:*
|rdf:RDF|rdf:Description
|rdf:ID|rdf:about
|rdf:bagID|rdf:parseType|rdf:resource) {
idAttr?, nodeElement
}
literalPropertyElt =
element * - (local:*
|rdf:RDF|rdf:Description
|rdf:ID|rdf:about
|rdf:bagID|rdf:parseType|rdf:resource) {
idAttr?, text
}
parseTypeLiteralPropertyElt =
element * - (local:*
|rdf:RDF|rdf:Description
|rdf:ID|rdf:about
|rdf:bagID|rdf:parseType|rdf:resource) {
idAttr?, parseLiteral, literal
}
parseTypeResourcePropertyElt =
element * - (local:*
|rdf:RDF|rdf:Description
|rdf:ID|rdf:about
|rdf:bagID|rdf:parseType|rdf:resource) {
idAttr?, parseResource, propertyEltList
}
parseTypeOtherPropertyElt =
element * - (local:*
|rdf:RDF|rdf:Description
|rdf:ID|rdf:about
|rdf:bagID|rdf:parseType|rdf:resource) {
idAttr?, parseOther, any
}
emptyPropertyElt =
element * - (local:*
|rdf:RDF|rdf:Description
|rdf:ID|rdf:about
|rdf:bagID|rdf:parseType|rdf:resource) {
idAttr?, resourceAttr?, bagIdAttr?, propertyAttr*
}
idAttr =
attribute rdf:ID {
IDsymbol
}
aboutAttr =
attribute rdf:about {
URI-reference
}
bagIdAttr =
attribute rdf:bagID {
IDsymbol
}
propertyAttr =
attribute * - (local:*
|rdf:RDF|rdf:Description
|rdf:ID|rdf:about
|rdf:bagID|rdf:parseType|rdf:resource
|rdf:li) {
string
}
resourceAttr =
attribute rdf:resource {
URI-reference
}
parseLiteral =
attribute rdf:parseType {
"Literal"
}
parseResource =
attribute rdf:parseType {
"Resource"
}
parseOther =
attribute rdf:parseType {
text
}
URI-reference =
string
literal =
any
IDsymbol =
xsd:NMTOKEN
any =
mixed { element * { attribute * { text }*, any }* }
B.2 Other Syntax Schemas (Non-Normative)
Two schema language authors submitted schemas for RDF/XML based on
the new grammar in the previous version of this draft. We include
pointers to these schemas for information purposes; they are not part
of this specification.
Changes since the 18 December 2001 working draft
(Newest at top)
- FIXME: To be updated to changes after CVS v1.216
- Added xml:lang support by adding a new element property, using it
throughout to generate literal() or xml() literals
- Added a grammar summary section (experimental)
- Added an explicit constraint on rdf:ID and rdf:bagID values, and with
respect to the base URI
- Updated notation for A:=B assignment, string literal and xml literals
- Removed note on propertyElt about
potential future parseTypes values
- Correct the illegal rdf:* names on node and property elements
- List all infoitems indicating ones that
are not used; and note that all infoitems must be preserved inside
parseTypeLiteral
- In rdf-id production, kept rdf:ID as XML Nmtoken
- Added style from XSD for term definition and reference
- Introduction gained pictures taken from draft primer
- Added Nodes for all SAX-like nodes
- Added rdf:bagID rules in nodeElement
and emptyPropertyElt
- Added Section 3.10 Base URIs for XML Base support, updated other sections and added to references
- emptyPropertyElt: Allow rdf:ID and rdf:resource together; updated Relax NG schema to match
- Section 3.4: Noted unknown rdf: names generate a warning
- Section 5.3: Made parseType only take "Resource", "Literal" and other values are
always the same as "Literal"
- Added Section 3.75 RDF MIME Type to note proposed mime type
- Updated issues list to record closed and postponed issues
- Removed original grammar (Appendix C), updated grammar (Appendix D) sections
Changes since the 06 September 2001 working draft
- Most of the document is new
- Original document grammar sections moved to appendices
- Expressed in more detail the use of the XML Infoset as used here
in a SAX-like manner
- Grammar updated to remove rdf:aboutEach - see
rdfms-abouteach for details.
- Added the mapping to the RDF Model as expressed by N-Triples
- Added the non-normative RELAX NG schema
- Added Issue sections
- Added serialisation section
- Added introduction to the RDF/XML syntax
