Introduction

Shift from Implicit to Explicit Semantics

In today's common industrial practice, a machine-to-machine communication is designed in such a way that the communication partners exchange characters, e.g. bit patterns, between each other.

The use of the exchanged bit patterns with the correct meaning is ensured by the fact that the developers of machine software have the same understanding of exchanged characters between sender and the receiver of data.

This type of information exchange is called information exchange with "implicit semantics". So, the meaning of the exchanged information is known to both communication partners .

If only an identifier of property and his value with a reference to the semantic definition of this property are exchanged between the interaction partners, a context for the transferred value is thus provided.

An information exchange of this kind is called an information exchange with explicit semantics .

The concept identifier identifies "concepts", like properties or units of measure, which are described in a reference dictionary and serve as the context for interpreting associated values. The definitions in the reference dictionary may be multilingual and may even provide information in localized terminology (country-specific, area-specific, but also per market, per company) and can be resolved to unambiguous, multilingual concept names, which provide the context for interpretation of the values transferred, since concept identifiers are language independent.

Example: In natural language, an end connection of a nozzle may be described as follows: End connection in 316L stainless steel flange to DIN 2501, Form C; nominal diameter DN25, nominal pressure PN40, nozzle length 300 mm, while in electronic data exchange this concept may be uniquely identified by 112-2#02-AAA123#001

The information exchange via identifier and value is possible if the interaction partners use the same semantic model of a concept.

A unique identifier acts as an semantic identifier and refers to a type description of a characteristic. This type description may include the name, definition, SI unit, value format, data type and other attributes that are unchangeable throughout the life of a characteristic and serve to describe the actual meaning of a characteristic.

A type description thus provides a minimal context necessary for understanding the meaning of a value.

However, there are attributes, such as the value or the unit of measurement, which can be different for each individual use of the characteristic (for each instance of a characteristic).

Why Do We Need a Dictionary

When a person thinks of an object existing in the real world, for example a laptop, she/he has a specific image in her/his mind about this object.

Another person, nevertheless, might have a different image in the mind for a laptop (different colour, display, keyboard etc.).

The best way to make the two persons have the same image for an object existing in the real world is to create a model for respective object. The model can be realized in different ways

• as a picture

• as a construction diagram

• as a semantic model

• etc.

Which model will be used depends on the purpose the model is intended to serve. 

What is a Dictionary

The semantic model (some call it ontology) created to describe objects from the real world with the purpose of creating, sharing and comparing product descriptions is called a Dictionary. By abstracting reality, a model serves to formalize information about a real-world object. The formalized description creates a unified understanding of the object that can now be shared with others.

The tools needed to describe the model are referred to as Structure Elements of a Dictionary. 

A Structure Element is a semantic representation of a real world concept in the Dictionary. The Structure Element is uniquely identified by an IRDI.

For human understanding, each Structure Element is described by translatable Terminological Information.

Dictionary Structure Elements

Classification Class

The first step when attempting to formally describe objects of the real world in a semantic model is to separate them into distinct categories.

Continuing with the laptop example above, before starting the actual description of the laptop, one would first define broader categories in which a laptop would fit, such as Electronic devices with sub-category Computers and accessories, or Information, communication and media technology with sub-categories Computer system and Mobile PC.

These categories used to group representations of similar objects of the real world are referred to as Classification Classes in the semantic model of the Dictionary. The Classification Class helps to categorize the described product(s) and divide them into certain categories of similar products.

Classification Classes are organized hierarchically, from a broader to a more detailed category. In addition to a main label (preferred name), the Classification Classes have a so called Coded Name, which is a unique, human readable class code in a classification hierarchy (can be formed out of numbers, such as 19, 19-01, 19-01-02 etc., letters A, AB, AC etc. or combinations of the two A1, B2 etc.)

The purpose of such groupings into categories is an easy retrieval of the needed information. When searching for a specific product, users would look for the logical category of respective product, i.e. they would look for laptops in categories such as Electronic devices or Information & communication technology and for bread in categories such as Food or Bakery products.

Keyword

Alternate naming might be in circulation for one and the same category. For example, a category Laptop might be also known under the name Notebook or Portable notebook or even Portable computer.

Therefore, the semantic model needs to offer the possibility of defining alternate labels for one and the same Classification Class so that users might find the needed products regardless of the naming they use. Alternate labels (naming) for the same Classification Class are referred to as Keywords in the semantic model of the Dictionary. Keywords must not have the same meaning as the preferred name of the Classification Class and cannot be translated 1:1: therefore vary in the language versions.

Application Class

After the categories for grouping representations of objects of the real world were defined, one may continue with creating the semantic model for the actual description of a real-world object (aka product).

When we try to describe real-world objects, for example a laptop, in words, we actually point out the main characteristics of respective object such as - in case of a laptop - the memory, the display, the operating system, the processor, the colour, the size etc. 

The semantic representation of a class of products which can be described by a generic set of characteristics is called in the semantic model of the Dictionary an Application Class.

Application Classes may be organized hierarchically from a general to a specific class by the specialization relation "is_a". The specialization relation implies the substitution principle of the generic by the more special. A specialization relation of an Application Class implies that the specialized class inherits all properties of the generic class. However, additional properties may be added.

In addition to a main label (preferred name), the Application Classes may have a so called Hierarchical Position, which is a unique, human readable class code in a Application Class hierarchy. The Hierarchical Position is used for sorting the display of Application Classes situated on the same level.

Synonym

Alternate naming might be in circulation for one and the same product. Therefore, the semantic model needs to offer the possibility of defining alternate labels for one and the same Application Class so that users might find the needed products regardless of the naming they use. Alternate labels (naming) having the same meaning as the preferred name of the Application Class are referred to as Synonyms in the semantic model of the Dictionary.

Property

The characteristics of the product are referred to as Properties in the semantic model. An Application Class must have at least one Property assigned. Additionally, an Application Class may be categorized by connection to a Classification Class.              

Since different naming might be in circulation for one and the same Property, the semantic model offers the possibility of defining different labels for one and the same Property so that users might find the needed data regardless of the naming they use. Different labels (naming) for the same Property are referred to as Synonyms in the semantic model of the Dictionary. By definition, Synonyms have the same meaning as the preferred names of Structure Elements. Synonyms cannot be translated 1:1 and therefore vary in the language versions.

A Property is a Structure Element which represents a set of values, either by the description of its data-type or by a relation to its Value(s) which determine the enumeration of the most useful characteristics of the described item (e.g. property: color, value: red).

Property(ies) are used for describing the products which are instances of a Characterization Class.

Each Property has mandatory exactly one data type assigned, which describes or enumerates the set of possible Value(s) in a Value List.

Quantitative Properties are Properties used to represent numeric Values, which are assigned to a Unit of Measure.

Properties are assigned to a Quantities, in order to allow conversion of values referencing other Unit of Measure belonging to the same physical Quantity.

Units of measurement are a standard for measuring physical quantities. All units measuring the same physical quantity are grouped in the semantic model in a Quantity. Units of measurement have aspects of conversion and conversion factors defined, which allow the conversion of a value into the different units of a quantity. An Aspects of Conversion relates a Unit of Measure to the base of the underlying unit system(s) in terms of exponents of the base units. 

Therefore, the Property Display in our example above would have a primary Unit of Measure e.g "cm" and a Quantity "Distance" connected. The connection of the Quantity to the Property allows its value to be expressed in cm or in inch (e.g. 39.6 cm (15.6")).

Value and Value List

For specific Properties, the set of possible values that the Property may take in the product description is already known when the semantic model is defined. In our laptop example, for the Property colour the list of possible contents (black, white, blue, green, pink, ..) is known when the model is designed. 

The set of possible values of a Property in a product description is referred to as Value List in the semantic model of the Dictionary. One single element in the Value List is referred to as Values.

A Value List defines a set of permissible Value(s) being implicit by the Data Type or explicit by listing the possible Value(s).

Value Lists are reusable and can be open or closed. Open Value Lists allow values outside of the defined set of permissible Values as valuations, whereas closed value lists accept only their defined values as valuations within a product description.

Value Lists may have optionally a Unit of Measure assigned, provided the Value List is intended for Quantitative Properties.

Value(s) are enumerations within the Data-Type of a Property - Definition which restrict the set of possible Values for the Property.

Note: A Property does not necessarily have a Value List assigned. However, a Property always has a mandatory Data Type.

Values have a Data Type which must match the Date Type of the Property.

Values may have optionally a Unit of Measure assigned, provided the value is intended for Quantitative Properties.

For a Property of Data Type Reference the Values are references (i.e. IRDI) to Characterization Class, what represents the set of instances which are abstracted by this Class.

Values may be subdivided into:

Coded Values have a code identifying the meaning, thus allowing translations. For example a Boolean value would have a code TRUE and then translations like DE=Ja, EN=Yes, SP=si etc. Coded values are reusable. In the laptop example, one could use coded values to describe for example the colour of the laptop (Code ABC123 with translatable meaning black/schwarz/negro etc.) or the protection offered by a laptop case as IP54 (code) with the translatable meaning EN: Protected from limited dust ingress. Protected from water spray from any direction and DE: Geschützt gegens Staub in schädigender Menge. Schutz gegen allseitiges Spritzwasser.

Explicit values represent commonly-used concepts, like numbers (e.g. 10,25) and do not need a translation of their meaning. Explicit values are not reusable (i.e. can be part of only one Value List).

In the semantic model of the Dictionary, Values and Value Lists have a data type which defines what kind of information they may transport. Only Values of the same data type with the Value List may be connected to a Value List, whereas only Value Lists of the same data type with the Property may be connected to a Property. 

Properties expressing one characteristic of a product can be used globally (i.e. the same Property is used in all classes) or locally (different Properties expressing the same characteristic are used in different classes).

The definition class of a Property may restrict the possible usages of a Property. If the scope class of a Dictionary is used as definition class (default use case), then the Property may be used in all Application Classes, Blocks and Aspects. If the root of Application Classes is used as definition class, then the Property may be used only in Application Classes. The same applies if the root of Blocks or Aspects is used as definition class, the Property may then be used only for classes under respective root class. If the usage of a certain Property needs to be restricted to only one class, then the definition class of respective Property may be set to only that specific class and the usage in other classes is not possible.

Locally used Properties are duplicated Properties in Dictionary and may have different value lists to fit the context where the Property is used.

Globally used Properties prevent duplicate Properties in Dictionaries but could have a very big list of possible Values to cover all possible usage contexts.

In case of globally used Properties having a Value List, the possible Values of a Property need to be restricted in the context of a class so that only suitable values are offered for the product description created on a specific Application Class.  

Constraints

Value List restrictions (for example in context of an Application Class) are referred to in the semantic model of the Dictionary as Constraints (Enumeration Constraints).

Properties may act in different ways. If the property's value is not depending on any other value, the Property is a Non-Depending Property.

However, there are cases, where a Property's Value makes only sense if another Property's Value is mandatory existing in a product. In this case the Property is a Depending Property which depends on a non-empty-set of Properties, its Conditions.

Condition and dependent Properties can also be used to create cardinality structures. Cardinality is a structural concept which allows to depict the behavior of a particular block regarding its order of multiplicity. This number could be fixed or variable depending to the way is defined.

Cardinality structures are created by using a condition  Property of data type Integer (count) and a depending Block Reference Property.

Block

A product description usually contains direct characteristics of a product, indirect characteristics coming from specific features or parts built in the product itself as well as characteristics relevant under certain conditions for a given product.

Properties describing the direct characteristics of a product are normally assigned directly to the Application Class.

If all Properties of a device type are arranged with equal importance on one single level, the list will become less understandable while more Properties are added. Clarity can be achieved by structuring the Properties into sub-concepts, which are described by Properties.

Properties describing indirect characteristics coming from specific features or parts built in a product are grouped into a class referred to as Block in the semantic model of the dictionary.

Continuing on the laptop example above: a laptop has a certain number of ports (HDMI, USB etc.). These ports cannot exist by themselves; therefore, they cannot be described by an Application Class. They can only exist as parts of a product. The Properties describing such ports would be therefore grouped into a Block.

Since a laptop has normally more than one port, these Block should allow multiplicity (i.e. should be created as a cardinality structure).

Since all ports share a set of common characteristics, they should be modeled with a “is a” hierarchical relation as specializations under a general block (parent Block) Ports. Such a structuring allowing later in the product description the selection of the needed specialized port is called polymorphism. In addition to the general and specialized blocks, the polymorphism also needs a Property controlling the selection of the specialization in the product description. The values of the controlling Property in a polymorphism are assigned to a specialized block via a so-called class-value-assignment (CVA).

Aspect

Properties describing a certain aspect of the product are usually grouped into a class referred to as Aspect in the semantic model of the dictionary.

For example, properties describing the requirements of a device would be grouped into an Aspect since they do not describe the product itself, but certain conditions under which the product should function.

Characterization Class

The three described class types (Application Class, Block, Aspect) are referred to as Characterization Classes in the semantic model of the dictionary because they all can be grouped hierarchically by the specialization relation "is_a", which implies the substitution principle of the generic by the more special. 

Characterization Classes must have at least one property assigned.

A special case of Characterization Class is the Application Class, which is used for product description. It is mandatory connected to the 4th level of the ECLASS Classification-Class hierarchy.

Another case of Characterization Class is the Aspect which is used for describing a special external perspective on an Application Class.

A Block is also a Characterization Class which is used for describing sub-concepts of an Application class.

Note: Blocks are referenced by Property of Data-Type Reference.

A Characterization Class may have zero to n Keywords and/or Synonyms assigned.

A Characterization Class may have zero to many Template which are defining the formal data requirement specification (according to ISO 22745-30) of this class.

Free Relation

In the semantic model, the possible relations between objects are predefined. For example, a Classification Class can be connected to an Application Class, but not to a Block, Aspect or directly to Properties, Blocks can be connected to an Application Class only via a Block Reference Property etc. Nevertheless, one might want to express also other relations between Dictionary structure elements, which are not defined in the semantic model but needed in a business process. This is allowed by the so called Free Relations. 

Using the laptop example above one could model via a free relation something like Laptop "can be stored in" Laptop bag.

Further information on how the Structure Elements of a Dictionary are maintained can be found in the next chapters.

Release Management

The information needed to realize state-of-the-art product descriptions is continuously evolving. Therefore, the maintenance of a Dictionary is a dynamic process reflecting the development of the information needs. At the same time, it must be ensured that the product description process is not stalled by the further development of the Dictionary.

To achieve this, snapshots of a defined set of elements of the dictionary at a selected moment in time can be created. Such a snapshot is called a Release of the dictionary and collects all elements (including relations) allowed for use at a specific point in time. This mechanism also allows persistent unmodified storage of the releases. Formal Dictionary Change Management Rules apply between Releases.

Therefore, the product description process can rely on the latest release of the Dictionary without interference from the further developments of the Dictionary. Further developments (changes, novelties, withdrawals of usages) are usually realized as so-called Change Requests. Change Requests can be checked against defined business rules so as to ensure conformity with defined business policies.

Change Management Engine and Change Management Rules

On generation of a new release, defined dictionary change management rules and engines come into place.

The change management rules have the purpose of organizing, controlling and tracking changes on reference dictionaries. The engine interprets these rules and produces the results.

In ramp-up mode, the change management rules are not so strict as when a dictionary is used productively. Therefore, in the ramp-up mode usually a ramp-up (No versioning) engine is used, while in productive mode an engine tracking all changes is recommended (Versioning engine).

The main considerations of the change management rules used by the versioning engine are:

• Compatibility of changes / ontological continuity

• Identifiers and versioning

• Deprecation

 The changes performed within a dictionary may be

• Backward compatible: any characterization defined from Ot also conforms to Ot+1 (e.g. Textual description may change but no change to semantics allowed, Set of possible values must not decrease)

• Upward compatible: any characterization defined from Ot+1 also conforms to Ot (Textual description may change but no change to semantics allowed, Set of possible values must not change)

• Incompatible (May be applicable when there is a formal concept that defines for each possible value from Ot what to do with it in Ot+1)

The identifiers (IRDI) of structure elements change depending on the change compatibility. Backward and upward compatible changes would result in an increase of the revision, while incompatible changes would result in a new identifier.

Removal of elements would result in deprecations.

On release generation, Transaction Update Files (TUF) and Structure Difference Files are developed. These files are used to ensure the traceability of changes from one release to another. In addition to tracking all changes between releases of a dictionary, a change history indicating who changed what when is kept based on Change Requests.

Dictionary Manager supports the ability for multiple users to initiate structure releases at the same time. These are called Collaborative Structure Releases.

With the Collaborative Structure Release function, teams can now work in parallel, significantly reducing release times and boosting efficiency.

Dictionary Change Workflow 

Additionally, Change Requests undergo an approval process before they are released for use. The approval process of dictionary changes is supported by Workflows. Workflows allow a controlled distribution of responsibilities within the Dictionary further development process.

Workflows describe a defined sequence of steps to produce results. Workflows run according to a defined scheme (representing a defined business process) and usually include:

• a trigger

• one or more roles responsible for the specific tasks defined in the workflow

• several work steps (tasks)

• the assignment of work steps to responsible roles

• results or partial results

• the assignment of results or partial results to responsible roles

• states as status information about the degree of completion of activities and results

• a defined end