Re: Problem with auto-generated fragment IDs for graph names

On 2/15/13 11:59 AM, Pat Hayes wrote:
> On Feb 14, 2013, at 4:36 PM, Eric Prud'hommeaux wrote:
>
>> >* Pat Hayes<phayes@ihmc.us>  [2013-02-14 11:13-0600]
>>> >>
>>> >>On Feb 14, 2013, at 8:02 AM, Eric Prud'hommeaux wrote:
>>> >>
>>>> >>>* Pat Hayes<phayes@ihmc.us>  [2013-02-13 23:16-0600]
>>>>> >>>>Manu, let me try to put the other case, in terms that approximate your self-confidence that you must be right. Obviously I am speaking here as an individual, not on behalf of the WG.
>>>>> >>>>
>>>>> >>>>On Feb 13, 2013, at 9:24 PM, Manu Sporny wrote:
>>>>> >>>>
>>>>>> >>>>>On 02/13/2013 05:11 PM, Richard Cyganiak wrote:
>>>>>>> >>>>>>PROPOSAL: Put @id on all graphs.
>>>>>>> >>>>>>
>>>>>>> >>>>>>Why the aversion against simple and obvious solutions?
>>>>>> >>>>>
>>>>>> >>>>>The simple and obvious solution you propose is wrong for developers.
>>>>> >>>>
>>>>> >>>>For all developers? That seems like a rather strong claim.
>>>>> >>>>
>>>>>> >>>>>
>>>>>> >>>>>It attempts to side-step an arbitrary constraint imposed on developers
>>>>>> >>>>>by RDF Concepts by making developers lives harder. Worse, it ignores the
>>>>>> >>>>>reality of transient messages, including transient RDF Datasets that
>>>>>> >>>>>must be identified with document-local identifiers if the digital
>>>>>> >>>>>signatures are going to work out.
>>>>> >>>>
>>>>> >>>>Well, this is the first time I have heard of "transient RDF". RDF, as far as I have always understood, was never intended to be transient. It is intended for publishing data on the Web. So it sounds as though you are simply using it for a purpose for which it was not designed, and never intended to be used. Perhaps your problems may arise from this mismatch between the intentions of the designers and your planned use.
>>>> >>>
>>>> >>>I'd characterize this more as "quoting RDF", which we've been wrestling with since the beginning.
>>> >>
>>> >>We have? News to me. It has come up*very*  occasionally, but nobody has argued for it very strongly in any WG activity. And in spite of TImBL's early interest in it, I have never seen anyone cite an actual use case. It would break (or seriously complicate) SPARQL.
>> >
>> >If I want to know who says the moon is made of what, I can ask supply
>> >data:
>> >  @prefix : <x:/>.
>> >  { _:doc1 :author "Bob" }        # default graph
>> >  _:doc1 { :TheMoon :madeOf :greenCheese }
>> >query:
>> >  PREFIX : <x:/>
>> >  SELECT ?who ?what {
>> >    ?doc :author ?who
>> >    GRAPH ?doc { :TheMoon :madeOf ?what }
>> >  }
>> >results:
>> >  ┌───────┬──────────────────┐
>> >  │ ?who  │ ?what            │
>> >  │ "Bob" │ <x:/greenCheese> │
>> >  └───────┴──────────────────┘
>> >
>> >The system that did this passes all of the SPARQL CR tests.
> OK, I am impressed. I wasnt aware that SPARQL allowed variables in graph name position.
>
> But let me ask you about this example. You are assuming here that the _:doc1 in the triple in the default graph, and the _:doc1 used as a graph label, refer to the same thing, which is the moon-green-cheese graph, right? What is interesting here is that this assumption seems inevitable when we have a bnode involved, as here, but (the WG has decided) it cannot be assumed when an IRI is used. So this data:
>
> {ex:doc1 :author "Bob" }
> ex:doc1 {:TheMoon :madeOf :greenCheese }
>
> does*not*  entail that Bob is the author of the graph (since 'ex:doc1' might denote something else, which is what the default graph would be about, and not about the graph.) So this actually gives us a new, Manu-independent, reason to allow bnodes as graph labels in datasets: they provide exactly the missing expressivity that is needed to have the default graph act as genuine metadata.
>
>
+1


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen