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

On 2012-09-26, at 18:25, David Wood wrote:

> 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

I think I've already said this, but this scheme simply doesn't work in the general case.

There's no reliable way to separate metadata about graph <A> from metadata about graph <B>.

Suppose I have the following dataset:

DEFAULT {
   <A> dc:date "2012-09-27" ;
           dc:creator <myscript12.3> .
   <B> dc:date "2012-09-27" ;
           dc:creator <myscript12.3> .
    <myscript12.3> :name "MyScript" ;
                :version 12.3 .
}
<A> {
   …
}
<B> {
   …
}

And I want to update the metadata about <B>, how can I do that practically? This is a relatively trivial example, obviously, but it shows some of the problems.

Plus, paraphrasing what Lee said, leaning heavily on a feature of SPARQL that many people actively go out of their way not to use is silly.

- Steve

-- 
Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
80 Victoria Street, London, SW1E 5JL