Glossaries and ontologies: Definitions of terms in data

In the wonderful talk "Design in Practice", Rich Hickey talks about how important an up-to-date glossary is in the design process.

I have a similar view, and see something like "Business Knowledge Blueprints" as an important foundation for business applications and especially for (enterprise) knowledge graphs.

Today, however, I was given the idea of including formal definitions in a glossary. The Web Ontology Language (OWL) is defined as a description logic which, as the name suggests, is primarily suitable for describing or classifying a section of the world or the entities in the Universe of Discourse.

So is it a good idea to manage a formal description for each glossary entry directly in the glossary?

I will try this out.

Unique names?

Rich also talks about how important unique terms or names are in the glossary and gives the term "customers" as an example.

I have my doubts here: in my opinion, the term "customer" in particular is not suitable for being clearly defined. When I'm in companies, salespeople, management, the billing department and employees in end "customer" contact often understand "our customers" to mean something quite different.

And despite all the effort to make support staff say "user", "client" or similar, for example, in everyday language it often becomes "our customers want ...".

Here I am glad that in RDF and thus in OWL with the prefixes something like namespaces are created that allow me to map something like this by using accounting:customer or support:customer.

And no, I am not a fan of incomprehensible IDs for entities as myont:4321 and myont:4334, which are then given the name "customer"@en and "customer"@de by label. Hopefully more on this in another article :)

Examples

Let's look at a thing which almost nobody defines, an address. What does this mean for your example?

I like to go to the publicly available upper-level ontology gist von Semantic Arts for ideas on how to define concepts. gist is minimalistic but quite precise in it's definitions.

Address

If we look at the definition for physical addresses, we see that is has a gist:StreetAddress as well as a gist:PostalAddress. In the description, which can be seen as a glossary entry, a gist:StreetAddress is defined as "An address which references a fixed location in the physical world.", whereas the definition of gist:PostalAddress says "A set of codes the postal authorities can use to deliver physical mail.".

Quite the difference. And I think the gist:StreetAddress is not ideally named: there are "addresses" in the physical world that have nothing to do with streets.

And while gist is defined as an "ontology", if we look at the OWL version of it, both concepts have no formal definition :)

Obviously the authors decided, that a definition would be to restrictive for an upper level ontology. But maybe in a specific project adding a formal definition referencing actual data structures in use would be beneficial.

But this shows that OWL can be a good way to manage gloassaries. You can define textual descriptions, even with more semantic meaning than using "only" text. gist:StreetAddress for axample as a skos:ScopeNote saying "This excludes addresses not associated with a fixed location, such as a PO box or FPO code.". The existence of "ScopeNotes" alone can suggest to users to add notes of this kind, which leads to more precise definitions.

The meaning of skos:ScopeNote itself can be found in in the Simple Knowledge Organization System, it's "skos:scopeNote supplies some, possibly partial, information about the intended meaning of a concept, especially as an indication of how the use of a concept is limited in indexing practice. [...]" SKOS Primer

Specification

Let's look at a slightly more formally defined example, a specification.

Remember, gist is an upper level ontology, so the specifications are very high level, that's intended to make it usab le in many different contexts.

Still, gist defines two type of specifications, a product and a service specification. And for both it adds a formal definition. Let's look at this:

The natural language definition of gist:ProductSpecification states "Offering something which could be physically warehoused or digitally stored." and for gist:ServiceSpecification it says "A description of something that can be done for a person or organization (which produces some form of an act).".

Both of these are concise, clear and describe the difference ("physically" vs "can be done"), but looking at the formal definition you might be surprised about some added detail:

gist:ProductSpecification
  a owl:Class ;
  owl:equivalentClass [
      a owl:Class ;
      owl:intersectionOf (
          gist:CatalogItem
          [
              a owl:Restriction ;
              owl:onProperty gist:isCategorizedBy ;
              owl:someValuesFrom gist:ProductCategory ;
              ]
          ) ;
      ] ; [...].
 

gist:ServiceSpecification
  a owl:Class ;
  owl:equivalentClass [
      a owl:Class ;
      owl:intersectionOf (
          gist:CatalogItem
          [
              a owl:Restriction ;
              owl:onProperty gist:isBasisFor ;
              owl:someValuesFrom gist:Event ;
              ]
          ) ;
      ] ; [...].

Both define their specifications as a gist:CatalogItem. So, as something to be sold. This means it excludes explicitly purely internal specifications, which I find rather surprising.

Also, gist:ServiceSpecification clearly states that it is the basis for some gist:Event, and we could look up the definition for this to find that an gist:event (not an "event") is defined to be a gist:behavior with a gist:startDateTime and a gist:endDateTime, i.e. something that actually happens in the world.

And the gist:ProductSpecification is a gist:CatalogItem that is categorized by some gist:ProductCategory. Also a definition I would not have guessed from the natural language text: only something that is categorized into a gist:ProductCategory is actually accepted as ProductSpecification.

Also note the details that a specification is in the catalog, not a product. This is quite obvious if you think about it, but quite often we say "put that product into our catalog/offer/....".

This is where a formal definition nudges us to think and act with more precision. I also think it makes the difference between a glossary and everyday language clearer if we speak about the meaning of ourontology:customer than just about "customer". 
 

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.

We use cookies on our website to support technical features that enhance your user experience.

Es werden keine Dienste zur Analyse Ihres Verhaltens genutzt, wir tracken sie nicht.