ISM Pre-requisite: Mapping Data between ISM and AIM-A

Before starting any Registers Gateway configuration, ensure that the data model is built and ISM pre-requisites explained below are completed in the fragment of data model.

Namespace

Extension namespaces are standard schemas to enable the communication between applications.

• Standard schema to communicate from AIM-A to Anet - this namespace should be created in fragment one: Data model Standards.

• Standard schema to communicate from the Registers Gateway to Info Interface - this namespace should be created in fragment two: Registers Gateway fragment.

  Namespace name	Description
  Info Interface	Contains rules for capturing and interpreting data using the Registers Gateway. For example, attribute mappings, class mappings classification logic, register configurations etc.
  Anet	Used for describing behaviour specific to AIM-A. For example, defining associations, hiding classes from the UI – for example anet: visible, etc.

Namespaces are added in ISM on the general configuration menu, on the extension namespaces tab.

Nomenclature

Nomenclatures are considered alternate identifiers, similar in nature to IDs. They are used to map incoming data to systems, industry standards and local standards when naming conventions used by source systems are drastically different in order to have a common terminology. For example, source-1 uses length while source-2 uses len, but both systems mean the attribute length present in ISM. Therefore, each source will have its own nomenclature.

ISM uses nomenclature to interpret terminology from multiple source systems into a common language (semantic harmonization).

Nomenclatures are added in ISM on the global toolbar menu, on the Naming conventions tab. This nomenclature should be created in fragment one Data model Standards.

Contexts

Contexts are used to uniquely identify an object. When the Registers Gateway classifies each object, it picks up the context defined on the class and appends it for that object.

Contexts are defined on the class level using anet:context as an extension on any class, subject to standard inheritance rules. The specified context will then be applied to any IDs and references to an object, where the classification is known.

Contexts are added in ISM on the Extension tab of each class. These contexts should be created in fragment one Data model Standards.

For example, all objects classified as Electrical Cable will get the context TAG as it will be inherited from the Functional Root class. So, when the Registers Gateway finishes processing, it will append the context it picks from its class and create an object called Root|TAG|PU202143A in the database.

Upper ontology mapping

Upper ontology is a set of built-in classes in AIM-A that will connect the AIM-A upper ontology classes to ISM root classes, establishing a connection between ISM & AIM-A. The upper ontology should be created in fragment one Data model Standards.

1. If it is related to the root functional class's parent and its attributes, then it will go on class level.

   Add node = parentClassId and property = TAGGED ITEM for Functional Root Class

   Add node = parentClassId and property = DOCUMENT CONTENT for Document Root Class

   Add node = parentClassId and property = FACILITY for General Root Class

   

   

   

2. If it is related to upper ontology classes, properties, etc, then it will go on global extension level.

   

   Regarding classes of activities/tasks and events, in AIM-A the class for activities/tasks is ACTIVITY and the class for Events is EVENT and we are connecting our ISM class Task – Reliability with AIM-A class ACTIVITY and ISM class "Work Order" with the AIM-A class EVENT.

   Once we have created the class accordingly, parentclassID must be added, parentClassId=ACTIVITY for activities/tasks and parentClassId=Event for Events. And finally, both classes and their attributes should be mapped.