TNO Terminology Design: Effectively resolving semantic discussions for data sharing

This methodology consists of

1. well-moderated discussion sessions for terminology design;
2. open-source tools that help readers of texts you author to (learn to) properly understand the terminology you designed;
3. trained vigilance to maintain terminology consistency.

Some history: semantic interoperability between humans

TNO, a Dutch national research institute, has a wealth of experience with semantic interoperability. Semantic interoperability is essential when sharing data between systems within or between organisations.

TNO’s “Semantic Treehouse” is a vocabulary hub, which enables systems to communicate smoothly by using a common data model. It also provides a methodology to agree on, define and improve these models.

TNO also has a long history in contributing to international standards development (W3C, IETF, ETSI, ITU, ISO, etc.), as well as sector-based initiatives. We recognize the frequent occurrence and debilitating effect of semantic discussions, where multiple people debate/argue over the definition of commonly used terms, such as “risk”, “identity”, “architecture”, “role”, etc..

We notice the wholesale import of terminology from other documents, work on terminology documents and sections while lacking a proper context or agreed conceptual models, as well as blatant violations by using terms with different semantics than previously agreed. All of these result in major delays, wasted efforts and low-quality interoperability specifications, as illustrated in Figure 1.

It’s clear that semantic interoperability between systems starts with semantic interoperability between humans. Whereas there exist many methodologies and trainings focused on human interaction in the workplace, none of these address multi-stakeholder discussions for the development of data-sharing interoperability specifications. This is where TNO Terminology Design comes in.

TNO Terminology Design was first conceived by Rieks Joosten in 2015, as a contribution to help resolve terminology-related issues for the ISO 27000 standard. It was made more operational when he started to contribute to the development of self-sovereign identity (SSI) standards by W3C-CCG and ToIP (Trust-over-IP foundation).

Rieks co-founded and co-chaired the ToIP CTWG (Concepts & Terminology Working Group), where a group of willing experts develops consistent conceptual models and designs terminology in collaboration with other ToIP groups.

With investments from the EC (eSSIF-Lab) and TNO, this approach is now being productized as the TNO Terminology Design proposition, and it is already being experimentally applied in several places. More about that later.

The Terminology Design Process

The purpose of this blog post is to explain the TNO Terminology Design methodology, illustrated in Figure 2, and to encourage people to consider it whenever they feel caught in semantic discussion.

Step 0): Acknowledge the semantic discussion

As illustrated in the well-known four-stages-of-competence model, any change starts with acknowledging that there is a problem. The inaneness of some semantic discussions does not necessarily mean that there is willingness to resolve.

Some people may be unwilling to acknowledge the situation because of incompetence and or ego (“if everybody would just stop discussion and agree with me”). Other people may feel in a rush and presume that they can quickly deliver a result by ignoring the semantics issues. Still other people may benefit from the status-quo and have no business or personal interest to change. In such cases, one can better walk away, and TNO has regularly walked away.

Presuming that there is sufficient consensus to systematically address the difficulty of terminology design, and people are willing to invest time and effort, then we can take the next step.

Step 1): Moderated sessions focus on “criteria”

“Seek first to understand then to be understood” is a well-known adage for human interaction, and it applies equally to TNO Terminology Design. The key role in the moderated sessions is the moderator, who we’ll affectionally call the “Smart Friendly Silly (wo)man” (SFS).

The SFS is smart in their well-trained understanding of semantic discussions, their application of TNO Terminology Design methodology, and staying focused on the context of the moderated session. The SFS is friendly in their attitude towards their participants and their efforts to achieve mutual understanding. The SFS is silly in that they sometimes purposefully misunderstand statements or insert examples that highlight potential points of semantic confusion.

TNO Terminology Design focuses on criteria that define the concepts behind the terms that are used, rather than on their various “(in)correct” definitions. The SFS will invite a first participant to come up with the criteria that it uses to determine what is, and what is not (an instance or example of) the particular concept that they refer to when using the contested term.

Next the SFS will (request participants to) provide examples and request all participants to say whether it satisfies the uttered criteria (e.g., ‘Does an apple satisfy the criteria?’). The first participant may modify their criteria subsequently, and the process will repeat until there is sufficient common understanding of the concept as the first participant has conceived it, and as defined by the criteria for that concept.

