Linking ontologies to UML

This article closes the gap between down-to-earth, tech-heavy UML and the frighteningly academic and philosophic world of ontologies.

Software system architects use UML to master the maze of complex system design. Class models are the core of UML models where people collect the concepts that define systems. An architect quizes users, writes user stories and learns the language and concepts from the domain experts who are the true masters of their closed universe of discourse.

Ontologies can readily be used as foundation for system designs.

For the reader in a hurry, scroll to the bottom to see how ontologies can be easily imported into Sparx' Enterprise Architect.

What is an ontology ?

Ontologies can be regarded as reusable encyclopedias and sometimes go by other names such as knowledge graphs or object type libraries (OTL, get it?).

Ontology is the art of describing and classifying things like so

• define things - what are we're talking about
• categorise things into classes - sort things into boxes by colour or other properties
• define attributes that distinguish the classes - "clothes maketh the man"
• define and name relations between classes

These activities are familiar to system architects whom I herewith congratulate for unwittingly having earned the badge of applied philosopher. Also, ontology has been around since Plato so truly is a proven technology.

Ontology modelling largely overlaps UML class modelling. They differ in that UML is meant for automating the systems under scrutiny. Often the architect has a platform and solution in mind such as a data base, computer language or technical interfaces which constrains the modelling. Technical solutions are distracting straightjackets that steer thinking away from frowned-upon techniques such as multiple inheritance or slow complex joins. Yet, system architects are aware of the good practice to disregard technical constraints in early stage white-board design. Some system designers discipline themselves by using a limited subset of the vast UML toolbox to avoid the temptation and curse of technological prescience. In other words, they do their best to think like ontologists.

Ontology and the web

A URI is a Unique Resource Identifier that most often is accessible on the web and that refers to a thing/concept/entity/classes/objects. A resource on the semantic web should link to a meaning and related concepts. Does this sounds like wikipedia to you? Spot on! Things are identified by URI's and described by triples, simple subject - predicate - object sentences. These turn into a web if one considers that subjects and objects are nodes linked by predicates. Resource Description Format (RDF) is the purely descriptive language used to attach meaning to things.

Thus, one can turn a vocabulary, an encyclopedia or any body of knowledge into a graph of concepts by picking apart the phrases into their smallest parts, or "units of thought".

Concepts are defined and named in a given domain of expertise and ringfenced into a namespace. A forecast in the namespace "shipping" differs from a "forecast" in the namespace "finance". Mostly, ontologies cover a single such domain but cross-domain hyperlinks are easily created so that one domain can reuse and build on concepts from another domain.

Many ontologies have been published on the web with the intent of reuse and standardisation of terminology. This is particularly relevant to large organisations such as governments.

Everyone over the age of 45 probably remembers the effort it took to try and find written information, understand jargon or explaining terms to newcomers. Today online information is findable, accessible, interoperable and reusable - short FAIR.

Why should system engineers bother with ontologies

Reasons for doing so are

• reuse existing vocabularies - don't reinvent the wheel
• standardised terms improve interoperability
• standardised attributes and data types reduce the chance of mishaps (metric vs. imperial)
• users can easily find and access definitions - no need to eat up the precious time of domain experts - Herr Doktor, was zum Teufel bedeutet "ELARIWI"?
• users can find out context by following links to related concepts - developer, just follow your nose
• multilanguage definitions and labels further lower linguistic hurdles - aiguillage@fr is same as point@en-gb, switch@en-us, Weiche@de, wissel@nl
• data that claims to match a given ontology can be quality checked against a set of restrictions because an ontology can have schema information much like XSD but with even more oomph.
• reusing know-how adds confidence to the completeness of new models

Building on the shoulders of giants

All this begs the question how a system architect can latch on to the treasure trove of existing RDF ontologies. A proper translation mechanism was lacking until this publication by the EU's SEMIC working group standardised the translations which opens the doors to tooling.

Importing ontologies into Enterprise Architect

Today, reusing existing ontologies into Sparx' Enterprise Architect is a matter of just a few clicks. Below screenshot shows my Ontology Add-In that applies the rules laid down by the TED & EU Public Procurement office. The aim was to create a simple user interface for importing RDF and automatically create class models.

This Add-in imports existing ontologies straight into a package ready for use in your own UML model. It retains URI's, definitions and relations that are defined in the original RDF ontology. The "select URI" - button will download RDF from the web.

The import collects classes, attributes, relations and definitions from the RDF into the project browser. Classes are organised by package which is named after a known prefix, e.g. localgov and given a base-uri such as https://purl.org/oslo/ns/localgov#

The user creates a diagram and drops classes like the one above. The relations show automatically as classes are dropped in the diagram.

Given the imports, a user can explore existing ontologies at leisure and reuse whichever classes and relations are suitable. Awkward but necessary questions will be raised early when one discovers attributes and relations that one would never have thought of when working in isolation.

Reuse in action

Exploring existing models is good, reusing and extending them is better:

This diagram shows how to extend a design based on existing ontologies. The Person class is defined in this ontology so you can convince yourself that the definition was correctly imported as demonstrated by the note in the diagram.

No existing definitions have been harmed in the making of this new model.

Reusing as-is concurs with our goal that the model should be the single source of truth. Also note the numerous imported packages in the browser folder to the left. The Ontology importer created a package for every imported ontology and classes for each concept in the matching package.

I manually created a new class "Officer" in the new package https://example.eu/ns/police and gave it an attribute "inServiceSince" of type xsd:gYear. He has a rank taken from an enumeration, i.e. a codelist.

The inherited attributes from the localgov package also allow me to inform a peerage and "legal cohabitation". This raises the question whether I picked the right kind of "Person" class. And that's exactly the point because these are the sort of questions one should ask oneself when modelling information.

What's next

This newly created model can be used for "business as usual" in UML, e.g. to generate code, HTML, OO-code , or, guess what, exported as a new ontology which will be the subject of my next story...