Re: LANG: owl:ontology

From: Jim Hendler <hendler@cs.umd.edu>
Subject: Re: LANG: owl:ontology
Date: Sun, 15 Sep 2002 13:00:24 -0400

[...]


> >way we decide whether
> >  > >>  carrots or potatoes are in the same ontology.
> >>  >
> >>  >  But everything that relates to it is probably everything on the entire
> >>  >  web.  You have to say which axioms and facts you are including.  In fact,
> >>  >  as RDF/XML is the exchange language, you have to say which *triples* you
> >>  >  are including.
> >>
> >>  Yes, but we have exactly that same problem in the current system. 
> >
> >Not at all.  Ontologies are documents, so everything in a document is
> >included.   No other determination is needed.
> 
>   It is certainly not the case in many of the examples I've seen and 
> used, and even if it were the case in D+O (I don't think it is), I 
> think we should fix it for owl.

In the current systems (DAML+OIL) ontologies are documents, at least as far
as I can see.  Having ontologies be documents is a viable solution in my
eyes, and provides an elegant solution to which information to import.

> >  > It
> >>  is perectly legal to have a document with nothing on it but a class
> >>  definition, another document that has some other class definition
> >>  that points to it, and a third document that claims to be an ontology
> >>  and has something which is a subclass of one of these.  That's
> >>  perfectly legal, and I have a number of tools which take advantage of
> >>  the fact (letting one document add properties to an ontology in
> >>  another, for example). 
> >
> >This does nothing to determine which information to import.
> >
> >>  In point of fact, we could have all the
> >>  triples on the ontology be in a closed list - but I don't like that -
> >
> >This would work, in some sense at least.  An ontology is a collection of
> >triples.   But then how is this significantly different from an ontology
> >being a document that is a collection of triples?
> 
> because we break the connection between a document and the collection 
> of triples.  This makes it possible to have multiple ontologies in a 
> single document, to compose ontologies from parts of other 
> ontologies, and to merge ontologies without having to create new 
> documents.  It also means that the triple store itself will contain 
> the list of classes, instead of that having to be assumed from the 
> document.  This means that our resolution that the graph should 
> convey the ontology will be more directly met.  Also, if one 
> considers that on the modern web "document" is not actually a 
> terribly well-defined entity (can it be a page which is generated 
> from a database, a java program, a plug-in from an ontology site?) 
> then it would be nice to have something that scopes what a particular 
> ontology claims, ot what I claim from it.
> 
> >  > I htink it better to have some general ideas of how the pointers
> >>  work, and leave the rest unspecified for now. 
> >
> >Huh?  Leave the determination of which triples to import unspecified?  How
> >could anyone use imports then?
> 
> All I meant was that whatever we could do for the current use of 
> imports could be done with this solution as well - I didn't propose 
> this as a solution to imports, but as a mechanism that will make it 
> easier to implement whatever solution we determine without requiring 
> a lexical (document-based) solution.

Well, divorcing ontologies from documents appears to me to prevent the
current solution for imports, and makes it a difficult problem.  

The basic problem is, indeed, determining the contents of an ontology.
Making an ontology a collection of classes and objects does *not* solve
this problem at all, at least as far as I can see, as it leaves totally
open which information about these classes and objects is part of the
ontology.

> >>  If you want
> >>  decidability/consistency, you can insist that people only use local
> >  > referents or something like that.
> >
> >How did decidability or consistency get in here?   Decidability or
> >consistency of what?
> >
> >>  A view of ontologies that cannot point to each other, and instances
> >>  that only point to one ontology, is like the web without the links --
> >>  it's still a lot of documents, but it ain't the Web.
> >
> >Why?  I see absolutely nothing to back up this claim.  Ontologies being
> >documents and ontology documents pointing to other ontology documents sure
> >looks like the Web to me!
> 
> but how do we get the pointing to?  That's the whole discussion I 
> thought we were having - the DAML+OIL solution is terribly vague on 
> this - and although I can live with that vagueness, it doesn't help 
> the interoperability goals we have as a WG.

The DAML+OIL documents are rather vague.  However, an imports refers to a
URI and it seems to me that this means to import the contents of the
document, as there is no other potential thing to import.

[...]

> >>  >I bring your attention to the abstract syntax document, available at
> >>  >http://www.w3.org/TR/owl/ab-syn/, which includes a treatment of imports.
> >>  >DAML+OIL also includes a treatment of imports.
> >>
> >>  yes, but we have an issue open asking for a better way to handle
> >>  imports - I'm perfectly fine with going with the D+O approach (magic
> >>  syntax) but the issue was raised as to whether there is a better way,
> >>  and I think this is one.
> >
> >Sure we want a better way.  But there *is* a mechanism from DAML+OIL, and
> >other proposals have already surfaced.
> 
> and mine is one of them - which is why I proposed it.

