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

Dan,

There seems to be no room for either of us to compromise. To me, this is
the single most important feature of the language. Without it, OWL is
worthless. For this reason, I will not let this issue be postponed. I am
also willing to wait as long as it takes to satisfactorily close the
issue, even if it means delaying last call.

Let me restate my need:
I as a document author need to be able to state that my document commits
to some set of ontologies and possibly other documents. Short of solving
the "AI-problem," this is the only way we can have reliable agents on
the Web. If I own a web service and advertise it in OWL, it is important
that agents that discover this service can understand what the terms
mean and what the full consequences of it are. We cannot rely on "social
agreements." We cannot expect an agent to say to its user "I found a
potentially useful service, please call its owner up and ask him what
additional documents are relevant to understanding this service, so I
can decide if it is appropriate to use." There must be someway for the
service and the agents to agree on what other documents and ontologies
are relevant.

In your message below, you say "just follow your nose." This is entirely
too vague of a notion to build e-commerce systems on. Do you mean
"whatever one agent happens to find in its travels across the Internet?"
If so, then no two agents will ever agree on anything, because no two
agents are going to have visited exactly the same pages. Perhaps you
mean follow namespace declarations as Tim suggested in his IRC chat with
me. I will grant you that if we made this rule a formal part of our
semantics, then that resolve some of my problems. I still wouldn't be
able to point to other relevant instance data, but at least we would
have a notion of ontology commitment. However, I emphasize, such a
solution would be incompatible with eventually extending OWL to include
the ability to import parts of ontologies, and I believe Jim Hendler
would strongly object to that.

Can you give a complete proposal for a solution to the problem I
described above? I'd be happy to discuss it with you. 

BTW, you've asked for reference that discuss ontology inclusion. Here
are a few of them:

A. Farquhar, R. Fikes, and J. Rice. Tools for Assembling Modular
Ontologies in Ontolingua. In Proc. of AAAI-97. 1997.

Borst, Benjamin, Wilenga, and Akkermanns. An Application of Ontology
Construction. In Proc. of ECAI'96 Workshop on Ontological Engineering.
1996

T. Gruber. Toward Principles for the Design of Ontologies Used for
Knowledge Sharing. In Guarino and Poli, eds., Formal Ontology in
Conceptual Analysis and Knowledge Representation. 1993.

Guarino, N. Formal Ontology and Information Systems. In Proc. of FOIS
'98. Trento, Italy. 1998.


Jeff


Dan Connolly wrote:
> 
> Summary: we still disagree.
> 
> To elaborate...
> 
> On Thu, 2002-10-31 at 08:42, Jeff Heflin wrote:
> > Dan Connolly wrote:
> > >
> > > On Wed, 2002-10-30 at 19:34, Jim Hendler wrote:
> > > >
> > > > [various stuff snipped]
> > > >
> > > > I've been avidly following this discussion, and also carefully read
> > > > the dialog between Jeff and Tim Berners-Lee publicly logged at [1].
> > > > I find myself torn - on the one hand, I'm certainly familiar with
> > > > Jeff's work in SHOE and the use of something like "imports" to mean
> > > > "Commits to" -- i.e. that I agree with EVERYTHING that some ontology
> > > > (or set of instances or whatever) says, whether I link to it directly
> > > > or not. On the other hand, I'm beginning to better understand what
> > > > Dan (and Tim) are saying about maybe we want to allow more freedom to
> > > > explore different commitment methods and the like.
> > > >
> > > > I would ask the following - if imports is an optional feature (we've
> > > > already agreed it doesn't have to be used),
> > >
> > > but it has to be
> > >   -- implemented
> > > not to mention
> > >   -- tested
> > >   -- specified
> > >   -- explained
> > > etc.
> >
> > Implementing it is breeze.  What is is so complex about computing the
> > "imports closure" of a document?
> 
> I didn't mean to say that the implementation burden of imports
> was prohibitive; just that it's not free. i.e. just because
> I don't have to use it in my documents doesn't mean it costs
> me nothing.
> 
> > It is no more complex than deferencing
> > a sequence of namespaces! Here's the pseudo code for a naive way to do
> > it:
> >
> > findImportClosure(doc)
> >
> >   closure = doc
> >   for each imports in doc
> >     impClose = findImportsClosure(imports.importDoc)
> >     closure = closure union impClose
> >   return closure
> >
> > If you wanted to be more efficient, you could keep track of which
> > documents have already been included, and only include those that are
> > not in the list, but that is also trivial.
> >
> > > > and since anyone can
> > > > invent their own term to explore a different commitment strategy what
> > > > is the downside of including an imports statement of the type Jeff
> > > > advocates?)
> > > >
> > > > For example, I am playing with something that looks a bit like this:
> > > >
> > > >   <> jim:commits
> > > >     [jim:partialMappingTo foo: ;
> > > >      jim:usingMappingRules bar: ] .
> > > >
> > > > in some recent research, and don't see where the existence of
> > > > imports, which I won't use here, bothers me. I couldn't live with
> > > > the meaning that referring to something in another ontology
> > > > automatically had the strong implication that imports does (total
> > > > agreement), but I have no real problem with one I don't have to use,
> > > > but can if I want that particular meaning.
> > > >
> > > > So Dan, I guess this is to you -- why do you think including one
> > > > particular imports method would be premature standardization?
> > >
> > > Because specification of it involves connecting logic
> > > with protocols in an unprecedented way.
> >
> > But the group chose to embed logic in RDF in non-standard way that has
> > delayed us by untold months, and who knows if the semantics will stand
> > the test of time. If you were really concerned only about standardizing
> > stuff that was well understood, we should have never taken that path.
> > Imports is much cleaner and much more well-understood than how to embed
> > a logic in RDF.
> 
> I disagree. RDF a funky syntax for the existential-conjuctive
> fragment of FOL; to that we added a bunch of axioms; quoting
> from my original Aug 2000 proposal:
> 
> <Property ID="inverseOf">
>   <comment>for inverseOf(R, S) read: R is the inverse of S; i.e.
>      if R(x, y) then S(y, x) and vice versa.</comment>
> </Property>
> 
>   -- http://www.w3.org/2000/08/daml-ont.rdf
> 
> I don't see the "untold months" as a delay; I see it as the
> work of this group, to get the details right.
> 
> > At least scores of ontology work have already done this
> > in a non-Web context.
> 
> I might find that more convincing if you cited this
> work so that I could study it myself.
> 
> > > ---
> > > excerpt from
> > > > [1] http://ilrt.org/discovery/chatlogs/rdfig/2002-10-30.html
> > >
> > >  22:31:33   <timbl> I am saying that the functionality is useful but
> > > here are many ways of doing it and you need a new model theory for the
> > > web. I can write axioms for daml:imports using my log:semantics and
> > > log:includes. But i think the community would wantto discuss al this. So
> > > it shouldn't be core webont.
> > > ---
> > >
> > > And because I see so many places where the requirement
> > > is met without using daml:imports.
> >
> > And fine. You don't have to use it. But I suspect the reason you don't
> > think you need it is because you don't actually share your data with
> > anyone else's application.
> 
> Not so.
> 
> > You may publish it on the Web somewhere, but
> > can you name another application independently developed by someone else
> > that actually consumes your data and uses it for a useful purpose?
> 
> I share data among applications and tools like
>   -- Mike Dean's airport scraper
>   -- Jim Lay's image annotation and mapping tools
>   -- the MIND group's authoring tools
>   -- Euler
> not to mention the variety of tools that probably
> don't qualify as "independently developed".
>   -- cwm
>   -- various XSLT tools, like my circles-and-arrows stuff
>         http://www.w3.org/2001/02pd/
>   -- Zakim
>   -- libby's squish query engine.
> 
> I'm certainly interested to hear about independently developed
> tools and applications interoperating on the basis of
> daml:imports.
> 
> > In
> > order to reach agreement, you would have to tell them which ontologies
> > and subsets of documents are relevant. How to you propose to do this?
> 
> They follow their noses from one document to another.
> rdfs:seeAlso is one relavent mechanism, but there's
> a variety of others.
>

Received on Thursday, 31 October 2002 15:53:57 UTC