search

opengeospatial / ogcapi-common

OGC API - Common provides those elements shared by most or all of the OGC API standards to ensure consistency across the family.
https://ogcapi.ogc.org/common
Other
45 stars 13 forks source link

New media types vs conneg by profile #8

Open lvdbrink opened 5 years ago

lvdbrink commented 5 years ago

See https://github.com/opengeospatial/D040-Complex_Feature_Handling_Engineering_Report/issues/6

On request of @cmheazel creating this issue in this repo as well.

Upon reading of the finalized report of the testbed 14 work, specifically OGC Testbed-14 Next Generation APIs: Complex Feature Handling Engineering Report, I have a suggestion to make.

Recommendation 7 of the published ER states:

Register media types for encodings to be used in Web APIs. The selection of the data format used in a response must support HTTP content negotiation. This requires that format can be identified using media types that should be registered with IANA. For example, media types should be registered for i3s, 3D Tiles, CityJSON and perhaps also for CityGML.

I wonder if instead of doing this, the new idea developed at W3C for content negotiation by profile might be used - at least for encodings like CityJSON and CityGML.

cmheazel commented 5 years ago

To re-state the issue - can there be an industry standard to fully describe a resource being returned by an HTTP request? That may include the HTTP response encoding, the resource encoding (which may be different from the response packet encoding), the media type (ex. XML), the schema, and the conceptual data model / ontology. Consider feature data passed as the encrypted payload of a digital signature (Base64) which uses a profile of GML (XML, GML, and the profile schema) implementing the NSG Feature Types.

prushforth commented 5 years ago

@cmheazel

can there be an industry standard to fully describe a resource being returned by an HTTP request?

Yes! Per Clemens' response, the standard for this is IANA media types.

That may include the HTTP response encoding, the resource encoding (which may be different from the response packet encoding), the media type (ex. XML), the schema, and the conceptual data model / ontology. Consider feature data passed as the encrypted payload of a digital signature (Base64) which uses a profile of GML (XML, GML, and the profile schema) implementing the NSG Feature Types.

Most of these (e.g. schema, ontology etc) should be communicated by the media type. If there isn't a suitable media type, that's when you may have to invent and register one, if you want it to be an industry standard. Other aspects, like response encoding, have explicit headers that describe how the response is encoded. I'm not sure what you mean by resource encoding.

cmheazel commented 5 years ago

@prushforth Consider the case of Cloud Optimized GeoTIFF. We have a TIFF file with the GeoKeys added and organized so that it can be accessed using HTTP GET Range Requests. I can represent this as a media type, but at what point does this approach become unduly complicated? I would like to bring this topic up in the Hackathon to see what they think.

rob-metalinkage commented 3 years ago

@prushforth IANA media types barely scratch the surface for "describing" resources. They are a useful facet for "full descriptions" but do not provide a flexible or extensible option.

They describe different encoding options only, and there is nothing to stop different representations having the same encoding. The "ontology" cannot be expressed by media type - not for any domain specific use - the media type may have an encoding based on a meta-model that can be expressed as an ontology, but that does not provide a pathway for expressing, for example, alternative Feature Type representations of the same Feature, or even different forms (detailed vs generalised geometries) using the same Feature Type.

joanma747 commented 3 years ago

There are people thinking about this in W3C: It is called negotiation by profile: https://www.w3.org/TR/dx-prof-conneg/ One of the things proposed is a new header Prefer: profile="urn:example:schema"

The need for this has been stablished several times. There is a risk in trying to standardize if now the OGC API way and the the main IT going into another direction. We expect that W3C spec becomes so we cannot do anything to preclude the adoption of W3C solution (or another that becomes available)

cportele commented 3 years ago

If there is interest in OGC to work on this, maybe directly engage with the IETF HTTP API WG (or the W3C DXWG) and standardize it first there and once this done use it in OGC.

Recently a discussion in the IETF HTTP API WG was started: https://mailarchive.ietf.org/arch/msg/httpapi/gNW6BBxaQSsjtKHuTFwTkIld7L8/

joanma747 commented 3 years ago

This is the "first" IETF proposal; very recent https://www.ietf.org/archive/id/draft-svensson-profiled-representations-00.txt

KathiSchleidt commented 3 years ago

This would be of great interest to the O&M group, three contexts come to mind:

We've recently contracted an extension to GeoServer to make this profiling process easier. With this extension, one can create different profiles based on the same source via a simple templating mechanism - would be really nice if there could reference each other! We'll be presenting this functionality at the ELISE Workshop: Smart Data Loader and Templating for GeoServer this Thursday at 14h00 CET (UTC+1).

sgrellet commented 3 years ago

+1 on progressing on that front

The interest goes further than O&M SWG

As a DataProvider, we are more and more working on exposing different representations of the same features such as GeoSciML:BoreholeView (OGC SimpleFeature) for discovery and GeoSciML:Borehole ("real" complex feature model) for in-depth reuse still for the same 'hole in the ground', same URI and same MediaType

ghobona commented 3 years ago

The IETF was planning to discuss Content Negotiation by Profile at their meeting on Monday 2021-03-08 13:00 CET (12:00 UTC).

@larsgsvensson Any feedback from the IETF regarding outcomes of that meeting?

cportele commented 3 years ago

@ghobona - There was some follow-up discussion on the dispatch mailing list. Look at the recent emails, I think the main point of discussion is raised in this email.

ghobona commented 3 years ago

Thanks @cportele .

jerstlouis commented 2 years ago

This was discussed on 2021-09-08 in the Coverages SWG and we were wondering how soon a Content negotiation by profile draft specifications could be approved in the W3C, or how the OGC membership could help make this progress, as it is an issue that keeps coming up across OGC API specifications. @lvdbrink @rob-metalinkage @nicholascar

Until the specification is approved, it is difficult for OGC API specifications to make use of it, and new specific media types based on encoding formats such as JSON or XML must be defined when content negotiation might sometimes be more appropriate.

See also https://github.com/opengeospatial/NamingAuthority/issues/54 https://github.com/opengeospatial/coverage-implementation-schema/issues/19 https://github.com/opengeospatial/ogcapi-coverages/pull/22#issuecomment-814910807

lvdbrink commented 2 years ago

If there is sufficient interest in this, we may be able to progress it to draft standard status via the Spatial Data on the Web working group. It could then be a joint OGC/W3C spec. There is already a stable text, so publishing a working draft should be possible to do this year. Plz contact me to discuss further and schedule a slot for you to present this question to the Spatial Data on the Web working group.

lvdbrink commented 2 years ago

If there is sufficient interest in this, we may be able to progress it to draft standard status via the Spatial Data on the Web working group. It could then be a joint OGC/W3C spec. There is already a stable text, so publishing a working draft should be possible to do this year. Plz contact me to discuss further and schedule a slot for you to present this question to the Spatial Data on the Web working group.

Argh, sorry, I'm going to have to retract this remark. I was thinking of the CRS negotiation draft in this github repository.

The conneg by profile Note is really a W3C document, created by the DXWG, so not something SDW can really help with. The DXWG can be reached via their github repository, it may help for the group to express its interest there.

ghobona commented 1 year ago

@larsgsvensson Is there any update on when Content Negotiation by Profile is likely to be completed?

rob-metalinkage commented 1 year ago

At this stage we have been treading water whilst gaining some implementation experience. There is a plan to re-start the sub-working group now we have a raft of OGC API experiments underway looking at the issues of polymorphism, and some further potential interest from RDF* working group. Being explicit about semantics is something the world has developed a passion for ignoring - so we're neither much further ahead nor faced with competing alternatives, and the spec as is works well for providing at least human readable landing pages for profile options.