Semantic Richness: The Different Types Of Hierarchical Relations

Going beyond the simple idea of broader and narrower relations: which other, more specific, hierarchical relations can we identify?

As a Multilingual Knowledge System (MKS), Coreon unifies knowledge and language by combining concept maps with terminology data. Generally these concepts are simply linked by hierarchical broader or narrower relations, but Coreon has developed a system to go way beyond that. Instead of just modelling simple broader or narrower relations, Coreon allows you to specify terms and concepts with semantic precision by using various hierarchical relation types, namely: generic, is instance of, is part of, and unspecified.

Generic represents a general abstract broader or narrower relation and thus identifies the link between a class and its members or species.  It is used quite frequently and can be seen as some sort of standard selection.

Example: A sunflower [narrower concept] is a plant [broader concept].

Is instance of indicates the link between a general category of things or events, expressed by a common noun, and an individual instance of that category, e.g. entities or specific examples, often in the form of a proper noun.

Example: The Alps are a specific example or instance for mountain regions.

Is part of: The Whole-Part relation (linguistics: meronymy) is used when one class represents the whole object and other classes represent parts, e.g. if you want to indicate that a subordinate concept is part of a broader concept or one concept is inherently included in another. Some examples are:

• Systems and organs of the body: The brain is part of the nervous system.
• Geographic locations: Ontario is a part of Canada.
• Hierarchical organizational, corporate, political, or social structures: The chancellor is part of the government.

Unspecified: This relation type has no particular semantic meaning. In other words, you can decide whether you are ready to be more precise and select a specific relation type when creating a concept, or to simply leave it still as unspecified. As such, it is a helpful tool for data maintenance since no clear classification is required and the relation type can still be changed later on.

How to use this in Coreon?

Situation 1: Add the first narrower concept

1. Click on + Create New.
2. Choose one of the four relation types listed in the drop-down menu.
3. Create your new, narrower concept.

Situation 2: Add further narrower concepts

1. Select your broader concept of interest.
2. Click on the pencil icon (top right corner) to enter the edit mode, if not already done.
3. Within the Broader & Narrower area, select one of the four listed relations by clicking on the  icon next to it.
4. Create your new narrower concept.

Situation 3: Change the type of a relation

The hierarchical relation type can be changed at any time.

1. Click on the pencil icon (top right corner) to enter the edit mode, if not already done.
2. Click on the pencil icon (below the different relation types) to edit relations to broader and narrower concepts.
3. Drag and drop your concept to the new type of relation in order to change it from its previous broader/narrower relation

Visualising the types

In order to represent the different relation types visually in the concept map, as well as in the concept itself, each type is indicated by a corresponding symbol.

• Generic:
• Is instance of:
• Is part of:

Summary

	Explanation	Example	Symbol
unspecified	undecided yet, can be changed later
generic	general, abstract broader-narrower relation	sunflower < plant
is instance of	entities, often product names	Alps < mountain regions
is part of	subordinate concept is part of / member of broader concept	brain < nervous system

Selecting the ‘type’ of relation is a great way to specify more precisely how concepts are hierarchically related. It simplifies the data maintenance process, and makes your MKS ready for solutions that demand higher semantic richness, rather than just simple taxonomies.

But why we did we focus on these particular relation types for Coreon? Well, firstly we followed the ANSI/NISO Z39.19-2005 (R2010) standard, which recommends these exact hierarchical relations. Secondly, having unspecified as an option was highly requested by our users for data maintenance reasons, namely to have a way of indicating that a given relation has not yet been looked at in detail, and has therefore not yet been decided upon.

Do you have any ideas or suggestions for further types of hierarchical relations that we should bring into Coreon? Get in contact with us!

Note: This blog post has been developed by students of the University of Mainz in the context of a seminar discussing modern ways to document agile software.