Friday, October 14, 2016

Tackling Important Knowledge Needs in Manufacturing

A multilingual knowledge system (MKS) combines language, such as multilingual terminology, with knowledge, a graph connecting the concepts via relations. The most common type of relation is the hierarchical one, also known as 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, namely from more generic to more specific. So that us humans can 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 large amounts of concepts (pieces, parts, assembled components) are put 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. Also these concepts are in a hierarchical relation to 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 respectively consists-of relation: 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'.

Polyhierarchical Relations alone are not Sufficient
However, in the manufacturing context above mentioned 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 children 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 do 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 1) – efficiency – is 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 2) – different sub-maps – is addressed, since one alias can have another set of narrower concepts than the other alias.


Coreon: aliases in a concept map
Aliases in a concept map


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 indeed different children: the wheel built into the front fork additionally 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 onto the needs for global manufacturers, companies that develop and ship products. I'd be interested to hear opinions how aliases help in classification and nomenclature-like activities.

6 comments:

  1. Looks really good, Michael. I was advocating the concept of single source terminology management in the late Nineties, but back then had nothing as sophisticated as Coreon to "single source" with :-)

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete