3.2: Actual reuse of existing ontologies

What various ways to reuse an existing ontology do exist? What scenario applies to my ontology?

  • Question: How can we best reuse existing ontologies for our own ontology?

  • Category: Conceptual

  • Problem owner: Linda

  • Date: 14 Dec 2020

Context

We do not want to reinvent the wheel when designing an ontology for a specific domain. So when feasible, we want to reuse already existing ontologies. But how do we go about the actually reuse?

Problem

Three specific problems arise when actually reusing an existing ontology:

  • Which way of reuse is most suitable?

  • When do you define a subclass relation and when an equivalent class relation between concepts in the existing ontology and your ontology?

  • When do you add a new concept in your own ontology related to a concept in the existing ontology and when not?

Discussed options

Ways of reuse

In order of increasing dependency and loose coupledness, the following four alternatives exist for ontology reuse.

  • Inspiration: this implies not actually reusing the existing ontology, but only the ideas behind it.

  • Partial integration: the concepts that are of relevance are directly copied into our own ontology, with an inclusion of their source. The reused concepts will become part of our namespace.

  • Reference: use of the owl:equivalentClass or owl:equivalentProperty results in setting an equivalence relation between your concept and that of the external ontology. Note that this adds only to the reasoning capabilities of your ontology, and particularly about the individuals as opposed to the concepts themselves.

  • Import: by use of the owl:imports statement, the namespace of the ontology that you want to reuse becomes available for reference in the ontology. As a result, you can directly apply its concepts in your ontology. This is the most flexible way of reuse, but sets demands on the availability and dereferencable capabilities of the external ontology, and pushes the external ontology out of your direct control.

Subclass vs equivalent class

A good reference is: https://www.w3.org/TR/2004/REC-owl-guide-20040210/#equivalentClass1

Equivalence relationship means:

  • A equivalent with B: A is subclass of B and B is subclass of A.

  • Individuals in both classes are the same.

Adding a new concept or not

You choose to introduce a new class or property as subclass or sub property when:

  • You want to constrain the class/property

  • You want to change the context of the class/property

Things to consider:

  • If you refer to a class in an existing ontology, you can choose to introduce a new class in your ontology, as a subclass of a class in an existing ontology. This makes the model clean, but it also offers the possibility to make the class more specific, for example by adding your own properties.

  • Adding a new concept improves manageability of your own ontology.

  • When you want to reuse properties from the superclass for you own subclass, it does not seem to be necessary to introduce your own sub properties. The REPRO group however was not completely sure about the pros and cons.

  • The REPRO group is not yet sure about all the implications of adding a new class as subclass of an existing class. Questions that still need to be answered are:

    • Are all properties belonging to the superclass automatically transferred to the subclass?

    • How do we deal with the fact that you may not want to use all properties, or, do not want to allow all properties?

Get inspired by others

For inspiration on this issue, you can look at the extension mechanism of Schema.org. For example, GS1 has an allowed extension: https://schema.org/docs/extension.html

Outcome

In 90% of the cases you will use a subclass relation when reusing existing ontologies and their concepts, because you are unsure whether the classes are really equivalent and thus have the same instances.

When you consider using a equivalent relation, take a moment to reflect on whether maybe the classes are currently equivalent, but might not be in the future.

Last updated