Support for CURIEs (compact URIs)

[cportele]

The OGC Naming Authority assigns URIs to resources that are registered (like coordinate reference systems, link relation types, etc.). During the September 2021 OGC Member Meeting the OGC Naming Authority has decided to allow the use of CURIEs to allow for shorter URIs with the following conventions (see the comments starting with this comment):

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.

That is, we could use, for example,

• ogc-rel:conformance as an alias for http://www.opengis.net/def/rel/ogc/0/conformance
• epsg:4326 as an alias for http://www.opengis.net/def/crs/EPSG/0/4326
• ogc:CRS84h as an alias for http://www.opengis.net/def/crs/OGC/0/CRS84h

We should consider to allow the use of these CURIEs for CRS URIs (at least in the query parameters "crs", "bbox-crs" and "filter-crs", but maybe also in the "crs" and "storageCrs" members in the Collection resource) and OGC link relation type URIs ("rel" member in Link objects, with a default for "ogc-rel" as the prefix). At least for "rel" the CURIEs should be safe CURIEs (in square brackets) to avoid ambiguous cases, because "rel" values are often not URIs.

This would affect parts 1, 2 and 3 and will require an update to the schema for the relevant building blocks. In case of parts 1 and 2, this will require a version 1.1. It might also be an option to just add normative statements in an additional requirements class that allow the CURIE values in specific building blocks.

As an aside, there is an open issue that not all resources have a OGC URI with version "0" (e.g. CRS84). The OGC Naming Authority is still looking into how to address this in a consistent way.

[pvretano]

@cportele big +1 for this ... long URIs as the value of rel are a pain!

[cportele]

Meeting 2021-10-25: We want to introduce support, but it would make sense to introduce it to Parts 1 to 3 at the same time. Revisit once we have completed the Part 3 v1.0 release candidate.

[jerstlouis]

Thoughts about requiring the use of [ ] around them for safe CURIEs in CRS or not?
The policy states:

5.3.2. Use of Safe CURIEs
OGC Standards should only allow safe CURIEs, unless support for other forms of CURIEs is inherited from another standard (e.g. GeoSPARQL inherits its support of CURIEs from SPARQL). Safe CURIEs are specified in square brackets. For example, the safe CURIE [EPSG:3857] may be used in an API request such as : https://example.org/foo/collections/bar/items?crs=[EPSG:3857]

It says should.

It seems to me that where there is no potential misinterpretation (e.g., for CRSes), the [ ] should not be required...

Related to opengeospatial/ogcapi-maps#15 (comment) .

[cportele]

"EPSG:3857" matches the URI ABNF with a URI scheme "epsg". If I remember correctly, registering that URI scheme with IANA was an idea when srsName="EPSG:3857" was used in early versions of GML, but the registration never happened.

Maybe one can argue that as long as there is no registered "epsg" URI scheme there is no ambiguity, but generic URI parsers may still interpret this as a URI and you never know, if someone registers the "epsg" URI scheme for some purpose in the future. There are quite a few schemes registered and new ones are added all the time: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml.

[jerstlouis]

@cportele Thanks for pointing this out.

My thinking is that the specifications themselves would avoid any potential ambiguity by specifying that a CURIE {authority}:{id} where a CRS is expected as a query parameters or in OGC API schemas, would first be resolved to http://www.opengis.net/def/crs/{authority}/0/{id}, regardless of whether a new URI scheme matching this is defined.

Either way, if a matching URI scheme is defined, it would either be:

