W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2001

RE: RDF/XML Syntax Revised WD for review

From: <Patrick.Stickler@nokia.com>
Date: Fri, 14 Dec 2001 03:18:33 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B1B430E@trebe006.NOE.Nokia.com>
To: dave.beckett@bristol.ac.uk, w3c-rdfcore-wg@w3.org

> -----Original Message-----
> From: ext Dave Beckett [mailto:dave.beckett@bristol.ac.uk]
> Sent: 11 December, 2001 12:32
> To: w3c-rdfcore-wg@w3.org
> Subject: RDF/XML Syntax Revised WD for review
> 
> 
> I attach a copy of the syntax document for your consideration
> for publication as a working draft.  ...


Patrick's Comments:


All in all, a great document, Dave. Only minor points came to mind.


1. Would it be good to add somewhere in section 2 para 2 a footnote or 
reference to some other section which warns users of RDF about the
potential for unintended URI collisions based on direct concatenation
of namespace to local name (loosing the partition) so that folks are
aware of that issue and can avoid it when crafting qnames. Section 6 
hints at some of these issues, but should they be more explicit? 
Particularly with regards to possible URI collisions? 

2. Section 2 para 3, it would probably help users understand the striping
structure of the serialization if there was a very simple graphic.

3. Section 2 para 5, you may want to change "property value is a string"
to something like "property value is represented as a string" to avoid
any incompatabilities with the eventual data typing clarifications. I
think we all are at least in agreement that values denoted by serialized 
literals are represented as a string, whether they are or are not a string.

4. Section 2 para 6, you may wish to change "replacing the rdf:Description 
element" with "replacing the rdf:Description element name" as the element
itself corresponds to an rdf:Description element and only the name change
signifies the typing.

5. Section 3, list item "Element Information Item", you're missing a
square bracket after "local name".

6. Section 3.6 para 1, you need to define what a "bNode" is in relation
to a bnodeID. Since "bNodes" are not in the orig specs, folks will not
know what they are (unless they've been lurking about the mailing lists).

Question: Should we have a shared glossary of terms for all RDF specs? If
so, we could then simply reference terms in general documents and not have
to repeatedly define them or risk a loss of reader understanding if not
defined.

7. Section 5.5 bullet list 1, since you define the namespace for RDF and
the terms within that namespace sans any prefix, I think it is reasonable
to omit the prefixes everywhere those terms are referenced, since 'rdf:'
is not mandated by the spec and (it appears that) it is not necessary to
differentiate those terms from other namespaces. It is also probably
misleading to state conditions in terms of undefined prefixes. If the
prefix is manditory in those examples, then there should be a clause 
somewhere saying that in this document, the prefix 'rdf:' will be used
to refer to the RDF namespace.

8. Section 5.12, the generation of "local" identifiers for bNodes seems 
to take a per-instance scope view, yet these productions are for producing
an RDF graph which may have content from multiple instances. Are we
speaking only of generating a single graph from a single instance, which
must later be merged into a larger graph constituting the combined 
knowledge space? If so, then we're OK with this scope, but it perhaps
should be clarified that what we are generating is an instance specific
graph and merging issues are not herein addressed. If however we are
talking about a graph that should be mergeable with any other RDF graph
without any considerations beyond tidying of nodes with equivalent URI
labels, then we have the issue of creating bNode identifiers which are
unique for that broader scope, which may in fact span more than one
system. In such a case, would it be too presumptuous to recommend
(though not mandate) GUIDs or UUIDs as bnodeID values?

9. Section 5.26, the names subject, predicate, and object are not included
in the listed terms included in the RDF namespace given in section 4.4, 
where it presents an "exhaustive" list of terms.

10. Section 5.27, some discussion (possibly) should be provided for
scenarios where there is a mingling of rdf:li and rdf:_n in the actual
serialization. Should li-counter consider the explicit _n values?
Should it ensure resume counting after the explicit _n value? Does
the parser have to ensure no collisions or does it create a partial
ordering? 

11. Section 6, should a recommended algorithm for generating qnames
on re-serialization be provided? One simple means of achieving 
reasonable round-tripping of at least qnames is to provide the
RDF/XML writer with a set of namespace declarations to use and
have it select for each URI the namespace which has the maximal 
intersection with the URI and use that for deriving the qname. 

12. Appendix A.2 rdfms-qname-uri-mapping, this issue also includes
the potential for collision, not just "wrong" URIs.

13. Appendix A.2 rdfms-difference-between-ID-and-about, should the 
decisions about this be more explicit in the normative sections?

[Note: I didn't review Appendices B and C]

--

Cheers,

Patrick
Received on Thursday, 13 December 2001 20:18:40 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:43:03 EDT