TransWiki - an Open Translation Project(OTP)

摘要_文檔狀態_目錄 第1節 第2節 第3節 第4節 第5節 第6節 第7節 鳴謝_辭彙表_術語索引_參考文獻 附錄

---

4. Ontology Mapping

In order for ontologies to have the maximum impact, they need to be widely shared. In order to minimize the intellectual effort involved in developing an ontology they need to be re-used. In the best of all possible worlds they need to be composed. For example, you might adopt a date ontology from one source and a physical location ontology from another and then extend the notion of location to include the time period during which it holds.
It is important to realize that much of the effort of developing an ontology is devoted to hooking together classes and properties in ways that maximize implications. We want simple assertions about class membership to have broad and useful implications. This is the hardest part of ontology development. If you can find an existing ontology that has already undergone extensive use and refinement, it makes sense to adopt it.
It will be challenging to merge a collection of ontologies. Tool support will almost certainly be required to maintain consistency.
==4.1. Equivalence between Classes and Properties

equivalentClass, equivalentProperty== To tie together a set of component ontologies as part of a third it is frequently useful to be able to indicate that a particular class or property in one ontology is equivalent to a class or property in a second ontology. This capability must be used with care. If the combined ontologies are contradictory (all A's are B's vs. all A's are not B's) there will be no extension (no individuals and relations) that satisfies the resulting combination.
In the food ontology we want to link wine features in the descriptions of dining courses back to the wine ontology. One way to do this is by defining a class in the food ontology (&food;Wine) and then declaring it equivalent to an existing wine class in the wine ontology.

<owl:Class rdf:ID="Wine">

  <owl:equivalentClass rdf:resource="&vin;Wine"/>

</owl:Class>

The property owl:equivalentClass is used to indicate that two classes have precisely the same instances. Note that in OWL DL, classes simply denote sets of individuals, and are not individuals themselves. In OWL Full, however, we can use owl:sameAs between two classes to indicate that they are identical in every way.
Of course the example above is somewhat contrived, since we can always use &vin;Wine anywhere we would use #Wine and get the same effect without redefinition. A more likely use would be in a case were we depend on two independently developed ontologies, and note that they use the URI's O1:foo and O2:bar to reference the same class. owl:equivalentClass could be used to collapse these together so that the entailments from the two ontologies are combined.
We have already seen that class expressions can be the targets of rdfs:subClassOf constructors. They can also be the target of owl:equivalentClass. Again, this avoids the need to contrive names for every class expression and provides a powerful definitional capability based on satisfaction of a property.

<owl:Class rdf:ID="TexasThings">

  <owl:equivalentClass>

    <owl:Restriction>

      <owl:onProperty rdf:resource="#locatedIn" />

      <owl:someValuesFrom rdf:resource="#TexasRegion" />

    </owl:Restriction>

  </owl:equivalentClass>

</owl:Class>  ? 

TexasThings are exactly those things located in the Texas region. The difference between using owl:equivalentClass here and using rdfs:subClassOf is the difference between a necessary condition and a necessary and sufficient condition. With subClassOf, things that are located in Texas are not necessarily TexasThings. But, using owl:equivalentClass, if something is located in Texas, then it must be in the class of TexasThings.
RelationImplications
subClassOfTexasThings(x) implies locatedIn(x,y) and TexasRegion(y)
equivalentClass  TexasThings(x) implies locatedIn(x,y) and TexasRegion(y)

locatedIn(x,y) and TexasRegion(y) implies TexasThings(x)

To tie together properties in a similar fashion, we use owl:equivalentProperty.
==4.2. Identity between Individuals

sameAs== This mechanism is similar to that for classes, but declares two individuals to be identical. An example would be:

<Wine rdf:ID="MikesFavoriteWine">

  <owl:sameAs rdf:resource="#StGenevieveTexasWhite" /> 

</Wine>  ? 

This example does not have great utility. About all we learn from this is that Mike likes an inexpensive local wine. A more typical use of sameAs would be to equate individuals defined in different documents to one another, as part of unifying two ontologies.
This brings up an important point. OWL does not have a unique name assumption. Just because two names are different does not mean they refer to different individuals.
In the example above, we asserted identity between two distinct names. But it is just as possible for this sort of identity to be inferred. Remember the implications that can be derived from a functional property. Given that hasMaker is functional, the following is not necessarily a conflict.

<owl:Thing rdf:about="#BancroftChardonnay">

  <hasMaker rdf:resource="#Bancroft" />

  <hasMaker rdf:resource="#Beringer" />

</owl:Thing>  ? 

Unless this conflicts with other information in our ontology, it simply means that Bancroft = Beringer.
Note that using sameAs to equate two classes is not the same as equating them with equivalentClass; instead, it causes the the classes to be interpreted as individuals, and is therefore sufficient to categorize an ontology as OWL Full. In OWL Full sameAs may be used to equate anything: a class and an individual, a property and a class, etc., and causes both arguments to be interpreted as individuals.
==4.3. Different Individuals

differentFrom, AllDifferent== This mechanism provides the opposite effect from sameAs.

<WineSugar rdf:ID="Dry" />

<WineSugar rdf:ID="Sweet">

  <owl:differentFrom rdf:resource="#Dry"/>  

</WineSugar>

<WineSugar rdf:ID="OffDry">

  <owl:differentFrom rdf:resource="#Dry"/> 

  <owl:differentFrom rdf:resource="#Sweet"/> 

</WineSugar>

This is one way to assert that these three values are mutually distinct. There will be cases where it is important to ensure such distinct identities. Without these assertions we could describe a wine that was both Dry and Sweet. We have stated that the hasSugar property applied to a wine has no more than one value. If we erred, and asserted that a wine was both Dry and Sweet, without the differentFrom elements above, this would imply that Dry and Sweet are identical. With the elements above, we would instead get a contradiction.
A more convenient mechanism exists to define a set of mutually distinct individuals. The following asserts that Red, White, and Rose are pairwise distinct.

<owl:AllDifferent>

  <owl:distinctMembers rdf:parseType="Collection">

    <vin:WineColor rdf:about="#Red" />

    <vin:WineColor rdf:about="#White" />

    <vin:WineColor rdf:about="#Rose" />

  </owl:distinctMembers>

</owl:AllDifferent>

Note that owl:distinctMembers can only be used in combination with owl:AllDifferent
In the wine ontology we provide an owl:AllDifferent assertion for all of the WineDescriptors. We also state that the Winerys are all different. If we wanted to add a new winery in some other ontology and assert that it was disjoint from all of those that have already been defined, we would need to cut and paste the original owl:AllDifferent assertion and add the new maker to the list. There is not a simpler way to extend an owl:AllDifferent collection in OWL DL. In OWL Full, using RDF triples and the rdf:List constructs, other approaches are possible.

---