Re: LANG: owl:ontology

Mike,

Although I understand your point, and am not necessarily opposed to your
preference for possibility 2, there are other alternatives.

First, having each state's ontology have information about adjacent
states may not be the best way to go. I would actually expect that a
US-Geo ont would give me information about which states were adjacent to
which other states. I imagine regardless of how we design the language,
good ontology engineering practices will evolve that will work best for
that design. That being said, I don't want to make ontology designers to
do strange contortions just to get their ontologies to work properly.

A second point is that just because an ontology imports another ontology
doesn't mean a reasoner has to load the imported ontology. If the
reasoner wants to guarantee completeness, then it would have to, but I
suspect there will also be many useful incomplete reasoners for OWL. So,
if a reasoner found that a good heuristic was to only load the first few
ontologies in the imports chain, then fine, as long as it doesn't claim
to be OWL-complete.

Jeff

"Smith, Michael K" wrote:
> 
> In the context of the wine onotlogy and looking as Guus' region example I
> was thinking a little about distributed geographical ontologies.
> 
> The following scenario seems simple and desirable:
> 
> Assume GeoOnt is an ontology for regional geographcial descriptions,
> including countries, regions, states, provinces, cities, towns, and their
> relations.
> 
> Assume the following import GeoOnt.
> 
>   TX-Ont - Definition of entitities in the state of Texas
>   OK-Ont - Definition of entitities in the state of Oklahoma
> 
> And so forth for other geographical areas.
> 
> Now both TX-Ont and OK-Ont are going to want to refer to adjacent states.
> The authors of TX-Ont can refer to Oklahoma by
> 
> 1. Defining a new identifier, txont:Oklahoma, that is unrelated to
> okont:Oklahoma.  If someone chooses to use both TX-Ont and OK-Ont together,
> it will be up to them to identify all of the correspondences and create the
> needed equivalences.
> 
> 2. Use okont:Oklahoma, with a okont: namespace declaration, but no imports.
> This does permit inconsistencies to arise, but that's life in a distributed,
> web-based world.
> 
> 3. Import the entire OK-Ont ontology.  In a well-connected but distributed
> use of GeoOnt, a consequence of this would be that in order to reason about
> traveling from Austin to San Antonio (both in Texas) I would import the
> transitive closure of the entire world's geographical ontology.
> 
> Possibility 2 seems simplest.  It enables another party to import both
> TX-Ont and OK-Ont when they need to and reason about them without having to
> jump through the hoops in 1.  AND, they don't get the complete geography of
> Siberia clogging up their system as an inevitable consequence.
> 
> - Mike
>

Received on Thursday, 19 September 2002 17:13:11 UTC