Inconsistent CURIEs

[pvretano]

See Issue 975 in Features.

[jerstlouis]

@joanma747 @pomakis can we make this one of the topic of our OGC API - Common session next week at 12:00 PM (noon) Eastern Thursday February 13th?

[joanma747]

CURIEs were invented to save bytes in URL query parameters. If this work this means that clients and servers know how to transform form one to the other. If they know how to do it in one place it is easier from a developer point of view to support both everywhere.
For that reason I recommend to consider them equivalent everywhere: in JSON documents, HTTP headers, rel names, etc.

[jerstlouis]

SWG 2025-07-31: From the Common perspective, CURIEs will be allowed everywhere, which will be consistent with published Standards such as OGC API - Maps where they are allowed for:

• query parameters (such as for crs, bbox-crs...),
• within responses (particularly helps keeping the Custom Projection CRS responses concise: https://docs.ogc.org/is/20-058/20-058.html#_b8f30122-e54f-4bd7-9916-788100c8c88d)
• for link relations in links within JSON response
• in response headers defined by OGC API standards explicitly allowing them (such as OGC API - Maps which allows it for -- but we realized that we did not clearly indicate the need for the angle brackets around the URI or CURIE in the requirement for Content-Crs:, altough the example uses a full URI within angled brackets, and they are required in Features - Part 2: CRS)

To maximize interoperability and in order to conform to OGC API standards not allowing CURIEs in some of these places, servers can avoid returning CURIEs to the client in responses.

@pomaki summarizes well what needs to be consider to convert CURIE to URIs in opengeospatial/ogcapi-features#975 (comment)

While this may appear daunting, some of the difficulties with converting CURIEs to a resolvable RAINBOW URIs could potentially be fixed on the RAINBOW side (e.g., availability of last version URI / using versionless URIs for concepts which should never mean something different, inconsistent cases of /ogc/ vs. /OGC/).

[pvretano]

@jerstlouis @joanma747 sorry but I am not sure that I understand the resolution of this issue? As they stand, CURIEs are not consistent or easily resolvable. This issue was closed. Is that because Common is letting Features resolve the issue OR is this closed because you have actually resolved the issue? ... which based on the comments is not apparent to me. Even if the server chooses NOT to use CURIEs as long as they are kosher as far as OGC is concerned that still compels servers to support them which is currently not possible given @pomakis summary.

I will mention that I think we took CURIEs out of some of the parts of Features. @cportele please confirm.

[jerstlouis]

@pvretano

The situation is that:

• There are published OGC API standards such as OGC API - Maps where CURIEs are explicitly allowed in the places I listed above
• @joanma747 's main point was that if clients are allowed to pass CURIEs as query parameters, such as in the case of output CRS crs parameter, it implies that both the client and server understand how this CURIE maps to a full CRS URI, which the server may use in the list of output CRS (the crs array in the collection description), as the client needs to either convert the full URI to CURIE or validate that the CURIE it intends to request a map with matches one of the supported CRS URIs. Therefore limiting CURIEs to client request query parameters does not avoid the need for having a clear mechanism how to resolve a CURIE to a full URI.
• Yes, there are a number of challenges for clients to resolve/understand CURIEs, as @pomakis summarized. We believe some of these challenges could be addressed at the Naming Authority level as I mentioned above. However, while I agree it's not particularly "easy", I disagree that it's "not possible". At least, anything "not possible" should be addressed at the Naming authority level. Several of the challenges/difficulties listed also have nothing to do with CURIEs themselves: https vs http URIs, /0/ for latest vs. explicit version (even in cases like link relation where a version concept is not helpful), /ogc/ vs. /OGC/ cases for different registers. These challenges are there also with regular URI, so this long list is really making the CURIE-specific aspect of the issue appear worst than it actually is.
• We closed this issue because it was tagged as "Part 2: Geospatial Data", and we reviewed the document and addressed whatever we could related to CURIEs in Part 2, and we want to move Part 2 forward with the OAB review and RFC.
• Since Part 2 is specifically about the /collections and /collections/{collectionId} resources, and we cannot prevent the use of CURIEs there where OGC API standards like OGC API - Maps allow it, there is nothing more we could do here, other than possibly add a recommendation to use them or not in certain places, but since we may not all agree on a particular position, it might be best to avoid such recommendation altogether.
• Particular OGC API standards like Features may decide to allow CURIEs or not in specific places, and as long as no OGC API standards requires servers to return CURIEs, then it should still be possible to conform to Common and have multiple access mechanisms by avoiding them

No one had contributed to the discussion here in Common since you opened it in February, with the discussion taking place in opengeospatial/ogcapi-features#975 instead.

If we want to continue the discussion here in the Common repo, I suggest we either close this issue and transfer the Features one here, or we re-tag this issue Part 1 instead of Part 2, since it's not specific to Part 2. I think a lot of this is a Naming Authority-related discussion.

I should also point out that I find the idea of having "CURIE register" a bad idea. However complex the mechanism to expand a CURIE is, it should be possible to describe it with an algorithm and not require a register, otherwise it seems to completely defeat the purpose.

[rob-metalinkage]

+1

Given a perfectly good standardised way to handle Curies with JSON through inclusion of a reference to a JSON-LD context document, perhaps all that is needed is to identify which JSON artefacts carry this so a client can agree on curie resolution with the server.

Note any well known endpoint could return a context document using content negotiation.

Inline contexts are also possible but are much harder to cache, compare, integrate with other contexts and unit test.

For enhanced interoperability of course contexts could be published as part of FAIR service and data descriptions and reused.

[cportele]

@pvretano ist correct. In the Features API and the JSON-FG SWGs we decided to not support CURIEs in those standards (with the possible exception of API query parameters, such as crs) and have removed them from all drafts. We did this after a longer discussion and the reasons are well documented in the issues about the subject.