dr-shorthair
commented
4 years ago You are correct that there is almost no precedent for an item to be registered in the IANA link register which is not described in either a IETF or W3C standard. However, you will see that there is a set of 15 relations concerning temporal intervals that are derived from an OGC document - OWL-Time which of course is also a W3C standard. We missed a trick when we generated the published version, as we did not remember to put an IANA considerations clause. This clause does appear, however, in a revision which is available as an Editors Draft which was generated in September - see https://github.com/w3c/sdw/pull/1138.
I will now push to get the revision issued as a replacement of the original.
All just FYI for this issue, but a reminder that OGC has (slightly indirectly) been involved with IANA registrations in the past.
ghobona
OAB Issue 1436
In OGC API Features we have re-used existing link relation types where we have found a match, but for three types we did not find a match and defined new ones ("conformance", "items" and "data").
See OGC API - Features - Part 1: Core, 5.2. Link relations.
Since we now have a published spec, which is a pre-requisite for getting something into the IANA registry, I have discussed these types with the gatekeepers of the registry.
The feedback was that the terms are defined for specific applications but at the same time use very generic terms. They avoid including such terms, even if the definition is broad and not specific to the application context as "people tend to assume that being defined as part of a narrow specification (like OGC) restricts them to that use".
Fair enough. Based on the discussion, it looks as if there are three ways forward for link relation types in OGC API:
We define the additional link relation types not as part of the OGC API standards, but in a general spec that gets reviewed by the wider Web community (IETF RFC, W3C Rec).
We use terms for "our" additional link relation types that put them in the specific application context (e.g. "ogc-conformance", etc.).
We continue to use generic terms and do not register them with IANA.
As you may guess, I am firmly against the third option, but I have still added it for completeness. Since OGC API is trying to integrate spatial data better into the rest of the Web and inventing our own hidden universe of link relation types would be counterproductive to that goal.
So, it would be good to have a discussion about the direction that we want to take with link relation types in OGC API in general. This is why I have created this as an issue here [in OGC API Common] and not in OGC API Features.
The first option would be harder and more work than the second option. On the other hand, more general terms may be more useful in general and might see reuse in other applications outside of OGC API, too. This would help to make our links more understandable to others (without reading our specs).
There could also be a mix. That is, define link relation types that we think are of general use in an IETF/W3C spec and use a consistent OGC-specific naming strategy for others and continue to define those in the OGC API standards.