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

Re: ACTION 2001-10-12#5: frankm respond to gk text

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Sun, 14 Oct 2001 17:42:05 -0500
Message-Id: <p05101023b7efc47c511b@[]>
To: Frank Manola <fmanola@mitre.org>
Cc: w3c-rdfcore-wg@w3.org
>Pat Hayes wrote:
>>>A clearer explanation of how our resolution affected the questions 
>>>that were originally raised would explicitly address the existence 
>>>of the locally-generated names we talk about (at least in 
>>>Ntriples), and would go something like this:
>>>"This resolves specific questions in the original issue raised thus:
>>>[1.] Should anonymous resources have URI's?
>>>  -- No (point 1 above).  However, they are assigned local names, 
>>>of the form '_:name'.  These names are not URIs, and their scope 
>>>is the N-triples document in which they appear.
>>Er... be careful. Those are names for NODES, not for the resources 
>>that the nodes refer to in the RDF semantics. We really should be 
>>careful not to say anything that could be read as saying that these 
>>'_:name' thingies are names of anything in the RDF semantic domain. 
>>They are entirely to do with the Ntriples-to-graph mapping, which 
>>is a mapping between two different syntaxes. By the time one gets 
>>to talking about resources (the ones that the RDF graph is talking 
>>about) those bNode names are completely gone. An unlabeled node 
>>really has NO label. (Which is why it makes perfect sense that they 
>>should not be URIs, by the way.)
>Point taken.  How about this?
>[1.] Should anonymous resources have URI's?
>  -- No (point 1 above).  However, in order to refer to bNodes in 
>N-triples, the bNodes  are assigned local names, of the form 
>'_:name' (point 2 above).  These names are not URIs, and their scope 
>is the N-triples document in which they appear.
>It also might be worthwhile, in order to nail this point down, to 
>change point 2 from starting "To reflect un-named descriptions in 
>N-triples" to "To refer to bNodes in N-triples".

I'm happy with both of these.

>>>[2.] If so, should they be clearly distinguishable as parser 
>>>generated URI's?
>>>  -- Stricly speaking, the parser is not required to generate URIs. 
>>>The parser *is* required to generate local names (that are not 
>>>URIs) for anonymous resources. These names *are* distinguishable 
>>>from URIs.
>>What exactly is 'the parser' here? (Parser of what?) If the parser 
>>is parsing an Ntriples document, then the bNode ids are in the 
>>document already and nothing needs to be generated. If the parser 
>>is dealing directly with the graph syntax, then there is no need 
>>for the bNode labels at all, and nothing needs to be generated. If 
>>the parser is reading RDF/XML and constructing a graph, no new 
>>names need to be generated. The only case that requires generating 
>>any new names is when something is reading either a graph or 
>>RDF/XML, and *generating* an N-triples document. In that case, and 
>>that case alone, it needs to generate some bNode names (since the 
>>Ntriples syntax requires them and they aren't present in any other 
>>version of RDF.)  But that is an issue with Ntriples, not 
>>(centrally) with RDF itself, and I think we should keep those 
>>issues separate. Our remit, after all, is to clarify RDF; 
>>N-triples is only a handy notation we have invented for describing 
>>RDF graphs, right? The graph is central.
>Graham's point 1 starts off talking about "Resources that are 
>described but not
>named in an XML serialization", so I had assumed that the parser in 
>question was
>an XML parser.  Also, as you say, any "parser" reading a graph and generating
>N-triples would also need to generate bNode names.  I think one of the things
>we need to keep in mind in constructing this (and some other) text 
>is that people who had issues with the M&S don't necessarily have 
>this "graph is
>central" point of view that we've adopted;  they may very well think
>(encouraged by various statements in previous writings about RDF) 
>that the XML syntax is what's central, and the graph is just an 
>expository mechanism.   We're going to have to make sure we get the 
>"graph is central" idea across.

Right, but that is a more global effort; and in the meantime, lets 
just make sure we always say 'XML parser' or whatever. I honestly was 
not sure what you meant here, hence the screed.

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Sunday, 14 October 2001 18:42:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:05 UTC