This document introduces an ontology for links and forms, the main hypermedia
controls in use on the Web. This ontology offers, among others, a means to reify
RDF statements interpreted as links between Web resources. It also provides
a versatile exchange format for links and forms in RESTful Web applications.
Hypermedia controls are of importance in the fields of the Web of Things and
the Embedded Web, in particular in the W3C Thing Description model and the IETF
Constrained RESTful Application Language.
Validation of the document by the Working Group is expected by the end of June 2019.
The concept of Representational State Transfer (REST) [[rest]] is at the core of most modern
Web applications. The state of a Web resources, exposed via a collection of Web
resources, can be browsed by clients by following links and acted upon by submitting
forms to servers.
Links and forms have always be present in Web technologies, including HTML [[html]]. Web
linking [[rfc8288]] is a fundamental principle of the Web architecture that can be leveraged to
drive applications, e.g. when a server returns a link to a newly created resource as the
result of a client's request. Conversely, forms, are request templates that servers can expose
to clients for them to fill in with client-specific information and send back to servers.
Forms are similar in spirit to operation desriptions as defined by the Open API Specification
[[openapis]] or by the Hydra RDF vocabulary [[hydra]].
Links and forms are generically referred to as hypermedia controls. They are
of increasing importance in the fields of the Web of Things and the Embedded Web,
which respectively led to the standardization of the Thing Description (TD) model
[[wot-thing-description]] and the Constrained RESTful Application Language (CoRAL)
[[coral]]. The present hypermedia controls ontology is an attempt to formalize the
concepts these two standards specify.
A form can be viewed as a statement of "To perform an operation type operation on form context, make a request method request to submission target" where the optional form fields may further describe the required request. In Thing Descriptions, the form context is the surrounding Object, such as Properties, Actions, and Events or the Thing itself for meta-interactions.
This optional term can be used if additional expected responses
are possible, e.g. for error reporting. Each additional response needs to be
distinguished from others in some way (for example, by specifying
a protocol-specific response code), and may also have its own data schema.
This optional term can be used to define a data schema for
an additional response if it differs from the default
output data schema.
Rather than a DataSchema object, the
name of a previous definition given in a
schemaDefinitions map must be used.
By default, the context, or anchor, of a link conveyed in the Link header field is the URL of the representation it is associated with, as defined in RFC7231, Section 22.214.171.124, and is serialized as a URI.
This optional term can be used if, e.g., the output communication metadata differ from input metadata (e.g., output contentType differ from the
input contentType). The response name contains metadata that is only valid for the reponse messages.
Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Examples of content coding include "gzip", "deflate", etc.
Indicates the exact mechanism by which an interaction will be accomplished for a given protocol when there are multiple options.
For example, for HTTP and Events, it indicates which of several available mechanisms should be used for asynchronous notifications such as long polling, websub (also see https://www.w3.org/TR/websub/), or server sent events (also see https://www.w3.org/TR/eventsource/). Please note that there is no restriction on the sub-protocol selection and other mechanisms can also be announced by this subprotocol term.
The following table gives alignment between the hypermedia controls
ontology and Hydra,
an alternative vocabulary for hypermedia-driven Web APIs. Each row
represents a close match between two classes. These alignments are
not to be understood as formal semantic equivalences but rather as
hints to Hydra users.
JSON Representation of Links & Forms
Same terms as specified by JSON hyper-schema and the TD model.
OCF example (equivalent to an OpenAPI definition). HTTP in RDF vocabulary.
Either as RDF statements or as reified statements. Primarily for WoT compatibility but also e.g. to include validity metadata.