At this stage, all participants have a shared understanding of the concept conceived by this first participant. While they still may be convinced that the term used by the first participant should not be the one to use for the concept, they at least have a proper understanding of what the first participant means by it.

These steps may be repeated, e.g., for participants that have a different understanding of such a term. This typically leads to a variety of criteria that can be tested until all participants make the same distinctions when using it, thereby showing they have the same understanding of the associated concepts. Multiple participants may have concepts that are relevant in the context of the moderated session. The above approach would be repeated until all possibly relevant concepts have been teased out.

Once all concepts have been teased out, the next step is to achieve consensus which of these concepts are relevant for the purpose of the moderated session. Here again, the SFS challenges participants to be clear what purpose a specific concept would serve.

The last step in the process is to come up with proper terms for the agreed concepts. For example, if different participants use the same term for different concepts, then it is obvious that different terms are needed. Again, the SFS plays its role of keeping the participants within the agreed context of the moderated session. The SFS may support the discussion by throwing in previously agreed criteria, voting and other approaches to stimulate consensus.

Step 2): Documentation using Docusaurus with TNO Terminology Design plug-in

Once consensus has been achieved on a set of concepts, their defining criteria and their agreed terms, this consensus needs to be documented. There are various static-site generators, such as Docusaurus, that can be used to quickly build optimized websites, with focus on content.

They are regularly used to develop static websites that contain documentation and specifications. TNO is currently developing open-source tools that can be integrated with such static site generators,enabling documenters to not only document the terminology they designed, but also highlight the defined terms where they are used in the documentation texts, and provide linked pop-ups to their defining criteria.

Figure 3 provides an example of a TNO Terminology Design popup for a defined term. When clicking the link, one gets to a page where the term is defined through a short description, the purpose of the term, its defining criteria and a few examples of its use.

You can follow the progress of the tool-developments on github.

Step 3) Trained vigilance to maintain terminology consistency

Data interoperability specifications have their lifecycle. New developments may require the addition or updating of terms, and deprecation of old ones. Newcomers may enter during the specification process and start new semantic discussions.  Vigilance is required, not only to maintain the consistency of the terminology as it evolves, but also to maintain the consistency of existing texts that use it.

This is why the TNO Terminology Design methodology includes training in how to deal with this. What are signals that may jeopardize terminology? How to deal with those signals? For example, how about participants disagreeing with a previously defined term? Or what if our own terminology turns out to be inconsistent with terminology defined elsewhere?

We’ll address this vigilance training in more detail in a future blog about TNO Terminology Design.

Experimental validation: does TNO Terminology Design work?

TNO Terminology Design is currently at Technology Readiness Level TRL4 (“validated in lab”). We are using TNO’s 2023 investment to achieve TRL5 (“validated in relevant environment”).

TNO has already tested the methodology with some friendly users at the 2022 RWOT event in the Hague. Some of the prominent RWOT participants reacted very positively, see Figure 4.

One result of an RWOT terminology session was the term “Verifiable Issuer and Verifier”, which is a central concept in one of the resulting RWOT papers. Also the RWOT paper on “Identifier Binding” has benefitted from a moderated terminology session. The methodology, focusing on “criteria first” has also been effectively applied to some discussions in W3C-CCG and ToIP.

In 2023, we are testing and refining the methodology both TNO-internally, and with “friendly users” in standardisation (ToIP) and customer projects about interoperable data-sharing. In this process, we want to learn how much willingness groups of stakeholders have to dedicatedly work on terminology design and to invest time and resources in this, as well as the effectiveness of the methodology to achieve its goals. We’ll publish about those experiences later.

Contact us to try TNO Terminology Design yourself

As asked in the opening of this blog: do you find yourself regularly caught in inane semantic discussions when developing interoperable solutions for data sharing, e.g., for (self-sovereign) identity management? Do you wish there was a way to effectively resolve such discussions, and get to business with developing the specification? And hence, has this blog triggered your curiosity about TNO Terminology Design?

If so, please contact us and let’s talk! Also, if you want to contribute to the further development of the TEv2 toolbox.