docs(terminology): extended and updated terminology #1653
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,34 +1,54 @@ | ||
| # Terminology | ||
|
|
||
| | Name | Description | | ||
| |:-----------------------------|:--- | | ||
| | **Artifact** | The instance of code which can be modulized used by the EDC | ||
| | **Asset** | An **asset** describes **data** that can add value to a **dataspace** and contains the **dataAddress** | ||
| | **Asset Index** | **Asset Index**<p>* manages assets<p>* provided by an extension<p>* may support external catalogs<p>* can be queried | ||
| | **Broker** | see **IDS Broker** | ||
| | **Catalog** | **Catalog** is a directory about all meta-information about the **assets** a **data consumer** can reach in the **dataspace** | ||
| | **Configuration** | The EDC allows using a configuration file which will be loaded at every startup of an EDC instance | ||
| | **Connector** | **Connector** is the central instance for a participant to join a **dataspace**. The **connector** is the gateway from the user to the **dataspace**. | ||
| | **Contract** | **Contract** is the finalized meta-information for a data transfer after a **contract negotiation** including the **policies** who have to be followed | ||
| | **Contract Managment** | Includes all parts of **contract offer**, **contract agreement** and **contract negotiation** | ||
| | **Contract Agreement** | **Contract Agreement**<p>* points to a **Contract Offer**<p>* results from a **Contract Negotiation Process**<p>* has a start date and may have a expiry date and a cancellation date | ||
| | **Contract Negotiation** | * MVP: only possible to accept already offered contracts. Counter offers are rejected automatically. | ||
| | **Contract Offer** | **Contract offer**<p>* set of obligations and permissions<p>* generated on the fly on provider side (see **Contract Offer Framework**)<p>* are immutable<p>* persisted in **contract negotiation process** once the negotiation has started<p> | ||
| | **Contract Offer Framework** | **Contract offer framework**<p>* generates **contract offer templates**<p>* provided by **extensions**<p>* may be implemented in custom **extensions** to created **contract offers** based on existing systems | ||
| | **Contract Offer Template** | Blueprint of a **contract offer** | ||
| | **Consumer** | see **data consumer** | ||
| | **Consumer Pull** | The data transfer is initilazied by the Consumer | ||
| | **Data** | **Data** describes the properties of business objects | ||
|
There was a problem hiding this comment. That is plain wrong. Business objects' properties are described by fields, at least in an OOP sense. There was a problem hiding this comment. I have tried to reformulate it in the sense that data have the task to represent information. Honestly, however, a good description for data is to be found, because from different points of view data are always defined slightly differently. Hope it fits better now. |
||
| | **Data Consumer** | **Data consumer** are receiver of data in a data transfer | ||
| | **Data Provider** | **Data providers** produce data and are the source for data in a data transfer | ||
| | **DataAddress** | Reference to the physical Address of an **asset** | ||
| | **DataFlow** | Transfer of **data** from **data producer** to **data consumer**. | ||
| | **Dataspace** | A **dataspace** is a space where different participants exchange **data** to get an benifit of this | ||
| | **EDC Extension** | A module piece of the EDC which can be customized used for the EDC | ||
| | **EndpointDataReference** | **EndpointDataReference** describes an endpoint at which one receives data | ||
| | **Event** | An **event** is a action which is be observed in the EDC and published by the **Event Framework** | ||
| | **Event Framework** | **The event framework** is a way to react to actions in the EDC and can also be extended | ||
| | **Event Router** | **Event router** is the central part of the **event framework**, which collects all published **events** | ||
| | **Extension** | see **EDC Extension** | ||
| | **Federated Catalog** | A decentralized **catalog** | ||
|
There was a problem hiding this comment. since There was a problem hiding this comment. I have now tried to better illustrate that the |
||
| | **Framework** | see **contract offer framework** | ||
|
|
||
| | **Health** | Infrastructure status of the EDC | ||
| | **HTTPDataAddress** | Specific type of **dataaddress** in context of HTTP-endpoints | ||
|
There was a problem hiding this comment.
There was a problem hiding this comment. Deleted this term now in context of your advice that something like this should be in the javadoc and not in an markdown. |
||
| | **Identity Provider** | Management of the correct identification of all participants in the **dataspace**. | ||
| | **Injection** | **Artifacts**/**EDC Extensions** can be injected in different parts of the EDC to be used | ||
|
There was a problem hiding this comment.
There was a problem hiding this comment. I deleted this also because of your advice in context of what has to be in javadoc and what in markdown. Only my question about it is this. The Injection Interface is used to make the different modules usable among each other. So to give a module of the EDC the possibility to find the COde of another used module within the EDC. If this is a complete misconception of your injection mechanism, I need to look deeper into your injection mechanism. There was a problem hiding this comment. first of all, we don't inject extensions or modules, we simply inject services. this is a very wide-spread concept that deals with object instantiation. I strongly suggest diving deeper into the code and reading the appropriate documentation, and only add documentation if really necessary. |
||
| | **Offer** | see **contract offer** | ||
| | **Offer Framework** | see **contract offer framework** | ||
| | **Monitor** | The **monitor** is an interface to realise different ways to put out logs and debug information | ||
| | **Policy** | logical collection of rules | ||
| | **PolicyArchive** | Location to get **policies** by their ID | ||
| | **PolicyDefinitionStore** | Storing all **policy definitions** in the EDC | ||
| | **PolicyEngine** | Enforcing of **policies** in the EDC | ||
| | **Provider** | The participant in an dataspace who is producing and publish sth. See **Data Provider** | ||
| | **Resource** | Infrastructure component for data transmission | ||
| | **Resource Manifest** | Collection of **resources** | ||
| | **Rule** | **Rules**<p>* bound to a **contract offer**, **contract agreement** or **contract offer framework**<p>* exist independent from an **asset** | ||
| | **Transfer Process** | **Transfer process**<p>* based on a **contract agreement** | ||
| | **Transfer Process Store** | Storing all informations about handled **transfer processes** | ||
| | **TypeManager** | **TypeManager** manages system types and is used to deserialize polymorphic types | ||
| | **UsageControl** | **Usage Control** is the part of the EDC that is responsible for ensuring that the **policies** for the **data** specified in the **contract** are adhered to. | ||
| | **Vault** | Providing secrets | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The term "Contract Offer Framework" is not in use anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok sorry, deleted it now. I wasn't aware of it.