Linksets: Beyond Inline Hypermedia Controls

Hypermedia is based on the assumption that representations contain a mix of data and control information (think HTML's embedded links as the canonical example). Usually, that control information is mixed into or alongside the data, meaning that the producer of the representation (and thus the owner/manager of the resource) has the privilege and the responsibility to add hypermedia controls.

There are many settings, however, where representations of resources and information about possible interactions with them are not necessarily coming from the same (or a single) source. In these cases, going beyond the usual simplistic hypermedia pattern of inextricably mixing data and controls can be an interesting alternative, opening up many new possibilities of how to provide hypermedia information to clients.

This article describes the idea of Linksets, which is not something that is new in hypermedia research or advanced practice, but has seen little usage on the Web so far. To change this, Herbert Van de Sompel and myself are working on "Linkset: A Link Relation Type for Link Sets", which establishes a linkset link relation type. The linkset relationship has the potential to be used in a wide variety of use cases, ranging from the basic ones described in the I-D, to the more elaborate ones explored in this post.

As one example, consider a product resource. The product resource contains information about the product itself, as well as related information and services such as similar products. However, information about payment options is not provided by the product resource itself, and is provided via a linkset instead. This means any client requesting payment options will request payment links from a separate server. This not only decouples product resources from payment management; it also allows the payment options to be more easily customized based on the specifics of the client, meaning that the complete "product and payment options" view is a combination of the product resource (and associated hypermedia controls), and payment links provided by the specialized payment options service.

Essentially, the pattern proposed here establishes Links as a Service (LaaS) for hypermedia: It separates those parts of a resource that are integral to the resource itself, and provides a model how to relate to links that also matter for the resource, but are not an integral part of it. Why is this interesting?

From Inline to Out-of-Line

What linksets do is to move links from inline mechanisms to out-of-line mechanisms. In hypermedia speak this means that links do not have to be embedded in the resources that they are connecting. This can be useful for various reasons:

• Link computation cost: It can be costly to compute links and they might not be needed in most cases. in this case out-of-line links only are requested when required, and computation costs can be minimized.

• Link quantity: It is possible that the volume of links is too high to embed at once, or to embed in a specific way (such as inside an HTTP Link header). In this case, out-of-line links allow to manage the size problem, and can even allow sophisticated interactions with linksets such as paging or query mechanisms.

• Contextual links: While the resource representation may be the same in all cases, it may be the case that links depend on context, such as client identity or access rights. Out-of-line links in this case allow to focus the contextual processing on the links alone, while keeping the resource representation itself context-free.

There are more possible reasons why linksets can be useful, but most importantly they are a design pattern in hypermedia that allows more flexibility. In many cases this design pattern may be unnecessary. But in other cases it might allow better designs than inline links.

In the example given above, the biggest deciding factor might be contextuality. Payment options can be decided on the fly based on client identity and possibly information about their preferences or capabilities. In addition, payment options only need to be provided (possibly saving link computation cost) when the context of product presentation requires it: a linkset link that (in HTML) looks something like <link rel="linkset payment-options" href="..."/> helps clients to selectively request payment options only when required for the application.

Orchestration? Choreography? Does it Matter?

The concept of linksets introduced in the previous section implies that relationships between two resources are described/represented by a third resource (the linkset). In many scenarios, this kind of configuration is described as orchestration, in the sense that for making the two related resources work together, the orchestration provided by the third resource is necessary.

However, it is important to keep in mind that what often is referred to as choreography is also covered by the linkset approach. The reason for this is that linkset discovery is not prescribed or constrained when using hypermedia and linksets. Consider the following two scenarios:

• If a linkset is assumed by an application, then the application assumes that the linkset might/will contain information that provides additional linkage for the resources used by that application. In this case, that looks a lot like orchestration, with the control how to relate resources being the "well-known" linkset.

• If a resource itself links to a linkset (for example through the proposed linkset link relation), then the resource itself decides how to be interlinked with others. In this case, this looks a lot like choreography, with no centralized or authoritative control.

Given these two scenarios, it should become clear that linksets, while simple as a concept, have very interesting implications. The reason for that is that because of hypermedia's approach to represent control flow information. it can be arranged and distributed in a variety of ways.

Linksets in Practice

One motivating example for the current draft is the scenario of archiving. Each sufficiently complex archive has a substantial number of archival-related links associated with each archived resource. One goal is to manage these links out-of-line, so that they can be accessed and traversed only when needed.

While the question of linkset access is important (only access the links if an application is interested in archival information), the question of linkset size may be equally important. If there are too many links associated with a resource to reasonably include all of them in the standard representation of a resource, then factoring them out into a linkset can help to reduce bandwidth requirements (at the cost of adding a roundtrip).

If linksets are factored out as separate resources, the question arises how they are represented. The proposed linkset link relation type only specifies how to find them, but does not say anything about how to interact with them, or how they are represented. There are two possible levels of sophistication:

• Linkset representation: The way how linksets are represented probably should fit into the way in which a scenario is designed. For example, when a scenario is focusing on HTTP Link header fields, it may use the CoRE Link Format, which essentially is a media type for the way how the HTTP Link header field represents links. If a scenario focuses on XML, then XLink may be a useful way to represent links.

• Linkset interaction: For certain scenarios, it might be useful to think of a linkset as a collection of links for more than just one resource. In these scenarios, the linkset in effect is a resource that must be queried to get the set of links that a client is interested in. Querying can be as simple as just specifying the resource that a client is interested in ("Give me all links that have resource X as a source."), or it can be more advanced by allowing filtering and possibly even more advanced features as result paging.

While the questions of representation and interaction must be addressed in practical applications, it is important to keep in min that they are out of scope for the linkset link relation type.

Security Considerations

Finally, it goes without saying that the scenario presented here introduces security issues. If links that are supposed to guide a hypermedia client are supplied by a third party, then this is a possible source of "link hijacking". It is therefore important that in all scenarios using linkset there is some "trust" in the client's relationship with the linkset.

Remember, however, that "trust" is in the eye of the client, not the source resource owner. Based on current events, imagine a linkbase that for each press report issued by a government would link to resources on a variety of fact-checking web sites, putting the press report into a context that may not be in the interest of the government, but in the interested of those critically looking at government's claims.

Apart from the general issue of the more complicated distribution of resources, links, and clients, there are also are various more technical issues about how to use links securely in such a scenario. Here are two examples:

• Prioritization issues: If there is conflicting link information from resources and linksets, is there a specified way how one overrides the other?

• Transitive linksets: Is it possible that a linkset resource itself links to a linkset, creating a "linkset chain"? And if it is possible, how does that affect complexity, the prioritization model, and the way in which clients are supposed to navigate this possibly complex linkset hierarchy?

We are certain that there are more security issues that are relevant, and most likely these will come to light when the linkset model is applied to certain scenarios. We would like to encourage hypermedia and API enthusiasts to think about this "extended hypermedia model", to apply it to their scenarios in some thought experiments, to read the linkset draft, and to join the discussion via GitHub.

Comments

[Nick Lynch]

Hi
Enjoyed your article
We are using Linksets within Life Science research to support identity mapping.
One of my colleagues Alasdair Gray @Herriot Watt has worked on this concept for a while
Equally a group at Maastricht has created BridgeDB which was extended by Uni of Manchester

Might be worth some exploratory discussions on overlap?

Cheers
Nick