- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Sat, 14 Dec 2002 12:33:07 +0000
- To: "Joshua Allen" <joshuaa@microsoft.com>, "Dave Beckett" <dave.beckett@bristol.ac.uk>
- Cc: "www-rdf-comments" <www-rdf-comments@w3.org>
At 22:43 13/12/2002 -0800, Joshua Allen wrote: > > Personally, I'm a bit nervous of that. My recollection is that the WG >has > > discussed these node id's as being file scoped. If we start making >them > > relative to the base uri then they are starting to look like URI's. >They > > are not and that will lead to confusion. > >Isn't BaseUri a way of scoping something by file? I may be misunderstanding the term. Does xml:base change the BaseUri? > Are there other ways >besides BaseUri to precisely define what a "file" scope is? Should we >consider items loaded into an infoset via XInclude or entity expansion >to be in the same "file"? That is certainly something we should be clear about. >I agree that people could be confused by the idea that something which >is meant to *not* have an ID (bnode) is assigned an ID in the XML >serialization. But I personally consider that an orthogonal issue to >the issue of BaseUri. Here is why: > ><http://www.cnn.com/> dc:Author _1 . >_1 ex:Name Joe . > >("CNN.com has author who is named Joe"). > >If you import that file twice, regardless of whether or not you change >the Name of the resource referenced by _1, the blank node _1 is *not* >the same resource across two different parsing activities, while the >named node http://www.cnn.com/ *is*. Well, the blank node is not a resource at all, in the sense you mean. Its a node in a graph. The question I think you are addressing is whether one can be sure its the same node in the same graph across two different parsings of the same file, and I agree with you in general, one cannot. >In other words, parsers MUST NOT use the same nodeID to reference the >same resource across multiple parsings of the same file. With this statement I'm not so sure I agree with you. Are we considering a parser which reads rdf/xml and writes n-triples, and by nodeID you mean the blank node id's in the n-triples? If so, a parser is free to reuse blank node id's across different parsings as the blank node id's are scoped by the "set of triples" they are in. i.e. one doesn't have to use GUID's. If two graphs respresented in n-triples are merged, then at that point one has to disambiguate. You might chose to have your parser always generate unique blank node id's but that is an implementation strategy, not a spec requirement. > This is >covered appropriately in the spec, since it needs to be covered for >nodeIDs that are *not* scoped by file, so it is already covered for >nodeIDs that *are* scoped by file. I didn't understand that bit. Brian
Received on Saturday, 14 December 2002 07:31:54 UTC