This repository defines profiles of OGC APIs and exchange formats to support interoperability in the ILIAD Digital Twin of the Ocean context.
The profiles link several APIs such as OGC API Features to specific schemas supporting the Oceans Information Model used by ILIAD.
This repository is both a place where common elements can be tested and specificed and a set of examples to show how these can be used to define specific application profiles.
Here is a short (11mins) video describing this from a "Best Practices" perspective.
The compiled (ready to use) elements and documentation are available here: (https://ogcincubator.github.io/iliad-apis-features/)
These profiles demonstrate a scalable and extensible approach to creating different levels of interoperability for different sub-domains.
Examples used Linked Data published vocabularies managed in a separate repository - these can be managed by individual application domains independently of the common API patterns.
This profile defines a baseline for all APIs delivering observational data in the ILIAD system. The requirements are simple and pertain to metadata required to register services and data in the ILIAD ecosystem.
This profile defines transformations for the Features JSON schema to and from other APIs, such as EDR and STA.
The core of this profile is the SOSA component of the Oceans Information Model using a standardised JSON schema, JSON-LD context and SHACL rules regarding disposition of metadata across ObservationCollections and individual observations.
Common constraints on Iliad Observations for Citizen Science applications. These constraints match the semantics of the STA+ API defined by the OGC Citizen Science Working Group
Largely this is expected to describe the project using a standardised form.
Specific constraints for services delivering data for the Jellyfish Pilot.
Applies the ILIAD Citizen Science Profile to the Citizen Science general profile.
Defines specific procedures and observable properties required.
The schema and content of this are based on an draft implementation based on early analysis by PSNC and OGC and will be finalised as pilot design progresses.
(TBD)
The interoperability specifications defined here will be tested and deployed as working examples and tested in context of alternative representations using other OGC APIs according to the following approach:
Note the common semantic model target achieved using the JSON-LD binding, inherited from the ogcapi-sosa building block
The build/ directory contains the reusable assets for implementing this building block, in full or part, and the rest of the repository contain sources to build these assets. Sources minimise redundant information and preserve original forms of inputs, such as externally published schemas etc. This allow these to be updated safely, and also allows for alternative forms of original source material to be used whilst preserving uniformity of the reusable assets.
Note that the these components will be consistently structured for a given type of building block, and the editable components may vary according to the source material used to derive the building block, and therefore cannot be directly referenced.
features/: schemas for the feature types defined by this bb (which is a "super-bb" containing at least oneOf these defined features)datatypes/: reusable schemas for (potentially complex) datatypes defined by this bbaspects/: groups of properties that may be included in feature types (equivalent to attribute groups in XML schema)assets/: Documentation assets (e.g. images) directory. See Assets below.