- From: Dave Beckett <dave.beckett@bristol.ac.uk>
- Date: Thu, 30 May 2002 16:09:52 +0100
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- cc: www-rdf-comments@w3.org
>>>"Peter F. Patel-Schneider" said:
> Comments on the Syntax Specification:
>
> In general the new syntax specification is a giant step forward. It
> finally makes RDF/XML real XML.
Thanks
> I do not understand why the information set nodes are transformed into a
> sequence of events, however. Why not just work directly on the information
> set nodes?
To get around various issues about working at the infoset level
- removing (expanding) entities
- combining adjacent sequences of character infoitems
- explicitly defining the used infoitems (and those with no mappings)
Which is based on how XPath does it, using a mapping to nodes:
XPath - Appendix B: XML Information Set Mapping (Non-Normative)
http://www.w3.org/TR/xpath#infoset
I use some of the same words, but didn't want to introduce a
normative dependency on XPath 1.0 REC which puts in a non-normative
appendix, or on the draft XPath 2.0 / XQuery 2.0 WD, still in
development: http://www.w3.org/TR/query-datamodel/
Adding such a dependency might indicate that in order to implement
RDF/XML, you needed to understand and implement XPath, which isn't
the case.
This transformation to a sequence of events is meant to be familiar
to developers as directly mapping to the three SAX events that are
needed for implementing RDF/XML - start element, end element, and text.
This has had good feedback at being clear to developers.
Note: It seems you are looking at the editors draft of the WD, since
in the current published WD 'events' are called nodes. However I
have subsequently felt this was confusing since there are RDF graph
nodes mentioned several times. I have yet to add emphasis that the
word 'event' isn't meant to imply anything else (and other words such
as entity, item, object are also overloaded).
> Problems and Specific Comments:
>
> 1/ The rule for abbreviation of string-valued properties (Section 2) is not
> correct, because of the XML requirement that attributes names be unique
> within an XML element.
I assume you are refering to
"When the property value is a string it can be encoded more simply
as an XML attribute and value, as an attribute of the node
element. This is known as a property attribute and shown in Example 4:"
and you are correct, I will fix this.
>
> 2/ How is base-uri set from the root node? If this is part of the infoset
> model, it should be mentioned.
The root (document) node is from document infoitem and it is there
that it defines base-uri:
"5. [base URI] The base URI of the document entity."
http://www.w3.org/TR/xml-infoset/#infoitem.document
and the Infoset REC in section 1 subsection "Base URIs"
makes a normative reference to XML Base which defines the method.
The syntax WD points this out in the definition of the root node:
http://www.w3.org/TR/rdf-syntax-grammar/#section-root-node
In addition section 5.1 Grammar start describes how base-uri is
defined if RDF/XML is embedded in other XML.
> 3/ The semantic action for an empty subject on a nodeElement could be
> executed even for element nodes with an rdf:ID or rdf:about attribute.
> This is probably benign, but would cause the blank node identifier
> generator to be pointlessly run, resulting in distinct (but
> model-theory-equivalent) sets of n-triples resulting from a single
> RDF/XML document.n
I don't follow you here; can you expand?
> 4/ The constraint on only one rdf:ID (or rdf:bagID) for a URI in a given
> document is hidden deep in the document. It would be much better to
> gather all these context-sensitive constraints in one place. It would
> be even much better to remove these context-sensitive constraints, as
> there is no need to have only one rdf:ID with a particular URI in a
> document. The development of this constraint is rather confusing, as
> there have been statements to the effect that rdf:about="#foo" is a
> synonym for rdf:ID="foo".
Linking and making these constraints more prominent is a good idea; I
will add this.
If I recall correctly, RDF Core decided that keeping them (for IDs)
was useful for users who could then rely on them, for example, when
defining RDF Schema RDF/XML documents, that the terms being defined
using rdf:ID were unique identifiers in that RDF/XML file.
It is true that the constraints don't apply when using rdf:about="#foo"
which I guess is seen more as referring rather than defining "foo"
despite these being equivalent; rather rdf:ID="foo" is equivalent
to rdf:about="#foo" but with the extra constraint.
<snip/>
> Comments on the Primer
> ...
> 3. An XML Syntax for RDF
This section is also similar to section 2 of the syntax WD, so some
comments here might need to be folded into the syntax WD; I'll also
comment here on syntax issues.
> It is not possible to use namespaces for the URI labels for object nodes,
> except (sometimes) for the labels of types. In general, only edge labels
> can employ namespaces. This is illustrated in the example RDF/XML syntax,
> which does not use namespaces for http://www.example.org/index.html.
(XML) Namespaces are only in the RDF/XML syntax and not in the RDF
graph. The RDF graph uses URI-refs to label nodes, so graph edge labels
cannot "use (XML) namespaces"
I suspect you are getting at that in RDF/XML, XML qnames can only be
used to label the RDF graph URIs, and cannot be used to label graph
nodes? If so I will try to fix in the syntax WD to make this clearer.
> The abbreviation example incorrectly states that rdf:resource is (always)
> used when ``the property value is another (existing) resource''. There
> are, instead, lots of ways to do this in RDF/XML.
There are other ways, but this is a gentle introduction. It can be
updated to note the other more verbose forms:
<rdf:Description rdf:about="http://example.org/subject">
<ex:prop>
<rdf:Description rdf:about="http://example.org/object"/>
</ex:prop>
</rdf:Description>
giving
<http://example.org/subject> <http://example.org/prop> <http://example.org/object> .
Will fix (in syntax WD).
> This section retains the notion that rdf:about is used for existing
> resources and rdf:ID is used for new ones. This is not correct.
Will fix (in syntax WD).
> The example for parseType="Resource" misleadingly implies that an rdf:ID
> attribute here would provide a name for the resource. Instead an rdf:ID
> attribute here is a reification mechanism.
We have quite recently clarified this area, and indeed now rdf:ID on
properties always reifies so this needs fixing.
<snip/>
Thanks for the feedback
Dave
Received on Thursday, 30 May 2002 11:10:36 UTC