Dimensions of Auxiliary Resource Types

In the interest of resolving #177 , which is a prioritized issue, I read through many of the open issues labelled auxiliary resources. I may still have missed something. As @csarven notes, we need different relation types for different auxiliary resource types, otherwise, a client would not know what to get. In #172 , @justinwb suggested a few types. However, I have been looking for commonalities, and I think we'd resolve many issues if we took a more general approach. I think that "server managed" is one of several dimensions that auxiliary resources can map to, rather than a type in its own right. If we identify the dimensions that can be used to build auxiliary resource types, then we can in using hypermedia ( #270 ), define types in terms of those dimensions.

The four dimensions that I have identify so far are whether an auxiliary resource

• is tied to the lifecycle of its resource (LC).
• has its own access control, or uses its parent's access control (AC).
• is server managed (SM)
• can timeshift (e.g. Memento) (TS)

As we define the Link relation, the type URI itself should resolve to a definition based on these dimensions as well as other data.

Start by reading issues #177, #172, and #270, then review the existing Link relation discussion. Define the common dimensions for auxiliary resources—lifecycle, access control, server management, and timeshifting—and determine how type URIs should resolve to definitions. Done means the proposed model is agreed and documented clearly enough to guide relation types.