Provide HTTP link headers

[zozlak]

The HTTP protocol defines the Link response header allowing linking to related URIs.

The full list of registered link types is available on the https://www.iana.org/assignments/link-relations/link-relations.xhtml.

A quick list of to-be-implemented candidates:

• prev and next (HTML) for linking to a to-be-introduced schema.next (arche-schema v4 introduced acdh:hasNextItem)
• up (registered on a personal request and does not relate to any existing protocol) or collection (RFC6753) for linking to a schema.parent
• describedby (POWDER) for linking to a binary resource metadata
• about (RFC6903) or describes (RFC6892) for linking to the binary resource from its metadata
• alternate (HTML) for redirecting to the resolver listing available dissemination formats
• cite-as (RFC8574) for providing an identifier desired for use in citing (requires additional config property providing the preferred id namespace)
• latest-version, predecessor-version, successor-version (RFC5829) derived from schema.isNewVersionOf for linking to another versions of a resource
• license (RFC4946 - an ATOM extension) for linking to the license (would require adding a schema.license config property)

See also https://signposting.org/patterns/ where some convention is already proposed.

This could be implemented in to ways:

• By hardcoding the possible list of link types which are provided if a required mapping is defined by the metadata schema (and, obviously, a processed resource)
• By creating a separate module generating the link headers based on the provided configuration. All in all it looks like there are only a few scenarios to handle:
  • simple mapping of a given metadata property to a link header type, e.g. up/collection; possibly with a regex-based filter and replace on metadata values, e.g.cite-as, describedby, about; maybe with an additional single hop support (license)
  • bidirectional links on a given metadata property which requires two link types to be defined (for forward and backward match), e.g. prev/next and predecessor-version/successor-version