OSDU-(C)/Design-and-Implementation/Entity-and-Schemas/Comparing-OSDU-&-OpenDES-Schema-Semantics.md

@@ -12,6 +12,13 @@ This page & the recommendations are collectively authored by the following membe
 * Thomas Gehrmann (SLB)
 * Vincent J Kowalski (Shell)
 
+> *Update*
+> The proposals were subcommittee to the core members of EA subcommittee in December. And the following proposals were revised for more examples and descriptions. A quick summary is as below:
+
+> * Kind vs. Master Data, Reference Data, Work Product & Work Product Components - Added more examples, linked the page that captures the EA notes
+
+> * Handling Identifiers - updated rational to link the parent page.
+
 
 # Contents
 [[_TOC_]]
@@ -47,7 +54,9 @@ Each of these same concepts follow a "ResourceTypeID" to identify its type. The
 
 ## Proposal
 
-*  Update - a few additional discussions were captured [here ](https://gitlab.opengroup.org/osdu/opendes-contribution-wiki/wikis/Resolutions-for-GroupType,-WorkProduct-and-Kind-identity-discussions)- please refer for latest
+Below is the illustration of the current OSDU model merging into the combined model
+
+![image](uploads/2a2832405d546249188e749948c18f5b/image.png)
 
 We propose that the following model that emulates the best of OSDU & ODES
 
@@ -55,36 +64,60 @@ We propose that the following model that emulates the best of OSDU & ODES
 |--|--|--|--|
 |namespace  |Namespace    | Namespace | The authority which published and owns the schema, such as shell, cvx, osdu |
 |NONE|source| Source| The origin of schema that could be come from a.) Formats defined by solutions such as Petrel, ProSource, IHS, OpenWorks (or) b.) Industry standard formats such as SEGY-Rev1, LAS etc |
-|GroupType |NONE| Add GroupType as a Property inside the JSON schema| |
+|GroupType |NONE| Add GroupType as a Property inside the JSON schema - with values matching with the OSDU GroupType - Master, WP, WPC and Reference Data | |
 |IndividualType|EntityType| Type| -- | Well, Log, Seismic3D etc. |
 |Version [0-9]+| Version (Semantic Version - n.n.n)|Version (Semantic Version - n.n.n)| Adapt semantic version |
 
-Subsequently, the kind will be retained as four parts.
 
-`Namespace:Source:Type:Version`
+You'll notice that GroupType is retained and carried forward from OSDU. 
 
-1. osdu:osdu:well:1.0.0
-2. slb:ps:well:1.0.0 
-3. hal:ow5000:well:1.0.0
-4. osdu:ihs:well:1.0.0
+Below are some of the examples on how the Kind would look across different domains.
 
-The GroupType will be part of the property, with enumeration 
-* Work Product Component
-* Work Product
-* Master Data
-* Reference Data
+*Work Products named Project and Study*
 
-### Rationale
+```
+   * opengroup:osdu:project:1.0.0
+   * opengroup:osdu:study:1.0.0
+   * shell:osdu:project:1.0.0
+   * shell:osdu:study:1.0.0
+   * schlumberger:osdu:project:1.0.0
+   * schlumberger:osdu:study:1.0.0
+```
+
+*Work Product Components named Well Logic and Survey*
+
+```
+  * opengroup:osdu:welllog:1.0.0
+  * opengroup:osdu:survey:1.0.0
+  * shell:osdu:welllog:1.0.0
+  * shell:osdu:survey:1.0.0
+  * schlumberger:osdu:welllog:1.0.0
+  * schlumberger:osdu:survey:1.0.0
+```
 
-* Source is a valid and useful concept and is retained
+*Master Data named Well and Field*
 
-* GroupType is a valid concept and carried forward into the merged model. We propose to include GroupType as a mandatory instance level property. Please see a dedicated page on [GroupType as a Mandatory Instance Level](/OSDU-\(C\)/Design-and-Implementation//Entity-and-Schemas/Comparing-OSDU-&-OpenDES-Schema-Semantics/GroupType-as-a-Mandatory-Instance-Level-Property) Property for details and examples.
+```
+  * opengroup:osdu:well:1.0.0
+  * opengroup:osdu:field:1.0.0
+  * shell:osdu:well:1.0.0
+  * shell:osdu:field:1.0.0
+  * schlumberger:osdu:well:1.0.0
+  * schlumberger:osdu:field:1.0.0
+```
+*Well log example*
 
-* Kind as a single string encapsulates all the necessary elements. This provides for us to identify a just by looking at the schema name. As an example, the schema file could be named after a kind and multiple schemas can be published and hosted at the registry, each providing a clear way to differentiate from one other.
+  * opengroup:osdu:well:1.0.0 - WP(groupType=Master)
+  * opengroup:osdu:welllog-channelset:1.0.0 – WPC (groupType=WorkProductCompoent)
+  * opengroup:osdu:project:1.0.0 or opengroup:osdu:study:1.0.0 – Master (groupType=Master)
+  * opengroup:osdu:File:1.0.0 (groupType == File).
+
+
+### Rationale
+
+Please see https://community.opengroup.org/osdu/documentation/-/wikis/Resolutions-for-GroupType,-WorkProduct-and-Kind-identity-discussions for additional rationale.
 
-* Having a kind as a single identifier also helps applications such as indexing, search & delivery to bind their behavior based on this single tag.
 
-* Semantic versioning is now widely adopted the standard for open and distributed systems development. We recommend that we adopt it Semantic versions instead of the running sequence. This makes way for future extensions and compatibility - such that a set of services (code modules) and schema can be bundled together by an operator, following similar versioning schemes. It must be noted that the code modules, follow the semantic version already and is widely adopted by the systems developed for the cloud.
 
 # Use of $ref & $allOf, to reuse schema definitions
 
@@ -138,6 +171,8 @@ The `<instance>:<version>` can be used a unique identity to look up data on a 'l
 
 ## Rationale
 
+> Please see https://community.opengroup.org/osdu/documentation/-/wikis/Resolutions-for-GroupType,-WorkProduct-and-Kind-identity-discussions for additional rationale.
+
 1. Staged introduction of new `id` scheme with limited data migration. 
 2. Self-documenting `id`
 3. Standards compliance.