Merge branch 'tutorial' into 'master'

remove DE references from doc

See merge request !5

docs/api/register_openapi.yaml

 openapi: 3.0.0
 info:
-  description: APIs to manage registrations in the Data Ecosystem.
+  description: APIs to manage registrations in the OSDU.
   version: 1.0.0
   title: Register
   contact:
     name: OSDU Support
     email: devportal-help@osdu.com
+  license:
+    name: Apache 2.0
+    url: http://www.apache.org/licenses/LICENSE-2.0
 tags:
   - name: Domain Data Management Service (DDMS)
     description: ""
@@ -1050,9 +1053,9 @@ paths:
         - bearer: []
         - appkey: []
 servers:
-  - url: https://api.evq.csp.osdu.com/de/register/v1
+  - url: https://evq.csp.osdu.com/api/register/v1
     description: EVT
-  - url: https://api.evd.csp.osdu.com/de/register/v1
+  - url: https://evd.csp.osdu.com/api/register/v1
     description: EVD
 components:
   securitySchemes:

docs/tutorial/HowToBecomeADDMS.md

@@ -10,7 +10,7 @@
 * [Client retrieves the bulk data](#retrieve)
 
 ## Introduction <a name="introduction"></a>
-A Domain Data Management Service (DDMS) can be seen as any source of truth for data that manages the data life cycle, satisfies given mandatory data access concerns, and makes its data globally discoverable and retrievable through the Data Ecosystem. It could be a standalone service dedicated to a specific data type or a subcomponent of an application or platform. It simply enables its data to be retrieved outside of its regular scope.
+A Domain Data Management Service (DDMS) can be seen as any source of truth for data that manages the data life cycle, satisfies given mandatory data access concerns, and makes its data globally discoverable and retrievable through the OSDU. It could be a standalone service dedicated to a specific data type or a subcomponent of an application or platform. It simply enables its data to be retrieved outside of its regular scope.
 
 A DDMS needs to enforce the common concerns of 
 
@@ -19,7 +19,7 @@ A DDMS needs to enforce the common concerns of
 *  Discovery
 *  Retrieval of the data based on discovery
 
-Data Ecosystem solves these concerns primarily using Storage records. A Storage record is metadata pertaining to the bulk data stored in the DDMS. Every record created in Storage enforces that ACLs are assigned, checks compliance and then indexes the record into search, making it discoverable.
+OSDU solves these concerns primarily using Storage records. A Storage record is metadata pertaining to the bulk data stored in the DDMS. Every record created in Storage enforces that ACLs are assigned, checks compliance and then indexes the record into search, making it discoverable.
 
 The following is the preferred method of using Records to enable these concerns for a DDMS.
 
@@ -123,7 +123,7 @@ Note that you can register as much of your API specification as you like. You on
 
 ## Create a Storage schema <a name="create-schema"></a>
 
-It is up to the bulk data store to determine what properties of the bulk data they want to push into a Storage record and to make discoverable within the Data Ecosystem (DE).
+It is up to the bulk data store to determine what properties of the bulk data they want to push into a Storage record and to make discoverable within the OSDU.
 
 They define a storage schema to represent this. The schema is a list of properties and the type of data they represent that will be on the Record.
 
@@ -266,7 +266,7 @@ Remember, you should append your DDMS Id, entityType and the bulk data’s local
 
 As mentioned, a DDMS should create a shadow record for every instance of bulk data ingested into their data store. This can have advantages beyond global discover-ability. Whenever you request a storage record, both compliance and entitlements are checked before returning the data. A DDMS can use this to their advantage.
 
-By forwarding on any request by the client to retrieve the record, you can delegate these responsibilities to the Storage service. If Data Ecosystem returns the Record, the client can access both this and the bulk data, and so you can return the same to the client or only the Record.
+By forwarding on any request by the client to retrieve the record, you can delegate these responsibilities to the Storage service. If OSDU returns the Record, the client can access both this and the bulk data, and so you can return the same to the client or only the Record.
 
 <details><summary>curl</summary>
 
@@ -293,7 +293,7 @@ By forwarding on any request by the client to retrieve the record, you can deleg
 
 </details>
 
-In this scenario, you also don’t need to store the ACL or legal tag information in your DDMS because those are being retrieved directly from the Data Ecosystem in this request. However, you need to either store or be able to generate the Storage record ID needed to retrieve the record for the bulk data requested.
+In this scenario, you also don’t need to store the ACL or legal tag information in your DDMS because those are being retrieved directly from the OSDU in this request. However, you need to either store or be able to generate the Storage record ID needed to retrieve the record for the bulk data requested.
 
 ## Client retrieves the bulk data <a name="retrieve"></a>