Focusing on the generalization of concepts, functionality, and overall processes involved in the creation of a secure 'network of trusted data' , the IDS-RAM resides at a higher abstraction level than common architecture models of concrete software solutions do. The document provides an overview and dedicated architecture specifications.
Currently, Section 3.3 provides all information for the standard use case: an IDS Connector provides data offers and another IDS Connector queries these and consumes data. Especially Section 3.3.2 deals with data offerings. However, the ids:ResourceCatalog provides the ids:requestedResource property. Thinking of a scenario, where the data provider has not yet made a data offer, but the consumer wants to express what data is needed. Basically, this would reference the same aspects: making this public via the self-description, providing it at the IDS Metadata Broker, initiating a contract negotiation, transferring data. Nevertheless, this case is not covered by the RAM as-is.
Currently, Section 3.3 provides all information for the standard use case: an IDS Connector provides data offers and another IDS Connector queries these and consumes data. Especially Section 3.3.2 deals with data offerings. However, the
ids:ResourceCatalogprovides theids:requestedResourceproperty. Thinking of a scenario, where the data provider has not yet made a data offer, but the consumer wants to express what data is needed. Basically, this would reference the same aspects: making this public via the self-description, providing it at the IDS Metadata Broker, initiating a contract negotiation, transferring data. Nevertheless, this case is not covered by the RAM as-is.