W3C home > Mailing lists > Public > public-lod@w3.org > February 2012

Re: Metadata about single triples

From: Barry Norton <barry.norton@ontotext.com>
Date: Wed, 22 Feb 2012 18:58:42 +0000
Message-ID: <4F453AE2.4060803@ontotext.com>
To: public-lod@w3.org
On 22/02/2012 18:18, Kingsley Idehen wrote:
> On 2/22/12 12:30 PM, Barry Norton wrote:
>> On 22/02/2012 17:21, Bob Ferris wrote:
>>> [...] Named Graphs unnecessary fragment complex descriptions into 
>>> (very) small piece due to their provenance descriptions*. So when 
>>> you would like to query this complex description at once you may 
>>> have to include many Named Graphs. This makes the SPARQL query 
>>> rather complex.
>>> A current workaround is to duplicate this fragmented knowledge into 
>>> a default graph to be able to easily query such complex descriptions 
>>> (without their provenance information). 
>>
>> But this is what (most?) triple stores do with the default graph in 
>> the absence of FROM/NAMED clauses in queries anyway. (Certainly this 
>> is the Sesame approach, followed by OWLIM.)
>
> Not so re. Virtuoso. The Graph IRIs don't matter. Only used them if 
> you explicitly seek to constrain the dataset from which you seek a 
> SPARQL based solution.

Actually, I think you are saying the same thing. If you don't nominate a 
FROM/NAMED clause in your query then you can use triple patterns across 
triples that 'belong' to different named graphs just as if you'd 
explicitly included FROM for each of the many graphs (except that you 
can also perhaps nominate graphs in quad patterns for all graphs too). No?


>>> This increases the maintenance costs as well and the (originally) 
>>> related knowledge is now decoupled.
>>
>> I didn't understand this - can you clarify? (I'm tempted to think 
>> you're talking about a real duplication, rather than the default 
>> construction of the default graph)
>>
>
> Same data across different Graph IRIs != duplication.
[...]
> See my comment above re. use of Graph IRIs re. SPARQL. They can serve 
> as Named Partitions for your data. You may have a variety of reasons 
> for having the same triples across many Named Graphs. Nothing wrong 
> with that :-)

OK, apparently I am missing something here: aren't updates more 
difficult to manage if you've... I just want to say duplicated again... 
propagated given triples across multiple graphs.

You could write:

DELETE {GRAPH ?g {?s ?p <old>}}
INSERT {GRAPH ?g {?s ?p <new>}}
WHERE {GRAPH ?g {?s ?p <new>}}

but there's no reason to assume it's kosher given just that you've 
'propagated' the triple across certain graphs.

Barry
Received on Wednesday, 22 February 2012 18:59:08 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:37 UTC