- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Wed, 26 Sep 2012 13:35:41 -0400
- To: David Wood <david@3roundstones.com>, RDF WG <public-rdf-wg@w3.org>
On 9/26/2012 1:25 PM, David Wood wrote: > Hi Lee, > > On Sep 26, 2012, at 12:41, Lee Feigenbaum <lee@thefigtrees.net > <mailto: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. Isn't it about where metadata describing the _dataset_ 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. Well, but what I'm saying is that data in the named graph parts of a TriG document is going to be used pretty consistently when put into a store. If I take a TriG doc and load it into my favorite store, I can pretty predictably figure out how to access the data from the named graphs via SPARQL. I can't do the same thing with data that was in the unnamed TriG graph. So, given the choice, I'd rather put information into named graphs in the TriG doc then into the unnamed graph. I'd even rather invent something entirely new (like a @meta directive) such that I can specify what ought to be done with it rather than rely on the inconsistently used default/unnamed graph. Lee > 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 >> >
Received on Wednesday, 26 September 2012 17:36:09 UTC