Usability issues with http / https register

[jerstlouis]

This https URL:

https://www.opengis.net/def/interpolation/OGC/0/

(from #260 )

is broken in at least 2 ways:

• it redirects to an http URI
• it results in an Input Error

wget https://www.opengis.net/def/interpolation/OGC/0/
--2024-12-11 11:51:29--  https://www.opengis.net/def/interpolation/OGC/0/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving www.opengis.net (www.opengis.net)... 66.244.86.70
Connecting to www.opengis.net (www.opengis.net)|66.244.86.70|:443... connected.
HTTP request sent, awaiting response... 303 See Other
Location: http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/interpolation/OGC/0/&_mediatype=text/turtle [following]
--2024-12-11 11:51:30--  http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/interpolation/OGC/0/&_mediatype=text/turtle
Resolving defs.opengis.net (defs.opengis.net)... 66.244.86.71
Connecting to defs.opengis.net (defs.opengis.net)|66.244.86.71|:80... connected.
HTTP request sent, awaiting response... 400 BAD REQUEST
2024-12-11 11:51:30 ERROR 400: BAD REQUEST.

Shouldn't /0 always resolve to the latest?

https://www.opengis.net/def/interpolation/OGC/1/

is also broken on Chrome.

It redirects to:

http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/interpolation/OGC/1/

also with wget:

wget https://www.opengis.net/def/interpolation/OGC/1/
--2024-12-11 12:42:50--  https://www.opengis.net/def/interpolation/OGC/1/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving www.opengis.net (www.opengis.net)... 66.244.86.70
Connecting to www.opengis.net (www.opengis.net)|66.244.86.70|:443... connected.
HTTP request sent, awaiting response... 303 See Other
Location: http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/interpolation/OGC/1/&_mediatype=text/turtle [following]
--2024-12-11 12:42:50--  http://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/interpolation/OGC/1/&_mediatype=text/turtle
Resolving defs.opengis.net (defs.opengis.net)... 66.244.86.71
Connecting to defs.opengis.net (defs.opengis.net)|66.244.86.71|:80... connected.
HTTP request sent, awaiting response... 400 BAD REQUEST
2024-12-11 12:42:50 ERROR 400: BAD REQUEST.

when it should probably redirect instead to:

https://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/interpolation/OGC/1/

I still believe that the concept of "alias register" for http / https in the definition server is causing all kinds of usability troubles (e.g. landing on a completely different web page for each, and even different page using different browsers for the same URI), and simply treating https / http URIs as equivalent for the purpose of lookups would make everything work significantly better.

The redirects to /vocprez changing URIs entered in the browser address bar still contribute to extremely painful user experience with the definition server (#85 #109), especially when combined with and trying to understand such problems.

[rob-metalinkage]

"when it should probably redirect instead to:

https://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/interpolation/OGC/1/"

I believe this is correct - @kstegemoller can you fix the top level redirects - I think this is done there from memory and from what I can tell looking at the defs server config. @avillar please confirm.

IMHO we probably need a Naming Authority action to define functionality tests. I am planning to revisit the redirection and content negotiation infrastructure next year when I can sit down with @avillar and explore simplifications possible now we have more extensive github automations available.

[avillar]

There's two things at play here:

1. I'm pretty sure the https -> http redirection is done by Django (uriredirect?). I can definitely see the request to https://www.opengis.net/def/interpolation/OGC/0/ being handled by the Django instance in the logs. So unless I'm mistaken it's a matter of configuring the URI redirects to use the https VocPrez for visualization.

2. Nonexistent resources will result in a 400 or 500 error from VocPrez (this is something that we'll fix in the upcoming RAINBOW version). https://www.opengis.net/def/interpolation/OGC/0/ doesn't exist (checked against triplestore), and neither do http://www.opengis.net/def/interpolation/OGC/0/ or https://www.opengis.net/def/interpolation/OGC/1/. The only one that contains any data is http://www.opengis.net/def/interpolation/OGC/1 (which has no https alias!).

[ghobona]

There is no resource registered at https://www.opengis.net/def/interpolation/OGC/0/ . We could not find a standard that uses that URI. Please let us know if you know of one.

There is, however, a resource registered at http://www.opengis.net/def/interpolation/OGC/1/ . This URI is originally from the WCS Interpolation Extension standard (OGC 12-049).

[jerstlouis]

Thanks @ghobona

Shouldn't /0/ always refer to the latest available version, or be used for identifiers where a version is not applicable? New concepts being defined should probably just be added to /0/ as opposed to changing all URIs everytime we want to add a new concept. ( https://docs.ogc.org/pol/09-048r6.html#toc13 #143 )

Whereas it might sense to have versioned standards, most conceptual registers should not be versioned I think.

e.g., QUDT definitions like https://qudt.org/vocab/quantitykind/AtmosphericPressure have no "versions".

CRS84 for example resolves at both:

https://www.opengis.net/def/crs/OGC/1.3/CRS84

https://www.opengis.net/def/crs/OGC/0/CRS84

with identical definition except for the URI (presumably they are the same entity -- or they should be).

[pebau]

There is, however, a resource registered at http://www.opengis.net/def/interpolation/OGC/1/ . This URI is originally from the WCS Interpolation Extension standard (OGC 12-049).

FWIW, the WCS Interpolation extension does not have any particular requirements on such URIs, in particular it does not normatively require that path. It was just an example based on the recommendation by OGC people at that time.

Bottom line, from a WCS perspective it can be tweaked if necessary.