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

RDF/XML Syntax Revised WD comments

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Fri, 14 Dec 2001 14:33:40 +0000
To: w3c-rdfcore-wg@w3.org
Message-ID: <30331.1008340420@tatooine.ilrt.bris.ac.uk>

In reply to my message

  Various typos (Dan, Jos, Patrick): accepted, details below
  Reification (Jos): staying until RDF Core WG decides otherwise
  General comments (Patrick): see below, some potential ACTIONs here

Typo changes are in CVS version 1.134  at

(CVS http://cvs.ilrt.org/cvsweb/redland/rdfcore/syntax/index.html )

At this time I've got reviews from

  Dan Brickley

  Jos De Roo

  Patrick Stickler

I've replied to each comment below, where it isn't a simple typo.



General comments

  I would propose to drop reification!
  so proposal to drop its sentences in 5.5, 5.9, 5.10, 5.11, 5.12 and 5.14
  as well as "5.26 Reification Rules"

I can't do this yet until we make a decision on reification.  Until
then, the rules to generate the right N-Triples should stay.  What
they *mean* isn't for this document (and isn't yet in the Model Theory).

  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? 

A section describing the RDF/XML URI/qname generation rule would be a
good idea.  I could also put the ID value to URI rule there.  A note
that there may be several namespace URI/local name combinations for
the same URI would be a good idea.

Potential ACTION for this draft: Add a short section about this

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

Yes, I intended to create examples with pictures based on Dan's
document but had no time.  Something along the lines of a picture

  [this document] -> [has a title] -> "RDF/XML Syntax Revised"
                  -> [has an author] -> [] -> [has a family name] -> "Beckett"
                                           -> [has a home page] -> [...]

and then expand the example to show the striping, and talk about the
blank node in the graph, generate the XML

starting from the stripy
        <ex:homePage rdf:resource="http:/.../" />

and filling out to:

  <?xml version="1.0"?>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    <rdf:Description rdf:about="">
      <dc:title>RDF/XML Syntax Revised</dc:title>
	  <ex:fullName>Dave Beckett</ex:fullName>
	  <ex:homePage rdf:resource="http:/.../" />

or something.

Actually I've just noticed that the RDF/XML syntax document contains
no XML!  This is funny.

Potential ACTION for this draft: Add at least 1 XML example

  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.

How about when a "property value is a literal string"

  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

I only every use "blank nodes" when talking about the graph (refering
to the model theory) or "bnodeIDs" when talking about emitting
N-Triple _:foo things.  This could be aded to the section about URIs
and IDs, I suggest above

Potential ACTION: Add this to the URIs/IDs section

  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.

The RDF namespace is defined in 4.4 and the (XML) prefix you mention
is not defined in there.  The notation I'm using is just so that in
the document we don't confuse, say rdf:subject (the term subject from
the RDF namespace) and the bare word subject and so on for other

I don't understand: "It is also probably misleading to state
conditions in terms of undefined prefixes."  It is defined.

However I have added a new paragraph to 4.4 to define this
rdf:... notation for the entire document, although it was also
introduced in the table in 4.2.

  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?

This document defines how to turn an RDF/XML document into a sequence
of N-Triples, forming an N-Triples document with local identifiers
for the blank nodes.  The scope of the blank node identifiers is the
N-Triples document, which generates an RDF graph.  I shall try to
explain further what these local (blank node) identifiers are and
their use.

The rest of your comments are more about the RDF graph and hence the
model theory.

We previously decided (at the last F2F) to not use globally generated
IDs for graph nodes with no URI; but create these blank node
identifiers, which are not URIs.

  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

The resolution of this issue and the consequent test cases already
define this.  The rdf:li generation rule takes no notice of explit
rdf:_n value and works as I described it.

See http://www.w3.org/2000/03/rdf-tracking/#decisions
and http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-containers-syntax-vs-schema/

This *may* generate duplicate N-Triples in the serialisation, but
these have the same interpretation in the graph.

As far as I know we are also neutral on containers (nodes) that have
duplicate rdf:_n values, since somebody may find that useful.

  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. 

Lots of heuristics are possible including the above.  If that was
recommended, it also would be a good idea to recommend recording
these namespace URIs/prefixes during parsing too.  Maybe we could
improve this for the next draft

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

This issue isn't decided; those words are just a suggestion.

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

I was wondering about making the rdf:ID value to URI conversion more
explicit and might pull that out.

Typos: all accepted

  "The RDF Model Theory ([RDF-MODEL]) is a graph consisting of nodes "

  ...the Model Theory itself isn't a graph; it's a theory. So we kind of
  want to say 'the RDF model is a', except we don't seem to use the word
  'model' that way anymore. Same goes for 'the RDF data model', I think.

  "The RDF Model Theory" [RDF-MODEL] defines RDF as a graph..." perhaps?

  in "3 Data Model" last line
  ... part of the node ro computed from the string-value of contained nodes.

  in "3.6 Identifier Node" 2nd sentence
  ... These nodes are created by giving two values for the for the ...

  in "5.9 Production resourcePropertyElt" the N-Triples statement
  ... e.parent.subject.string-value <e.URI> n.subject.string-value; .

  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".
  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.
Received on Friday, 14 December 2001 09:33:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:54 UTC