- From: Sampo Syreeni <decoy@iki.fi>
- Date: Mon, 20 Dec 2010 20:41:36 +0200 (EET)
- To: Michael Schneider <schneid@fzi.de>
- cc: Melvin Carvalho <melvincarvalho@gmail.com>, Semantic Web <semantic-web@w3.org>
On 2010-12-19, Michael Schneider wrote: >>> Since RDF is a set, the duplicate triple is disgarded. So Alice >>> still is described as owning one dog. >> >> Alice owns _1: which is a dog, alice owns _2: which is a dog, which >> are not necessarily the same unless by some other logic we can >> conflate them. > > One has to distinguish between the syntactic and the semantic > situation. [...] So basically you're talking about the fact that nowadays we compare graphs modulo leanification. I always forget about that, because it wasn't always so. I do that because from my relational background, it would be *so* much more complicated in full than from RDF's simplified, graded, binary model. But do remember, even here you have to assume that the two graphs you gave would have to be the full graphs. If say even a single triple of the form _1: :hasColour :blue was added, the leanified version would be different. That is to say, when you look at leanified graphs only, they never stand alone; you have to give the whole context before you can infer upon them. I'll have to defer to the real mathematical logicians around here, like Pat, but I do think this is an instance of nonmonotonicity, introduced by leanification/modulo-graph-isomorphism-thinking. Very much a hindrance to efficient inference, then, and probably something which has to do with the multiple layers of OWL we now have. (I've also pretty much killed myself trying to explain the precise same complexity boundary to my relational coworkers: how do you write up code which actually continuously and incrementally graph-minimizes an arbitrary, n-ary relational database? Don't make any mistakes, it's even harder in the RDF environment, in the general case.) -- Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Received on Monday, 20 December 2010 18:42:18 UTC