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

> 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

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

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

Best Regards,

Ivan Mikhailov
OpenLink Software

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:08 UTC