Re: Putting metadata in the "default" graph Re: Dataset Syntax - checking for consensus

Hi Lee,

On Sep 26, 2012, at 12:41, Lee Feigenbaum <lee@thefigtrees.net> wrote:

> On 9/26/2012 12:09 PM, David Wood wrote:
>> * Some designs for carrying for metadata
>> 
>> PROPOSED: In our dataset syntax, we'll say that metadata goes in the default graph
>> +0.5, especially if it can be aligned with SPARQL service descriptions.
>> 
>> 
> 
> What do existing systems do when importing a TriG file that contains data in the "default" graph? The Anzo store has no default graph, and therefore either throws an error or throws away any information in a TriG "default graph". Similarly, all TriG exported from Anzo does not have a default graph unless it's the serialization of a SPARQL RDF dataset (which by definition does have a default graph, of course).
> 
> I bring this up because I brought up a related thread on public-sparql-dev recently:
> 
> http://lists.w3.org/Archives/Public/public-sparql-dev/2012JulSep/0025.html
> 
> In that thread, I asked:
> 
> """
> Do all quad stores  / named graph stores include a default graph? If the store that you develop or use does have a default graph, does that graph also have a name (URI)?
> """
> 
> The answers were:
> 
> Anzo -- no default graph (except ones assembled on the fly for querying).
> OWLIM -- has a default graph with no URI
> RDF::Query -- has a default graph with no URI
> 4store & 5store -- default graph is a view on existing graphs (& therefore, I assume, doesn't exist for purposes of storing data) -- uses a "special" named graph for writing default data
> TDB -- can either have an actual default graph or just use the default graph as a view onto the other named graphs
> 
> Additionally, there was input from 3 implementers (SteveH, GregW, and Chime) that if they could re-implement their systems they would not include a default/unnamed graph.
> 
> All of which is to say, I think there's a fair amount of evidence that the "default" or unnamed graph is not consistently used, and perhaps not widely used. We need to support it for compatibility, but I think it's a mistake to specify that anything important be put in that graph.

I certainly agree that default graphs are used in inconsistent ways in existing systems and that the idea of a default graph in a system backing an HTTP or SPARQL endpoint is generally a bad idea.  However, that is not what is being proposed.

The proposal deals with syntax within a TriG-like document, specifically where metadata describing a graph goes.  It does not suggest where that metadata would be stored in a system that parses such a document.  It most certainly does not suggest that metadata in a default graph in a TriG-like document be put in the default graph in a system that parses such a document.

It would be nice (IMO) if such systems had a standard place to describe the graphs that they ingest.  That could happen via server-side implementations of SPARQL service descriptions or in some other way.  Right now, it happens in a wide variety of ways, many of which are out-of-band to an underlying RDF store.  Clearly that is an area ripe for standardization since almost everyone does it, but in non-standard ways.

Regards,
Dave



> 
> Lee
>