- From: Sandro Hawke <sandro@w3.org>
- Date: Sat, 17 Dec 2011 08:09:44 -0500
- To: William Waites <wwaites@tardis.ed.ac.uk>
- Cc: phayes@ihmc.us, david@3roundstones.com, public-rdf-wg@w3.org
On Sat, 2011-12-17 at 10:29 +0000, William Waites wrote: > On Sat, 17 Dec 2011 00:43:38 -0500, Sandro Hawke <sandro@w3.org> said: > > sandro> We haven't quite figured that out yet. I'm proposing one > sandro> part of that is that a dataset being true implies its > sandro> default graph is true. > > What about this, > > :a { > :moon :substance :green_cheese . > } > > :b { > :moon :substance :blue_cheese . > } > > :c { > :bob :thinks :a . > :alice :thinks :b . > } > > This is all fine and true and everything. But what then in the > (common) case where the default graph is the union of all named > graphs, we have the merge of :a and :b which (suppose) is false > because we know the moon is only made of one kind of cheese? Merging the named graphs may be common, but I don't think it's truth-preserving. So, don't merge the labeled graphs unless you're willing to take responsibility for the conclusions. In terms of an entailment test: <a> { <b> <c> <d> } does NOT entail { <b> <c> <d> } Speaking of these default-is-the-merge datasets... I don't know how one is supposed to backup/restore them, or how one is supposed to put metadata in them. It would probably be good to have a flag saying this is one of those default-is-the-merge datasets, but I don't know where to put that flag, except in the default graph. (In SPARQL 1.1, I could put it in the Service Description, but that's not part of the dataset, and wouldn't come out in a TriG file.) Maybe default-is-the-merge should be handled as a special case: in serial form, the default graph is { <> a rdf:DefaultIsMergedDataset }, but in a running server, that flag is elsewhere, and the default graph is the merged group. That's a total hack, though, and I'm sure will cause other problems down the road. -- Sandro
Received on Saturday, 17 December 2011 13:09:59 UTC