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

>>>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.

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

> 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.

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.


> 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.


> 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.

Thanks for the detailed comments

Dave

Received on Monday, 28 October 2002 15:21:33 UTC