Re: RDF Core WG draft of RDF/XML Syntax Specification (Revised) for review

On Mon, 2002-10-28 at 15:18, Dave Beckett wrote:
> >>>Daniel Krech said:
> > Hi Dave,
> > 
> > The spec is looking great. Here are some comments on the RDF/XML
> > Syntax Specification (Revised) you archived here:
> > 
> > http://lists.w3.org/Archives/Public/www-archive/2002Oct/att-0062/01-index.html
> > 
> > My implementation is mostly synced up with this latest spec, but not
> > completely, so I may have more feedback as I finish syncing up this
> > week. I hope the comments are helpful.
> > 
> > --eikeon, http://eikeon.com/
> > 
> > --------------------------------------------
> > 
> > 2.1 Introduction
> > 
> > Why does the introduction now refer to URIs instead of URIRefs? 
> 
> It was shorter to type and I didn't notice.  I'll have a look and
> replace them.
> 
> > .... Also,
> > could the terms be linked to where they are defined in the other
> > documents?
> 
> Which terms? 
>
> Some such as "blank node" are not defined in any other normative
> document.  Others aren't citable since they aren't in published
> documents - such as datatyped literals in the concepts WD.  I think
> I link to the others.

Ah yes, URI references and RDF Literals are linked to in section 5.2
later on. Maybe add a note to Blank node Identifiers that there is no
mention in RDF Concepts to link to yet. Only other term that I noticed
that seems to get used a fair bit throughout much of the syntax spec is
nodes... perhaps a link could be added for it if it does not already
have one.

> If you mean also things like "node element" defined here, I can add
> some more backward links to these.

I was fine with those being blank and not universal since they are in
the same document :)

> > 2.4 Empty Property Elements
> > 
> > Typo in first sentence: with -> which
> 
> Fixed.
> 
> > 2.9 Datatyped Literals
> > 
> > Typo in third sentence: syntax syntax -> syntax
> 
> Fixed.
> 
> > 2.10 Identifying Blank Nodes
> > 
> > To me, the difference between a bNode and a URIRef is whether or not
> > the label is universal. In the context of a single document, thinking
> > of bNodes as not having a label (blank) only creates confusion in my
> > mind. I think bNodes would be less confusing if they where described
> > as having a non-universal resource identifier. And to note somewhere
> > that non-universal resource identifiers are good when one does *not*
> > want *anybody* to be able to say anything about the resource, but only
> > the one document.
> >
> > The fact that bNode identifiers may not need to be written out in some
> > cases[1] does not mean they need to be thought of as blank.
> > 
> > [1] When the document does not need to reference the bNode identifier
> > from more than one place in the document.
> 
> I'm trying to explain the syntax in terms of the XML, so I don't want
> to talk about existential variables scoped to the graph, but I could
> call them local, document-scoped identifiers (non-URI references)
> instead?  The nodes in the graph are blank, but that could remain
> graph terminology, not used here.

"Blank nodes have local, document-scoped identifiers" works better for
me than "blank nodes have no URI label". But I think I am mostly after
additional definition/clarification that falls within another document.

> As to what the (blank) nodes mean or their purpose, that's a model or
> even more of a modelling style question and not for this document.
 
Agreed. I should send these comments toward the RDF Concepts document.
 
> > 2.17 Reifying Statements
> > 
> > It might be nice to allow rdf:nodeID here too... So that one has a
> > choice of whether or not the reified statement itself will have a
> > universal identifier or just an identifier that can only be used
> > within the scope of the document.
> 
> We'd have to introduce new syntax for that, rdf:bagIDnode, rdf:IDnode
> or somesuch and for marginal benefit.  You can always write out the
> reified statements in their long form.  So, no.

I agree. But non the less just wanted to toss it out there.

