Conditional Requirements

B 060	If an IDS Meta Data Broker sells the access to its data content: - An IDS Meta Data Broker must outline how data can be bought and which usage restriction or license applies. - An IDS Meta Data Broker must provide »One Click« agreement - An IDS Meta Data Broker must be able to execute a Transaction Accounting - An IDS Meta Data Broker must be able to send notifications to an IDS Clearing House for Data Exchange Clearing If a ContractAgreementMessage has been acknowledged by a Broker and another entity, an IDS Meta Data Broker must behave according to this Agreement.
B 061 (B11)	If multiple Meta Data Broker exist, the following options for data provision to an index service must be ensured: a) A Connector sends multiple identical data messages to different IDS Meta Data Broker b) A Connector sends different data messages to different IDS Meta Data Broker c) A Connector sends data to a singular IDS Meta Data Broker. The data is propagated to other Brokers by the initially targeted Meta Data Broker.
B062 (B14)	An IDS Meta Data Brokers’ index service can refuse the processing of Publishing Messages based on locally defined rules. If such rules exist an IDS Meta Data Broker must respond with a RejectionMessage with a RejectionCode and an explanation message. Example rules are: - An IDS Meta Data Broker message is incorrect - the signature is missing or can't be validated - the sender is not authorized to send message to this index service - the sender of the message is different to the id-token in the data header - the number of queries in a specified time may be limited
B 063	An IDS Meta Data Broker may also block a distinct Connector for an arbitrary period to prevent DDOS attacks. If such a rule is triggered, no ResponseMessage should be send, not even a RejectionMessage.
B 064	SPARQL is the query language of the Semantic Web and Linked Data. IDS Brokers may accept SPARQL queries as payloads of QueryMessages but can also provide support for path-based query languages (JSON-Path, XPath, ...), other graph-related query languages (Gremlin) or any other standardized query language. If an IDS MetaData Broker provides querying possibilities, it should indicate the supported languages in their Self-Description.
B 065	In case an IDS Meta Data Broker accepts an IDS Usage Contract describing usage restrictions targeting a stored metadata element, an IDS Meta Data Broker must also enforce the contained restrictions. If an IDS Meta Data Broker cannot enforce the Usage Contract, it must reject it.
B 066 (B25)	Some persistence technologies provide native query languages. An index-service may allow native queries in BrokerQueryMessages which is not obligatory. Here is a list of native query languages: a) SQL ==> RDBMS (B24 c) b) LDAP-Query ==> LDAP / AD (B24 d) c) SPARQL ==> RDF(B24 e) and as an additional component: d) full-text search ==> query engine like Apache Lucene (B24 a-e) If such native query languages are implemented, they have to be stated within an IDS Meta Data Brokers Self Description.
B 067	If an IDS-Meta data Broker allows the usage of HTTP as the interaction protocol, HTTPS must be enforced.
B 068	If IDS Meta Data Broker has the ability to subscribe to a data source, it must react to published messages targeting it self according to IDS specifications. See "Behavior".
B 069	If IDS Meta Data Broker requires an authorization token for incoming messages, this token must beprovided and verified according to the latest specification.
B 070 (B8)	If multiple Meta Data Broker index services exist within an IDS Meta Data Broker Following options of meta-data inventories for index services are possible: a) all index service provide the same meta-data, and synchronize their local states accordingly, b) individual index services provide different meta-data, or c) combinations from a) and b)