• equivalent (e.g., EPSG:, with the the same definitions that the OGC /def/crs/{authority}/0/{id} refer to),
• something that has nothing to do with CRS (therefore not an issue as it would never be used in this context), or
• an extremely unlikely very bad decision (e.g., another authority registering an EPSG: scheme with conflicting CRS definitions.

But I guess your concern is more for the generic URI parser that is not aware of the specifications? Personally, I feel that this unlikely potential ambiguity for OGC-unaware clients is less problematic than forcing the full implementations of the OGC API specifications to use safe CURIEs wihin [ ] everywhere.

If an OGC API client requests an {authority}:{crsID} and that is ambigous with [{authority}:{crsID}], it probably really intends [{authority}:{crsID}].

[cportele]

The OGC policy that CRSs and other resources are identified by a URI is unchanged. The idea in the OGC-NA discussions was simply to allow CURIEs in some places (which OGC controls) as a shorter representation of a URI as well. Of course, we need to disambiguate, which is provided - URI or CURIE.

This disambiguation should be really simple and not require complex rules (including resolving a URI to check if the response is a 404). Using a safe CURIE seems to be the easiest way. Which is what everyone agreed when the updated OGC-NA policies were discussed. If you want to change the policy again, I suggest to open a new OGC-NA issue.

It is also not clear to me, why the square brackets are such a problem.

[jampukka]

Has there been any discussions on whether support for these should be added as a separate conformance class or by releasing new version of existing conf classes? e.g. with features-1/1.1/conf/core

[cportele]

@jampukka - The idea so far is versions 1.1 (see the milestone associated with the issue). In my view, it would be much clearer to update parts 1 to 3, because this requires small changes in a number of places, than to have another part that makes small amendments to many sections in parts 1 to 3.

[jerstlouis]

@cportele

If you want to change the policy again, I suggest to open a new OGC-NA issue.

The policy says should, so I'm not sure to what extent this is binding for OGC API specifications to require safe CURIEs.
We'll probably discuss this next week in Maps and see what others think, and whether we should raise the issue in OGC-NA again.

It is also not clear to me, why the square brackets are such a problem.

I think it is a matter of how the requirements are worded in terms of the expected behavior of the server when clients do not use a safe CURIE, similar to the lower/upper casing issue.
The WxS specifications allow e.g. crs=EPSG:4326, when manually testing URLs it is two more characters to type, so inevitably clients will make requests without them.

If a permission allows the server to interpret unsafe CURIE as what they are likely intended to be, even if the requirements is only for servers to interpret safe CURIEs, then it is not such a big problem.

[nmtoken]

From https://www.w3.org/TR/curie/#P_curie

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,...

Seems to conflict with

The OGC policy that CRSs and other resources are identified by a URI is unchanged.

[cportele]

@jerstlouis

If a permission allows the server to interpret unsafe CURIE as what they are likely intended to be, even if the requirements is only for servers to interpret safe CURIEs, then it is not such a big problem.

For me that would work. Servers can be tolerant, but don't have to.

The WxS specifications allow e.g. crs=EPSG:4326, when manually testing URLs it is two more characters to type, so inevitably clients will make requests without them.

Unless I am mistaken, WMS is the only WxS standard for which this is the case (because it is so old and predates some OGC policies). For example, in WFS a CRS was always identified by a URI.

[cportele]

@nmtoken

Seems to conflict with...

Where is the conflict?

To allow CURIEs in addition to URIs in certain resources or query parameters, we need to update their schemas to allow both a URI or a CURIE in a revision. Which is why I wrote above (emphasis added):

The idea in the OGC-NA discussions was simply to allow CURIEs in some places (which OGC controls) as a shorter representation of a URI as well.

So, we can allow the use of CURIEs in the "crs" query parameter or in the "rel" attribute of a Link object. But in an HTTP "Link" header, the "rel" will always have to be a URI.

[m-mohr]

My question is: Do 1.1 servers then deliver links with both CURIE and long URL as relation type at the same time? If not, wouldn't the introduction of a CURIE require a 2.0 release? It seems rather breaking to me to allow additional variants for relation types. Many (client) implementations right now don't support CURIEs and once an 1.1 implementation would only empraces CURIEs for example, the clients would be completely broken.

I feel like STAC (API) would also "forever" stick to OAF 1.0 and not upgrade to 1.1 until STAC (API) 2.0 due to the vast number of required changes in the ecosystem (there are much more clients than servers).

Disclaimer: I don't like CURIEs at all. In my opinion they don't simplify anything, they just make things more complex for everyone. Ideally they would go away.

[cportele]

@m-mohr

Servers implementing 1.1 will need to continue to provide the URI. Otherwise it would be a breaking change as you point out. You have a point that providing URI and CURIE does not really add any value.

The main driver for using CURIEs was from simpler query parameter values (e.g. in the crs parameter). Maybe we should restrict CURIEs to those and in content stick to URIs?

[jerstlouis]

We've allowed / used CURIEs in content in other OGC APIs approved / soon to be approved (Maps, DGGS).
It allows for shorter example content response, and also normative and informative text can use the shorter CURIE form.

[cportele]

@jerstlouis - That works in building blocks in v1.0, but not in v1.x building blocks that are consumed by clients. Building blocks where the content is only processed by the server, like query parameters, can also support CURIEs in a v1.x.

[m-mohr]

The main point is: Only allow one option, not two. If a spec uses CURIE, only use CURIE. If a spec uses full URIs, only use those (or short IANA registered ones). Having two options and providing them both makes the content LONGER, not shorter.