Re: importing and entialment

> The final discussion of owl:imports at the f2f kind of melted down, 
> for which I take much of the blame. Afterwards it occurred to me how 
> to phrase the statement everyone wanted to make about owl:imports so 
> as to avoid all the unwanted implications. Not surprisingly, it is 
> easy, and it has to do with the model theory:
> 
> ------------
> owl:imports BBB
> 
> is true in an interpretation I just when the owl KB gotten by 
> dereferencing BBB is true in I, OR if there is no such owl KB.
> -------------
> 
> If there isn't any such document, therefore, this is just plain true, 
> which makes it kind of vacuous in that case. But if there is, then 
> the imports assertion amounts to the same as asserting that KB inside 
> this KB.
> 
> So in this case:
> 
> A:
> socrates rdf:type B:human .
> 
> B:
> human rdfs:subClassOf mortal .
> 
> C:
> owl:imports B
> socrates rdf:type B:human
> 
> then A does not entail
> 
> D: socrates rdf:type B:mortal
> 
> but C does, provided of course that the imports worked; since in that 
> case the imports statement is only true in interpretations which make 
> B true. If the imports failed, then C wouldnt entail D, but not 
> because 'entails' changes its meaning, but because in that case 
> asserting C doesnt amount to saying as much as it does when the 
> imports did work. In effect, C gets smaller when the imports fails.
> 
> Note, this uses the usual notion of entailment, so entailment is not 
> subject to the whims of 404 errors. Also note, this does not say that 
> anyone is under any obligation to do anything (such as load a file) . 
> It only says what is being claimed to be true.

Thanks for the update, Pat (I am sorry I missed the "melting" ;)

The above goes towards the operational import ([1]), so I can't that be glad. There's one difference, and then non-differences. Let's call the above the "entailment import" to differentiate.
Let's start with the non-differences:

Current apparent differences: 404s errors, and "no obligation".
"404s": the "whims" of the 404 errors are in fact there, in the "OR" part of the definition, so it's just terminology (right? ;), hence this is not a real difference.
"no obligation": this can be seen as a difference, but only with the rfc2119-MUST version of the operational import, which already seemed too strong. In fact, the rfc2119-SHOULD or rfc2119-MAY gives you no obligation. In fact, the entailment import seems exactly equal to the rfc2119-MAY version of the operational import.

Now the difference:
The entailment import pays its more elegant formulation in the fact it's more limited wrt the operational import, as it doesn't allow to do other things that are not just entailment.
Example: you'll remember the discussion we had at the f2f in Amsterdam, where Frank (and Ian, I think) posed the problem that using RDF as exchange syntax we would lose important syntax info (like modules, ontology boundaries etc). At the time, I suggested to stick special comments (verbatim from the f2f, "annotations") directly in the RDF graph. Not that we decided anything about this (btw, this can still be very relevant to the versioning issue, cf. [1]...), but it's just an example.
These "comments" are transparent to the model theory, henceforth, they don't "exist" in the entailment realm. More practically, if an ontology B had such ontology/modules/UML annotations, then a
> owl:imports B
> socrates rdf:type B:human
like proposed above would necessarily be limitative and don't include those annotations.
So, staying in the entailment realm only (which is without doubt elegant) has as countereffect losing power in other contexts (out of the entailment realm). This can't be fixed later, because then we would have interoperability problems. To fix it now, we'd have to add something about the "operational import", falling in the original def of operational import (in an rfc2119-MAY or SHOULD flavor).

Summing up: both entailment and operational imports are good because the actual import info is in the graph (yes! :). The only real difference, apart from terminologics (admittedly, entailment import has a much more sexy formulation to mathematicians ;), is the above. So, it all depends on whether we want an operational definition (to deal with everything you can do with RDF graphs, now and *in the future*), or we are happy to stay within the entailment realm only.

-M


[1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0019.html

Received on Wednesday, 9 October 2002 13:23:11 UTC