How-to-become-a-DDMS.md

@@ -10,14 +10,34 @@ A DDMS could be a standalone service dedicated to a specific entity type or a su
 
 OSDU solves most of these concerns using Storage Records. A Storage Record is metadata pertaining to the bulk data stored in the DDMS. Every Storage Record created enforces that ACLs are assigned, checks compliance and then indexes the record into search, making it discoverable. 
 
-As long as the DDMS uses Storage Service correctly and exposes the data it stores through a registered set of APIs to consumers of the OSDU it can be classed as a DDMS.
+As long as the DDMS uses Storage Service correctly and exposes the data it stores through a registered set of APIs to consumers of the OSDU it can be classed as a DDMS for the 'entity-type' that they register. This is important as each registration declares the entity that their DDMS stores and makes retrievable. 
+
+## Scope
+A DDMS has a scope that is defined by the entity type(s) it declares when it registers with the registration service. For instance imagine I had an application that displayed images of drill bits from the field for review. I may have a set of APIs that allowed for the retrieval of these images by any client of my OSDU deployment. 
+
+If I register these APIs with the entity-type 'drill bit images' and use Storage Service to make these images discoverable and compliant my application is now a DDMS for 'drill bit images'. However it is not a DDMS for any other entity type.
+
+DDMS already exist in OSDU for certain entity types and these should be re-used.
+
+## Existing DDMS
+OSDU already comes with DDMS for specific entity types.
+
+* [Wellbore Domain](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/wellbore/wellbore-domain-services/-/wikis/home)
+* [Seismic Domain](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic)
+  * The OpenVDS project found [here](https://community.opengroup.org/osdu/open-vds) will be parent under seismic domain data management services after R2 completion.
+* [Reservoir Domain](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/reservoir) - contribution from Energistics and Emerson (placeholder)
+* [Well Construction and Delivery Domain](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/well-delivery) - provides services related to Well Planning and Delivery
+
+These are the source of truth for these entity types within the OSDU and should be used when working with these entity types. Other services and systems can declare different entity types when registering a DDMS. They then act as a DDMS for that entity type within OSDU.
+
+We then have a platform that is both open for extensions and sharing of data that is also standardized for core entities allowing for greater velocity of integration between systems.
 
 ## Granularity
 One of the most important points for a DDMS to decide is at what granularity to apply these concerns on the data stored. 
 
 For instance a DDMS that relates only to seismic data may choose to ingest data using SEG-Y files. Then a single legal tag and ACL may be applied to the whole file during ingestion.
 
-However, it may want this data to be discoverable and retrievable for each trace individually. It would then need to create a separate storage record for each trace in the file so that each ne is individually discoverable and apply the same ACL and legal tag to each. It would then need to expose an API that allowed for retrieval of individual traces.
+However, it may want this data to be discoverable and retrievable for each trace individually. It would then need to create a separate storage record for each trace in the file so that each one is individually discoverable and apply the same ACL and legal tag to each. It would then need to expose an API that allowed for retrieval of individual traces.
 
 It is important to think about these things up front so you make the correct decisions about how you expose these concerns and integrate with the OSDU core platform.