Re: Metadata about single triples

On 2/22/12 1:58 PM, Barry Norton wrote:
> 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?

Ah! Correct. I misread the response :-)

>
>
>>>> 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.

Very application dependent. Re., Virtuoso, if you had to keep triples 
across Named Graphs in sync (as an application requirement), you can 
leverage graph delta-syncs using inbuilt functionality. Then you don't 
have to perform the multiple statements above.

One common use case of Named Graph partitioning is data staging. For 
instance, cross links across dataset where you want to keep the mappings 
in a separate named graph. This is something we do regularly re. 
DBpedia. The one time we forgot (re. New York Times to DBpedia dataset 
mapping), it quickly created problems for services like sameas.org .  
This also means that updates and deletes apply to one named graph 
instead of the entire DBpedia dataset which has its own named graph IRI.
>
> Barry
>
>


-- 

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