ogcapi-features
ogcapi-features copied to clipboard
opengeospatial
Support for CURIEs (compact URIs)
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:conformanceas an alias forhttp://www.opengis.net/def/rel/ogc/0/conformanceepsg:4326as an alias forhttp://www.opengis.net/def/crs/EPSG/0/4326ogc:CRS84has an alias forhttp://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.
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.
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 https://github.com/opengeospatial/ogcapi-maps/issues/15#issuecomment-1310588773 .
"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.
@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}].
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.
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
@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.
@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.
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.
@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.
@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.