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

Re: LANG: need to CLOSE Issue 5.6 Imports as magic syntax

From: Jeff Heflin <heflin@cse.lehigh.edu>
Date: Tue, 29 Oct 2002 14:29:41 -0500
Message-ID: <3DBEE1A5.7D376AA5@cse.lehigh.edu>
To: Dan Connolly <connolly@w3.org>
CC: webont <www-webont-wg@w3.org>

Dan Connolly wrote:
> 
> On Tue, 2002-10-29 at 09:20, Jeff Heflin wrote:
> [...]
> > Therefore, I propose the following:
> >
> > 1) The syntax for imports be the same as that of DAML+OIL
> >
> > 2) The semantics essentially be "A imports B means if B entails P then A
> > entails P."
> 
> No, entailment is a relationship between formulas; it doesn't
> depend on the state of the Web.

The Semantic Web can be viewed as a collection of distributed formulas.
The proposal above depends on the state of the Web only in the same
sense that what is entailed by a set of formulas depends on what
formulas you are considering. Please see my earlier message to Pat on
this point:

http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0057.html

> I much prefer defining something like imports closure.
> 
> i.e. the imports closure of D is the graph you get from D
> plus following all the (syntactically evident) daml:imports
> links, recursively.
> 
> "the" graph here is somewhat informal; you get different
> graphs depending on the state of the web; this is inherent
> to the defintion of imports closure.

This is a very inflexible notion of imports. Some applications may find
that they can do complete reasoning for certain queries without
computing the imports closure. Mike Smith had an example of states with
borders relations where computing the imports closure would be very
undesirable because it would require you to import the ontologies
describing every state just to reason about any one of them. My proposal
does not require this, it just tells you how to test whether your
reasoning has computed the entire set of entailments or not.

> We can then use our existing notion of entailment
> to test whether the imports closure of D1 entails D2.
> At the ftf, we discussed having a separate class of
> tests for this relationship between D1 and D2.
> 
> > Here A and B can be any document, not just ontologies. Also
> > note that when a document does not contain an imports statement, we do
> > not specify a mechanism for determining what statements from other
> > documents are entailed.
> 
> It seems to me that entailment (i.e. large-owl entailment and
> fast-owl entailment) is 100% specified; we leave no room
> for interpretation, implementation-dependency, change-over-time,
> etc

The current semantics say nothing about how and when documents are
merged. They only provide semantics for a single document. Users can
arbitrarily create a virtual document by combinging two or more
documents and apply the semantics to them, but this often entails things
that are not entailed by either document alone. This proposal says that
if an imports is not present, people can still arbitrarily merge
documents according to whatever policy they choose, but the entailments
are those of the virtual merged document, and not of any of the
individual component documents.

> > Thus, developers are free to implement various
> > things, just as they are free to combine arbitrary unlinked documents.
> > However, in such situations, they take responsibility for the
> > conclusions they make.
> >
> > 3) The imports triples are considered extra-logical, and any statements
> > that contain owl:imports as a subject or object are undefined.
> 
> ??? What do you mean by "undefined"? How should that be specified
> in the ref/semantics/guide docs?

I'm not a fan of this undefined concept, but this is what seemed to
reach
consensus when Jim suggested it on the telecon a few weeks ago. I'd much
rather say that such triples are somehow "dark" (although I hear we
don't need dark triples anymore) or better yet syntactically prohibit
them (which RDF won't let us do). However, if stuck with the "undefined"
notion, my best suggestion is wording to the effect that "triples of
these forms do not participate in any entailment relations."

> Perhaps you mean that they don't affect the imports closure of
> a document (i.e. you can't expect agents to pay attention
> to subproperties of imports when computing the imports closure)
> then very well.
> 
> > Furthermore, any imports statements that have a resource other than the
> > containing document as a subject are undefined.
> >
> > I suggest that anybody who cannot live with this solution speak up now
> > and clearly explain how this would break their applications. If there
> > are no serious objections with it, I'd be happy to write up the details
> > of this proposal.
> 
> I don't know if you consider this an objection or a clarification
> question. In any case, I need to see more details (in particular:
> test cases that show that imports *does not* affect large/fast
> entialment, plus test cases regarding imports closure) before
> I'm prepared to agree.

What do you mean by "a test case that shows that imports does not affect
large/fast entailment?" Of course it affects it, just as adding or
subtracting any other meaningful language feature affects it. Maybe you
mean prove that it doesn't change computational complexity? That should
be simple enough, as long as you can't infer imports, you can compute
the "imports closure" in linear time using a recursive algorithm. If
this is a pre-processing step to logical reasoning, it is by far
dominated by the time to do either large or fast OWL entailement.

As far as test cases, we already have the "Socrates type Man, man
subClassOf Mortal" example from the F2F. What else do you need?

Jeff
> 
> >
> > Jeff
> >
> > [1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0057.html
> > [2] http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0141.html
> > [3] http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0060.html
> > [4] http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0150.html
> 
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Tuesday, 29 October 2002 14:29:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:53 GMT