Re: TriG and default graphs

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