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