Use the whiteboard above to explore the development steps of merging the ontologies!
Step 1 – mapping concepts between individual ontologies
- Export the individual OwlVis graphs and visualise in a whiteboard tool (Miroboard)
- Draw connections and commonalities between individual ontologies
- Resulted in 5 generalisations
- Stakeholder and usage
- Physical objects
- Place and climate
- Materiality
- Unique concepts*
*Some, but not all individual ontologies had unique concepts (such as documentation in ‘architectural’ or loading analysis in ‘structural’). In some cases these unique aspects needed to be ‘trimmed back’ (ie. there was more detail than what would be logical for the new topic), generalised or added in its entirety (perhaps necessitating extension among sibling classes).
step 2 – developing a draft document with new reorganisation of concepts
- This required working through the mapped concepts whiteboard from the previous step and drafting out a taxonomy for the integrated ontology which would guide implementation in Protege in the following step.
- This was a documentation of the reorganisation and merging of concepts. For example, materials used among different individual ontologies were combined into one list of all required materials to avoid repetition.
- Some guiding principles in this step were:
- Minimising the number of top classes
- Following the ‘is a’ logic in building chains of related sub-classes.
- Deciding which concepts should be classes in their own right or which could perhaps take the form of object or data properties**.
**One way to think about this question is to consider that deciding for a concept to take the form of a data property, makes that concept static. If a concept is somehow fundamental to the ontology, it may in future need to be extended or further detailed. In this case it would be suitable as a class rather than a data property.
An example of where we needed to consider this decision was with regard to the ‘component status’ (or, to put it another way, ‘building phases’) class. Phasing is a fundamental concept in the renovation process, and one which may reasonably require further detailing later on. Thus it became a class rather than a data property of individual instances.
Step 3 – merging individual ontologies and reorganising in Protege
- It had been hoped that there would be some intelligent function to align on shared concepts within Protege, but it turned out to be a fully manual process.
- A piece of advice is to reorganise the classes in a textual document and not do this directly in Protege until some idea of the structure is known (as was shown in step 2).
- Using the ‘merge’ function in Protege, the 4 individual ontologies were combined into a single file, the resulting list of top classes, object and data properties shown under heading 3 in the board above.
- A method that was used in reorganising classes was to first place all merged classes into a single top class, create all the top classes structure as defined in step 2, and to then drag and drop from the combined list.
- This was the step at which various subclasses which went into unnecessary detail for the new ontology, were dropped (such as providing specific named site locations from the structural ontology).Others were dropped and made into data properties, such as the various shape of columns (square, circular, cross etc.), again, from the structural ontology.
- It was important to be careful with repeating identical classes in the merge as they behave as one in Protege (thus, deleting one deletes both!)***.
***An early conclusion may be to recommend building new ontologies from scratch. This guidance is also found in seminal literature on the topic of combining ontologies, Pawels et al. (2017) discussing one of the main benefits of this approach as being to not extend legacy issues into new developments. Another benefit, they point out, is in the process of building an ontology from scratch, significant understanding of the domain can be learned.
This advice of course is greatly dependant on the scale of integration. In the case of the BIMDO ontology (Niknam & Karshenas 2017), the authors utilise very large ontologies in their workflow, including one for construction material specification (Free Class OWL ontology comprising 88 million triples) and one for quantities and units of measurement (QUDT ontology). In this case of course, building the ontology from scratch becomes extremely impractical!
Step 4 – extending the ontology to fill out the logic of the new domain
- Once the ontology structure had been filled out in Protege with the repurposed classes from the individual ontologies, it was necessary to extend the ontology with new classes.
- This extension completed the logical organisation of the new ontology.
- For example, the addition of the ‘component status’ top class and associated phasing subclasses (as described previously in Step 2) was a logical extension to the renovation domain. Another was the list of ‘implementation processes’ (or construction steps), a logical extension given the integration of scaffolding and logistics into the new ontology.
Download link: group4combinedontology
