Re: Lang: owl:ontolgy (was RE: LANG: syntactic version for imports (and other things))

I think I generally agree that "knowing where things come from" should not 
be part of OWL, per se.  I think in your example that, (as I believe Dan 
was saying in the telecon) if your search engine needs to know about where 
things come from, it can keep track of it as it sucks stuff in.  In fact, 
that is what contemporary search engines do with web pages they index - 
the information about the location of the information is NOT in the HTML 
the engines index (it can be of course, but it usually isn't), it is part 
of the data model of the index.  The engine records the URL of a page when 
it sucks in the page.  So if that's your use case, I'm not convinced.

I do, on the other had, think imports and versioning are good ideas.

-Chris






Jeff Heflin <heflin@cse.lehigh.edu>
Sent by: www-webont-wg-request@w3.org
09/19/2002 11:52 AM

 
        To:     pat hayes <phayes@ai.uwf.edu>
        cc:     www-webont-wg@w3.org
        Subject:        Re: Lang: owl:ontolgy (was RE: LANG: syntactic version for  imports (and 
other things))

 


Pat,

You asked why I think it is important to know where the information came
from. The short answer is that you yourself admit that this information
would be needed for performing trust or truth maintenance. Isn't it
enough to say that we shouldn't build a design that rules out such
applications?

If that answer isn't good enough for you, let me describe a personal use
case. Over the last five years I have been interested in building
semantic web search engines. One of the things I realized though, is
that such search engines should just reason with every single ontology
that's ever been published. That is sure to lead to chaos due to
contradictions, different opinions, etc. However, at the same time, I
don't want to have to design a separate search engine for every domain
because there ends up being a lot of duplication in each engine's
repository (that is, if you want any kind of integration). So, what I
think the right approach is to store all of the information in one
repository, but have reasoning algorithms that can only use parts of it
at a single time. Ideally, a user can say, "I have this query Q and I
want you to answer it using only the semantics of the ontologies O1, O4,
and O5)." For such an approach to work, the repository must know which
statements come from which ontologies.

You also said:

