status: WIP, expect changes

As a content creator user
I want to be able to author (and store) arbitrary hypermedia,
So that my readers (and collaborators) can freely navigate, interact with (and possibly add to) the data.

As an app developer
I want to provide controls that enable my users to author arbitrary hypermedia and/or to author arbitrary hypermedia on behalf of my users,
So that I can provide other users (same or different app) with views, links, and options to interact with the authored data.

This is not a use-case, but a pattern that spans a family of use-cases that I would describe as knowledge work¹. At the outset, I find the template not suitable for expressing patterns. I find that it is more important to express the concepts involved, rather provide examples that would never be exhaustive. Hence, my reticence in submitting this issue.

I am also certain that I am subsuming aspects covered in use cases already specified. It is not my intention to diminish the importance of specific use cases. Rather, this is an attempt at a broader view of what LWS must enable in order to serve a broad class of problems.

Definitions

For the purposes of this discussion, I shall be sticking to Roy Fielding's definition of hypermedia²:

When I say Hypertext, I mean ...

• The simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions.

Hypermedia defined this way provides data guided controls, which is necessary to implement both non-linear documents and selectable GUI controls to act on documents, the two main features needed for navigating documents on the web.

Use Pattern

Users of the linked web storage might want to (and should be encouraged to) conform to the REST architectural style when creating resources. A key constraint of the REST architectural style is “hypermedia as the engine of application state” (HATEOAS). This constraint, as you are all aware, allows clients to follow their nose starting from just a given resource identifier, without the need to rely on out-of-band knowledge.

Since, the linked web storage allows users to store arbitrary data, it follows that an author wanting to conform to the REST architectural style should also be able to generate/specify links as well as configure (expose/restrict) affordances on resources they create in the process. LWS needs to provide comprehensive and canonical mechanisms with proper guidance on how to create such “self-documenting” hypermedia in a consistent manner.

Caveat: When I say “arbitrary” hypermedia, I do NOT imply that Linked Web Storage cannot impose any restrictions on resources or the user's store (for example, container resources implement a part of LDP specification in Solid protocol). But those restrictions must be principled and limited to allow users to support the broadest class of hypermedia. Having said that, a server with some extension mechanism to allow stores to augment available affordances (say, for example, add pagination to containers) could also be valuable.

No place have these concerns been more conspicuous and contentious than in the case of containers (See solid/specification#69, solid/specification#134, solid/specification#198, solid/specification#525, solid/data-interoperability-panel#225). Currently, Solid does not have a canonical strategy for handling triples written by clients to containers. Solid implementations are inconsistent in their handling of such triples. It is unclear, for example, how links to resources outside the containment hierarchy are to be stored alongside contained resources.

One convention the community has developed is the use of index.ttl files ³. This convention is however undocumented, and they put additional burden on clients having to manage data, that nominally belongs to the container, in another resource. If not handled carefully, it can easily lead to inconsistent state, such as in the form of dangling links (say by deleting a contained resource but not removing associated triples from index.ttl). Having doubled paths also creates ambiguity for readers, which way to proceed.

Preconditions:

That users or their apps can create hypermedia resources on a linked web storage server.

Actors:

• Users (and their applications) that author and engage (navigate, modify etc.) with hypermedia.
• Storage (and Storage Providers) that expose affordances for hypermedia authors.

References:

List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.