- 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