Re: MT for imports (was: Re: Imports Proposal)

Pat,

I can live with this the proposal. It seems like we have to go to a lot
of trouble to make this fit into RDF, but we made our bed, I guess we
have to lie in it. I'd like to hear what others (especially Peter),
think of this idea.

I have a few comments on the wording, please see below...

Jeff


pat hayes wrote:
> 
> >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'.

I object to singling out imports for this kind of statement. This is
true for every construct in the language. For example, a reasoner is not
OBLIGED to compute the subsumption hierarchy given a set of complex
class descriptions, but if it doesn't then it cannot be considered a
complete (as in sound and complete) reasoner for the language. We should
make clear the difference between obligation and entailment in general
for the language.

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

I would think that any inferences on the Semantic Web should incorporate
an implicit reference to the state of the Web at the time the inference
was made. Imports is not special in this aspect. The Web changes, this
is a fact. The triples on a single page can change just as easily as
pages can come and go (and quite likely, much more frequently than
that). I can choose to put a bunch of triples in one page, or distribute
them among a hundred pages. If I delete a set of triples from the single
page, then this is equivalent to removing one of the distributed
documents from the Web. Should not these two types of changes be treated
equally in the semantics? If I have a document d with a set of triples t
that has an entailment p, and then I modify d so that it consists of
triples t', it may no longer be true to say d entails p. There is
clearly an implicit reference to the state of the Web there.

> 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 Tuesday, 12 November 2002 10:55:04 UTC