- From: pat hayes <phayes@ai.uwf.edu>
- Date: Thu, 7 Nov 2002 18:01:13 -0600
- To: Jeff Heflin <heflin@cse.lehigh.edu>
- Cc: www-webont-wg@w3.org
>Pat, > >The proposal we were discussing on the telecon today is at: > >http://lists.w3.org/Archives/Public/www-webont-wg/2002Nov/0004.html > >I hope you can come up with wording that you find suitable, while not >changing the basic idea considerably. OK, I will write it in terms of triples, hope that is OK with you. ----------- Short version. aaa owl:imports bbb . means that the document aaa asserts the content of the document bbb. If this occurs in document aaa itself, then it means something like 'I assert bbb', ie it means the same there as if you had copied the OWL content of bbb and inserted that into aaa in place of the imports triple. Call this an "I-import triple". Since this rule applies to any owl:imports assertions in bbb, and so on, the assertion of a document amounts to the assertion of the imports closure of the document. Therefore, a document containing an I-import triple entails anything which is entailed by the imports closure of the document referred to be the object, in the usual sense of 'entails'. This does not, however, mean that a reasoning engine is obliged to actually perform any fetching or inserting operations when it comes across an imports statement; the use of the term 'assert' here can be understood as meaning something like 'assent to' or 'agree with'. If bbb does not identify an OWL document, the 'imports' statement is equivalent to importing an empty graph, ie it is vacuously true, ie meaningless; the graph means the same as the subgraph got by erasing it. If aaa contains bbb owl:imports ccc . where bbb does not identify aaa, then this does not entail any consequences of ccc (or its closure.) The difference is somewhat analogous to that between (bbb implies ccc) and (bbb and (bbb implies ccc)) ----------- Long version. The truth conditions for owl:imports are non-standard in two ways, both of which require us to modify the semantics, but in ways that are orthogonal to the other semantic issues, fortunately. First, they are given for a particular token of owl:imports in a particular document, and may be different for other tokens of the same triple in other documents. This is actually not possible in a conventional semantic theory, but we will tackle it directly by altering the semantic rules. An interpretation is usually defined in terms of a mapping from a vocabulary, ie a set of names. We will instead consider this to be a mapping from a set of name *tokens*, where we will say that for all tokens not in an imports triple, that all tokens of a given name map to the same meaning. This reproduces the usual semantics for the rest of the language but allows us to distinguish one token of owl:imports from another. (To sum up, one could say that the meaning of owl:imports is *essentially indexical* (http://csli-publications.stanford.edu/site/1575862697.html) ) Second, they use urirefs to refer to documents, in ways that go beyond the standard semantic rules for RDF but which have been argued for by many eminent authorities. So let us follow those authorities and say that any token of an absolute HTTP URI in an imports triple must always be interpreted as denoting the document which would be retrieved by using the HTTP protocol on the WWWeb, so that for example I(http://www.coginst.uwf.edu/~phayes) is required to be a certain document with a picture of an idiotic grin on it, in all interpretations. This leaves open the issue of how to define 'document', but we need not do that, since the only documents we need to worry about are OWL documents that define an OWL/RDF graph; so we will treat all such HTTP URIs as denoting an OWL/RDF graph, and if there isn't any OWL in the document, or if you get a 404 error, then that is the empty graph. However, since the result of an HTTP operation depends on the state of the WWWeb, the truth of any particular owl:imports token may vary depending on the state of the web. Inferences made from any such triple should therefore be considered to incorporate an implicit reference to the state of the WWWeb at the time the inference was made. Users SHOULD use some means to distinguish state-dependent inferences from non-state-dependent inferences. Owl:imports is the only item in the OWL namespace that requires this special treatment. We express the truth conditions in terms of the IEXT mapping, bearing in mind that interpretation rules apply now to particular *tokens* of 'owl:imports' and the subject and object urirefs. General semantic condition. If PPP is a token of 'owl:imports', then <x,y> is in IEXT(I(PPP)) iff x is an OWL/RDF graph, y is a token of a uriref BBB, a triple AAA QQQ BBB . occurs in x, where QQQ is a token of 'owl:imports'; and <I(AAA),I(BBB)> is in IEXT(I(QQQ)). What this means is that 'aaa owl:imports bbb' is true anywhere iff the document aaa really does import bbb. Obviously, if that claim occurs in the document aaa itself, then this condition is vacuous (it just says that owl:imports is true there iff owl:imports is true there) so we have to give another condition in that case, which is the one with the real meaning in it: Indexical semantic condition. If I(AAA) is an OWL/RDF graph and PPP is a token of 'owl:imports' occurring in I(AAA) in a triple AAA PPP BBB . then <x,y> is in IEXT(I(PPP)) iff I(BBB) is an OWL/RDF graph and I(I(BBB)) = true. That is, the object of the owl:imports triple in this case must denote (via the second convention above) an OWL/RDF graph, and then that graph has to be true, when interpreted by the same rules used to interpret the first graph. That is, the graph indicated by the object uriref gets (re)asserted by the owl:imports triple itself. That this graph I(BBB) is the imports closure can be proved by induction on the path length of the HTTP links, by the way, assuming of course that the WWWeb stays finite. ----- OK, I think that covers all your bases. Sorry it gets a bit complicated, but it really is an indexical, and indexicals are rather complicated to talk about. But this account conforms to the OWL/RDF syntax and semantics rigorously (with the token-indexicality generalization, which is transparent to the rest of the language), does not mess with any of the standard notions of truth, entailment, and so on, handles 404 errors and non-OWL objects smoothly (they all are empty graphs which are trivially true so the main condition becomes vacuous and therefore so does the other one.) And there is always the short version to fall back on. This also makes sense of imports with an arbitrary subject, which might be handy; and in fact it even gives a way to make sense of things like subproperties of owl:imports, or restrictions on owl:imports to classes of documents, or even.... ahahahah.... Oh, sorry, I don't know what came over me there for a second. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes s.pam@ai.uwf.edu for spam
Received on Thursday, 7 November 2002 19:00:55 UTC