Avoid redirecting to awkward /vocprez/object?uri= URLs (only redirect to correct URIs)

[jerstlouis]

http://www.opengis.net/def/rel redirects to
http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/rel

http://www.opengis.net/def/tms redirects to
http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/tms

http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad redirects to
http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad

This makes using the registry, e.g. discovering, sharing, copying URIs extremely cumbersome.

On a related note, it is very confusing that the list of TMS is at:
http://www.opengis.net/def/tms/
but individual TMS are at e.g.
http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad

i.e. as an API, the registry itself should ideally follow the relevant important OGC Web APIs guidelines ;)

[rob-metalinkage]

Redirect is necessary because the same concept has many possible expressions

We are working on making a prominent means to cite the original URI (which is the only thing that should be persisted).

Browsers are a bit broken by not automatically bookmarking the original canonical URI where the redirect code does not explicitly require the new one to be used. (a 303 is not a "moved" - there is a special code for that) - so we have to workaround that ugly reality. (clever ideas - rel="canonical" didnt seem to work either when I had a play - so two potentially viable mechanisms are both broken, and it seems to be up to us to deal with it via user education...)

We are also looking at restructuring the data, this will be a matter of each SWG weighing in to suggest how its defintions should be structured...

[jerstlouis]

@rob-metalinkage returning 200 when requesting the canonical URI is what I am hoping for here, not for alternate expressions of it.

In most cases, alternate expressions should be avoided at all costs because they prevent from being able to do simple string comparisons on URIs.

• TileMatrixSets
• WellKnownScaleSets
• CRSes
• relation types

and many other items registered on the definition server are all checked with simple string comparisons in clients.

Clients should not have to rely on requests to the definition server to resolve them to be usable -- that is impractical as it adds useless server round-trips, reliance on an additional service, and breaks completely for offline use.

[rob-metalinkage]

returning 200 not an option - user must respect:
a) canonical URIs
b) need to offer alternative representations

now there may be a case to try using HTTP 302 found - its semantics are explicitly that the browser should remember the original URI and because of some problem a temporary location is suggested. W3C recommends HTTP 303 - but according to this blog it suggests the new Location should be remembered

https://airbrake.io/blog/http-errors/303-see-other

I'll perform some experiments and bring findings to the OGC Naming Authority meeting.

[jerstlouis]

@rob-metalinkage are you saying returning 200 is not an option even when the request is for the canonical URI?
(that is currently done for CRS, e.g. http://www.opengis.net/def/crs/OGC/0/UnixTime returns a 200 with the XML definition of the CRS)

[rob-metalinkage]

late comment - sorry missed the question - the current CRS behaviour is problematic because it only offers an XML definition.

Redirect allows different subsystems to deliver different forms of resource - such subsystems include simple file systems with pre-prepared or customised files.

[jerstlouis]

@rob-metalinkage But shouldn't this still be possible with a 200 and content negotiation through an Accept: header?
It could still relay the content provided by different subsystems, in the requested representation.

I still feel very strongly that a redirect is wrong for the definition server presenting a canonical URI, because when you check those canonical URIs, ending up somewhere else leads to confusion about which is the actual canonical URI for that resource: the URI originally accessed, or where you end up being re-directed. It also requires setting up a different hosting place for the resources, while the definition server could probably serve that purpose for many use cases, as long as there is a simple mechanisms to keep what is being served up to date (e.g. TileMatrixSets).