CURIE inconsistencies #975
Comments
|
... and more from @pomakis Regarding my second point in my previous comment, I just noticed that section 5.3.3 of the "OGC Name Type Specification - definitions - part 1 – basic name" specification (09-048r6) states: But then in section 6.4 of the same document, it says: The only way this makes sense to me is if OGC CRS URIs can't be CURIEd. That is "[OGC:CRS84]" is an illegal CRS reference. This is a published specification. How do you make sense of this? On Wed, Feb 5, 2025 at 11:51 AM Keith Pomakis <[email protected]> wrote: |
|
@pvretano Probably overdue for a discussion... We're having a special OGC API - Maps / Compliance session today at our usual Thursdays 12:00 PM (noon) Eastern OGC API - Common Session, but perhaps this could be the topic for next week's meeting? Some initial thoughts:
|
|
I now think that servers should always (?) use URIs (so that clients know what to expect) and that CURIEs should basically be restricted to clients using CURIEs in query parameters (or perhaps payload) to simplify constructing the values. So, CURIEs are a convenience for clients and servers have to be able to process both. Servers will have to use URIs for existing building blocks anyhow to be backwards compatible. See also the recent discussions in #632. On the use of CURIEs in links: For an RFC 8288 Weblink (that is, a |
|
@cportele that would certainly seem to simplify matters ... always using URIs I mean... |
|
@jerstlouis sure. I can ask @pomakis to join to discuss. Let me know if it's a confirmed topic for the next maps meeting. |
Indeed, as @jerstlouis has mentioned, the convention is that /0/ is interpreted as "latest version", explained here. OGC-NA has adopted this several years back (around 2016). |
|
@pebau I'm not sure that guidance helps. My/our understanding of CURIEs is that the prefix is supposed to be a character-for-character comparable string that is everything up to the last element of the URI that you are trying to CURRIE. That means that Our confusion on the matter might be less so if we could get a list of OGC CURIE prefixes but so far I have been unable to coax that our of the definition server. |
|
@pvretano I was just reporting the decision by OGC-NA at that time. But personally I see no problem in having 2 paths from a CURIE leading to a single result. |
|
@pebau There are 13 entries in the CURIE register. See https://defs.opengis.net/vocprez/object?uri=http%3A//www.opengis.net/def/curie . |
|
This registry states that "OGC" is an alias of "http://www.opengis.net/def/curie/ogc/1.0/crs/OGC". So what are the CURIEs for the following URIs: And what URIs do the following CURIEs represent: |
|
The |
|
@jerstlouis but the following URIs can: and that, for example, a client application sniffing for an OGC API schema link will need to to recognize, at a minimum, the following relation types as being synonomous?: So much for easy link navigation. |
|
Another question. How does one get the CURIE prefix mappings from the registry? Earlier I stated that "OGC" maps to "http://www.opengis.net/def/curie/ogc/1.0/crs/OGC" because that's what the registry seems to be telling me. But that can't be right. Perhaps I still don't know how to eke this information out of the registry. Knowing what the mappings (or even the suggested mappings) are would really help this conversation. |
Ideally this http://www.opengis.net/def/rel/ogc/1.0/schema would never have existed, since I don't see a point to versioning link relations. But CURIEs always use the "latest" version by using
This /def/curie/ thing is new to me, and it seems to completely defeat the purpose to have URIs specific to curies and goes against the policy saying that:
I believe the note in Coverages:
is correct and is consistent with the CURIE policy.
I would add to these 3 the In an ideal world, clients would only need to check against |
|
Okay, so this is where I think we stand.
do not have a CURIE form, whereas their "latest-version" counterparts (which I've never seen anybody use) do:
including older forms for maximum backward compatibility, e.g.:
Does that sum it up? As an aside, I'd like to point out that according to section 5.3.1 of "OGC Name Type Specification - definitions - part 1 – basic name" (OGC 09-048r6), "CURIEs recorded in the register shall be treated as case sensitive". So it's "OGC", "OGC-crs" and "ogc-rel", in those exact cases. |
@pomakis Yes, that is quite an excellent summary, thank you! Regarding HTTPS URIs, there was a request to move entirely towards https URI during the OGC API - Maps OAB review. Some manual aliases have seen been created in RAINBOW, but I argued that this should be a more systematic equivalence, presenting to users accessing either the HTTP or HTTPS URL with the same web page as opposed to an "alias of" version. The case sensitiveness and the mismatch between OGC-crs and ogc-rel is certainly an oddity which would be nice to iron out. In practice, implementing 4 and 5 can be done in a localized single function accepting a canonical URI string and a URI string to test for a match, with the logic to generate all of the equivalent forms as part of that matching operation. Considering such function can be written once and then shared and re-used everywhere, this burden may not be as extreme as it may seem, and in my opinion, is worth the pain to avoid seeing and typing thousands of long URIs all over the place.
I'm not sure if this is what you have in mind, but I disagree with the notion of a "CURIE registry". This completely defeats the purpose of CURIEs which should be an automatic compact representation of longer canonical URIs. |
|
Regarding "a localized single function accepting a canonical URI string and a URI string to test for a match, with the logic to generate all of the equivalent forms as part of that matching operation": We've been attempting to maintain such a function for many years, and it really has gotten quite complex. I'm willing to bet that there's not a single implementation out there that does this correctly. I suspect most implementations that do it quasi-correctly take something like the following shortcut approach:
This generally works (in fact, I'm thinking of simplifying our code to this), but completely ignores authorities and version numbers, etc., making it not safe from possible futures where such things become relevant in the comparison. And I still say that, with respect to comparing link relation types, any such function violates RFC 8288 (Web Linking). Not only does it state that extension relation types must be URIs (which CURIEs are not), but also that "they MUST be compared as strings [...] in a case-insensitive fashion, character by character" (with the emphasis on "MUST" baked into the RFC). Not passed through some canonization function whose proper implementation can only be eked out by reading a dozen different OGC specifications. I strongly believe that the OGC-defined relation types be exact strings, not a bunch of optional variations. If those exact strings are long-ish URIs like "http://www.opengis.net/def/rel/ogc/1.0/schema", then so be it. Is saving 29 highly-compressible bytes really worth the complication of allowing CURIEs and breaking RFC 8288? As an aside, @cportele wrote "For an RFC 8288 Weblink (that is, a Link HTTP header), [...]". RFC 8288 isn't specifically for Link HTTP headers. It defines a serialization for Link headers, but allows and encourages other serializations. OGC API defines a JSON serialization. Section 6.3 of "OGC API - Common - Part 1: Core" (OGC 19-072) states "OGC Web API Standards use RFC 8288 (Web Linking) to express relationships between resources". This is a general statement, not specific to the HTTP Link header. |
yes. not for machines, but for humans. By way of history, from a WCS.SWG perspective:
My 2 cents. |
Yes, exactly. Brain-parsing and typing long URIs all day long all over JSON documents, standards and engineering reports are a major energy drain (especially if such days are long and many). Crafting and/or validating the proper long form URIs manually is notably made extremely difficult due to the definition server re-directing to other |
|
Sorry for beating this to death, but as an implementer (on both the client and server sides) I'm still lost as to how to properly implement these requirements. Section 7.1.2.1 of "OGC API - Common - Part 2: Geospatial Data" states that the link to the logical schema of the collection is done with the link relation type of "[ogc-rel:schema]". As discussed above, this should be considered a CURIE for "http://www.opengis.net/def/rel/ogc/0/schema", which I guess implies that either of the two forms is acceptable (setting aside the fact that the CURIE version is in violation of RFC 8288). The "OGC API - Coverages - Part 1: Core" specification repeats this, and adds it as a requirement that "each collection must include" such a link. Taking this literally (which an implementer must do), an OGC API server that reports a collection's schema link as: is in violation of the specifications, because it's not of the required relation type. Short of outlawing the use of CURIEs for link relation types, I can only see two resolutions to this. Either:
Am I missing something? |
The intent is that both CURIEs and URIs can be used (Common aims to be compatible with OGC API - Features - Part 1 and all other published OGC API standards). I believe the Conventions section says or should say that the CURIEs map to the equivalent, and wherever the shorter CURIE is used in the rest of the documents to avoid sore eyes, it's a placeholder for the CURIE or the full URI. The conventions sections probably need additional clarifications based on your earlier clarifications, and in critical places near the CURIE-related requirement we should probably add notes and/or explicit mentions of the different possibilities. I think before we agree on a resolution to 1, 2 or somewhere in the middle, in hope of potentially limiting the complexity, I think we should first discuss:
|
|
@jerstlouis asked:
I think non-zero version numbers in link relation types (or indeed any URI) can only reasonably work if: a) There's a different CURIE for each version number (as section 7.3 of the "OGC Features and Geometries JSON - Part 1: Core" specification does). Otherwise there can't be a one-to-one mapping between a CURIE prefix and the URI prefix it represents. and b) Version zero doesn't mean "latest". The concept of "latest" can't work in practice. Hear me out. First, let's assume that version numbers mean something, i.e., that there may be situations where linking to (or conforming to) something with version x may have slightly different semantics than linking to (or conforming to) something with version y. So if a client application sees a URI stating version y, but is only programmed to handle version x of whatever the URI represents, then negotiation fails (or execution degrades into a "cross your fingers and see what happens" situation). But what if a client application sees a URI stating the "latest" version? The latest version according to which software component, with respect to when? When the server was implemented, the "latest" version may have been version x, so that's what the server means when it indicates "latest". But that's useless to the client application that might be aware of a later version or isn't yet aware of the version that the server refers to as "latest". So how, in general, can a version-specific URI be compared with one that simply states "latest"? It can't. So I agree that link relation type URIs should be versionless (or hardcode a /0/ version if it's important to stick to that syntax template), since it avoids all that mess. After all, I can't imagine version numbers being relevant for link relation types. If ever a situation arises in the future where some newer version of a link relation type with different semantics is ever needed, it can be expressed as a different relation type. The situation is not so simple for CRS URIs or conformance class URIs, where version number is more likely to be relevant. (We've already seen an example of this a bunch of years ago when the meaning of EPSG:4326 fractured into separate lat,lon and lon,lat interpretations.) There, a version number in the URI might be relevant and should be taken into consideration by clients. But then, as I stated earlier, a /0/ version meaning "latest" becomes problematic. And the CURIE prefix would need to include the version number. |
This is exactly the point. Given that link relation types are simply a semantic concept, I don't see why they would need version numbers. I would argue the same for a 2DTMSs and DGGRSs which should never change or everything will break. With version numbers, there's also potential confusion as to what that version number represents, which instead of the version of the concept itself, we've already seen:
For URIs of concepts (like 2DTMS) maintained separately from standards (e.g. in a repository) or encodings, the version (if any) should relate only to the concept itself, and ideally, would never change as that will break things (completely new URIs should be created instead). One could argue the same with the CRSs, but historically versions were used and things broke :)
This is why I argue that "concepts" like link relation types or 2DTMS should be versionless and never change. Otherwise, and for other things, we would need the ability to encode version numbers in CURIEs. Is that something for which we could describe a mapping? Here I was just trying to avoid the extra version variation for link relation types primarily, but also hopefully for other things such as 2DTMSs and DGGRSs (which could remain fixed in stone forever and get a brand new |
|
@jerstlouis I'm in full agreement. So how many different working groups do we need to convince of this? |
|
@pomakis Ideally we would simply agree to all meet together in OGC API - Common sessions to discuss and agree or such broad-ranging issues, to avoid having to participate in 20 different meetings. Happy to make it the topic of the week this Thursday 12:00 PM noon Gatineau/Ottawa time if everyone interested in this discussion can make it. I think @pvretano already pinged several OGC API GitHub repo, perhaps we could add a mention of that meeting in those as well? Hopefully @ghobona would also be available to discuss the Naming Authority implications. Given the broad implications, we should probably also make whatever we propose a topic of discussion for the OGC API - Track sessions in Rome (we do have an OGC API - Common session reserved). cc. @joanma747 |
|
I think that a few years ago, the Naming Authority had determined that I agree with the position that @pomakis and @jerstlouis have taken, as it is akin to the IANA approach to media types: e.g. NetCDF does not had separate media types for versions 3 or 4, though that supplementary info/hint can be supplied. (Note: the underlying data structures of NetCDF V3 and V4 are completely different.) |
|
@chris-little regarding netCDF 3 vs. 4, see:
|
|
@jerstlouis but see https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml |
|
@chris-little Yes, I know there's a provisional media type, but that says nothing about netcdf3 vs. 4 profile, while the issue includes discussion about potentially supporting media type parameter to indicate this. |
|
There's a simple way to avoid all this: Don't use CURIEs. I don't see a benefit over URIs, most of it is just for communication between machines anyway. |
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".
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).
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)
map to the following URIs:
where in fact the proper URIs seem to be:
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.
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.
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:
The WebLinks specification (https://www.rfc-editor.org/rfc/rfc8288.txt) states:
This clearly states that extension relation types must be URIs (which CURIEs are not). It goes on to say:
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.
The text was updated successfully, but these errors were encountered: