Associations and Templates

The models illustrate how objects and associations are organized and instanced for specific purposes or functions. This is not the limit of associations that can be created or used. The whole notion of ISO 15926 is to create a fully flexible model that can be used to represent any data object or association. In most data warehouse implementations, this is typically at a very granular level. To improve the ‘human readability’ and the system's ‘repeatability/reuse’ of these objects, the idea of templating these objects and associations together is finding acceptance as a preferred modelling method.

Templates in the AIM Workhub are in two categories:

• Atomic Templates (AT): is indivisible semantically and normally forms the smallest usable building block of objects

• Molecular Templates (MT): is indivisible by business implementation, and represents logical groups of objects that are typically familiar to an end user

The following sections describe typical ATs and the context in which they are used.

Identification with Uniqueness Context

Business Usage Semantics (incl Cardinality)

Identification involves assigning a string or other encoded symbol to an object in order for it to be used subsequently to make unambiguous reference to that object.

Each object registered with EIF is to be captured at first installation using the OBR Template, which implicitly includes one embedded instance of the IDC Template. This separate IDC Template is therefore primarily intended for assigning additional identifiers (or aliases) to an object already registered. These additional (unique) identifiers (with their own contexts) are intended to enable sets of users in these particular contexts/phases of the business to navigate and access information via their preferred identification schemes, without losing management of underlying unique identity, and associated consolidation.

For objects which are versionable (essentially all associations and information objects) "version" is an essential part of identification. However physically implemented/constructed, identification therefore consists of <Context Symbol><Unique Symbol><Version Symbol>

Implementation Notes/Issues/Suggestions

An important aspect of EIF implementation is that not only will interfaces exist to external systems which create, manipulate and persist identifiers, but middle-ware components may themselves be distributed and integrated with other middle-ware systems. Whilst internal to EIF, controlled system numbering (for example, uid’s) is expected, it is essential that uniqueness of identification is managed and validated according to the agreed standard template at all interfaces.

Often business context produces standard formatted forms for the unique symbolic string – typically referred to as "tags". Often such tags contain embedded encoded information about the context, the type, and other attributes of the identified object. It is essential that the "unique identification" aspect and the implicit or explicit "encoded information" are handled distinctly. (See separate notes on identification, tags and aliases.)

Implicit in this template is that the "context" part of the identification is handled distinct from the unique symbolic string, whereas the "version" component is embedded in the unique symbolic string. This is an acceptable implementation at the interface, since the same template can capture identification, whether the object is versionable or not. It is anticipated that versioning/time-stamping/suppression-tree aspects will be handled through meta-data in implementation, however additional formal templates may be generated for this purpose as necessary.

Inherent in the EIWM template model is the nested assembly of information sets – which itself provides useful context hierarchies, very similar to the construction of XML Namespaces/URL’s/URI’s. it is recommended that this fact is exploited in efficient handling of identifiers and contexts.

Human Naming

Business Usage Semantics (incl Cardinality)

An object may be given any number of names as useful human "handles."

The naming template does not require or exploit uniqueness of the name, and EIF therefore provides no management of any such uniqueness. Where uniqueness is intended by the business, the IDC template shall be used.

The Name string is generally descriptive for human interpretation. Naming assumes that the context (compound template) in which the name is created makes the name sufficiently intelligible and recognizable self-evidently to human users.

An optional HNA atomic template is part of the OBR registration template on first instantiation of any object.

Implementation Notes / Issues / Suggestions

Generally the "Name" is presented for human recognition, often for corroboration or confirmation together with other formal IDC identifiers where there is selection ambiguity or in contexts where uncertainty of human recognition is possible.

Object Registration (Registry Entry)

Business Usage Semantics (incl Cardinality)

Every object of interest, of which the EIF is expected to take some part in its future management, or of information about it, must be "Registered" at least once with unique identification and essential classification. The "human name" is an optional component for cross checking purposes, particularly but not exclusively where the identification string or symbol, whilst strictly unique, is not in a form for useful human interpretation.

See IDC, CLE and NAM template definitions for individual semantics.

Implementation Notes / Issues / Suggestions

See IDC, CLE and NAM template definitions for individual implementation notes.

Templates and Registered Objects in general are distinct objects each with identity in EIF. For instances of the OBR Atomic Template, ID string for the real world object is intended to be used as a surrogate for the ID of the template instance itself, in order to avoid circular references / enable bootstrapping.

Essential Classification

Business Usage Semantics (incl Cardinality)

Every object handled within EIF shall be essentially classified at least once. (Generally, for objects captured in the Registry, this will be achieved once on instantiation via the Object Registration Template)

