404 error for register with ending `/`

[jerstlouis]

Including a / at the end of a URL returns a 404 errors. This makes it difficult to discover things:

http://www.opengis.net/def/rel/

[avillar]

I've applied a hotfix for the rule matcher and trailing /. Is it working as expected now?

[jerstlouis]

Thank you very much for looking into this @avillar

There is still some (big) oddity in terms of differences between:

http://www.opengis.net/def/rel/ and http://www.opengis.net/def/rel and https://www.opengis.net/def/rel/ and https://www.opengis.net/def/rel

The 2nd has a "System Home / Vocabularies / OGC Link Relation Type Register" not in the 1st. The 2nd also has a big "Vocabulary" title instead of "Collection". The 3rd and 4th have a big "Concept" title instead and say "Alias of https://www.opengis.net/def/rel/" instead of "OGC Link Relation Type Register".

The fact that all of these get re-directed to something like "http://defs.opengis.net/vocprez/object?uri=..." is still the one thing that annoys me the most in all of OGC.

If everything re-directed to THE canonical URI (presumably, https://www.opengis.net/def/rel?), it seems to me like it would be easier to guarantee that the correct / same thing is returned for all of these. Perhaps that could be the eventual "proper" fix?

Thanks again!

[ghobona]

When we designed the URI scheme, we intentionally created / suffixes on Collection URIs. This was to distinguish them from ConceptScheme URIs. This is because "skos:Collection is disjoint with each of skos:Concept and skos:ConceptScheme" (Clause 9.4 of SKOS). There is a declared relationship "Equivalent Containing Collection" that links them together.

As for the https URIs, they are simply aliases. They are explained in this closed GitHub Issue.

[jerstlouis]

Thanks for the clarification @ghobona . The distinction makes it somewhat more difficult for users to explore the resource collections with these two different vocabulary (with the list) vs. collection (without the list), especially since with OGC APIs resources ending with / are treated the same as the equivalent resource without a / (or at least do not have any resources ending with /).

As for the aliases, the https may be simply aliases (or the other way around, at least for the new URIs?), but could the user not be re-directed to what they alias to automatically?

For most common practical uses of the definition server, users want to see only two types of pages:

• The list of things ( e.g., http://www.opengis.net/def/rel )
• The thing themselves ( e.g., http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme )

Ending up on the page where the list is not shown ( http://www.opengis.net/def/rel/ ), or an alias that doesn't show the actual thing and you have to follow one more link ( https://www.opengis.net/def/rel/ogc/1.0/tiling-scheme ), just makes the definition server harder to use in my opinionated opinion ;)

...but that's just my 2 cents.

[ghobona]

"could the user not be re-directed to what they alias to automatically?"

The software we are using does not support automatic redirection from one concept to another.

[rob-metalinkage]

Software is fixable.. but probably the nuances around behaviour requirements mean this needs to be tested.

Need someone look into the security implications.

[jerstlouis]

A key thing to keep in mind about the aliases, is that if we ever manage to get the actual definition returned, the intent really is that a GET on the alias returns the same thing as the thing it points to. That is the whole point of having an alias in my opinion.

e.g., GET http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldCRS84Quad should return the same thing as GET https://www.opengis.net/def/tilematrixset/OGC/1.0/WorldCRS84Quad, and that should be the content currently at https://raw.githubusercontent.com/opengeospatial/2D-Tile-Matrix-Set/master/registry/json/WorldCRS84Quad.json with Accept: application/json

[ghobona]

Thanks @jerstlouis . We'll keep that in mind.