W3C home > Mailing lists > Public > www-webont-wg@w3.org > November 2002

MT for imports (was: Re: Imports Proposal)

From: pat hayes <phayes@ai.uwf.edu>
Date: Thu, 7 Nov 2002 18:01:13 -0600
Message-Id: <p05111b15b9f05ef5f460@[]>
To: Jeff Heflin <heflin@cse.lehigh.edu>
Cc: www-webont-wg@w3.org

>The proposal we were discussing on the telecon today is at:
>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 

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)
(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
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
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:37 UTC