Use Cases for DGGS Registry

[rggibb]

Use Case 1 addresses the question of whether a DGGS specification is formally compliant with the Conformance Classes and Requirements in Topic 21 v1 &/or Topic 21 v2 Part 1, and in the near future Parts 2, 3 & 4. Associated with this are the various formalised SWG duties of managing requests for assessment of a DGGS specification from an author and publishing the results.

[rggibb]

Use Case 2 is around DGGS Reference Systems .. this is the Use Case being exercised by the OGC API DGGS. First recall from Testbed 16, we identified that DGGS libraries might be either DGGS RS providers or DGGS Navigators. DGGS RS providers accept a set of parameters and generate a DGGS RS from those parameters. In this use case the role of the registry is to provide the lookup between a DGGS RS ID and the RS’s parameters. This is entirely analogous to the role of the EPSG repository, and the ability of a projection library to take a projection ID in the form of an EPSG code and return a set of parameters that allows the projection library to reliably recreate the maths for the projection.

Further details and variants for this Use case are elaborated in the the SwaggerHub document at /dggs/{dggsRSID}

[rggibb]

Rob Atkinson has mocked up a draft Use Case for how the OGC Definitions Server might interact with the DGGS Register, API definition and run-time implementations of the API

He says: I am developing and documenting a set of Use Cases for the Definitions Server as most applications have a similar number of moving parts and people struggle to understand it all, or how a sufficiently flexible infrastructure can be applied... so your feedback on this appreciated - and will collaborate with writing up a document if desired.

mock up

Feel free to drop comments or improve my characterisation of the moving parts of the API.

Note there are a few moving parts, and a few options: 1) CMS or file option for managing DGGS registry content 2) static files, general UI and custom UI viewer for both machine and human readable profiles 3) A limited view (profile) for API use is assumed - its possible this is not needed and the entire registry entry would be exposed to the API 4) JSON schema defines API, JSON-LD context decorates content to link schema elements to definitions 5) codelists are managed separately to DGGS but all are available to end API using same mechanisms

This is a bit scary - but in fact all the implementation architecture for the Definitions Server is in place - implementation means defining the DGGS ontology, profile if needed and custom forms, entailment/processing and viewers. Matt Purss has a DGGS registry django plugin already which may provide much of what we need. (I didnt add that generating the static HTML rendering can be done via the CMS as well as pushing the RDF definitions content - we just need to add some actions to fetch and persist these as static files in the github repo)

[ghobona]

Cc: @rob-metalinkage