2.3: Glossary of terms

What is our terminology? What do we speak about when we communicate?

What: General recommendations

The terms that we use in our business scenarios tell us something about their relevance: apparently they are important as a means to describe what motivates the use of our ontology. The purpose of defining a glossary is then to collect and define these terms that are in scope, with a description of their meaning in a Glossary of Terms. This glossary will remain a living document throughout the project and a growing index into the ontology. Moreover, generating a glossary of terms from the ontology is rather straigthforward and its validation against the initial, manually specified Glossary of Terms shows a perfect criterion in your Definition of Done.

In practice: deriving events and objects

The scenarios as defined in the previous step can be used to derive the relevant terms germane to the domain. A distinction can be made between events and objects by making difference between verbs and nouns. For example, highlight all verbs with pink and highlight all nouns with blue. Now you have made a first distinction between objects (nouns) and events (verbs). In the ontology, the objects will end up as classes and events might end up as relations/properties, or genuine temporal concepts. (This approach has been used in the FIT with Ontologies project. The identified objects turned out to be useful in defining classes, but the events were not directly used to create relations.)

When doing this exercise together physically, then it is recommended to write the verbs and nouns on post-its of different colours. Putting the post-its on a wall allows for additional steps to be performed:

• Discover the most important concepts. These are concepts that are being used in almost every scenario.

• This is also a good moment to identify duplicates by synonym. If synonyms exist, or necessary to exist, the domain experts should (later on) agree on the preferred name.

• Agree on the definition of the concept, because it often happens that domain experts mean something different when using the same term.

• Identify domain clusters. Although this will be the topic of 3.3: Ontology modularisation & Reuse, already identifying potential clusters is a quick win in this phase. Do this by clustering post-its on the wall. A simple question can already identify potential clusters for which no concepts yet exist, but which will support the fture modularisation task and the extension of the Glossary in the next iteration. A cluster can also drive the selection of the (sub-)domain(s) that is/are to be modelled in the iteration of the Chapter 3: Conceptual Phase.

General criteria

On writing down the Glossary, some questions can guide our exploration:

• What are the terms that we would like to talk about? This is essentially provided by the motivating business scenarios. However, blank areas exist in those scenarios; not because they are irrelevant or forgotten but because they represent either background knowledge that is considered generally known, or assumptions that apply in 90% of the cases. The difference is often hard to make, but the core idea here is to assume nothing and to turn as much as possible into explicit knowledge.

• What would we like to say about those terms? Apart from their apparent existence, what do they mean (see the above practice)? How do they relate to other concepts? What properties do they exibit?

Initially, it is important to get a comprehensive Glossary of Terms, including a list and/or graphs of all nouns and verbs that have been considered. At this point we should not yet worry about overlap between concepts they represent, relations among the terms, or any properties that the concepts may have, or whether the concepts are classes or properties: we will decide on all of these things at a later stage, when we create our conceptual model and create structure in our sets of concepts.

In practice, that will mean that each term will have at least:

1. a name;

2. a synonym;

3. a natural language description;

4. a type;

5. a source (to remember why it was put there in the first place); and

6. comments.

In practice: deciding on definitions

It often happens that domain experts mean something different when using to the same term. The ability to differentiate is at the core of an ontology, so identifying differences should not come across as a nuisance but as a feature to be embraced instead. Discuss what a term / concept refers to in reality and agree upon the use of multiple concepts when necessary.

In practice it turns out that this can be done best by defining and discussing a concept in smaller groups, followed by a discussion with a bigger group to iron out the variations in the definition of the concept. The sketched scenarios and processes can be useful input for these discussions. It is important to reach consensus as we are modelling a shared language. When consensus has been reached the concept and its definition can be included in the Glossary of Terms.

Throughout discussions, often new concepts will pop-up; when they do, their definition (or purpose, or scope, or intention) is not always certain, hence, a decision on their relevance or importance is difficult to make. As opposed to hammer that out, record these terms, for example by adding a new post-it on the wall, with the purpose to elaborate on them and discuss their definitions later, when all other terms from the list have been processed. In this way the group keeps her focus on the task at hand while the potentially relevant concepts are not lost. When time allows, we can go through the list of emerged concepts as if they belonged to the initial list. However, when time prevents such exercise to happen, the reason for their existence might be lost quickly, and with it their existence. Hence, before deferring these emerged concepts to another session or even the next iteration, we need to make sure that the initial reason for their popping-up and/or meaning is recorded.