Tackling Important Knowledge Needs in Manufacturing

A multilingual knowledge system (MKS) combines language (such as multilingual terminology) with knowledge (a graph that connects the concepts via relations). The most common type of relation is a hierarchical one, also known as a broader/narrower, or parent/child relation. Such a hierarchically structured concept system is often also referred to as a taxonomy.

Many taxonomies that we see in real life are used to categorize vast amounts of information into classes and sub-classes of information, from more generic to more specific. This allows us humans to navigate and find them in an easy and meaningful way: books in libraries, types of goods in an online shop, or even a classification of industries – for instance the Industry Classification Benchmark (ICB). Fine.

Concept Systems to Model Products, Modules, Components

Now, manufacturers use multilingual knowledge systems to capture the language, the labeling of their products, modules, and components that make up their goods. Also in this scenario, a large amount of concepts (pieces, parts, assembled components) are stored in relation to each other. Let us imagine a manufacturer that produces bicycles. A bicycle – the broadest concept – then consists of a frame, handlebar and saddle, wheels and brakes, the propulsion etc. These concepts are also in hierarchical relationships with each other. However, in contrast to classification systems or nomenclatures, the broader-narrower relation that we see here is more to be understood as an is-part-of/consists-of relationship: A spoke reflector is-part-of a wheel (… yes, experts in linguistics and semantics already know that I talk about the so-called meronomy here).

Re-Using Parts and Components

Of course, in manufacturing processes components are re-used everywhere, like from a library or a construction kit: one component – i.e. a concept in the knowledge system – becomes part of several modules; it is assembled into several products. For instance, a wheel is part of the front fork as well as the rear frame. This means, in an MKS, the concept ‘wheel’ must appear two times, once as a child concept to ‘front fork’, once as a child concept to ‘rear frame’ (and probably also again and again in different types of bicycles). How can we model this in an MKS?

The obvious and immediate answer to this is usually that an MKS must support so-called polyhierarchical structures: the graph may not be a simple tree but must support multiple parent relations. Of course, Coreon’s MKS does support polyhierarchies – multiple inheritance from parent to child nodes. Last but not least, this is also a mandatory requirement for classification-like taxonomies: in the taxonomy of a construction market’s online shop the marketeers may want to file ‘silicone’ both underneath ‘bath/ceramics’ as well as under ‘building materials’.

Polyhierarchicial Relations Alone Are Not Sufficient

However, in the manufacturing context mentioned above, polyhierarchies do not yet address the requirement to a satisfying degree. Why?

1. Efficiency: Manage the concept only once. It would be absolutely inefficient to store the common information about a wheel as often as it is used in a bicycle. Maintainers rather want to elaborate on a concept only once, describe it, illustrate it with images, incorporate all terms, synonyms in all languages.
2. Different child concepts (“sub-maps”): Depending under which parent a concept is hooked, it can have different children concepts. For instance, the wheel being part of the front fork has additionally the part, i.e. the narrower concept, ‘dynamo’, whereas the wheel being part of the rear frame is additionally equipped with the ‘rear brake’.

These two requirements together ask for a solution that goes beyond polyhierarchies. How does Coreon address this?

Aliases: Re-Using a Concept in the Map

Coreon’s MKS resolves this by its unique “Alias” capability. A functionality that makes one and the same concept show up several times in the concept system. Intuitive and powerful, aliases work like shortcuts, like placeholders. How does it work?

Instead of hooking the concept ‘wheel’ two times under different parent concepts or (even worse) instead of inefficiently storing ‘wheel’ and all its information and terms multiple times in the repository, we store ‘wheel’ only once with all its terms, meta data, illustrations. Then a maintainer creates one alias to ‘wheel’ underneath ‘front fork’ and another alias underneath ‘rear frame’. Both aliases are just shortcuts and point to one and the same referent concept, but make it explicit that wheel is part of the front fork as well as the rear frame. A future change made to the referent concept, for instance, add another language, is immediately visible also via the aliases. Requirement number 1 – efficiency – is therefore addressed.

Further, an alias itself does exist as a physical node in the knowledge graph; it can have a complete set of own relations: broader/narrower as well as associative ones. Thus requirement number 2 – different sub-maps – is addressed, since one alias can have another set of narrower concepts than the other alias.

Have a look at the screenshot and notice two things: 1) the different rendering of the aliases in the concept map (the ones with the curvy arrow) and, 2), aliases pointing to the same referent concept have different children: the wheel built into the front fork has a dynamo, the wheel built into the rear frame has a rear brake. And, of course, aliases can have aliases as narrower concepts too (see ‘spoke reflector’).

With this unique capability, manufacturers benefit from an efficient and effective way to model products, modules, and components via a Multilingual Knowledge System.

I’ve written this post with a particular view to address the needs of global manufacturers, companies that develop and ship products. I’d be interested to hear opinions how aliases help in classification and nomenclature-like activities.

*Feature Image: Business photo created by senivpetro – www.freepik.com