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.
Add a new, narrower concept and specify its relation type

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.
Add another narrower and specify its relation type

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
Start modifying hierarchical relation types
Drag ‘n drop to the desired type

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:
Note the different symbols that indicate the relation type

Summary

ExplanationExampleSymbol
unspecifiedundecided yet, can be changed later
genericgeneral, abstract broader-narrower relationsunflower < plant
is instance ofentities, often product namesAlps < mountain regions
is part ofsubordinate concept is part of / member of broader conceptbrain < 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.

Author

Michael is co-founder of Coreon GmbH and Managing Director. He also holds the position of Senior Product Manager in ESTeam AB since 2011. He focuses on everything product by leveraging his long term experience in team and product management, standardization, and problem solving.