> 
> > Section 5.1 The RDF Namespace
> > 
> > Syntax names is missing: nodeID, datatype
> 
> Oops.  Fixed.  I had added them to the syntaxTerms production (7.2.2) later.
> 
> > > 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.
> > 
> > If the syntax is not being constrained and what happens with the
> > syntax behaves normally then the matter is no longer one for the
> > syntax spec. I can only guess that "SHOULD generate a warning" instead
> > of "MUST generate an error" is due to backward compatibility? ...
> 
> We decided that unknown rdf namespace terms must generate a warning.
> Therefore we must list the known terms precisely.  Unknown rdf terms
> fall into the general matching of allowed nodeElementURIs or
> propertyElementURIs and are processed as normal (apart from the
> warning).
> 
> > ... If not,
> > then why not define the productions with anyURI in them as follows:
> > 
> >     nodeElementURIs = rdf:Description | classURI | rdf:nil | anyURI
> >                       except from the RDF namespace
> > 
> >     propertyElementURIs = rdf:li | propertyURI | anyURI except from
> >                           the RDF namespace
> > 
> >     propertyAttributeURIs = anyURI except from the RDF namespace
> > 
> >   where:
> > 
> >     classURIs = SEQ | BAG | ALT | STATEMENT | PROPERTY | LIST
> > 
> >     propertyURIs = SUBJECT | PREDICATE | OBJECT | TYPE | VALUE | FIRST
> >                    | REST | _n
> 
> 
> I do like the classURIs & propertyURIs split and will consider this.
> Particularly I like it if it matches the namespace split too in 5.1.
> Maybe I should define the lists in 5.1 and then refer to it from the
> grammar or would that be splitting the grammar up too much?
> 
> 
> > Section 6.1.1 Identifier Event
> > 
> > Typo in second to last sentence: for the for the -> for the
> 
> Fixed. 
> 
> > Section 7.2.2 Production syntaxTerms 
> > ( http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/#syntaxTerms )
> > 
> > Defining syntaxTerms so that it is not slightly different from the
> > list of Syntax names, but one in the same, would make the section
> > using syntaxTerms read better (after they have been changed
> > accordingly). Also, the use of syntaxTerms in section 8 would be more
> > correct (since it would include rdf:Description).
> 
> I noted the bug, some things here didn't match earlier.
> 
> Yes - syntaxTerms ref in 8 is incomplete, needs to include
> rdf:Description.
> 
> 
> > Section 7.2.3 Production nodeElementURIs
> > Section 7.2.4 Production propertyElementURIs
> > 
> > It looks like rdf:aboutEach and rdf:aboutEachPrefix are allowed by
> > these productions. Which causes the following four test cases to
> > fail. Hum, unless a warning that gets generated as described in
> > section 5.1 is enough to make the negative test cases pass.
> > 
> > http://www.w3.org/2000/10/rdf-tests/rdfcore/rdfms-rdf-names-use/error-009
> > http://www.w3.org/2000/10/rdf-tests/rdfcore/rdfms-rdf-names-use/error-010
> > 
> > http://www.w3.org/2000/10/rdf-tests/rdfcore/rdfms-rdf-names-use/error-019
> > http://www.w3.org/2000/10/rdf-tests/rdfcore/rdfms-rdf-names-use/error-020
> 
> I should add these as forbidden terms so these errors do happen.
> 
> The warning from the 5.1 description isn't sufficient.
> 
> > Why is rdf:nil not allowed as a propertyElementURI or
> > propertyAttributeURI, but is allowed as a nodeElementURI?
> 
> rdf:nil is neither a class nor a property - it is a sentinel for the
> end of an rdf:first property.  So it doesn't seem sensible to allow
> it as a property.  However, rdf:nil might (will) be declared in an
> RDF vocabulary (schema) document, with some descriptive properties
> off it, hence allowing it as node.  Does that make sense?  I'm
> open to an argument it should be allowed.

I was actually wondering why it was allowed as a nodeElementURI... since
rdf:nil is not a class. 

> 
> Thanks for the detailed comments
> 
> Dave

Received on Monday, 28 October 2002 17:00:10 UTC