What would the mechanism be to discover available metadata profiles?

[nmtoken]

I see in the editors draft Draft Outline for OGC API - Catalogue, that a catalogue may implement any underlying data model that it wants (e.g. ebRIM, ISO19115/ISO19119, etc.) however, all internal data models must be mapped to the record schema defined in this standard

Has any consideration been given to how a user would search for available metadata models / profile and then request that profile in the desired encoding?

[pvretano]

@nmtoken No. At the moment we are really focusing of defining the core which is limited to the core queryables (i.e. id, title, description, etc.) and the core query parameters (i.e. bbox, datetime, limite, etc.). Discovering what the underlying information model (e.g. ebRIM) is and being able to query it directly would be an extension.

[nmtoken]

Thanks,

Is your understanding that there will be only one underlying model, or will an implementation be able to supply metadata to multiple models?

[pvretano]

@nmtoken No restriction as far as I am concerned. An implementation can provide output in multiple models. My implementation, for example, offers the core queryables as GeoJSON: https://eratosthenes.pvretano.com/cubewerx/cubeserv/default/ogcapi/catalogues/collections/tb16cat/items?f=json and also offers the same information using ebRIM as XML: https://eratosthenes.pvretano.com/cubewerx/cubeserv/default/ogcapi/catalogues/collections/tb16cat/items?f=xml&schema=ebrim&resultType=results I use the vendor-specific parameter "schema" to trigger which information model should be generated but that particular aspect of the issue would be defined in an extension for discovering and accessing alternative information models.

[rob-metalinkage]

The specification at https://www.w3.org/TR/dx-prof-conneg/ provide a canonical means for discovery of, and handling content negotiation over, multiple models (or profiles which is slightly more generic as possibly multiple profiles may use the same data model but contain different information, for example based on spatial resolution, CRS, authorisation, detail etc.)

a working draft implementation can be seen at https://defs-dev.opengis.net/def/schema/hy_features/hyf?_profile=alt - this is the way OGC itself will publish resource types for resolvable URIs

you may of course choose some custom parameters in an API to specify model and encoding, but if a genuinely self-documenting, extensible and flexible approach is required then please consider this. Note that the spec also provides a means (QSA-ALT) to document choice of non-standard parameters to handle model and format, and can provide for ad-hoc ways of listing available choices by specifying a specific profile that contains the "alternates" view - provided some way can be found to let users know what that is - and means either "magic" client knowledge of the specific API or more work for the profile itself to describe itself in a canonical way.

[pvretano]

@rob-metalinkage Yeah, that looks good. If there is a "standard" or "on-the-way-to-becoming-standard" way to negotiate which model/profile to use I am good with that.

[rob-metalinkage]

@pvretano Its not terribly complicated, and you might want to consider a minimal profile of it with no inheritance support - but suggest its worth having a think about whether its actually also a good way of handling declarations of FeatureType subclassing too. Happy to discuss implications and alternative approaches any time.

Ps there are a few python implementations - but a library that could be contributed as an apache module would be a cool option too.

[pvretano]

21-SEP-2020: The ability to advertise and/or discover profiles is not something we thing is a "core" capability. Perhaps an extension.

[mhogeweg]

that seems odd. in CSW 2.0.2 implementers can advertise the capabilities of their catalog in terms of queriables (INSPIRE add various, AP ISO adds various) and response schemas. While defining the list of those added queryables is in the realm of the community creating the profile (not OGC per se), the catalog service itself provides the mechanism to advertise those capabilities. That seems part of the core then.

[rob-metalinkage]

Discoverability has two parts: 1) mechanism 2) canonical description

Note that the PROF vocabulary (https://www.w3.org/TR/dx-prof/#Class:Profile) has prof:Profile, whilst not designated as a subclass of dcat:Resource, designed to follow the same pattern as a dcat:Dataset, i.e. resources that are used to describe a profile are modeled as structures equivalent to dcat:Distribution. It could be used as the model for the canonical description of profiles, thus any DCAT compatible catalog approach could fairly easily offer this. Clients would need to know to use a catalog query in the same way they need to know how to hit a GetCapabilities, except it wouldnt be idiosyncratic per service type. Content-negotiation-by-profile as described above supports another mechanism without needing an API specific method.

[rob-metalinkage]

An experimental version of OGC API exposing two profiles of GeoJSON with vector geometry and DGGS and multiple feature type views for the same features is in underway as part of testbed-16. This will use Conneg-by-profile to perform this function, and also JSON-LD for Linked Data compatibility. Reinventing this wheel may not be the best option.

[mhogeweg]

would be great if the yaml file for the records API gets updated along with the discussions and prototypes.

[pvretano]

Hey, I'm pedaling as fast as I can! ;)

[mhogeweg]

happy to help out with that! fork + pull request?

[pvretano]

Sure ... works for me ...

[mhogeweg]

small updated available here: #53

[pvretano]

Pull request #53 merged.