Essential classification concerns the nature of (some aspect of) the object being classified (registered / instantiated). It is a specialization of the object base entity type (As per the "upper ontology"), independent of the business use of information about the entity, and independent of any additional classification for business management and access reasons for chunking and navigation. (See also Incidental Classification).

Example usages: (Hold)

Mapping guidelines / rules: (Hold)

Implementation Notes / Issues / Suggestions

RDL class objects should be referred to by unique ID (just like any other registered object). Typically implementations use the non-unique class "name", however whilst a human interpretable name will always be captured at time of first registration (of the class), classes will have alternative names (synonyms) and multilingual translations / representations.

Essential classification(s) should be assumed fixed for the life of an object, however objects may receive additional essential (and incidental) classifications during their life as a result of increasing knowledge of more aspects of the object. Examples of the occurrence of multiple essential classifications include:

• Discovering additional specialization (common event)

• Discovering additional specialization of multiple orthogonal aspects (common event)

• Discovering erroneous earlier classification (hopefully infrequent event)

At any one time, one of the essential classifications shall be considered the "default essential classification" of the object, for display, navigation, search purposes etc. This default may be re-assigned to any one of its multiple essential classifications by an "Information Manager" level user with appropriate access rights. (This may be achieved by incidental classification of the essential classification template instance, or by creation of a separate atomic template for this purpose, or by association meta-data for the relevant essential classification association, since it is an implementation artifact to assign this default).

Recognition needs to be given to the inheritance aspects of classification – wherever calls make reference to (say) "pumps", the normal semantic will include "and all subtypes", unless the query is constructed explicitly otherwise to exclude sub-types. One corollary of these last two issues is that as well as "base entity type" and "lowest level specialization class", each object will probably need to have recognized a default organizational node in that hierarchy. Since this is an implementation artifact, a meta-data implementation is acceptable.

Incidental Classification

Business Usage Semantics (incl Cardinality)

Any object may be incidentally classified (and subsequently de-classified) any number of times.

Incidental classification is used to create manageable groupings of objects according to any circumstantial (i.e., non-intrinsic) aspects of those objects – aspects which are concerned with their (temporary) involvement or usage in any aspect of the business. (See Essential Classification for classification according to lifelong intrinsic aspects).

Example usages: (Hold)

Mapping guidelines / rules: (Hold)

Implementation Notes / Issues / Suggestions

None currently recognized.

Assembly/Collection

Business Usage Semantics (incl Cardinality)

The assembly relationship applies between two (whole and part) objects, where the individual part plays a distinct or systematic role in the whole (It says nothing about physical assembly or joining).

The collection relationship applies between two (whole and element) objects, where the individual element plays no distinct role in the whole. (It says nothing about physical proximity or gathering together).

Example usages:

• Pump P102 is a part of System S100.

• Filter F103 is part of System S100.

These are assembly relationships, because although both P102 and F103 are "parts" of the system, they are not wholly interchangeable in their relationship to the system.

Pump MfrZ2002/02/317/M is an element of Shipment PO192/7

Filter MfrX2001/04FQP4/23 is (also) an element of Shipment PO192/7

This instance of Model no BD/PG4010scx is an element of "The set of available 10 bar pressure gauges."

That instance of Model no BD/PG4010scx is (also) an element of "The set of available 10 bar pressure gauges."

These are collection relationships, because there is no different significance in the way the distinct elements relate to the whole.

Mapping guidelines / rules:

If in doubt map whole-part relationships to Assembly. In general Collection tends to be about "discovering" useful sets of things post-hoc, and set membership is ultimately indistinguishable from incidental classification.

Implementation Notes / Issues / Suggestions

None.

Template Composition by Ownership and Reference

Business Usage Semantics (incl Cardinality)

A "Template" is an information object whose (relevant) schema is defined according to this EIWM Template model. They exist as both the Template Schema and Template Instances according to those schema. See the EIWM Overview graphic for the relationship between Templates of various kinds (AT’s, MT’s and DT’s). These TCO and TCR AT’s define assembly relationships between other AT’s, MT’s and DT’s.

These template composition AT’s are simply specializations of the ‘Assembly’ AT, applicable when the objects in question are Templates. The semantic differences are:

TCO applies when it is intended that instances share "ownership", that is the part inherits "publish" (create, update and delete) rights from the whole instance. A whole can have many owned parts, but a part can have ONLY ONE OWNING PARENT / whole at any one time.

TCR applies when the part is included (by reference) in the whole, but the instances retain independent ownership and publish rights, and is effectively a "subscribe" relationship. (Parts can be referred to any number of times by any number of parent wholes).

Examples and Mapping Guidelines: To follow on request.

