Editorial comments.
Comments showing technical errors or must fix comments.
I suggest globally deleting the words "Working Draft" when
referring to the other documents, as we are moving to
last call and onto recommendation, these will need to go at some time;
personally I think it is good to start getting the text precisely how we want
it in the rec.
I suggest dropping the ambition of giving examples of *all* RDF/XML productions in
section 2. You, understandably, lose heart when it comes to giving an account
of bagID. It is not possible to give a sympathetioc account for this monstrosity; you shouldn't even try.
The reification syntax (rdf:ID) is also not really attempted in your explanation.
I will note a few knock on effects of dropping those examples.
Of course, you could surprise me and have a very gung ho example showing the immense utility of bagID.
I note your frequent use of bnodeID - had we agreed to change
to nodeID? (This would globally impact this doc)
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
suggest "many parts"
of the RDF/XML syntax,
it gives an example of how it works Suggest "."and in grammar parse error: suggest "The formal grammar is annotated with actions ..."
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 suggest delete: "test" and "and testable" form. These tests
are gathered and published in the
RDF Test Cases
Working Draft.suggest delete last sentence
This is the editors version of a W3C
RDF Core Working Group
Working Draft produced as part of the W3C
Semantic Web Activity
(Activity Statement).
It incorporates decisions made by the Working Group
updating the XML syntax for RDF from the original
RDF Model & Syntax [RDF-MS] document
in terms of the
XML Information Set
[INFOSET].
including new support for
XML Base,
RDF datatyping,
rdf:nodeID for referencing blank nodes and
rdf:parseType="Collection" for
expressing a closed collection of nodes.
This document is being released for review by W3C Members and
other interested parties to encourage feedback and comments,
especially with regard to how the changes affect existing
implementations and content. The current state is that it represents
all the syntax as described in the
grammar section
of the original document, with some removed parts
(see rdfms-abouteach),
and the mapping to the RDF graph is considered complete.
The detailed changes from the previous
25 March 2002 draft
are described in the Changes section
however the main changes are as follows:
Section 2 An XML syntax for RDF expanded
with many more examples covering all Suggest: s/all/much/ of the syntax,
support for RDF datatyped literals using rdf:datatype was added,
rdf:nodeID was added to allow referencing of blank nodes,
rdf:parseType="Collection" was added for creating
closed collections of nodes
and many other more minor changes after RDF Core Working Group
decisions
made since the last draft.
This is a public W3C Working Draft and may be updated, replaced, or
obsoleted by other documents at any time. It is inappropriate to use
W3C Working Drafts as reference material or to cite as other than
"work in progress". A list of current W3C Recommendations and other
technical documents can be found at http://www.w3.org/TR/.
There are no known patent or
IPR
constraints associated with this Working Draft. The
RDF Core Working Group Patent Disclosure
page contains details, in conformance with
W3C policy
requirements.
Suggest unwise to say "no known" - DanC?
DanC suggested the text in the OWL Test Cases:
"See also patent disclosures related to this work."
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 [RDF-MS] W3C
Recommendation. Subsequent implementations of this syntax and
comparison of the resulting RDF graphs have shown that there was
ambiguity - implementations generated different graphs and certain
syntax forms were not widely implemented. These issues were
generally made as either feedback to the
www-rdf-comments@w3.org
(archive)
or from discussions on the RDF Interest Group list
www-rdf-interest@w3.org
(archive)
.
The
RDF Core Working Group
is chartered
to respond to the need for a number of fixes, clarifications and
improvements to the specification of RDF's abstract graph and XML
syntax. The Working Group invites feedback from the developer
community on the effects of its proposals on existing implementations
and documents.
Several decisions including amendments and deletions to the
grammar are referred to
below.
The definitive record of the decisions is the
RDF Core Working Group issues list.
Suggest delete from start of section to this point, none of the text above belongs
in a rec.
This document revises the
original RDF/XML grammar
in terms of
XML Information Set
[INFOSET] Information Items which moves
away from the rather low-level details of XML, such as particular
forms of empty elements. This allows the grammar to be more
precisely recorded and the mapping from the XML syntax to the RDF
graph more clearly shown. The mapping to the RDF graph is done by
emitting statements in the form defined in the
N-Triples
section of
RDF Test Cases [RDF-TESTS] Working Draft
which creates an RDF graph, that has semantics defined by
RDF Model Theory [RDF-MODEL] Working Draft.
The complete specification of RDF consists of a number of documents:
I have many comments on this section.
A few come up repeatedly:
- Terminology
- There is no consistency as to when you talk about values when about object nodes
etc. There is also a lack of recognition of when the text is about the XML document
and when the text is about the RDF graph.
- Very
- All instances of the word should be deleted.
- Precision
- Many of the examples have text that overstates a useful generalization
- Quantity
- For some of the productions you suggest that certain grapahs occur
often or common(ly) etc.
You do not suggest the degree of use of bagID. I suggest that a similar silence is appropriate
for other, perhaps more useful constructions too.
Really, I think this section needs a lot of work before it is acceptable.
Given timescales, I strongly advocate
deletion.
Assuming I lose that argument, here are some wholemeal constructive suggestions.
Do not talk as if one XML document is transformed into another.
The only work that we know of that takes that approach was my Snail
parser, this is unpublished, and the editor decided that it was not
an appropriate vehicle for the normative statement of the grammar.
It is too late to go back on that decision.
That
decision was connected with deciding that the primary audience for
the grammar doc was parser writers, another decision that I think
it would be a mistake (timescale wise) to revise.
Introducing this transformational approach in comments about
examples simply does not work. The comments are muddled, confusing,
and frequently wrong.
Better, would be to choose one example RDF graphs (an approach
you partially use); then serialize it using the striped syntax,
and list the grammar rules from section 7 that have been used in
that serialization (possibly with a count of the numbers of times
of use of each rule). Then for each grammar rule that you wish
to give an example for; reserialize the same graph using the new grammar
rule. Limit the text above such examples, to: "The same RDF Graph can be
serialized using grammar rule 7.23 propertyElt instead of grammar rule
7.16 proeprtyAttr." i.e. make short unambiguous sentences that relate
this section to the normative section on the grammar, and make this
section clearly dependent upon the normative grammar.
Such an approach, of course, makes it difficult to exercise rules
that show something a bit different (e.g. an XMLLiteral or a datatype). I think these should be addressed as test
cases: where each example is approved by the group as a test case and the
text in the syntax doc is limited to:
"This Graph (picture) can be serialized with this XML (table) and utilizes grammar rule (internal link and rule number and name)."
In order to avoid the encoding problems related with HTML usually being
in ISO-8859-1 and XML usually being UTF-8 I suggest that non english examples
be limited to US-ASCII; I can help with italian constructed from this reduced alphabet.
I think it is imperative that the examples included in this section should have:
- picture in the doc
- ntriple in test cases area
- XML in the doc and the test cases area
This facilitates automatic testing.
In the OWL Test Cases, which takes a similar view, I carefully
generate the XML in the doc from the XML files in the test area
to avoid copy/paste errors.
Such an approach, combined with limited and cautious comments would
help avoid future errors.
As is, my comments sometimes correct your text, despite my desire to
delete this whole section. In general, any minor correction should
be regarded as subsumed by the suggestion of major surgery.
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 graph has nodes and labelled directed arcs.
The nodes
can be labeled with URIs, literals or are blank and denote resources.
The arcs connect the nodes and are all
labeled with URIs. This graph is more precisely called a directed
edge-labeled graph; each edge is an arc with a direction (an arrow)
connecting two nodes. These edges can be described as triples of
subject node, at the blunt end of the arrow,
property arc and an object node at the sharp end of
the arrow/arc. The property arc can also be also interpreted as
either a relationship between two resources or as defining
an attribute value (object node) for some resource subject node.
It seems to me that we should not have this graph terminology
defined time over time in all the specs.
There are inevitably minor differences:
I see it as a bug that you use the term URIs above without any qualification or additional text.
I don't think it does to simply omit the above - we really need to sit down, all the editors,
and work out what vocabulary we need and where each term gets defined, and then be prepared to use
each others terms.
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 use term QName. Above text is unclear since it
does not explain how using a pair of things to be concatenated can be shorter than
using the concatenation.
A graph can be considered a sequence of paths of the form Node,
Arc, Node, Arc, Node, Arc, ... suggest final "Node" after the dots:
conventionally a sequence ending in dots is infinite whereas a sequence with dots in the
middle is finite which walk suggest: cover 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 next arc turns into a child
element, and so on. The stripes generally start at the top of an
RDF/XML document and always begin with nodes.
The sentence
There is a resource (this one) with a title, "RDF/XML Syntax Specification
(Revised)" and it has an editor, the editor has a name
"Dave Beckett" and a home page http://purl.org/net/dajobe/.
can be written as the RDF graph in Figure 1
where the nodes are represented as ovals and contain
their URI where they have them,
the properties such as "has an editor" have been given URIs
and these have been used to label the appropriate arc,
and the strings have been written in rectangular nodes.
We should not normatively describe a transformation from English to
RDF or RDF/XML; for example the RDF does not represent the english
context sensitive relative pronoun "this" which you have used.
If we follow the Node, Arc ... 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 the sequence of 5 nodes and arcs for the
arcs in Figure 2 corresponds to 5
XML elements shown in Example 1:
<rdf:Description>
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description>
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
There are two types of XML elements in the striping in Example 1 corresponding to the nodes and arcs in
the graph which are conventionally called Node Elements and
Property Elements respectively. Here,
rdf:Description is the node element (used 3 times for
the three nodes) and ex:editor and
ex:homePage are the 2 property elements.
Suggest: There are two types of usage of XML elements ...
It is the XML spec that gets to classify XML elements.
The Figure 2 graph consists of some nodes
labelled with URIs (others that remain blank) and this can be added
to the RDF/XML using the rdf:about attribute on node
elements to give the result in Example 2:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description rdf:about="http://purl.org/net/dajobe/">
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
I note that the HTML used to format the
examples varies - I worry about potential inconsistencies arising
from the lack of automation here. Copy/paste mistakes etc.
Adding the other two paths through the Figure 1
graph gives the result in Example 3:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description rdf:about="http://purl.org/net/dajobe/">
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:fullName>Dave Beckett</ex:fullName>
</rdf:Description>
</ex:editor>
</rdf:Description>
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
</rdf:Description>
There are several abbreviations that can be used to make very
common uses more easy suggest: easier to write down. In particular, it is very
common that a resource is being described with multiple property /
value pairs as in this example.
Suggest delete up to this point in para; replace with: "RDF/XML provides an abbreviation
for the case when a resource has multiple properties."
The resource
http://www.w3.org/TR/rdf-syntax-grammar
has two arcs and the blank node resource also has two arcs.
The whole notion of abbreviation has not been introduced; the notion of "more easy" (sic) is highly open to debate - most programs find it easy to write one triple at a time without any context - the Jena N-triple writer is significantly simpler than even the basic RDF/XML writer.
I prefer delete whole para and next para, and replace with. "The same graph can
be written in RDF/XML as:"
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:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description rdf:about="http://purl.org/net/dajobe/">
</rdf:Description>
</ex:homePage>
<ex:fullName>Dave Beckett</ex:fullName>
</rdf:Description>
</ex:editor>
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
</rdf:Description>
When an arc points to a node with 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.
Arcs do not "appear" in RDF/XML - there is a serialization process. URI is too narrow - I use the term RDF URI reference defined in the concepts doc.
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:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
<ex:fullName>Dave Beckett</ex:fullName>
</rdf:Description>
</ex:editor>
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
</rdf:Description>
When a property's value is a literal string (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 (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 value.
False: rdf:type may take a typed or untyped literal or a blank node.
Rephrasing this para to allow for non-standard usage of rdf:type is hard work.
The text also does not account for the case where two property elements have different xml:lang and
so can not both be compounded on the parent node
In our example, there are two property elements with literal string
suggest: untyped literal
values, the dc:title and ex:fullName
property elements. These can be replaced with property attributes
giving the result shown in Example 6:
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
dc:title="RDF/XML Syntax Specification (Revised)">
<ex:editor>
<rdf:Description ex:fullName="Dave Beckett">
<ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
</rdf:Description>
</ex:editor>
</rdf:Description>
To create a complete RDF/XML document, the graph must False be contained
inside an rdf:RDF XML element also graphs cannot be contained within rdf:RDF elements
only XML gets contained within rdf:RDF. Graphs may be serialized as XML within rdf:RDF elements.
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. Previous sentence incoherent, suggest delete.
Additionally, the XML declaration should what is the normative status of this should?
Suggest delete sentence to avoid confusion.
I note that most of your examples, and most of the test cases do not
follow this '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:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
dc:title="RDF/XML Syntax Specification (Revised)">
<ex:editor>
<rdf:Description ex:fullName="Dave Beckett">
<ex:homePage rdf:resource="http://purl.org/net/dajobe/" />
</rdf:Description>
</ex:editor>
</rdf:Description>
</rdf:RDF>
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 False: XML WG get to specify XML and they
say that xml:lang must be declared in the DTD; RDF/XML permits xml:lang on any 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.
Some examples of marking content languages for RDF properties are shown in
Example 8:
<?xml version="1.0" encoding="iso-8859-1"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
<dc:title xml:lang="en">RDF/XML Syntax Specification (Revised)</dc:title>
<dc:title xml:lang="en-US">RDF/XML Syntax Specification (Revised)</dc:title>
<dc:description xml:lang="it">Il Pagio di Web Fuba</dc:description>
</rdf:Description>
Questo non è vero. Questa pagina non è fuba per niente.
Suggest limit descriptions in languages that many wg members do not
understand to straight forward and completely uncontroversial comments.
<rdf:Description rdf:about="http://example.org/buchen/baum" xml:lang="de">
<dc:title>Das Baum</dc:title>
<dc:description>Das Buch ist außergewöhnlich</dc:description>
<dc:title xml:lang="en">The Tree</dc:title>
</rdf:Description>
</rdf:RDF>
RDF 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
a
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, retch the arc labelled with URI
http://example.org/stuff/1.0/prop (from
ex:prop) and the object node labelled with XML
content beginning a:Collection False: suggest change example.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://example.org/thingy">
<ex:prop rdf:parseType="Literal" xmlns:a="http://example.org/a#">Suggest delete
space.<a:Collection required="true">
<a:widget size="10" />
<a:grommit id="23" />
</a:Collection>
</ex:prop>
</rdf:Description>
</rdf:RDF>
RDF allows Datatyped Suggest: Typed 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 Suggest: xml:lang="")
intending to be interpreted as a
W3C XML Schema datatype int.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://example.org/thingy">
<ex:size rdf:datatype="http://www.w3.org/2001/XMLSchema#int">123</ex:size>
</rdf:Description>
</rdf:RDF>
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 serialization is a key concept
that should have been defined before use.
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
false
it is perfectly legal to use the same identifier in multiple docs.
- scope is not an ontological concept; suggest you use words like "scope"
e.g. "The scope of this identifier is .."
outside a particular
RDF/XML document or serialization.Which? it
makes a difference if a single doc contains multiple serializations? To use a bnodeID
should bnodeID be replaced by nodeID
for a blank node,
it can be used on a node element to replace rdf:about="URI"
or on a property element to replace rdf:resource="URI".
Taking Example 7 and explicitly giving
a bnodeID of abc to the blank node in it
gives the result shown in Example 11.
The second rdf:Description property element is
about the blank node.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
dc:title="RDF/XML Syntax Specification (Revised)">
<ex:editor rdf:nodeID="abc"/>
</rdf:Description>
<rdf:Description rdf:nodeID="abc"
ex:fullName="Dave Beckett">
<ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
</rdf:Description>
</rdf:RDF>
I made a comment that an example that required nodeID might be more motivating;
but I think in general I prefer always serializing the same graph.
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.
The jena code that uses this production
to serialize RDF as XML
does not do it this way; hence a normnative "This is done" is
unacceptable since it makes Jena non conformant.
Even an informative "This is done" is difficult to swallow, given
that the only code that we know of that does this, does not do it
this way.
The method used is that you examine the
productions you might use, you see whether the graph you are trying
to serialized meets the preconditions and then you expand the production.
Doing it the way you suggest is an interesting, but very slow exercise.
ARP has no difficulty reading rdf:parseType="Resource"; in fact it
prefers it, since it is shorter. ADOBEs XMP mandates it. If we believed
that this is too hard to read we should drop it. Otherwise we should avoid
making (normative) judgements about how easy something is to read.
I suggest you omit:
- quantative discussion - I have seen no published work that surveys
RDF and counts the frequency of occurrence of blank nodes as opposed to
bagIDs. Without such a study the "often" is unjustified. Suggest replace "appear often" with "may appear".
- Do not discuss "abbreviations" or any sort of mechanistic procedural view,
but talk declaratively. e.g. "Production propertyEltResource may be applicable
to the serialization of graphs containing blank nodes."
Taking the earlier Example 7,
the contents of the ex:editor property element
could be alternatively done in this fashion to give
the abbreviation shown in Example 12:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
dc:title="RDF/XML Syntax Specification (Revised)">
<ex:editor rdf:parseType="Resource">
<ex:fullName>Dave Beckett</ex:fullName>
<ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
</ex:editor>
</rdf:Description>
</rdf:RDF>
If all the property elements on a blank node have string literal
values (or at most one is rdf:type)
False: the actual constraint is significantly
more complicated. variations in xml:lang and non-standard usage of
rdf:type need to be taken into account, also you have forgotten the
at most one occurrence of any property
, 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.
This text is confusing - ignored? Either this is
Example 7 or it isn't; and it would be simpler just not to
mention example 7. Better still would be to ensure
that example 7 was usable here by changing example 7.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
dc:title="RDF/XML Syntax Specification (Revised)">
<ex:editor ex:fullName="Dave Beckett" />
<!-- Note the ex:homePage property has been ignored for this example -->
</rdf:Description>
</rdf:RDF>
It is very common for RDF graphs to have rdf:type
arcs from nodes. These are conventionally called Typed Nodes
and have a shorthand in RDF/XML to allow this to be expressed more consisely.
This is done by replacing the rdf:Description node element name
with the namespaced-element corresponding to the URI of the value of
the type relationship. There may, of course, be multiple rdf:type
arcs but only one can be used in this way, the others must remain as
property elements or property attributes.
These two versions (ex 14 and ex 15) are nearly the same length (if you omit the
redundant xmlns:eg in the first). "shorthand" seems wishful thinking.
IIRC, dublin core uses none of these arcs, I suggest omitting the
quasi-quantative "common".
Suggest:
"The rule nodeElement may encode an arc with property rdf:type.
The example graph (fig N) can be serialized as RDF/XML as:"
This form is also commonly used in RDF/XML with the built-in
classes in The RDF Namespace:
rdf:Seq, rdf:Bag, rdf:Alt,
rdf:Statement, rdf:Property and
rdf:List.
For example, the RDF/XML in Example 14
could be written as shown in Example 15.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://example.org/thing">
<rdf:type rdf:resource="http://example.org/stuff/1.0/Document"/>
<dc:title>A marvelous thing</dc:title>
</rdf:Description>
</rdf:RDF>
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<ex:Document rdf:about="http://example.org/thing">
<dc:title>A marvelous thing</dc:title>
</ex:Document>
</rdf:RDF>
Suggest swapping these two paras since the first
should refer to the second.
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.
and rdf:ID
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 this is not what you say below, where you
permit reuse of a name with a different xml:base, 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.
property elements do not have values.
propery elements are bits of XML.
object nodes in an RDF graph are (labelled with??) absolute URI refs (not restricted to US-ASCII).
The word value is overused - XML attribute values, Something from
XML infoset, the object node of an arc. Clarity is achieved by
saying a lot less.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://example.org/stuff/1.0/"
xml:base="http://example.org/here/">
<rdf:Description rdf:ID="snack">
<ex:prop rdf:resource="fruit/apple"/>
</rdf:Description>
</rdf:RDF>
RDF has a set of list properties that are mostly used with the
rdf:Seq, rdf:Bag and rdf:Alt
classes, written as typed nodes typcially.
Delete: "typically" (sp) use words like "may" - the Jena basic writer does not use typed nodes,
and it is not substandard because of it. 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 rdf:li
special property element that can handle the counting automatically,
turning avoid procedural
words, suggest: indicating or equivalent to,
also given the many different ways M&S text like this was misunderstood,
it really is imperative that this paragraph is deleted;
a reference to the formal grammar explains how the numbering is done.
into rdf:_1, rdf:_2 in order. The
equivalent graph to Example 17 written
in this form is shown in Example 18.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Seq rdf:about="http://example.org/favourite-fruit">
<rdf:_1 rdf:resource="http://example.org/banana"/>
<rdf:_2 rdf:resource="http://example.org/apple"/>
<rdf:_3 rdf:resource="http://example.org/pear"/>
</rdf:Seq>
</rdf:RDF>
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Seq rdf:about="http://example.org/favourite-fruit">
<rdf:li rdf:resource="http://example.org/banana"/>
<rdf:li rdf:resource="http://example.org/apple"/>
<rdf:li rdf:resource="http://example.org/pear"/>
</rdf:Seq>
</rdf:RDF>
Since you haven't shown the equivalent graph, this example seems
incomplete. I think it should go.
RDF/XML allows a closed This word closed hits the reader
in the goolies - what on earth does it mean, given that we are
not going to justify why webont wanted it, we should not attempt any
normative rationale as to why it is here/ 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 I don't know what value is meant to mean
here, but I can't think of a meaning of value that makes this sentence true.
. The exact graph generated is described in detail in
Section 7.2.17 Production parseTypeCollectionPropertyElt.
You are getting close to what's needed here. e.g.
"This is an example of production parseTypeCollectionPropertyElt see Section 7.2.17 for details
of the equivalent triples."
But all the rest of the text is misleading and/or dangerous.
Example 19 shows a collection of three
nodes in what does 'in' mean? a collection at the end of the ex:hasFruit
property element.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://example.org/basket">
<ex:hasFruit rdf:parseType="Collection">
<rdf:Description rdf:about="http://example.org/banana"/>
<rdf:Description rdf:about="http://example.org/apple"/>
<rdf:Description rdf:about="http://example.org/pear"/>
</ex:hasFruit>
</rdf:Description>
</rdf:RDF>
Since you haven't shown the equivalent graph, this example seems
incomplete. I think it should go.
The rdf:ID attribute can be used on a property
element to reify the triple that it generates (See
section 7.3 Reification Rules for the
full details).
The identifer for the triple is constructed as a relative URI of
# concatenated with the rdf:ID attribute
value. So for example if
rdf:ID="triple", that would be equivalent to the URI
#triple. Each such rdf:ID identifier has
to be unique in the RDF/XML document (from the same set of
identifiers as rdf:bagID).
Example 20 shows a rdf:ID
being used to reify a triple made from the ex:prop
property element giving the reified triple the
URI http://example.org/triples/#triple1.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://example.org/stuff/1.0/"
xml:base="http://example.org/triples/">
<rdf:Description rdf:about="http://example.org/">
<ex:prop rdf:ID="triple1">blah</ex:prop>
</rdf:Description>
</rdf:RDF>
Since you haven't shown the equivalent graph, this example seems
incomplete. I think it should go.
The rdf:bagID attribute can be used on a node element
to give an identifier for a rdf:Bag that lists the
statements generated by the property elements inside the node
element. This allows statements to be made about that bag. The
identifer is constructed as a relative URI 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). once again
you are neglecting the possibility of a change of base URI
Example 21 shows a rdf:Bag
with URI http://example.org/bags/#bag1
being made of the triples from inside the rdf:Description
node element.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://example.org/stuff/1.0/"
xml:base="http://example.org/bags/">
<rdf:Description rdf:about="http://example.org/" rdf:bagID="bag1">
<ex:prop1>blah</ex:prop1>
<ex:prop2 rdf:resource="http://example.org/elsewhere/"/>
</rdf:Description>
</rdf:RDF>
The RDF Core Working Group has developed an
RDF Primer
[RDF-PRIMER]
that goes into detail introducing RDF and its applications.
For a longer introduction to the RDF/XML striped syntax
with a historical perspective, see RDF: Understanding the Striped RDF/XML Syntax [STRIPEDRDF].
There is no indication that this section is informative
so why isn't the ref normative?
These keywords are used only once or twice, and then
usually ill-advisedly, I suggest you delete this section. You use most of
these words in lower case more often, which can only lead to confusion.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
RFC 2119
[KEYWORDS].
The Internet Media Type / MIME type for RDF is
"application/rdf+xml" -
see RFC 3032
(RFC-3023) section 8.18.
The W3C will register this type when this working draft is more stable.
Shouldn't you ref Aarons draft here.
It is recommended that RDF files have the extension
".rdf" (all lowercase) on all platforms.
It is recommended that RDF files stored on Macintosh HFS file
systems be given a file type of "rdf "
(all lowercase, with a space character as the fourth letter).
The
RDF Namespace URI is
http://www.w3.org/1999/02/22-rdf-syntax-ns#
and is typically used in XML with the prefix rdf
although other prefix strings may be used. The namespace contains
the following names only:
- Syntax names (no concepts in the graph)
-
RDF Description ID about bagID parseType resource li
This "(no concepts in the graph)" is not what I thought we had
agreed. I thought it was that if you use these terms in a graph,
then: (a) an application may issue warnings and (b) the graph
cannot be serialized in RDF/XML.
- RDF Classes in the graph
-
Seq Bag Alt Statement Property List
- RDF Properties in the graph
-
subject predicate object type value first rest _n
where n is a non-negative integer.
- RDF Resources in the graph
-
nil
Any other names are not defined and SHOULD generate a warning when
encountered in an application, but should otherwise behave normally,
and treated as properties and/or classes as appropriate for their use.
Throughout this document the terminology rdf:name
will be used to indicate name is from the RDF namespace
and it has a URI of the concatenation of the
·RDF Namespace URI· and name.
For example, rdf:type has the URI
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
When do these notes get deleted ....
sometime soon we should start indicating that these are
notes in WD which will not be in the REC
Note:
In the 18 December 2001
Working Draft the names aboutEach and aboutEachPrefix were removed
from the language and the RDF namespace by the RDF Core Working Group.
See the resolution of issues
rdfms-abouteach and
rdfms-abouteachprefix
for further information.
Note:
In this version of the working draft, the names List, first,
rest and nil were added to the
RDF namespace by the RDF Core Working Group.
See the resolution of issues
rdfms-seq-representation
for further information.
Group).
Note:
The Working Group invites feedback from the community on the effects
of the removals and additions of these terms on existing
implementations and documents and on the costs and benefits of
adopting a new namespace URI to reflect this change (currently not
proposed by the Working Group).
I am unsure about the order of things here,
we seem to need to refer forward to section 6, maybe putting bits of 6 earlier
or some of this later would flow better.
The
RDF graph
(RDF Concepts and Abstract Data Model Section 3)
uses three types of identifiers (or labels) for nodes and arcs:
- URI references (labeling nodes and arcs)
-
URI references (RDF Concepts and Abstract Data Model Section 3.1)
can be either given as absolute URIs, relative
URIs that have to be resolved to the in-scope base URI
as described in section section 5.3,
constructed from XML Namespace-qualified element and attributes names
(QNames) or from rdf:ID and rdf:bagID attribute values.
Within RDF/XML, 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.
- Literals (labeling object nodes)
RDF Literals (RDF Concepts and Abstract Data Model 3.2) are either
Strings Literals (ibid 3.2.1),
XML Literals (ibid 3.2.2)
or
Datatype Typed Literals
I've lost a page of my notes around this point; there may be
some late additions here.
- Blank node Identifiers (labeling nodes)
- These are given local identifiers
in the N-Triples serialization which MUST
match the name
production in
N-Triples.
This MUST is much too strong.
As I remember it, rdf:nodeID can expand to an NC_NAME (from namespaces).
This is substantially more generous than name in NTriples e.g. permitting
éhWhatsGoingOn . The treatment of mapping everything to Ntriples
and then to the graph is not a requirement of RDF/XML and so there is
no requirement to use Ntriple or to meet this constraint. ARP does not
behave like this.
The treatment of rdf:nodeID has to be modified to turn the unicode
attribute value into a unique US-ASCII string for ntriple; but this
ugliness is a feature of this document, not a feature of RDF/XML; and that
needs to be clear.
Note:
Suggest delete
In the past, some RDF applications have handled these nodes (then
called anonymous nodes) by generating arbitrary URIs. This
generates a different RDF graph.
See also the Skolemization
section of the RDF Model Theory [RDF-MODEL] Working Draft.
RDF/XML supports
XML Base [XML-BASE]
by being specified in terms of the
XML Information Set
[INFOSET].
This defines a
·base-uri·
accessor for each
·root event· and
·element event·.
RDF/XML uses URI-references throughout
and applies the in-scope Base URI to resolve both
same document references of the forms "#frag"
and "".
An empty same document reference ""
resolves against the URI part of the Base URI; any fragment part
is ignored. See
Uniform Resource Identifiers (URI) [URIS] section 4.2
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.
- constraint-id
-
This is very unclear see
Peter Patel-Schneider's msg.
The names used as values of rdf:ID and rdf:bagID
attributes must be unique in a single RDF/XML document
omit any justification: RDF/XML is a carbuncle and we
should not attempt to justify the unjustifiable since they
come from the same set of names. This applies with respect to the
in-scope
·base-uri·
accessor of the current element; so the same value
can appear on different elements in the same document but
only if the in-scope base-uri values were different.
The syntax of the names must match the
rdf-id production
Suggest :
"Each application of productions idAttr and bagIDAttr
match an attribute.
The pair formed by the string-value of the matched attribute and
the
base-uri value in-scope at the point of production is unique within
a single RDF/XML document."
- constraint-nodeID
The names used as values of rdf:nodeID come from a
set of names that are independent of those of rdf:ID and rdf:bagID.
The syntax of the names must match the
rdf-id production
There is no constraint here.
Any matching use of the production is valid.
This subsection must be deleted, it
is currently only a potential source of confusion.
e.g. on first reading I thought you were saying that
rdf:nodeID="foo" and rdf:ID="foo" could not both
be used in the same doc.
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-Triplessuggest: RDF Graph (no requirement to use N-Triples) from the XML. It does not mandate any implementation
method - any other method that results in the same N-Triples (RDF
graph) ditto may be used.
In particular:
- The N-Triples suggest: arcs may be generated in any order
- Duplicates may be eliminated at any point
- There is no requirement to support N-Triples in any way
- There is no requirement to use [XPATH] or [SAX2]
The syntax does not support non-well-formed XML documents, nor
documents that otherwise do not have an XML Information Set; for
example, that do not conform to
XML Namespaces
[XML-NS].
The Infoset requires support for
XML Base [XML-BASE]
which generates information item properties [base URI] below.
The use of this property in RDF/XML is discussed in
section 5.3
This specification requires an
XML Information Set[INFOSET]
which supports at least the following information items and
properties for RDF/XML:
- 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]
- Character Information Item
- [character code]
There is no mapping of the following items to data model events:
- Processing Instruction Information Item
- Unexpanded Entity Reference Information Item
- Comment Information Item
- Document Type Declaration Information Item
- Unparsed Entity Information Item
- Notation Information Item
- Namespace Information Item
Other information items and properties have no mapping to
syntax data model events.
Do we need to work on this together?
There are six types of event defined in the following subsections.
Most events are constructed from an Infoset information item (except
for Identifier,
Literal and
XML Literal). The effect
of an event constructor is to create a new event with a unique identity,
distinct from all other events. Events have accessor operations on them.
and all have the string-value accessor that may be a static value
or computed.
Constructed from an
Document Information Item
and takes the following accessors and values.
- document-element
- Set to the value of document information item property document-element.
- children
- Set to the value of document information item property [children].
- base-uri
- Set to the value of document information item property [base URI].
- language
- Set to the empty string.
Constructed from an
Element Information Item
and takes the following accessors and values:
- local-name
- Set to the value of element information item property [local name].
- namespace-name
- Set to the value of element information item property [namespace name].
- children
- Set to the value of element information item property [children].
- base-uri
- Set to the value of element information item property [base URI].
- attributes
Set to the value of element information item property [attributes].
If the value contains an attribute event xml:lang (that is, the
·local-name·
accessor of the attribute has value "lang" and the
·namespace-name·
accessor of the attribute has value
"http://www.w3.org/XML/1998/namespace"), it is removed
and from the list of attributes and the
·language· accessor is set to the
string-value of the attribute.
All other attributes beginning with xml are then removed
(that is, all attributes with
·namespace-name·
accessors values beginning with
"http://www.w3.org/XML/1998/namespace"). Note: this does not
include xml:base which is already present in the Infoset as the
·base-uri·
accessor.
suggest wordsmithing last note. e.g.
"Note: the baseURI is computed before any xml:base attribute is deleted."
(reading infoset I believe that the xml:base attribute is left in
the attributes property, and so does need to be deleted at this
stage).
- URI
- Set to the string value of the concatenation of the
value of the namespace-name accessor and the value of the
local-name accessor.
- li-counter
- Set to the integer value 1.
- bag-li-counter
- set to the integer value 1.
- language
- 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.
no, the way you've done it doesn't it have
to be at least the empty string?
- subject
- Has no initial value. Takes a value that is an
Identifier event.
This is used on elements that deal with one node in the RDF graph,
this generally being the subject of a statement.
Has no accessors. Marks the end of the containing element in
the sequence.
Constructed from an
Attribute Information Item
and takes the following accessors and values:
- local-name
- Set to the value of attribute information item property [local name].
- namespace-name
- Set to the value of attribute information item property [namespace name].
- string-value
- set to the value of the attribute information item property [normalized value] as specified by
Do we need to discuss the problems of whether we do XML
validation or not. The attrbite value normalization rules are different
for validated XML or non-validated XML?
[XML] (if an attribute whose normalized
value is a zero-length string, then the string-value is also
a zero-length string).
- URI
- Set to a string value of the concatenation of the
value of the
·namespace-name·
and the value of the
·local-name·
accessor.
Constructed from a sequence of one or more consecutive
Character Information Items.
Has the single accessor:
- string-value
- Set to the value of the string made from concatenating the
[character code] property of each of the character information items.
Suggest delete NOTE
NOTE: This is intended to be identical to how XPath defines this.
A node for a typed identifier which has the following accessors:
- identifier
- Takes a string value.
- identifier-type
- Takes one of the two values "URI" or "bnodeID"
- string-value
The value of this is calculated from the other accessors based on
the ·identifier-type· value as follows.
When "URI", the value is the concatenation of "<", the value of the ·identifier· accessor and ">"
Otherwise ("bnodeID"), the value is the concatenation of "_:" and the value of the ·identifier· accessor.
These events are constructed by giving two values for the
for the ·identifier· and
·identifier-type· accessors.
For further information on identifiers in the RDF graph, see
section 5.2.
An event for a text literal which can have the following accessors:
- literal-value
- Takes a string value.
- literal-language
- Takes a string value.
- literal-datatype
- Takes an optional string value used as a URI.
- string-value
The value is calculated from the other accessors as follows.
If ·literal-language· is empty
the empty string
then the value is the concatenation of """ (1 double quote),
the value of the
2 ·literal-value· accessor
and """ (1 double quote).
Otherwise the value is the concatenation of """ (1 double quote),
the value of the
·literal-value· accessor
""@" (1 double quote and a '@'),
and the value of the
·literal-language· accessor.
If ·literal-datatype· is not empty
then append to the value calculated above "^^<" concatenated with
the value of the
·literal-datatype· accessor
concatenated with ">".
Note that the double-quoted ·literal-value· string must use the N-Triples
string escapes
for escaping certain characters such as ".
These events are constructed by giving values for the
·literal-value· and
·literal-language· accessors.
Note:
Literals beginning with a Unicode combining character are
allowed however they may cause interoperability problems.
See [CHARMOD] for further information.
An event for an XML literal which can have the following accessors:
- literal-value
- Takes a string value.
- literal-language
- Takes a string value.
- string-value
The value is calculated from the other accessors as follows.
If ·literal-language· is empty
the empty string
then the value is the concatenation of
"xml"" ('x', 'm', 'l', and 1 double quote),
the value of the
·literal-value· accessor
and """ (1 double quote).
Otherwise the value is the concatenation of
"xml"" ('x', 'm', 'l', and 1 double quote),
the value of the
·literal-value· accessor
""@" (1 double quote and a '@'),
and the value of the
·literal-language· accessor.
Note that the double-quoted literal-value string must use the N-Triples
string escapes
for escaping certain characters such as ".
These events are constructed by giving values for the
·literal-value· and
·literal-language· accessors.
Note:
Literals beginning with a Unicode combining character are
allowed however they may cause interoperability problems.
See [CHARMOD] for further information.
To transform the Infoset into the sequence of events
in document order, each
information item is transformed as described above to generate a
tree of events with accessors and values. Each element event is
then replaced as described below to turn the tree of events
into a sequence in document order.
- The original element event
- The value of the
children
accessor,
suggest: recursively transformed a possibly empty ordered list of events.
- An end element event
The following notation is used for matching the sequence
of events generated as described in Section 6
and describing the actions to perform for the matches.
The RDF/XML grammar is defined here in terms of its
data model events, using statements of the form:
number event-type event-content
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.
Notation for matching events and grammar actions.
| General Notation |
| Notation |
Meaning |
| event.accessor |
The value of an event accessor. |
| rdf:X |
A URI as defined in section 5.1. |
| "ABC" |
A string of characters A, B, C in order. |
| concat(A, B, ..) |
A string created by concatenating the terms in order. |
| Notation for Matching Events |
| Notation |
Meaning |
| A == B |
A is equal to B. |
| A != B |
A is not equal to B. |
| A | B | ... |
The A, B, ... terms are alternatives. |
| A - B |
The term A but not the term B. |
| anyURI. |
Any legal URI. |
| anyString. |
Any string. |
| list(item1, item2, ...); list() |
An ordered list of events. An empty list. |
| set(item1, item2, ...); set() |
An unordered set of events. An empty set. |
| * |
Zero or more of preceding term. |
| ? |
Zero or one of preceding term. |
| + |
One or more of preceding term. |
root(acc1 == value1,
acc2 == value2, ...) |
Match a Root Event with accessors.
|
start-element(acc1 == value1,
acc2 == value2, ...)
children
end-element() |
Match a sequence of
Element Event with accessors,
a possibly empty list of events as element content and an
End Element Event.
|
attribute(acc1 == value1,
acc2 == value2, ...) |
Match an Attribute Event
with accessors. |
| text() |
Match a text event. |
| Notation for Grammar Actions |
| Notation |
Meaning |
| A := B |
Assigns A the value B. |
| event.accessor := value |
Sets an event accessor to the given value. |
identifier(identifier := value,
identifier-type := value, ...) |
Create a new Identifier Event. |
literal(literal-value := string,
literal-language := language, ...) |
Create a new Literal Event. |
xml(literal-value := string,
literal-language := language, ...) |
Create a new XML Literal Event. |
| 7.2.2 syntaxTerms | rdf:RDF | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype |
| 7.2.3 nodeElementURIs | anyURI - ( syntaxTerms | rdf:li ) |
| 7.2.4 propertyElementURIs | anyURI - ( syntaxTerms | rdf:Description | rdf:nil) |
| 7.2.5 propertyAttributeURIs | anyURI - ( syntaxTerms | rdf:Description | rdf:li | rdf:nil) |
| 7.2.6 doc | root(document-element == RDF,
children == list(RDF)) |
| 7.2.7 RDF | start-element(URI == rdf:RDF,
attributes == set())
nodeElementList
end-element() |
| 7.2.8 nodeElementList | ws* (nodeElement ws* )* |
| 7.2.9 nodeElement | start-element(URI == nodeElementURIs
attributes == set((idAttr | nodeIdAttr | aboutAttr )?, bagIdAttr?, propertyAttr*))
propertyEltList
end-element() |
| 7.2.10 ws | White space as defined by
[XML] definition White Space
Rule [3] S
in section
Common Syntactic Constructs |
| 7.2.11 propertyEltList | ws* (propertyElt ws* ) * |
| 7.2.12 propertyElt | resourcePropertyElt |
literalPropertyElt |
parseTypeLiteralPropertyElt |
parseTypeResourcePropertyElt |
parseTypeCollectionPropertyElt |
parseTypeOtherPropertyElt |
emptyPropertyElt |
| 7.2.13 resourcePropertyElt | start-element(URI == propertyElementURIs ),
attributes == set(idAttr?))
ws* nodeElement ws*
end-element() |
| 7.2.14 literalPropertyElt | start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, datatypeAttr?))
text()
end-element() |
| 7.2.15 parseTypeLiteralPropertyElt | start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, parseLiteral))
literal
end-element() |
| 7.2.16 parseTypeResourcePropertyElt | start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, parseResource))
propertyEltList
end-element() |
| 7.2.17 parseTypeCollectionPropertyElt | start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, parseCollection))
nodeElementList
end-element() |
| 7.2.18 parseTypeOtherPropertyElt | start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, parseOther))
propertyEltList
end-element() |
| 7.2.19 emptyPropertyElt | start-element(URI == propertyElementURIs ),
attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, bagIdAttr?, propertyAttr*))
end-element() |
| 7.2.20 idAttr | attribute(URI == rdf:ID,
string-value == rdf-id) |
| 7.2.21 nodeIdAttr | attribute(URI == rdf:nodeID,
string-value == rdf-id) |
| 7.2.22 aboutAttr | attribute(URI == rdf:about,
string-value == URI-reference) |
| 7.2.23 bagIdAttr | attribute(URI == rdf:bagID,
string-value == rdf-id) |
| 7.2.24 propertyAttr | attribute(URI == propertyAttributeURIs,
string-value == anyString) |
| 7.2.25 resourceAttr | attribute(URI == rdf:resource,
string-value == URI-reference) |
| 7.2.26 datatypeAttr | attribute(URI == rdf:datatype,
string-value == URI-reference) |
| 7.2.27 parseLiteral | attribute(URI == rdf:parseType,
string-value == "Literal") |
| 7.2.28 parseResource | attribute(URI == rdf:parseType,
string-value == "Resource") |
| 7.2.29 parseCollection | attribute(URI == rdf:parseType,
string-value == "Collection") |
| 7.2.30 parseOther | attribute(URI == rdf:parseType,
string-value == anyString - ("Resource" | "Literal") ) |
| 7.2.31 URI-reference | An attribute ·string-value· interpreted as a URI reference defined in
Uniform Resource Identifiers (URI) [URIS]
BNF production URI-reference. |
| 7.2.32 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 |
| 7.2.33 rdf-id | An attribute ·string-value·
matching any legal
[XML] token
Nmtoken |
If the RDF/XML is a standalone XML document
(known by having been given the RDF MIME Type)
then the grammar starts with Root Event
doc.
If the content is known to be RDF/XML by context, such as when
RDF/XML is embedded inside other XML content, then the grammar
can either start
at Element Event
RDF
(only when an element is legal at that point in the XML)
or at production nodeElementList
(only when element content is legal, since this is a list of elements).
For such embedded RDF/XML, the
·base-uri·
value on the outermost element must be initialized from the containing
XML since no
Root Event will be available.
Note that if such embedding occurs, the grammar may be entered
several times but no state is expected to be preserved.
This contradicts other statements that
talk about things with scope RDF/XML document.
e.g. constraint-id.
rdf:RDF | rdf:ID | rdf:about | rdf:bagID | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
These are the core terms from the RDF Namespace in
section 5.1
that are part of the RDF/XML syntax and never handled as
RDF properties or classes.
The URIs that are allowed on node elements.
We never disallowed rdf:nil did we?
The URIS that are allowed on property elements.
We never disallowed rdf:nil did we?
The URIs that are allowed on property attributes.
For element e, this e is slightly confusing,
which element are we talking about?
the processing of some of the attributes
have to be done before other work such as dealing with children events
or other attributes. These can be processed in any order:
Overall this subsection is clear.
If e.subject
is empty, generate a local blank node identifier i
and n := identifier(identifier := i, identifier-type:="bnodeID"). Then e.subject := n.
The following can then be performed in any order:
