diff --git a/docs-kits/kits/Digital Twin Kit/Software Development View/page_software-development-view.md b/docs-kits/kits/Digital Twin Kit/Software Development View/page_software-development-view.md
index d45926462f2..ef7e2c2a883 100644
--- a/docs-kits/kits/Digital Twin Kit/Software Development View/page_software-development-view.md
+++ b/docs-kits/kits/Digital Twin Kit/Software Development View/page_software-development-view.md
@@ -21,9 +21,8 @@ All openAPI-specifications for the Digital Twin Kit services are rendered in the
### Asset Administration Shell
-The Asset Administration Shell (AAS) is a specification that is released by the Industrial Digital Twin Association
-[(IDTA)](https://industrialdigitaltwin.org/) with a perspective to be adopted by the International Electrotechnical
-Commission [(IEC)](https://www.iec.ch/homepage).
+The Asset Administration Shell (AAS) is a specification that is released by the[Industrial Digital Twin Association (IDTA)](https://industrialdigitaltwin.org/)
+with a perspective to be adopted by the [International Electrotechnical Commission (IEC)](https://www.iec.ch/homepage).
Its mission is defining how “information about assets […] can be exchanged in a meaningful way between partners in a value
creation network”. As such, it is well-suited to contribute to the toolbox of Catena-X. While the Spec offers an extensive
suite of meta-model elements and APIs, Catena-X only uses a small subset. What exactly is defined in the Catena-X standard
@@ -32,7 +31,7 @@ CX - 0002.
#### Submodels
An Asset Administration Shell is organized in Submodels. Each Submodel represents a self-contained aspect of an asset -
-typical examples are the Nameplate or SingleLevelBomAsBuilt (which denotes the hierarchical composition of parts into
+typical examples are the *Nameplate* or *SingleLevelBomAsBuilt* (which denotes the hierarchical composition of parts into
a whole). As different aspects of an Asset may be known to different parties on the value-chain, Submodels for a single asset
must be capable to run independently of each other. The specification explicitly allows this, enabling easy cross-company
data integration.
@@ -46,14 +45,14 @@ mandatory.
#### Digital Twin Registry
What Catena-X calls the "Digital Twin Registry" (DTR) is actually the union of two different services that the AAS specification
-has specified. For the sake of simplicity, they are both defined in a single service. The DTR serves a similar function as the
-index in a book: When trying to discover information, it's convenient to have an overview WHAT one will find and HOW to
+has specified. For the sake of simplicity, they are both defined in a single component. The DTR serves a similar function as the
+index in a book: When trying to discover information, it's convenient to have an overview WHAT one will find, HOW and WHERE to
access it. The registry caters exactly that information: For every asset it knows, it holds a number of Submodel Descriptors and in
-these, a consumer app will find information WHAT it will find (via the semanticId) and how to access the information (endpoint,
+these, a consumer app will find information what it will find (via the semanticId) and how to access the information (endpoint,
security setup etc.). As the information contained in the DTR may be sensitive and not be trusted with a central entity,
every data provider must offer his own DTR as an EDC Data Asset. While it is only mandatory to implement the GET endpoints
as specified in the [Development View](https://eclipse-tractusx.github.io/docs-kits/next/kits/Digital%20Twin%20Kit/Software%20Development%20View/Specification%20Digital%20Twin%20Kit),
-data providers may find it useful to implement POST requests for registration on top. Either way, they are free to populate
+data providers may find it useful to implement other requests for registration on top. Either way, they are free to populate
their DTR in any way they desire.
### Catena-X specific Services
@@ -97,7 +96,7 @@ data that he set out to find.
Some use-cases assume that a consumer has prior knowledge of an asset's location in a provider's infrastructure. That's
-why data on a new asset will not necessarily be obtained by executing the whole discovery sequence above. For example,
+why discovering data will not always necessitate executing the whole discovery sequence above. For example,
a consumer may know not only the assetId but also the provider's BPN, allowing him to enter the sequence at step 10.
If this prior knowledge is given under all circumstances, registration steps 2-3 can be skipped provider-side.
@@ -106,131 +105,34 @@ If this prior knowledge is given under all circumstances, registration steps 2-3
Generic sample data for relevant data objects is contained in the openAPI-specs of the respective services. This chapter
contains data structures that are more specifically designed for use in the Digital Twin Kit. They are compliant with
-the base-specifications (like AAS) but restrict the application even further for use in this dataspace.
+the base-specifications (like AAS) but restrict the application even further for use in this Dataspace.
-### Registration at EDC
-
-While the exact AAS-EDC-integration is at the discretion of each Kit and use case, there are good practices
-that are likely to be standardized on the level of CX-0002 in the future. One relevant question is how the EDC-shielded services
-of this Kit should register with the Asset endpoint of the EDC Management API. The following recommendations follow
-the data structure expected from tractusx-edc v0.4.1 onwards. It demands a json-ld structure.
-
-Json-ld is a serialization for RDF graphs (see [Resource Description Framework](https://www.w3.org/RDF/)). The json-ld
-`@context` section can declare the namespaces that resources explicitly mentioned in the rest of the document belong to.
-It may also define default namespace with `@vocab` for resources without explicitly stated namespaces. Outside of
-the "@context" section, the "@type" property always defines the class that an object belongs to.
-As stated in the openAPI-specification of the EDC Management API's relevant endpoint, all entries in the `asset/properties`
-object and the `privateProperties` object can be chosen freely. The section on the `dataAddress` is structured depending
-on the `edc:type` property. The example below is determined by the [HttpDataAddress](https://github.com/eclipse-edc/Connector/blob/main/spi/common/core-spi/src/main/java/org/eclipse/edc/spi/types/domain/HttpDataAddress.java)
-class. Other implementations may require different parameters.
-
-For successful discovery of Digital Twins, it is critical to register Submodels and Digital-Twin-Registries in a
-harmonized way. The following overview shall explain how the `asset/properties` section could be used. Bear in mind that
-this is a non-normative example.
-
-- `asset:prop:type` (mandatory as per CX-0002): denotes the type of Asset that is registered. For all AAS-registries
-this property must be set to `data.core.digitalTwinRegistry`.
-- `rdfs:label` (optional): short name for asset.
-- `rdfs:comment` (optional): free text property for human consumption.
-- `dcat:version` (optional): version-string of the registered resource. Please note that the version of the AAS-spec is
- already considered in the `aas`-namespace.
-
-The top-level `@id` field denotes the identifier of the resource that is being registered.
-
-#### Digital Twin Registry as EDC Data Asset
-
-The top-level `@id` field is mandatory but can (for a DTR) be chosen freely at registration since a DTR usually has no unique
-identifier.
-
-```json
-{
- "@context": {
- "@base": "http://myCompany.org/identifiers/",
- "edc": "https://w3id.org/edc/v0.0.1/ns/",
- "dcat": "https://www.w3.org/ns/dcat/",
- "rdfs": "http://www.w3.org/2000/01/rdf-schema#"
- },
- "edc:asset": {
- "@type": "Asset",
- "@id": "04a0993c-aa76-446f-a026-cb2ed62ea03f",
- "edc:properties": {
- "asset:prop:type": "data.core.digitalTwinRegistry",
- "rdfs:label": "Digital Twin Registry",
- "rdfs:comment": "DTR Endpoint of provider Processor_BackendIntegrationTests",
- "dcat:version": "0.0.1"
- },
- "edc:privateProperties": null
- },
- "edc:dataAddress": {
- "@type": "DataAddress",
- "edc:type": "edc:HttpData",
- "edc:baseUrl": "https://mycompany.com/dtr/",
- "edc:authKey": "Authorization",
- "edc:authCode": "Basic XXX",
- "edc:proxyBody": "true",
- "edc:proxyPath": "true",
- "edc:proxyQueryParams": "true",
- "edc:proxyMethod": "true",
- "edc:contentType": "application/json"
- }
-}
-```
-
-
-#### Submodel as EDC Data Asset
+### Registration at Digital Twin Registry
-Registering a Submodel as Asset with the EDC Management API is at the discretion of each Data Provider. She may create
-one entry per Submodel or bundle them into one - yielding a smaller catalogue hence better performance. This may seem
-strange because unharmonized Asset Registration does not allow a Data Consumer to systematically find all EDC-Assets of
-type "Submodel". The discovery-sequence, however, is still intact since a Data Consumer will always know the Data Plane
-and Control Plane of a Submodel from its [Submodel Descriptor in the Digital Twin Registry](#registration-at-digital-twin-registry).
+The Digital Twin Registry connects an asset (identified by its assetIds) with links to the Submodels. Since Catena-X uses
+the EDC as a gateway for all inter-company interaction, the Digital Twin Registry must account for that. By design, it
+includes the possibility to add additional context via the fields `subprotocol`, `subprotocolBody` and `subprotocolEncoding`.
+`subprotocol` will always be set to `DSP`, short for the [Dataspace Protocol](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/overview/readme)
+as standardized by the IDSA. `subprotocolEncoding` is always set to `plain`.
-If a Data Provider wanted to
-The following shows an example for registration of an AAS-Submodel as EDC Data Asset. The basic structure of the
-`properties` section extends that of the DTR but additionally holds `hasSemantics:semanticId`. It is
-recommended and shall signify the meaning of the Submodel's payload.
+There's three relevant inputs to discover a referenced Submodel in Catena-X:
+- The `subprotocolBody` contains two pieces of information, assigned with `=` and separated by `;`:
+ - `dspEndpoint` is the URL of the Data Plane where a Data Consumer can negotiate for access to this Submodel.
+ - When calling the /catalog API of that Data Plane, she should filter for dcat:Dataset entries that have are identified
+ by the `id` mentioned in the subprotocolBody.
+- After having successfully negotiated for a Data Offer associated with the `id`, the Data Consumer can query the Data Plane
+of the given EDC to access the data. For that, she must use the URL given in the Submodel-Descriptor's `href` field and
+append the additional URL-segment /$value
-The top-level `@id` field should be equivalent to the id of the Submodel.
-```json
-{
- "@context": {
- "@base": "http://myCompany.org/identifiers/",
- "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
- "edc": "https://w3id.org/edc/v0.0.1/ns/",
- "aas": "https://admin-shell.io/aas/API/3/0/",
- "aas-submodel": "aas:SubmodelServiceSpecification/",
- "aas-semantics": "aas:hasSemantics/"
- },
- "edc:asset": {
- "@id": "urn:uuid:ca180cf7-7ed6-4f53-b32f-d072d4cad834",
- "@type": "Asset",
- "edc:properties": {
- "asset:prop:type": ["aas-submodel:SSP001"],
- "rdfs:label": "PCF Data",
- "rdfs:comment": "Endpoint for PCF data",
- "aas-semantics:semanticId": "urn:bamm:io:pcf:4.0.1:Pcf",
- "edc:contentType": "application/json"
- },
- "edc:privateProperties": null,
- "edc:dataAddress": {
- "@type": "DataAddress",
- "edc:type": "edc:HttpData",
- "edc:baseUrl": "https://data.plane",
- "edc:authKey": "Authorization",
- "edc:authCode": "Basic XXX",
- "edc:proxyBody": "true",
- "edc:proxyPath": "true",
- "edc:proxyQueryParams": "true",
- "edc:proxyMethod": "true",
- "edc:contentType": "application/json"
- }
- }
-}
-```
+#### Registering a new Twin
-### Registration at Digital Twin Registry
+Registration of a new twin is (at least in Catena-X) equivalent to the creation of a new twin. Thus, a Data Provider
+should
+always ensure that there is no shell-descriptor created for the respective assetIds yet. If there already is one,
+the submodel-descriptor should
+be [added to the existing shell-descriptor](#registering-a-new-submodel-at-an-existing-twin).
-#### Example for AAS-Registration
+`POST /shell-descriptors`
```json
{
@@ -245,7 +147,7 @@ The top-level `@id` field should be equivalent to the id of the Submodel.
"keys": [
{
"type": "GlobalReference",
- "value": "BPNL:someBpnOfAssetOwner"
+ "value": "{{BPN of the a party priviledged}}"
}
]
}
@@ -290,12 +192,9 @@ The top-level `@id` field should be equivalent to the id of the Submodel.
}
```
-#### Example for Submodel-Registration at existing AAS
+#### Registering a new Submodel at an existing Twin
-The Submodel Descriptors in the DTR must not only follow the schema defined by the openAPI file. Additionally, it is
-imperative that the network mandates how they shall be populated with data. This is especially critical because the
-data access is not straight-forward but passes through an EDC which the Data Consumer must negotiate with. That's why
-the subprotocol body holds information on how to talk to the EDC's Data Plane.
+`POST /shell-descriptors/{{aasId}}`
```json
{
@@ -334,12 +233,174 @@ the subprotocol body holds information on how to talk to the EDC's Data Plane.
}
```
-Currently, this structure is still standardized ambiguously in CX-0002. There, the `subprotocolBody` is not mandated to
-contain the specific data (`"id=xyz;dspEndpoint=myControlPlane"`). As this is however good practice in other Kits, the
-structure will likely find its way into the CX-0002 standard in the future.
+### Registration at EDC
+
+Integration between the EDC and AAS-Components in the dataspace is a strict prerequisite for robust discovery and data access
+in the Catena-X dataspace. As all data that crosses company-boundaries must be exchanged via an EDC, CX-0002 provides
+the necessary normative statements to facilitate interoperable data exchange.
+
+One relevant question is how the EDC-shielded services of this Kit should register with the Asset endpoint of the EDC Management API.
+While the EDC's /v3/assets endpoint is internal to the Data Provider only, the objects are also available via the /catalog API
+that is specified in the Dataspace Protocol.
+
+The EDC uses json-ld for Json-ld is a serialization for RDF graphs (see [Resource Description Framework](https://www.w3.org/RDF/)). The json-ld
+`@context` section can declare the namespaces that resources explicitly mentioned in the rest of the document belong to.
+It may also define default namespace with `@vocab` for resources without explicitly stated namespaces. Outside of
+the "@context" section, the `@type` property always defines the class that an object belongs to.
+As stated in the openAPI-specification of the EDC Management API's relevant endpoint, all entries in the `asset/properties`
+object and the `privateProperties` object can be chosen freely. The section on the `dataAddress` is structured depending
+on the `edc:type` property. The example below is determined by the [HttpDataAddress](https://github.com/eclipse-edc/Connector/blob/main/spi/common/core-spi/src/main/java/org/eclipse/edc/spi/types/domain/HttpDataAddress.java) class. Its parameters determine
+the behavior of the EDC's HTTP data plane at runtime. How they should be used is not subject to standardization since
+they
+aren't visible in the Dataspace. Certain values may have to be set in a certain way to enable the data exchange via
+the DT Kit.
+
+It presents the backend resources as dcat:DataSets with properties funnelled through from the assets-API. These
+properties can be freely set by the Data Provider.
+
+For successful discovery of Digital Twins, it is critical to register Submodels and Digital-Twin-Registries in a
+harmonized way. The following overview shall explain how the `asset/properties` section could be used.
+
+- `https://purl.org/dc/terms/type` (mandatory as per CX-0018): denotes the type of Asset that is registered. The property
+points to an RDF resource that can be either `https://w3id.org/catenax/taxonomy#DigitalTwinRegistry` or `https://w3id.org/catenax/taxonomy#Submodel`
+
+- `https://w3id.org/catenax/common/version` (mandatory as per CX-0002): version-string of the registered type of resource.
+ For all endpoints related to the AAS-spec, this must be set to "3.0" as that's the current normative version of the
+ AAS specification.
+
+#### Digital Twin Registry as EDC Data Asset
+
+- `asset:prop:type` (mandatory as per CX-0002): denotes the type of Asset that is registered. For all AAS-registries
+ this property must be set to `data.core.digitalTwinRegistry`. This property will likely be removed in the future as
+ it was overridden by the mandate in CX-0018.
+
+```json
+{
+ "@context": {
+ "edc": "https://w3id.org/edc/v0.0.1/ns/",
+ "cx-common": "https://w3id.org/catenax/ontology/common#",
+ "cx-taxo": "https://w3id.org/catenax/taxonomy#",
+ "dct": "https://purl.org/dc/terms/"
+ },
+ "@id": "{{ _.assetId }}",
+ "properties": {
+ "dct:type": {"@id": "cx-taxo:DigitalTwinRegistry"},
+ "cx-common:version": "3.0",
+ "asset:prop:type": "data.core.digitalTwinRegistry"
+ },
+ "privateProperties": {
+ },
+ "dataAddress": {
+ "@type": "DataAddress",
+ "type": "HttpData",
+ "baseUrl": "{{ _.url_backend }}",
+ "proxyQueryParams": "true",
+ "proxyPath": "true",
+ "proxyMethod": "false",
+ "oauth2:tokenUrl": "{{ _.url_keycl_backend }}",
+ "oauth2:clientId": "{{ _.client_id_backend }}",
+ "oauth2:clientSecretKey":"{{ _.sec_name_vault }}"
+ }
+}
+```
+The HttpDataAddress above configures the following behavior:
+- `baseUrl`: After successful negotiation, the data plane will delegate requests here and forward the answer. For the DTR,
+it's critical that the URL inserted here must end before the /shell-descriptors and /lookup segments.
+- `proxyPath`: This string can be either "true" or "false". If set to true, the EDC Data Plane will always forward
+the URL-segments added to the request to the dataplane to the backend URL. For example: If `baseUrl="http://mydtr.com/api/v3"`
+and `proxyPath="true"` then an authorized request to `http://dataplane.com/shell-descriptors` will be delegated to the backend
+`http://mydtr.com/api/v3/shell-descriptors`
+- `proxyQueryParams`: This string can be either "true" or "false". If set to true, the EDC Data Plane will always forward
+ query parameters to the backend. For the /lookup APIs of the registry, this is critical.
+- `proxyMethod`: This string can be either "true" or "false". If "false", the Data Plane will change the HTTP-Verb to GET
+for all incoming requests. As there is no scenario in the Catena-X scope where a business partner manipulates data in a
+foreign DTR, it should be set to false.
+
+
+#### Submodel as EDC Data Asset
+
+A Data Provider may create
+one Data Asset per Submodel or bundle them into one - yielding a smaller catalogue hence better performance. The discovery-sequence,
+does not strictly require uniformity here. Not even the typization via the EDC-property `dct:type` is functionally
+necessary. The discovery-sequence is still intact since a Data Consumer will always know the Submodel's
+location relative to the Data Plane's `baseUrl` from the submodel-descriptor's `href` field.
+The EDC-Asset shielding the Submodel is known from the descriptor's `subprotocolBody` containing the Control-Plane-URL and
+id of the EDC-Asset. For more details, see section [Submodel Descriptor in the Digital Twin Registry](#registration-at-digital-twin-registry).
+
+The following shows an example for registration of a single AAS-Submodel as EDC Data Asset. The
+`properties` section is analogous to that of the DTR but additionally holds `hasSemantics:semanticId`. It is
+recommended and shall signify the meaning of the Submodel's payload.
+
+```json
+{
+ "@context": {
+ "edc": "https://w3id.org/edc/v0.0.1/ns/",
+ "cx-common": "https://w3id.org/catenax/ontology/common#",
+ "cx-taxo": "https://w3id.org/catenax/taxonomy#",
+ "dct": "https://purl.org/dc/terms/",
+ "aas-semantics": "https://admin-shell.io/aas/3/0/HasSemantics/"
+ },
+ "@id": "{{ _.assetId }}",
+ "properties": {
+ "dct:type": {"@id": "cx-taxo:Submodel"},
+ "cx-common:version": "3.0",
+ "aas-semantics:semanticId": {"@id": "urn:bamm:io.catenax.asset_tracker_links:1.0.0#AssetTrackerLinks"}
+ },
+ "privateProperties": {
+ },
+ "dataAddress": {
+ "@type": "DataAddress",
+ "type": "HttpData",
+ "baseUrl": "{{ _.url_backend }}",
+ "oauth2:tokenUrl": "{{ _.url_keycl_backend }}",
+ "oauth2:clientId": "{{ _.client_id_backend }}",
+ "oauth2:clientSecretKey":"{{ _.sec_name_vault }}",
+ "proxyQueryParams": "false",
+ "proxyPath": "true",
+ "proxyMethod": "false"
+ }
+}
+```
+
+There is no normative guidance yet on how to register multiple Submodels bundled together yet. These bundles may include
+all the Submodels of a specific semanticId, all Submodels of an asset or any other arbitrary quality. This may be added to
+CX-0002 in future iterations. Even though the IDTA specifies a [Submodel Repository API](https://app.swaggerhub.com/apis/Plattform_i40/SubmodelRepositoryServiceSpecification/V3.0.1_SSP-002),
+in the context of the Catena-X architecture it is not strictly necessary to adhere to it. Submodels will be found regardless,
+given the URL-path relative to the `baseUrl` is appended correctly to the Data Plane's URL in the `href` field. The only
+differences are the changed typization. `proxyPath` parameter should be set `"true"` either way.
+
+```json
+{
+ "@context": {
+ "edc": "https://w3id.org/edc/v0.0.1/ns/",
+ "cx-common": "https://w3id.org/catenax/ontology/common#",
+ "cx-taxo": "https://w3id.org/catenax/taxonomy#",
+ "dct": "https://purl.org/dc/terms/"
+ },
+ "@id": "{{ _.assetId }}",
+ "properties": {
+ "dct:type": {"@id": "cx-taxo:SubmodelBundle"},
+ "cx-common:version": "3.0"
+ },
+ "privateProperties": {
+ },
+ "dataAddress": {
+ "@type": "DataAddress",
+ "type": "HttpData",
+ "baseUrl": "{{ _.url_backend }}",
+ "oauth2:tokenUrl": "{{ _.url_keycl_backend }}",
+ "oauth2:clientId": "{{ _.client_id_backend }}",
+ "oauth2:clientSecretKey":"{{ _.sec_name_vault }}",
+ "proxyQueryParams": "false",
+ "proxyPath": "true",
+ "proxyMethod": "false"
+ }
+}
+```
+
### EDC Usage Policies
The decision what policies shall be implemented for the exchange of data is at the discretion of each use-case and cannot
@@ -347,19 +408,40 @@ be standardized in the context of the semantics-standards or the DT Kit.
## Data Provisioning
-### Patterns
+### Versioning
+
+Versioning in the Catena-X network is an essential task. This holds true for Digital Twins more specifically, too. The
+network builds on several specifications where changes in API or specifications could break existing communication
+channels.
+In a simple scenario (where the Data Provider offers access to a Submodel via DTR and a Data Consumer GETs both
+resources),
+these are the layers of complexity:
+
+| Versioned Object | Presence in the [DT-Discovery](#discovery-sequence) Process | Description | Method to increment |
+|--------------------|-------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
+| Dataspace Protocol | 12, 22 | The body of the `{{consumerControlPlane}}/v2/catalog/request`-request points to a versioned endpoint of a business partner's DSP endpoint like `{{providerControlPlane}}/api/v1/dsp` | Unclear, under discussion in Connector Kit. |
+| AAS Specification | 4, 5, 15, 25 | For all AAS-related EDC-Assets (styled as dcat:Dataset in the catalog), a property cx-common:version must be added referring to the major and minor version of the AAS-spec. | Unclear, under discussion in DT Kit. |
+| Data Model Version | 5, 21, 29 | The structure of the Submodel is determined by the aspect-model's URN. It includes a section on versioning. | A new version of the schema requires setup of a new submodel. This includes registration at the DTR. |
+
+### Patterns for Submodels
Data Providers will usually follow one of two patterns:
1. Digital Twin Repository: Deploying a dedicated Repository for the persistence of digital twins and related data is the most
-convenient way to get going with the AAS. Due to the risk of data duplication and unclear initial ingestion mechanisms,
+ convenient way to get started with the AAS. Due to the risk of data duplication and unclear initial ingestion
+ mechanisms,
it may not scale to industrial sizes.
2. Delegation: Wrapping another API or a database may deploy the Submodel API as a new facade. It delegates the incoming
-requests to the respective backend systems.
+ requests to the respective backend systems. This is particularly feasible in the Catena-X dataspace since it
Offering data to the network requires mappings that are naturally dependent on the data source format. More on data integration
can be found in the corresponding [CX e.V. guide](https://catena-x.net/fileadmin/user_upload/04_Einfuehren_und_umsetzen/Onboarding/DataIntegrationPatterns_Guide_Final_V1.pdf).
-### Register Digital Twins
+### Patterns for DTRs
-As mentioned in CX - 0002, every Data Provider is required not only to deploy a DTR in his infrastructure but also to
-register each of the Submodels. Otherwise, the data will not be discoverable by Data Consumers.
\ No newline at end of file
+Usually, a DTR will implement a persistence with the specified AAS-APIs for data ingestion specified in the SSP-001 by
+means of POST endpoints, updatable with PUT and PATCH requests (
+see [reference implementation](https://github.com/eclipse-tractusx/sldt-digital-twin-registry)).
+These APIs should only be accessible by the Data Provider (for instance by introduction of proper access control scopes
+or setting `proxyMethod = false`, see [registration](#digital-twin-registry-as-edc-data-asset)). Delegation
+as backend integration pattern is more inconvenient as the DTR must process and return reproducable IDs not only for
+the assets but also for the AAS - this is hard to realize in a pure stateless implementation.
\ No newline at end of file
diff --git a/docs-kits/kits/Digital Twin Kit/assets/img/DTKIT_discovery_seq.svg b/docs-kits/kits/Digital Twin Kit/assets/img/DTKIT_discovery_seq.svg
index 6f127f26043..f8915da95de 100644
--- a/docs-kits/kits/Digital Twin Kit/assets/img/DTKIT_discovery_seq.svg
+++ b/docs-kits/kits/Digital Twin Kit/assets/img/DTKIT_discovery_seq.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs-kits/kits/Digital Twin Kit/page_adoption-view.md b/docs-kits/kits/Digital Twin Kit/page_adoption-view.md
index c0170aa2ef0..7ad1419e61d 100644
--- a/docs-kits/kits/Digital Twin Kit/page_adoption-view.md
+++ b/docs-kits/kits/Digital Twin Kit/page_adoption-view.md
@@ -22,8 +22,8 @@ The aim of the Digital Twin Kit is to trace parts and materials across the entir
cases over all n-tier levels without compromising data sovereignty. This Kit enables data and app providers to deliver
solutions for building data chains and to send quality notifications on all levels and industries.
-To provide the Catena-X Automotive Network with a uniform infrastructure to enable data-level interoperability between
-Business Partners is the purpose of the Digital Twin Kit. Regardless of the data's provenance, the Kit sets the scene
+The Kits purpose is to provide the Catena-X Automotive Network with a uniform infrastructure to enable data-level
+interoperability between Business Partners. Regardless of the data's provenance, the Kit sets the scene
for a comprehensive landscape of distributed Digital Twins of assets (mostly parts) along the entire lifecycle of the
supply chain.
@@ -44,14 +44,15 @@ are given the necessary tooling to format their data and APIs in a standardized
## Business Value
Point-to-Point integration between Business Partners is challenging. On the one hand, all questions of sovereignty,
-authorization, authentication must be agreed upon and implemented. That is covered by the
-[Connector Kit](https://eclipse-tractusx.github.io/docs-kits/category/connector-kit) and the
-services it relies on. What this Kit adds is a set of technologies that reduce the integration efforts on the
-data level. Data Consumers can develop their applications against data formats that are standardized and reuse
-them independent of whom they will consume the data from. This reduces the necessary investment significantly
-and saves a network-participant from a strict link between the application and the data model.
-Consuming applications can be substituted seamlessly if they are developed against the
-relevant Catena-X standards - further lowering the bar of entry for new applications in the CX-Ecosystem.
+authorization, authentication must be agreed upon and implemented. In the Catena-X network, that is covered by the
+[Connector Kit](https://eclipse-tractusx.github.io/docs-kits/category/connector-kit) and the services it relies on.
+
+What this Kit adds is a set of technologies to reduce the integration efforts on the data level. Data Consumers can
+develop their applications against data formats and interfaces that are standardized encouraging client-side reuse.
+Consequently, data providers present data agnostic to who will consume the data from. This reduces the investment necessary
+to onboard to additional Catena-X use-cases significantly. Consuming applications can be substituted seamlessly as
+they are developed against the relevant Catena-X standards - further lowering the bar of entry for new applications in
+the ecosystem.
## Use Case
@@ -59,9 +60,9 @@ relevant Catena-X standards - further lowering the bar of entry for new applicat
### Status Quo / Today’s challenge
This Kit's aim is not to solve a dedicated business problem. It is an infrastructure component, critical for scalable
-data sharing and integration. It does however deliver a broad set of capabilities that the use cases can leverage.
+data sharing and integration. It does however deliver a broad set of capabilities that the use cases can leverage, namely:
-- Well-defined API structure extensible by domain models. Each use case will want to share different data and the API
+- Well-defined API structures extensible by domain models. Each use case will want to share different data and the API
expands with the scope of the model.
- A distributed infrastructure of central and decentral components integrating hand-in-hand with backend-systems southward