> Seems to me it is why 'imports' is irrelevant. Look, you just said,
> we do not want to reason with all the descriptions... OK, so why do
> we need a pointer to more descriptions? This seems like saying that
> we don't want all the water, so we need to know where more water is.
> This just doesn't seem to follow: theres a premiss missing somewhere.
> (OK, Ian's point on todays phone call about completeness is well
> taken; but you aren't making that point here, right?)

Actually my point is the same as the completeness one. Let me put it
this way: we don't want to reason with everything everybody ever said
about a class, but when we are reasoning about a document, it would be
nice if that document's author could say "here are other things that I
agree with, and I sanction any inferences you draw when you combine
these documents with my document."  You may also want to see my message
to Dan Connolly for more arguments on the need for imports [1].

Jeff

[1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Sep/0121.html
).


pat hayes wrote:
> 
> Jeff, thanks for stating this so succinctly so that I can ask you why
> you believe these things. I simply do not follow your reasoning.
> 
> >Actually, this isn't as nice as it might appear. A minor issue is the
> >redundancy that it introduces in documents. When a user writes an
> >ontology, why should they have to write the definition and then later
> >say, oh by the way, this definition is in the ontology that is
> >represented by the document in which I wrote it? I think we'll have a
> >hard time explaining this awkwardness to users.
> >
> >However, a more fundamental issue is that it doesn't really do what we
> >need it to do. Your approach seems to imply that you can say that a
> >particular class or property is defined by a particular ontology.
> >However, in RDF, a class or property can be defined by many ontologies.
> >The descriptions of these object may be distributed across the Web.
> 
> OK so far, and I agree...
> 
> >In
> >order to manage reasoning with these things, it is absolutely essential
> >that we know which descriptions come from which ontologies.
> 
> WHY??? Why do I need to know where the information came from? I can
> see that for some 'advanced' purposes - for example, suppose I don't
> trust all my sources and I want to keep track of what follows from
> what authorities, or I expect to find inconsistencies and want to do
> truth-maintenance - that such meta-information might be important,
> but the basic inferential model of RDF and DAML+OIL and OWL is surely
> that in which I have many sources of information, and I draw
> conclusions from them about the things they refer to. For this I
> don't need to know where the information *comes from*.
> 
> >In many
> >cases, we do not want to reason with all the descriptions that 
everybody
> >ever said about a class
> 
> Of course not....
> 
> >(this is why imports is so important).
> 
> Seems to me it is why 'imports' is irrelevant. Look, you just said,
> we do not want to reason with all the descriptions... OK, so why do
> we need a pointer to more descriptions? This seems like saying that
> we don't want all the water, so we need to know where more water is.
> This just doesn't seem to follow: theres a premiss missing somewhere.
> (OK, Ian's point on todays phone call about completeness is well
> taken; but you aren't making that point here, right?)
> 
> >The only
> >way to distinguish between what was said in each ontology is to
> >associate RDF statements (not resources) with the ontology. Thus, each
> >subclassOf statement, subPropertyOf statement, owl:Restriction
> >statement, etc. must be associated with the ontology in which it is
> >stated.
> 
> WHY?? What purpose does this serve for a basic, vanilla RDF/OWL
> reasoner? What conclusion can it draw (or not draw) with these tags
> present, that it could not (or could) draw if they were absent? What
> entailments do they effect? Seems to me, the only possible answer is,
> none whatsoever.
> 
> Pat
> 
> >
> >Jeff
> >
> >Jim Hendler wrote:
> >>
> >>  Seems to me today's phone call revealed a problem.  We want to be
> >>  able to define an ontology as a "container" in which a set of
> >>  statements lives.  This doesn't necessarily imply that this 
container
> >>  is either closed or immutable (this message doesn't want to address
> >>  those issues) but rather to give you a place that makes statements
> >>  about the ontology (heretofore called its metadata) and also to say
> >>  what URIs are in it (not necessarily uniquely).  I've been 
discussing
> >>  this with a researcher in my lab, Bijan Parsia, and he's come up 
with
> >>  a solution that is relatively elegant, consistent with the RDF
> >>  approach to the world, and has a precedent in RSS, a widely used
> >>  language.  I think this is similar to what Mike Smith was talking
> >>  about today with using XMLbase, but might be more RDF friendly and
> >>  also a little easier to implement (since everything can stay in the
> >  > graph)
> >  >
> >  > The idea is that we can simply extend the owl:ontology to define 
its
> >  > classes in a manner similar to how RSS defines a channel (for those
> >  > who know that) -- that is, we create an owl:ontology statement that
> >>  includes a pointer to the set of URIs which it includes (could be
> >>  just class definitions, could be more).  This would look something
> >>  like this:
> >>
> >>  <rdf:RDF  {namespaces} >
> >>
> >>  <owl:class rdf:ID="foo">
> >>     <restriction ... (etc) />
> >>  </owl:class>
> >>
> >>  <owl:class rdf:ID="bar">
> >>     <restriction ... (etc) />
> >>  </owl:class>
> >>
> >>  <owl:class rdf:ID="baz">
> >>     <restriction ... (etc) />
> >>  </owl:class>
> >>
> >>  <owl:Ontology rdf:ID="OntologyName">
> >>    <owl:ontologyDefines rdf:parsetype="collection">
> >>       <owl:ontologyClass :foo />
> >>       <owl:ontologyClass :bar />
> >>       <owl:ontologyClass :baz />
> >>    </owl:ontologyDefines>
> >>     <dc:creator rdf:ID="me" />
> >>        {other metadata}
> >>  </owl:Ontology>
> >>
> >>  </rdf:RDF>
> >>
> >>  The beauty of this is that I could now handle imports in various 
ways
> >>  - I could import an entire ontology with an imports statement within
> >>  this
> >>
> >>  <owl:Ontology ...>
> >>     <owl:imports URI2 />
> >>
> >>  and extend it
> >>
> >>     <owl:Defines ...>
> >>       <owl:ontologyClass :notInURI2>
> >>     </owl:defines>
> >>  ...
> >>  <owl:Ontology>
> >>
> >>  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>
> >>
> >>  and I get for free some new properties that seem quite desirable - 
in
> >>  particular, I could create multiple ontologies in a document by
> >>  including pointers to different subsets
> >>
> >>  <owl:ontology rdf:ID="Pets">
> >>     ...
> >>     <owl:ontologyDefines>
> >>         ... dog
> >>         ... cat
> >>     </owl:ontologyDefines></owl:ontology>
> >>
> >>  <owl:ontology rdf:ID="Felines">
> >>     ...
> >>     <owl:ontologyDefines>
> >>         ... lion
> >>             cat
> >>             tiger
> >>     </owl:ontologyDefines></owl:ontology>
> >>
> >>  I think that version info could also be handled in here, although
> >>  still working on details.
> >>
> >>  I also think this works syntactically whether we put ontologies into
> >>  the domain of discourse or not -- I personally wouldn't prefer to,
> >>  but could go either way.
> >>
> >>    -JH
> >>  p.s. For the RDFS fans, the owl:ontologyDefines would be invertible
> >>  into rdfs:isDefinedBy statements - which is a nice bonus.
> >>  p.p.s. If we really want to get fancy, we could let the
> >>  owl:ontologyDefines statement be any RDF collection, meaning an
> >>  ontology designer could use either a collection, making it closed, 
or
> >>  a bag, making it open - thus letting the user have some ability to
> >>  control how extensible the solution is.
> >>
> >>  --
> >>  Professor James Hendler                           hendler@cs.umd.edu
> >>  Director, Semantic Web and Agent Technologies     301-405-2696
> >>  Maryland Information and Network Dynamics Lab.    301-405-6707 (Fax)
> >>  Univ of Maryland, College Park, MD 20742          240-731-3822 
(Cell)
> >>  http://www.cs.umd.edu/users/hendler
> 
> --
> ---------------------------------------------------------------------
> IHMC                                    (850)434 8903   home
> 40 South Alcaniz St.                    (850)202 4416   office
> Pensacola,  FL 32501                    (850)202 4440   fax
> phayes@ai.uwf.edu
> http://www.coginst.uwf.edu/~phayes

Received on Thursday, 19 September 2002 14:20:55 UTC