- From: Dave Beckett <dave.beckett@bristol.ac.uk>
- Date: Fri, 14 Dec 2001 14:33:40 +0000
- To: w3c-rdfcore-wg@w3.org
In reply to my message http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Dec/0075.html Summary: 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 http://ilrt.org/discovery/2001/07/rdf-syntax-grammar/ (CVS http://cvs.ilrt.org/cvsweb/redland/rdfcore/syntax/index.html ) At this time I've got reviews from Dan Brickley http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Dec/0077.html Jos De Roo http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Dec/0095.html Patrick Stickler http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Dec/0096.html I've replied to each comment below, where it isn't a simple typo. Dave ---- General comments (Jos) 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). (Patrick) 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 (Patrick) 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 <rdf:Description> <dc:creator> <rdf:Description> <ex:homePage rdf:resource="http:/.../" /> </rdf:Description> </dc:creator>> <rdf:Description> and filling out to: <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:ex="http://example.org/stuff/1.0/"> <rdf:Description rdf:about=""> <dc:title>RDF/XML Syntax Revised</dc:title> <dc:creator> <rdf:Description> <ex:fullName>Dave Beckett</ex:fullName> <ex:homePage rdf:resource="http:/.../" /> </rdf:Description> </dc:creator>> <rdf:Description> </rdf:RDF> 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 (Patrick) 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" (Patrick) 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. 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 (Patrick) 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 words. 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. (Patrick) 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. (Patrick) 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? 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. (Patrick) 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 (Patrick) 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. (Patrick) 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 (Dan) "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? (Jos) in "3 Data Model" last line ... part of the node ro computed from the string-value of contained nodes. ^^or (Jos) in "3.6 Identifier Node" 2nd sentence ... These nodes are created by giving two values for the for the ... ^^^^^^^ (Jos) in "5.9 Production resourcePropertyElt" the N-Triples statement ... e.parent.subject.string-value <e.URI> n.subject.string-value; . (Patrick) 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. (Patrick) 5. Section 3, list item "Element Information Item", you're missing a square bracket after "local name". ^ (Patrick) 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