Document RAINBOW usage scenarios for ILIAD, and generalised Use Case #7
Description
A key proposition of the RAINBOW is that by having better connected, and more granular components, users of standards will have better information and experiences.
Instead of (or to augment the legacy of) a body of large complex standards, the OGC Building Blocks approach will map dependencies on smaller elements - such as sub-schemas, concepts, API methods etc, and make it clearer which elements are shared.
This extends to the common profiling pattern, for the underlying use case of "how am i going to use this standard consistently in my domain, when i may not need all options and i may want to restrict where its too open for interpretation or implementation choices".
The BBs map "upstream" dependencies for a standard or a component - however this doesnt tell the use who else uses the standard in their profiles, or what parts are compatible with other related standards.
Further to this is the provision of "integration assets" - resources that help integrate specific elements across alternative standards - for example mappings from ISO19115 metadata elements to DCAT, or from OGC API schemas to standard ontologies.
Hence, the need for a Use Case to describe the role of the RAINBOW to discover all these other aspects needed to discover and interpret and evaluate standards for a given application.
A suggestion would be to identify a set of questions users would want to ask, ("competency questions") - we can then ascertain the gap between available information and answerability. Each question would then be tested against the various possible RAINBOW entry points (search, discovery, working out from a known point etc) and widgets (text or graphic) designed to meet these needs if necessary.
A scenario based on the ILIAD environment would be ideal - a graphic representation of the way "ILIAD APIs" could be accessed and exploited, and how users would extend by specialisation to meet new application needs.
Note that linkages between dataset metadata, services, standards and the underlying "Oceans Information Model" will also help drive some improvements in the API documentation - in particular update and presentation of coherent examples - and the SEADOTS and AD4GD projects among others can help consolidate the linkages (how metadata describes standards in use) into canonical standards/profiles.
outputs:
- documentation of "competency questions" and Use Case descriptions for the motivations
- Use Case Scenarios for ILIAD-specific cases, and ideally some other application domain to demonstrate these are generic RAINBOW requirements.
- presentation and report-ready diagrams of the key Use Case paradigms, with a Use Case Scenario showing what this looks like for a specific case
(this is probably a follow up issue... )
- Identification of gaps in the ILIAD examples (and possible API specifications), from the perspective of RAINBOW resources
- Identify if gaps are due to source gaps, data inconsistencies or RAINBOW data ingest/integration gaps.