A proposal to solve "Version" Mapping uncompatibility between Energistics Abstract Objects and OSDU Id version
DIFFICULTY ENCOUNTERED
This difficulty was emphazise when we tryed to operate the WITSML parser in the Ingestion Workflow. We constated an inconsistency during integrity checking.
The "Version" is processed differently into OSDU Data definition of Id.version and into the Energistics standard on the Uuid.Version and this drives to an uncompatibility between the two ways of managing these "versions".
It looks like In OSDU the version number is an integer which is the "translation" of the "lastUpdate Date" of the Meta data creation of an Object into a number of seconds from 01/01/1900. In Energistics Common //Eml23, the version is an attribute of AbstractObject. His name is objectVersion: String64. As you can see this is a String which uncompatible with the OSDU Version number. This Attribute is non mandatory. In this case we cannot execute an easay mapping between these two attributes.
PROPOSED SOLUTION
The proposal is to find a way to map another attribute of the Energistics Common // eml23 with the OSDU version number. this attribute : "last Update: Time stamp" is a date , not mandatory in AbstractObject.Citation which could be easilly translated into an OSDU version Number.
If this attribute exists in the "Energistics Entity" when the manifest is created, the the id version number can be calculated from it. If this attribute does not exist in the "Energistics Entity" it could be generated when the manifest is created and added into the original Energistics XML file before storing it into the persistent store.
By this way we will have a totally consistent management of the id version number between the Energistics Entities and their meta data into the OSDU platform. This will help to solve the inconsistency captured during integrity checking .
If we follow this method we will be able to be totally consistent between the id.version and the uuid."numerical translation of Last update date".