Extend WellLog to offer an optional acquisition context

[SnorreFossland]

Finished criteria:

This issue is finished when the update is presented to the OSDU forum.

What is the scope of this issue?

Show how to import existing version of Welllog and model the extension in AKM and generate a CSV-file for import in OSDU.

Why

To implement a way to update OSDU Schema giving a better overview over the change and also better visualization of the details.

How

• Run a test prototype of the whole procedure from import of existing to export of CSV.
• Demo

Who

@dagkarlsen , @SnorreFossland

When

March 2024
Milestone ....

[SnorreFossland]

Hei Snorre,

Here is my suggestion for a demo use case:

Goal: We need to extend WellLog to offer an optional acquisition ### context.

Prerequisites:

1. There is an independent modeling exercise to define a WellLogAcquisition object. Its main purpose is to hold all details about a well log acquisition, which produces raw WellLog instances in potentially multiple runs, which contain multiple passes. (current proposal WellLogAcquisition.1.0.0 (1)).

2. WellLogAcquisition.1.0.0 (1) is treated as ‘black box’, it is just there defined as a master-data group-type entity.

3. WellLog.1.5.0 you already have, the next minor version, which should be extended – this is the basis or equivalent for the AKM import ().

In AKM

1. You ‘somehow’ create a representation for the master-data WellLogAcquisition (without the detail inside)

2. You create an abstract fragment AbstractLogAcquisitionRunPass with version 1.0.0. (The happy outcome is attached with the same name). But you create the prop-links for (the descriptions are in the attached proposal spreadsheet)

   a. WellLogAcquisitionID (string) – this is the relationship to WellLogAcquisition (aka foreign key) – I made this a mandatory property (JSON schema: required)

   b. RunIdentifier (string)

   c. PassIdentifier (string)

3. The meta model is used to declare the WellLogAcquisitionID property as ‘relationship’ to master-data WellLogAcquisition.

4. You load the work-product-component WellLog.1.5.0 as the ‘next version’ with all its elements. You may not need to ‘show’ all the details, which we are only adding new elements.

   a. You add a new property to WellLog ‘AcquisitionDetail’, type nested object by reference, referring to an abstract group-type, the name AbstractLogAcquisitionRunPass and the version 1.0.0 (we need to uniquely identify the semantic version number we include/use as composition).

Now you can explain the change by creating views. Eventually, the approval could be done in AKM and you could fill the “State” column Y with Accepted (for the demo).

Now the CSV ‘copy by value’ starts:

1. Create a new abstract proposal for AbstractLogAcquisitionRunPass.1.0.0.xlsx – I attached a AbstractTemplate.1.0.0.xlsx for that purpose. It would have to be renamed as the name has to match the main type name.

2. Open the WellLog.1.5.0 and add the one new row (or if you are brave and can recreate the entire content, the entire main 1.5.0 sheet.

Hilsen,
Thomas

[SnorreFossland]

Screenshots of the resulting Model

Imported WellLog

Overview of the types involved

WellLogAcquisition and AbstractLogAcquisitionRunPass with properties and refs

[franklillehagen]

Snorre,

Jeg skal se mer på OSDU product and organization modelling i morgen.

Frank