3.6: Ontology reuse

Applying modularisation and CQ's to stimulate and apply reuse.

Reusing software components is a common theme in software development. Similar functions are required among various software projects. Therefore, a lot can be gained by categorizing those similarities and generalise functionality to one single component with different flavours in order to stimulate reuse.

As elaborated in section 3.3: Ontology modularisation, reuse in ontology engineering is similarly encouraged. In this section we will show that reuse can be stimulated by a proper use of ontology modularisation, functional requirements and CQ's. Different from the software engineering community, in the ontology community the ubiquituous use of (parts of) ontologies is widespread.

What: Putting it all together

In section 3.3: Ontology modularisation, we showed modularisation to be a stepping stone for reuse. Modularisation enables you to identify parts that exist in the domain of application which might have been modelled already. This allows for reuse of ontologies or parts thereof. Two questions remain: Firstly, which existing ontology to reuse? And, secondly, whether to reuse the available ontology, or not. When can we expect the task to map an existing ontology to the requirements of the new ontology difficult but worthwile, and when should we consider it useless or too costly, or both. This problem can be made somewhat easier by adding competency questions to the mix.

How: Pizzeria ontology example

We want to give an example to illustrate the idea of modularisation and reuse. For that purposes we use the Pizzeria ontology that we have already modularised in Section 3.3: Ontology modularisation.

When considering reuse, this also brings advantages. Since each module represents a comprehensive description with a single purpose in mind, the potential for being reused is much higher than the multi-purpose, multi-perspective Pizzeria ontology as a whole. Moreover, the chances that one of such domains has already been described in a separate ontology, is also much higher than with the heterogeneous Pizzeria domain. In fact, from the identified 6 modules there are already candidate ontologies for 5 of them:

• Pizzeria: custom

• Pizza: tutorial ontology

• Person: FOAF

• Location, geonames, wgs_84

• Building/restaurant: Buildings Topology Ontology

• Delivery vehicle: Vehicle ontology, Used cars ontology & vehicle sales ontology

This gives the ontology engineer a list of ontologies to review for potential reuse. Only when for a module no particular candidates are available, or candidates are available but addressing different purposes and, hence, providing different competences, a custom built solution is necessary. By application of reuse, the Pizzeria ontology can now be constructed as follows:

Pizzeria ontology with reused ontologies

In practice: reusing ontologies

The reuse of ontologies is not necessarily a fixed step in the process, but is something to keep in mind continuously while performing an iteration. For example, while actually modelling an iteration or specific concept, there are two questions you can ask:

• What (basic) ontologies, that we already reuse, can add something to this new concept being modelled?

• Are we now specifying any concepts or even a (sub-)domain that may exist already in other ontologies?

When ontologies exist that already cover the domain to be modelled, why not reuse them? Use search engines to find relevant ontologies by using keywords, or visit ontology repositories. Inspect the meta-data about the ontology, or the ontology itself, to gather an understanding of its domain of application. Decide whether it is useful to make a connection with this existing ontology, or whether this ontology can be used as an inspiration for your own model.

Competency questions per module

The combination of modularisation and reuse becomes more effective when we consider competency questions per module. Assume we have defined a set of CQs related to the DeliveryVehicle, as follows:

1. Which DeliveryVehicles does the Pizzeriause to deliver pizzas?

2. Are any of the DeliveryVehicles electric?

3. How many DeliveryVehiclesdoes the Pizzeria own?

4. What is the brand and type of the DeliveryVehicles?

5. What is the most recently bought DeliveryVehicle?

6. Are the DeliveryVehicles new or second-handed?

Having already established a reuse candidate, now we can establish a potential mapping from CQ to the property that already exists in the reuse candidate. For reference the Vehicle ontologies can be found at http://ontologies.makolab.com/uco/ns.html (denoted uco) and http://www.heppnetz.de/ontologies/vso/ns (denoted vso). Then, the CQs may be mapped as follows:

1. Which vehicle(s) does the pizzeria use to deliver pizzas?

   1. pizzeria:Pizzeria;

   2. uco:owner , uco:OwnershipInfo , uco:hasOwnershipInfo

2. Which types of vehicle does the pizzeria use to deliver?

   1. uco:CarType

3. Are the delivery vehicles electric?

   1. The ontology contains a vso:EngineTypeValue that may contain Electric_motor as value. This value may be used to determine whether the vehicle is electric.

4. How many delivery vehicles does the pizzeria own?

   1. Cardinality of uco:owner uco:OwnershipInfo

5. What is the brand and type of the delivery vehicle?

   1. foo:car_1234 gr:hasManufacturer ?manufacturer

   2. foo:car_1234 gr:hasMakeAndModel ?makeAndModel

   3. Object can be dbpedia ref in both cases

6. What is the most recently bought vehicle?

   1. ?var a uco:OwnershipInfo

   2. ?var uco:owner pizzeria:Pizzeria1

   3. highest(?var uco:from ?dateTime)

7. Are the vehicles new or second-handed?

   1. foo:car_1234 uco:numberOfOwners > "2"^^xsd:integer

The above mapping describes the properties from the candidate ontology that are necessary to address the CQs. This provides for a nice overview of how well the candidate ontology fits the requirements of the specific module. When doing this exercize for multiple candidates, the results represent a clear rational in support of the final choice between candidates. It also indicates which CQs require additional concepts and properties, or modifications to existing ones, to become comprehensive and faithful. Those results may even lead to the conclusion to decide against reuse of existing ontologies, and custom engineer the subject module.

Relevant sources that can carry candidate ontologies include libraries such as listed below. However, repositories for ontologies register ontologies notably random, without a shared view on what such a repository should address, and suffer from maintenance. This list, too, is rather incomplete:

• W3C Wiki (https://www.w3.org/wiki/Ontology_repositories)

• BioPortal (http://bioportal.bioontology.org/)

• OntoHub (https://ontohub.org/)

• TNO (https://ontology.tno.nl/)

When no candidate ontologies can be found, note that inspiration can also be found in domain vocabularies, linked open data resources and industrial standards. Not only will this provide suggestions for terminlogy and definitions, also structural and hierarchical aspects will be discussed.

All in all, the combination of modularisation and CQ's provides for a necessary tool to build better ontologies with higher complexity than a single monolithic ontology.