You left out the previous part of this exchange

> > >>  because there is no other mechanism currently on the table, so this
> > >>  is a solution to the open issue (with other desirable properties)

in which you claim that there are no other mechanisms on the table.  I am
disputing that by pointing two other mechanisms that appear, to me, to be
on the table.  

[...]

> >>  >  > >>  I could include classes from other ontologies (Without 
> >>importing the
> >>  >>  >>  whole thing) by simply including them in my owl:ontologyDefines
> >>  >>  >>  collection
> >>  >>  >>     <owl:OntologyClass cyc:dog>
> >>  >>  >
> >>  >>  >What is the impact of this?  That cyc:dog is a resource in 
> >>this ontology?
> >>  >>  >That the axioms about cyc:dog (from where?) are to be included in this
> >>  >  > >ontology?
> >>  >>
> >>  >>  yes, that the URI cyc:dog is a class, it contains class definitions,
> >>  >
> >>  >Classes do not contain class definitions.  Classes do not even have
> >>  >really have definitions.  All there is is triples!
> >>
> >>  class are referred to by URIs, and are thus "indexes" into larger
> >>  graphs.  Currently some people view those graphs as separable, others
> >>  of us don't. Whatever the semantics would hold for the document view
> >>  will hold just as easily in my view -- simply consider the ontology
> >>  statement plus its defines to be what you called a document, and
> >>  everything we've done to date still works just fine. 
> >
> >Not at all.  The problem is determining boundaries.  You haven't said where
> >the boundaries between classes are supposed to be, so you haven't produced
> >a viable proposal for imports.
> 
> well, I'm not real fond of boundaries personally, but I still don't 
> see why mine had any less boundaries than anyone else's.

The problem is precisely the opposite.  The ontologies as documents has
few, and simple, boundaries.  Your proposal requires many, many more
boundaries.  Essentially every class (and property and object) requires a
boundary around the information that is considered to be its definition.
Further, you have not even specified how to define these boundaries.

[...]

> >>  >>  >Again, which aspects of cat are part of Pets and which are 
> >>part of Felines?
> >>  >>
> >>  >>  all of each are part of both
> >>  >
> >>  >What all?  Do you mean all RDF triples currently on the web that mention
> >>  >cat?  Do you mean the intended meaning of whoever wrote the document that
> >>  >the URI points to?
> >>
> 
> of course not!!  URI1:cat is in no way the same as URI2:cat unless 
> someone comes along and states their equivalence.  And I can't know 
> the intended meaning of someone else - so I will assume that the 
> owl:ontologyDefines list is the same sort of "closure" that you are 
> assuming a document is, but I don't need to insist that it ever 
> appear as a document - which is an improvement.

But suppose we have the following triples spread out around the web:

URI1:cat rdfs:subClassOf URI2:cat .
URI2:cat owl:sameClassAs URI1:p .
URI1:p owl:onProperty URI3:owner .
URI1:p owl:maxCardinality 1 .
URI1:p owl:onProperty URI3:owner .
URI1:p owl:allValuesFrom URI3:PetOwner .
URI3:PetOwner rdfs:subClassOf URI4:Person .
URI1:cat rdfs:subClassOf URI1:p1 .
URI1:p1 owl:onProperty URI3:owner .
URI1:p owl:minCardinality 1 .

which of these triples are part of URI1:cat (or of any ontology that claims
URI1:cat)?


> >  > whatever solution you would use for DAML+OIL works for this as well
> >
> >Sure, the solution in DAML+OIL is to identify ontologies as certain kinds
> >of documents.
> 
> I am not convinced this is true, and if it is, I'm still not 
> convinced it's a good idea - which is why we have a working group to 
> discuss such things in.

Sure, we should discuss ontologies, but denying that there is an existing
solution is not a particularly good way of starting the discussion.

[...]

peter

Received on Sunday, 15 September 2002 13:57:10 UTC