Re: shared bnodes

On 08/24/2012 07:15 AM, Andy Seaborne wrote:
>
>
> On 24/08/12 11:39, Richard Cyganiak wrote:
>> On 24 Aug 2012, at 11:19, Antoine Zimmermann wrote:
>>> So, I'm saying that you can just forget about trying to identify
>>> equal bnodes across graph, and simply rely on a local identifier in
>>> one graph, a local identifier in another graph, and tell with a
>>> dedicated mechanism that these two locally identified bnodes are
>>> assumed to be the same.
>>
>> I think I'm +1 to this sentiment.
>>
>> So far, the only argument in favour of allowing shared bnodes that I
>> can recall was to manage inferred triples in a separate graph.
>

I think almost any kind of from-RDF and to-RDF data processing is likely 
to need this, if it's working with data that includes blank nodes.     
You might call that all "inference", but if so, it's quite broad.

> And sub/union graphs in general.
>
> Union graphs for those systems that already make one graph the union 
> of all others.  Whether we like it or not, those systems are common, 
> even maybe even the majority, and have been for several years.
>
> It is the compromise of the context point-of-view and the 
> multiple-graphs point-of-view.  In the context POV,
>
> (this is not advocacy, more like 'history')
>

agreed.

To put that slightly differently: shared bnodes are also required for 
the SPARQL dump & restore use case.

>>
>> This is a valid and compelling use case. But an equally valid use
>> case would be to manage all the inferred triples in another
>> *dataset*. So, if I can infer some triples from graph g1 in dataset
>> DS, then I can just store these triples in a graph named g1 in
>> dataset DS_inference.
>
> The use case includes being able to have one "thing" which as both 
> base and inferred information in it.
>
>>
>> Can datasets share bnodes?
>>
>> The whole bnode sharing thing brings a lot of complexity with it. In
>> a complete graph store management language, I need operations for
>> "copy graph with bnodes intact", "copy graph with fresh bnodes", and
>> so on. Most users won't understand the difference and it will just
>> add to the general sense of bewilderment that surrounds bnodes.
>>
>> I say let's simplify things for once and disallow bnode sharing
>> between graphs. The use case above can still be addressed via skolem
>> IRIs.
>
> Shared bnodes are already a feature "out there".
>
> (can't say I ever see the "copy graph with fresh bnodes" arise)
>

I remember struggling with this in writing my first RDF database in 2001 
-- trying to decide whether to allow blank nodes to be shared between 
g-boxes.   I haven't really kept track, but my impression is nearly all 
APIs I've seen since then have allowed it.

So I don't think forbidding it in the model would be okay, in terms of 
respecting existing deployments.   Forbidding it in TriG is probably 
okay on that front, but would be a hassle for the inference use case, 
and ... I think ... would fail the SPARQL dump/restore use case.

         -- Sandro
>>
>> Best, Richard
>>
>
>     Andy
>
>

Received on Friday, 24 August 2012 15:52:31 UTC