shared bnodes (Re: RDF dataset semantics again)

On 08/23/2012 09:08 AM, Antoine Zimmermann wrote:
> Le 23/08/2012 13:11, Sandro Hawke a écrit :
>> On 08/23/2012 05:57 AM, Antoine Zimmermann wrote:
>>>
>>>
>>> Le 22/08/2012 18:37, Sandro Hawke a écrit :
>>>> On 08/22/2012 12:30 PM, Antoine Zimmermann wrote:
>>>>>
>>>>>>
>>>>>> I could live with it if there were a syntactic sugar, probably
>>>>>> involving
>>>>>> curly braces. :-)
>>>>>
>>>>> Yes, the syntax is not really practical.
>>>>>
>>>>
>>>> Indeed. But, yes, it's a nice way to think about the semantics. I
>>>> understood it to be a way the WG was not okay with.
>>>
>>>
>>> My impression was that the group found the idea reasonable, possibly
>>> appealing, but due to a total absence of implementation of this
>>> solution, and no experience with it thereby, it was not a good idea to
>>> standardise such a thing.
>>>
>>>
>>
>> I don't recall hearing that, but it makes sense.
>
> It's my own interpretation of the situation at that time, but I don't 
> think we formalised this as a resolution.
>
>
>>>> One bit that doesn't quite work is that some of the use cases require
>>>> blank nodes to be shared between named graphs. That would be rather
>>>> strange with this literal-strings model.
>>>
>>>
>>> It is in principle possible to define the datatype such that the value
>>> space is not exactly the set of RDF Graphs, but rather "RDF Graphs
>>> where some bnodes can be labelled". The bnode labels are made disjoint
>>> from URIs, so they can be distinguished apart from normal names, but
>>> they would not be purely local to the graph.
>>>
>>
>> I'm not sure you'd need to change the value space. Existing (2004)
>> g-snaps can share bnodes, it's just the way the syntaxes are parsed
>> doesn't currently allow one to indicate that.
>
> But it's never possible to know that two graphs share the same bnodes, 
> as it is impossible to identify them in a RDF Graph.
>

That's not true.   It's easy when the two graphs are both subgraphs of 
some other graph, right?

Given this graph (g0) of two triples:

    _:x :p1 1,2.

There is a subgraph g1:

    (blank node) :p1 1.

and a subgraph g2:

    (blank node) :p1 2.

and those two graphs (g1 and g2) share a bnode.

This situation is easily handled in SPARQL and in various RDF APIs. It 
is required for various use cases, such as
http://www.w3.org/2011/rdf-wg/wiki/Why_Graphs#Separation_of_Inference

>> So, those graphs-in-quotes
>> would have to be parsed as some new kind of thing -- a
>> document-fragments, instead of a document. A little problem, IMHO, not a
>> big one.
>
> For me, "bnode sharing" is not exactly about sharing bnodes in RDF 
> Graphs. It is a case when you want to identify two bnodes in two 
> distinct RDF graphs, and consider that they can be unified when 
> combining the two RDF graphs. In fact, it does not much matter whether 
> the two bnodes are different, as long as you can indicate that they 
> can be unified in a union/merge operation.
>
> If I have { _:b  prop  _:c } and you have { :x  foo  _:b } and we 
> decide that the two (_:b)s are unifiable, then it does not matter that 
> they actually identify the same bnode. As long as you're cool with the 
> fact that you want to unify them.

If you don't have a syntax or protocol (such as an RDF API) for 
constructing graphs with shared bnodes, then, yes, you need to indicate 
that some kind of unification is desired/appropriate.

It seems to me the simple. obvious, and appropriate way to handle this 
for most use cases is to allow blank node labels to be shared between 
different parts of a multi-graph document.

An alternative would be to somehow use our Skolemization URIs, but that 
seems much more awkward.

> Think of bnodes as black marbles that have the exact same atomic 
> structure. You cannot distinguish them, apart from their position. If 
> you separate out a marble from a graph, and fix another marble there 
> instead, nothing changes. The result is still a black marble at the 
> same position. Anyway, they only indicate the existence of a thing, so 
> one bnode is as good as any other.
>
> However, if I play with these marbles, building a very big graph, that 
> I later record as Turtle, then put back the marbles in their pouch. 
> And I'd like the day after to extend that big graph with more triples, 
> I may have to assume that some of the marbles I'm using can be 
> identified to the marbles I used the day before. And still it does not 
> matter that I reuse the exact same marbles.
>

I think of blank nodes as locations on a surface (thanks to Pat). 
Multiple graphs may be drawn on that surface, using that blank node.   
They can be distinguished from each other by being different colors, or 
written on different transparent layers, or you just remember which arcs 
are part of which graphs.

>
>> IMHO we should at some point sketch out this solution and its
>> isomorphism to whatever we settle on. Maybe not actually assign a
>> vocabulary to it, lest people use it and not be interoperable.
>> Alternatively, it might be the way RDF/XML folks play in the named-graph
>> space. (That's a Time Permitting deliverable in our charter.)
>
> Ivan drafted something a while ago where he defined a datatype for 
> graphs. However, what I think made the document problematic, is that 
> it was trying to address too many things at the same time. We could 
> take out of Ivan's draft the part on defining the graph datatype, 
> together with portions of the discussions in there, and propose it as 
> a WG Note, maybe.
>

  Perhaps, but let's find our core solution first, then circle back and 
think about how to explain it for various audiences.

     -- Sandro
>
> AZ
>
>
>>
>> -- Sandro
>>
>>>
>>>
>>>>
>>>> -- Sandro
>>>>
>>>>>>
>>>>>> - s
>>>>>>
>>>>>>>>
>>>>>>>> Another (uglier!) representation would be
>>>>>>>> <g> ex:hasGraph
>>>>>>>> <data:text/turtle;charset=UTF-8,%3Cs%3E%20%3Cp%3E%20%3Co%3E> .
>>>>>>>>
>>>>>>>> Which would also allow you to make statements about the quoted 
>>>>>>>> graph
>>>>>>>> <data:text/turtle;charset=UTF-8,%3Cs%3E%20%3Cp%3E%20%3Co%3E> 
>>>>>>>> dc:date
>>>>>>>> "2012-08-22T14:29:23Z"^^xsd:dateTime .
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>>
>>>>>>>> - Steve
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

Received on Thursday, 23 August 2012 13:59:28 UTC