Implementation Notes / Issues / Suggestions

Need to address Template Schema which confer the above semantics on their instances.

Need to establish minimum essential meta-data content associated with template instances.

Need to consider whether owned parts should also inherit versioning and lifestyle related meta-data, in which case the parts effectively merge into the whole (the whole-part relationships become redundant) for all practical purposes for the instances, except for configuration management of changing schema. (Alternative specializations of Template Composition relationships are conceivable depending on implementation preferences).

Property with Value/Units

Business Usage Semantics (incl Cardinality)

This AT is used to assign a real value quantified property to an object (with units unless the property is dimensionless ratio).

Any registered object may possess any number of properties. (The same property may in principle be possessed by any number of registered objects, though this would involve registering and uniquely identifying the property itself).

Implementation Notes / Issues / Suggestions

It is permitted to use specializations of this AT for specific property types (and / or units) if this provides any implementation benefits. (Ex: Possession of Design Temperature in Degrees Centigrade say).

About Information Linking Groups of ATs

Business Usage Semantics (incl Cardinality)

This AT provides the basic "Asset Linking" mechanism to documents or other information objects from any objects (including other information objects). Any number of information objects can be "about" any number of objects.

Implementation Notes / Issues / Suggestions

The main issue with this (set) of AT’s is the mapping choice, not just in which specialization to select, but in being clear as the most appropriate asset to which to link. Example is a "test procedure" about a specific tagged or numbered pump or about a whole class or set of pumps or is a commissioning instruction about a specific item or about all components of a system.

The mapping guidelines will suggest including the "reference" AT for all explicit objects, and a definition or description AT for the true subject. Need to beware for example, where a specification "for" an individual pump (say) includes a reference to a (say) system or process unit, etc.

Qualitative Characteristic

Business Usage Semantics (incl Cardinality)

This AT is used to assign qualitative information which characterizes (some aspect of) an object. This is distinguished from PRU by the fact that the characteristic is not a physically dimensioned property (though it may infer one), and its values must be selected from a domain of valid values, rather than any real number value.

Any registered object may possess any number of characteristics.

The specialization FEA is used to characterize a shape or form feature such as having "a bevelled end" or having "a bolted bonnet." The feature is a design form, not merely a distinct component.

The specialization MOC is used to characterize the material of construction of an object such as "being made of Stainless Steel," or "being made of ASTM A234 WPB".

Implementation Notes / Issues / Suggestions

It is permitted to use specializations of this AT for specific characteristic types (and / or units) if this provides any implementation benefits. (Ex: Possession of Size according to ANSI mm Nominal Size, say)

Two particular specializations FEA and MOC are specified.

Attribute

Business Usage Semantics (incl Cardinality)

This AT is used to assign an arbitrary information attribute which characterizes (some aspect of) an object. This is distinguished from QAL by the fact that the attribute value is not limited to any domain by the class of attribute.

This is a fallback AT to be used only where other AT’s are inapplicable or insufficient knowledge exists to select a more specific AT.

Any registered object may possess any number of attributes.

Implementation Notes / Issues / Suggestions

None.

Direct/Indirect Connection

Business Usage Semantics (incl Cardinality)

These AT’s are used to indicate that objects are connected to each other.

DCO is used when the two objects are contiguous, physically touching (barring any materials actually used to make the connection into a joint).

ICO is used to indicate that two objects are connected indirectly in some systematic or logical way only.

Implementation Notes / Issues / Suggestions

None.

Involvement in Activity

Business Usage Semantics (incl Cardinality)

This AT is used to indicate that an object is involved in an activity (and its role in that activity).

Implementation Notes / Issues / Suggestions

None.

Generic Association/Relationship

Business Usage Semantics (incl Cardinality)

Used to capture the existence of a non-specific relationship between two objects, only where no applicable more specific atomic (binary) template exists in the template library at the time of instantiation, or knowledge about the association is insufficiently complete at that point in time.

As such, this Template offers no other semantic constraints on object types, string contents or cardinalities.

Implementation Notes / Issues / Suggestions

It is conceivable that the business may wish to add knowledge to a generic association, by further classification of the association instance, until such time as more explicit alternative AT is implemented.

Fulfillment

Business Usage Semantics (incl Cardinality)

This AT is used to indicate that a materialized physical object fulfills the "role" of a logical or functional physical object.

Main examples are:

The relationship between a "tagged" process item location (ex as defined on a P+ID) and an individual physical plant item of a specific serial number and model number installed at that location.

The relationship between a numbered and versioned document or other logical information content object, and a rendition of that document in some physical format or representation.

Implementation Notes / Issues / Suggestions

None.