href: absolute URI required?

[m-mohr]

The href property requires absolute links through the schema in https://github.com/opengeospatial/ogcapi-records/blob/master/core/openapi/schemas/link.yaml due to the format that is set to uri.

OGC API - Features doesn't have this requirement: https://github.com/opengeospatial/ogcapi-features/blob/master/core/openapi/schemas/link.yaml

Is this intentional? In STAC we allow relative references and it makes a lot of sense especially in non-API contexts. I think changing the format to uri-reference (or even iri-reference as in STAC) would make sense.

[pvretano]

The intent was that it be either an absolute or relative reference. In order to match what Features and Common do, I'll remove the format directive.

[m-mohr]

That would allow everything though, wouldn't uri-reference be better (also in Features and Common)?

[pvretano]

I think we would also want to allow UUIDs as well. No?

[m-mohr]

UUIDs are not valid URIs according to the RFC, I think?

[pvretano]

True but I was thinking about systems that have built-in UUID resolvers ... so that UUID can act as a reference mechanism. Although I support you can use a relative URI for that (e.g. "/uuid:c2423d34-a96b-4200-ac6e-d72410984d48").

I'm OK making it iri-reference but I don't remember why we didn't do that in Features in the first place. Maybe that format wasn't available when Clemens first create features Part 1. I'll have to poke around a bit ... but I will fix this (one way or another) in Records since the intent is to support relative references as well.

[cportele]

The href in a link object can also be a relative reference. The link target is a URI reference in RFC 8288, which is the conceptual basis for the link object.

We could have added format: uri-reference in the schema in Features. I guess that I did not do in the Features Core schemas, because the format hints created all sorts of issues in the validators at the time. In other schemas we have started to use format hints, so we probably should add them where applicable in the 1.1 revision of Features Core.

Note that in some cases we explicitly require a URI, not a reference. For example, in the conformance declaration or for a CRS identifier.

Edited to add: If you want to include a UUID in href, I would use a UUID URN per RFC 4122: urn:uuid:c2423d34-a96b-4200-ac6e-d72410984d48.

[m-mohr]

@cportele @pvretano Any thoughts from this group on iri-reference vs. uri-reference? In STAC we have iri-reference in the schemas, I guess to allow more international usage, but also not overly sure.

[cportele]

@m-mohr - That is a good question. Conceptually a link target is an IRI. However, since most IRIs in links will use HTTP as the protocol and the HTTP protocol requires a URI, not an IRI, the IRI will have to be converted to a URI anyhow before resolving the link. In that sense, one can argue that it is safer to require that a href is a URI reference. Otherwise the software that handles the link will typically have to convert the IRI to a URI first - and must know that its has to convert the string to a URI first. Therefore, I have a preference to restrict the value to a URI reference.

Related to this, RFC 8288 states:

Link contexts and link targets are both Internationalized Resource Identifiers (IRIs) [RFC3987]. However, in the common case, the link context will also be a URI [RFC3986], because many protocols (such as HTTP) do not support dereferencing IRIs. Likewise, the link target will sometimes be converted to a URI (see [RFC3987], Section 3.1) in serialisations that do not support IRIs (such as the Link header field defined in Section 3).

[m-mohr]

Makes sense to me, I feel like STAC should also switch to uri-reference...

[cnreediii]

Hi. Good discussion. Whatever you decide on we will use in CDB 2.1 work for referencing resources such as a 3D model. Would like to stay compatible with API - records etc.

Thanks

[pvretano]

FYI @m-mohr @cportele @cnreediii
I am going to update records to use the "uri-reference" format directive.