|
1 | 1 | ### Metadata Broker ### |
2 | 2 |
|
3 | | -The IDS Metadata Broker consists of an IDS Connector (see Section [3.5.2](./3_5_2_IDS_Connector.md#ids-connector)), an endpoint for the registration, publication, maintenance, and query of Self-Descriptions. Therefore, for any interaction with the IDS Metadata Broker, the processes defined on the Process Layer, the descriptions defined on the Information Layer, and descriptions defined on the System Layer can be applied. The Information Layer describes the message types for registration and query. An IDS Metadata Broker may provide additional services that in term must be described by using terms from the IDS Information Model in the respective Metadata Broker's Self-Description document. |
| 3 | +The IDS Metadata Broker is an IDS Connector (see Section [3.5.2](./3_5_2_IDS_Connector.md#ids-connector)), which contains an endpoint for the registration, publication, maintenance, and query of Self-Descriptions. |
| 4 | + |
| 5 | +A Self-Description encapsulates information about IDS Connector itself and its capabilities and characteristics. This Self-Description contains information about the offered interfaces, the owner of the component and the metadata of the data offered by the component. A Self-Description is provided by the operator of the Connector. The Self-Description in total can be seen as metadata. |
| 6 | + |
| 7 | +An IDS Connector providing a service or data can send its Self-Description to a IDS Metadata Broker so that every participant is able to find it within the dataspace. The IDS Metadata Broker can be understood as a phone book. Within a dataspace, there can be multiple IDS Metadata Brokers allowing to distribute the IDS Metadata Broker functionality. It is up to the dataspace authority to decide if there is a leading IDS Metadata Broker or if the different instances operate independently. |
| 8 | + |
| 9 | +A participant can interact with an IDS Metadata Broker by using the processes defined on the Process Layer, the descriptions defined on the Information Layer, and descriptions defined on the System Layer. The Information Layer describes the message types for registration and query as well as their content. An IDS Metadata Broker may provide additional services that in term must be described by using terms from the IDS Information Model in the respective Metadata Broker's Self-Description document. |
4 | 10 |
|
5 | 11 | **Note: Even though the name might indicate a different purpose, an IDS Metadata Broker is *not* a message broker or provides any similar functions to distribute data assets actively by itself.** |
6 | 12 |
|
7 | 13 | As a direct consequence of the IDS Connector-nature of the Metadata Broker, each instance must be compliant to the Connector Certification criteria and in particular provide the functionalities and endpoints of general Connectors. For instance, a Metadata Broker must provide a Self-Description that provides further information about itself for other IDS components. A Metadata Broker must also have a valid IDS Identity and use a valid DAT in its communication. |
8 | 14 |
|
9 | | -In addition to these requirements for each IDS Connector, the Metadata Broker provides further functionalities for a data space. Its main purpose is the persistence and storing of Self-Description documents and offering efficient access and search functions on their content. It therefore requires a reliable and scalable internal database. As the Self-Description documents are encoded in RDF, usually JSON-LD, a graph-oriented database like a triple store or a property graph database might be used. Nevertheless also traditional SQL or NoSQL databases may be applied, which may not have the same native query support but still can be sufficient. In any case, the internal architecture of a Metadata Broker must be flexible enough to cope with extensions of the data scheme. The IDS Information Model can always be enriched with further attributes, so a Metadata Broker must also allow the persistence and querying of information which was not yet known at its deployment time. Furthermore, Metadata Brokers operated for certain domains or dedicated data spaces might also enforce the existence of attributes that are not covered by the core IDS Information Model or part of the IDS namespace. That implies that a certain Metadata Broker instances require Self-Descriptions which information content goes beyond the IDS Information Model. In such cases, the additional requirements are outlined in the Metadata Broker Self-Description as well as in the content of the return messages, in case a Connector has not set such attributes yet. |
| 15 | +In addition to these requirements for each IDS Connector, the Metadata Broker provides further functionalities for a data space. Its main purpose is the persistence and storing of Self-Description documents and offering efficient access and search functions on their content. It therefore requires a reliable and scalable internal database. As the Self-Description documents are encoded in RDF, usually JSON-LD, a graph-oriented database like a triple store or a property graph database might be used. Nevertheless also traditional SQL or NoSQL databases may be applied, which may not have the same native query support but still can be sufficient. In any case, the internal architecture of a Metadata Broker must be flexible enough to cope with extensions of the data scheme. The IDS Information Model can always be enriched with further attributes, so a Metadata Broker must also allow the persistence and querying of information which was not yet known at its deployment time. Furthermore, Metadata Brokers operated for certain domains or dedicated data spaces might also enforce the existence of attributes that are not covered by the core IDS Information Model or part of the IDS namespace. That implies that a certain Metadata Broker instance requires Self-Descriptions containing information content that uses extensions of the IDS Information Model. In such cases, the additional requirements are outlined in the Metadata Broker Self-Description as well as in the content of the return messages, in case a Connector has not set such attributes yet. |
10 | 16 |
|
11 | 17 | Furthermore, a Metadata Broker implementation might add indexing or caching modules to reduce the query evaluation time. It can be generally expected that the amount of READ requests is significantly higher than the overall number of remote WRITE activities so a READ-optimized architecture can lead to better user experiences. Such design decisions however are in the responsibility of the operator. |
12 | 18 |
|
|
0 commit comments