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.
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.
On the other side, many triple store vendors are already utilising statement identifiers internally. So why not utilising them externally as well by introducing URIs instead of internal identifiers.Well, the cost is in indexing a large number of small graphs for efficient querying (especially in the presence of queries with unbound graph IDs). This does seem to become a common requirement these days though.The biggest issue is 'giving up' your one chance at a utilisation for named graphs, since these are not hierarchical or applied as a set to triples. This, though, is an old argument...
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 :-)
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
smime.p7s
Description: S/MIME Cryptographic Signature
