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

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".


> 
>> [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.


--Frank


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Saturday, 13 October 2001 11:13:59 UTC