Global Unique Identifiers (IRI)
As defined in the section "Mapping of the VEC Model to XML schema definition (XSD)" each xs:complexType defines a XML-Attribute id with the type xs:ID, either by itself or by inheritance from a superclass. By nature, those ids are volatile and have a purpose only within a specific XML file.
However, there are requirements in advanced use cases where it is necessary to be able to identify objects in the VEC globally and in a temporally stable manner. Such use cases are for example, but not limited to:
- Change Management & Synchronization
- Integration with other Standards, e.g. the Asset Administration Shell (AAS)
- Provision of VEC objects via modular APIs (e.g. REST)
- Compliance with other serialization formats like RDF.
Therefore, each xs:complexType that defines an id-attribute also defines an immutable-global-iri attribute with the type xs:anyURI. Despite its name xs:anyURI is in fact the type for an Internationalized Resource Identifier (IRI), see "W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes". If two VEC objects, regardless of their context or their affiliation to a specific file, have the same immutable-global-iri, they are in fact a representation of the same (real world) object (potentially in a different state).
The concept of IRIs allows the definition of global unique identifiers in various ways and with different strategies. For example, using http-IRIs allows the dereferencing (finding) of objects identified by such IRIs. However, the chosen strategy has a strong influence on the circumstances under which two objects in the VEC can be identified as the same. Both effects (same / not the same) can be desired effects in a specific use case / process / scenario. Therefore, this recommendation does not define a specific strategy for minting IRIs of VEC objects. It is also beyond the scope of this recommendation to describe or define valid strategies for minting IRIs.
However, two examples shall illustrate the influence of a choosen strategy. The examples are for illustrative purposes only and their description does not claim to be complete:
- UUIDs: IRIs can be created from UUIDs. UUIDs are generated random values that guarantee universal uniqueness. To satisfy the requirement of temporal stability, a source system has to maintain (store) those UUIDs for every object. Objects that are created distributed at the same time in different to locations are hard to handle. Objects deleted from a system (and then recreated) are always handled as different objects.
- Calculated IDs: IDs could be calculated from object keys in the domain (e.g. the identifying attributes of a PartVersion). Such IDs could be calculated on the fly and do not have the requirement to be stored along with the object. If the same object (same identifying attributes) is created in different locations, both variants can still be recognized as identical. On the downside, an ID generation algorithm has to be defined, that generates those unique IDs for every possible object type. The algorithm has to guarantee that the generated IDs fulfill uniqueness requirement, which depends on the naming / identification strategy of the process. And yet, there are still cases where objects can not be recognized as the same (e.g. renaming of "key"-attributes).