From @pomakis ...

I'm looking through the various OGC API specifications trying to make sense of the use of CURIEs (https://www.w3.org/TR/curie/). But I'm seeing a lot of inconsistencies, leaving me bewildered as to how to implement our clients and servers.

My understanding is that a safe CURIE is of the form [{prefix}:{reference}], where {prefix} maps to a {baseURI}, and that the full URI that the CURIE represents is simply {baseURI}{reference}. E.g., for the URI "[EPSG:4326]", the "EPSG" prefix maps to "http://www.opengis.net/def/crs/EPSG/0/", so the full URI it represents is "http://www.opengis.net/def/crs/EPSG/0/3857".

1. Where can I see a list of these CURIE prefix mappings? Presumably these mappings are available through the "OGC CURIE Register" (http://www.opengis.net/def/curie), but how does one actually view this list? The OGC API specifications don't seem to provide any guidance on this matter (other than the occasional example).

2. Sections 7.2.2 and 11.2.1 of the draft "OGC API - Coverages - Part 1: Core" specification (as of 2025-02-04) state:

   NOTE: A CURIE {authority}[-{objectType}]:{id} would map to the following
   OGC URI: http://www.opengis.net/def/{objectType}/{authority}/0/{id}. If
   -{objectType} is missing, the default object type is crs.

This indicates that the following CURIEs (as shown in the latest versions of the "OGC API - Common - Part 2", "OGC API - Coverages - Part 1" and "OGC API - Features - Part 5") specifications)

[ogc-rel:schema]
[ogc-rel:coverage]

map to the following URIs:

http://www.opengis.net/def/rel/ogc/0/schema
http://www.opengis.net/def/rel/ogc/0/coverage

where in fact the proper URIs seem to be:

http://www.opengis.net/def/rel/ogc/1.0/schema
http://www.opengis.net/def/rel/ogc/1.0/coverage

Is this note in the draft "OGC API - Coverages - Part 1: Core" specification bogus? If so, it should be removed and replaced by more general (and correct) guidance on the use of CURIEs.

3. Section 7.11 of the "OGC API - Features - Part 1" specification amd section 7.2.2 of the "OGC API - Coverages - Part 1: Core" specification indicate the following coordinate reference systems:

   http://www.opengis.net/def/crs/OGC/1.3/CRS84
   http://www.opengis.net/def/crs/OGC/0/CRS84h

Are these correct? If so, it's impossible to CURIEize these, since the "OGC" prefix can't map to both "http://www.opengis.net/def/crs/OGC/1.3/" and "http://www.opengis.net/def/crs/OGC/0/". Unless I'm misunderstanding how CURIEs work.

4. Section 5.3 of "OGC API - Features - Part 5" states:

   As an alternative, the Compact URI (CURIE), e.g., [ogc-rel:schema],
   can also be used when a CURIE is an allowed value.

Really? We're requiring OGC API clients to de-CURIE all relation-type URIs while navigating through links? I don't even think that's legal. Section 2,2 of the CURIE specification (https://www.w3.org/TR/curie/) states:

CURIEs and SafeCURIEs map to IRIs, but neither a CURIE nor a
Safe_CURIE is an IRI or URI. Accordingly, CURIEs and Safe_CURIEs
MUST NOT be used as values for attributes or other content that are
specified to contain only URIs, IRIs, URI-references, IRI-references,
etc.

The WebLinks specification (https://www.rfc-editor.org/rfc/rfc8288.txt) states:

Applications that don't wish to register a relation type can use an
extension relation type, which is a URI [RFC3986] that uniquely
identifies the relation type.

This clearly states that extension relation types must be URIs (which CURIEs are not). It goes on to say:

When extension relation types are compared, they MUST be compared as
strings (after converting to URIs if serialised in a different
format) in a case-insensitive fashion, character by character.
Because of this, all-lowercase URIs SHOULD be used for extension
relations.

And this makes sense. Any form of comparison that's more complex than an exact string match would be doomed to failure, since it would put too much of a burden on client implementations and very few would do it right.

And I don't think that the "after converting to URIs if serialised in a different format" clause saves us. These links aren't being serialized in a different format. They're coming right from the standard JSON and XML representations of a web link.