Re: shared bnodes (Skolems, SPARQL)

On 08/29/2012 08:43 AM, Steve Harris wrote:
> On 2012-08-29, at 13:15, Sandro Hawke wrote:
>> On 08/28/2012 11:52 AM, Steve Harris wrote:
>>> On 2012-08-24, at 16:52, Sandro Hawke wrote:
>>>
>>> … snip …
>>>
>>>>> 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.
>>> Yup, that was one of the motivations for Skolem URIs.
>> How would that work, if there was already Skolmized RDF in the dataset?    (And there will be, if your dataset comes from crawling other people's data sources, and those data sources emit Skolemized RDF, as we're expecting they will sometimes.)
>>
>> I guess you could make a new Skolem prefix (eg http://example.com/.well-known/genid/backup-20120829T081103/) and genid your bnodes to new URLs starting with that string -- and then pass that string along with the backup file.     But keeping those together might be difficult, and if you're going to do that, there's no need for any sort of standard format for Skolems.
> Well, in 4store (for e.g.) the Skolem URIs generally look like:
>     http://4store.org/.well-known/genid/[UUID_for_DB]/[ID_number]
> so the store can recognise it's own bNodes, and convert them back into internal IDs if it gets them back.

I'm not quite sure what a DB is, but it seems like it would be kind of 
hard control whether the nodes are de-Skolemized on database-restore -- 
users would have to understand whether they were loading it into the 
"same" DB or not.

> Other Skolem URIs in .well-known form can also be converted into new internal bNode identifiers, in the same way bNode labels are, but they're globally unique, so you can safely map any Skolem URI to the same bNode ID across graphs. I don't know for sure if 4store does this or not, but it could.

Is it okay for RDF client software to silently and automatically turn 
Skolem IRIs back into blank nodes?    (That will change the results of 
some SPARQL queries on that data.)   If it does this, how long does it 
have to keep the IRI-bnode map around?   For as long as it has that 
blank node?

I don't know the best answer to these questions, or even if we have to 
answer them, I guess.

>   To be honest bNode sharing in Trig hasn't come up in user requests, so I don't think anyone's tried it.

*nod*

       -- Sandro

Received on Wednesday, 29 August 2012 14:59:20 UTC