W3C home > Mailing lists > Public > public-rdf-wg@w3.org > November 2012

Re: TriG and default graphs

From: Ivan Mikhailov <imikhailov@openlinksw.com>
Date: Mon, 05 Nov 2012 02:55:51 +0700
Message-ID: <1352058951.3008.741.camel@octo.iv.dev.null>
To: Yves Raimond <yves.raimond@bbc.co.uk>
Cc: public-rdf-wg@w3.org
Yves,

> On 24 Oct 2012, at 17:29, Yves Raimond wrote:
> 
> I'd really like to understand what the rationale is behind supporting default graphs in TriG, apart from backward-compatibility.

I've suddenly got an answer for this question.

I'm experimenting with an extension for "federated SPARQL", to allow the
result of SPARQL 1.1 CONSTRUCT query be used as a source of another
SPARQL 1.1 query. I.e., I allow to write nested CONSTRUCTs (local or
federated) instead of (or as an addition to) plain FROM and FROM NAMED
clauses.

In this use case, TriG is a perfect data transfer format to get a SPARQL
dataset  from a remote endpoint(s). Default graphs form a default graph
of the dataset, properly separated from named graphs of the dataset. If
the default graph should go to storage, as in SPARQL 1.1 INSERT, a WITH
clause will indicate the destination "named" graph for it.

(
What might be _really_ funny extension is bnodes as graph names. I don't
want to put such graphs into quad store but they may be good hints for
querying.

If a dataset consists of numerous small clusters of facts, and <fn> is a
non-index-friendly function then a graph group pattern
graph ?g { ?s1 <p1> ?o1 . ?s2 <p2> ?o2 . filter (<fn>
(?s1, ?o1, ?s2, ?o2 )) }
may be orders of magnitude faster than
?s1 <p1> ?o1 . ?s2 <p2> ?o2 . filter (<fn> (?s1, ?o1, ?s2, ?o2 ))
However in case of federated SPARQL or other on-demand data generation
that require composing unique temporary graph IRI for each cluster, and
garbage IRIs is an unwanted overhead for both generation and receiving
ends.
)

Best Regards,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com


Received on Sunday, 4 November 2012 19:56:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:52 GMT