Re: Default Graph Contents

* Souripriya Das <souripriya.das@oracle.com> [2011-03-09 13:53-0500]
> Please see my answers inline. -- Souri.
> 
> On 3/9/2011 12:54 PM, David McNeil wrote:
> >Yesterday in the working group conference call we did not directly answer this R2RML question:
> >
> >For a SPARQL query that does not specify any "FROM <x>" or "FROM NAMED <x>" or "GRAPH <x>" clauses, what is expected to be in the default dataset for this query? I can think of a few possible  answers:
> >
> >1) Only those triples defined by the mapping to be in the unnamed graph
> >2) All of the triples defined by the mapping (including those produced in the unnamed graph as well as in named graphs)
> >3) This is an implementation specific detail that R2RML does not address
> >
> My position is that R2RML should not say anything about it. This will be decided by semantics of SPARQL (protocol and query language). In the scenario you mentioned, current SPARQL semantics says that the query will be executed against the default graph, which in a simple case consists of the set of triples in the unnamed graph.

I think Souri's position is consistent with my recollection of SPARQL Query's ambiguity around what's allowed in a default graph. I'm not sure that extending that ambiguity is helpful here. I'm a big fan of being able to query the aggregation of all data, but I think this will raise the implementation burden, and that simply not saying will produce damaging unpredictability. I propose that the default graph contain *only* those arcs specifically imposed by the R2RML directives.

This specifically does not address the use case of searching all of the triples without respect to which graph they find themselves in. We could say that the contents of the graph <> are implementation-specific, which would encourage folks to put metadata there, and possible recapitulate all of the data in all graphs.

Just my guess about what will give the sweetest trade-off between implementability and usability.


> >A related issue is whether an implementation is allowed to add triples (either in the unnamed graph or a named graph). For example, can an implementation add triples that are metadata describing the relational database or the mapping itself. This would be roughly analogous to the "system" tables provided by relational databases.
> >
> This is an interesting idea. I can see its use in specifying schema triples (such as, hierarchy and equivalence of properties and classes) that could be used by an implementation during SPARQL to SQL translation.
> >-David
> Thanks,
> - Souri.
> 

-- 
-ericP

Received on Wednesday, 9 March 2011 19:27:05 UTC