W3C home > Mailing lists > Public > semantic-web@w3.org > March 2011

Re: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"

From: Nathan <nathan@webr3.org>
Date: Sun, 20 Mar 2011 22:18:12 +0000
Message-ID: <4D867D24.5050607@webr3.org>
To: Kjetil Kjernsmo <kjekje@ifi.uio.no>
CC: David Booth <david@dbooth.org>, Tim Berners-Lee <timbl@w3.org>, SW-forum Web <semantic-web@w3.org>
Kjetil Kjernsmo wrote:
> On Friday 18. March 2011 22:45:33 David Booth wrote:
>> 2. Because this kind of ambiguity of reference is inescapable (though
>> the example is an extreme case), so we have no choice but to learn to
>> deal with it.  
> 
> So, what you're saying is "relax, whether it is an RDF Graph or an RDF 
> Document is not important to specify, ambiguity is inescapable and can be 
> useful"? 
> 
> I can see that point, and I appreciate the arguments that you make. However, 
> it still seems that accepting this means accepting what webarch calls a URI 
> Collision. 
> 
> Also, I very much appreciate Sandro's clean sheet terminology. This new 
> terminology is unfortunately not currently available as normative reference, 
> and for such a simple protocol as we currently discuss, I feel that we should 
> be able to specify it clearly enough for all practical purposes without.
> 
> There are two points that I feel has not been answered yet, and that's whether 
> the apparent conflict that I think I see between the usages of RDF Document and 
> RDF Graph are real, is the ambiguity real? And if so would a URI collision be 
> acceptable? 

well, it depends if you mean g-text, g-snap or g-box when you say "RDF 
Graph" and "RDF Document"

If you mean:
RDF Graph = g-text, *and* RDF Document = g-box, *and* the RDF Document 
never changes, that is to say the g-text is the one and only 
representation of the g-box, then there is no URI collision.

In all other cases there is an ambiguity and a URI collision.

I won't speak to whether that's acceptable or not.

Best,

Nathan
Received on Sunday, 20 March 2011 22:18:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:24 UTC