Auxillary Resources Hypermedia Idea

[kjetilk]

I would like to air some pretty loose ideas around auxillary resources with you all.

It seems to me that auxillary resources come along a small number of dimensions. Dimensions as in orthogonal axes :-)

These dimensions might be things like "Access Control applies", "append-only", "server managed", "life cycle tied to resource", "you need Control to make changes to it", "only owner can read it".

I'd like to entertain the thought of auxiliary resources being defined in terms of hypermedia RDF, i.e. you don't need a spec to define them, all you need is an RDF document that describes the auxiliary resource type in terms of the above dimensions. On the vocab and protocol level, we'd need to specify what these dimensions mean, and how to implement each of them, but not the actual auxiliary resource type. They could be something like

<resource-types/audit-log> a solid:AuxiliaryResourceType ;
  rdfs:label "This is the auxiliary resource type definition for Audit Logs" ;
  aux:typeDefinition aux:append_only, aux:server_managed, aux:owner_readable .

The hardest to make to fit in this scenario seems to be Memento, but perhaps that isn't such a big deal anyway, since that's already specified elsewhere.

This idea needs a lot more work, but I'd like to share it now, since auxiliary resources are high on the agenda.

[csarven]

Is this codifying what I've proposed in the last editors meeting (re specifying the dimensions for auxiliary resources) :) or am I misreading? That was based on the idea that a spec can define an Extension mechanism (or perhaps Profiles in the case of Auxiliary Resources eg. ODRL's Profiles: https://www.w3.org/TR/odrl-model/#profile ). It is within the scope of Variability in Specifications: #138 , https://www.w3.org/TR/spec-variability/#extensibility . FWIW, WAC ED went in that direction eg. how new access modes can be specified.

[csarven]

Key dimensions would be the properties and the objects can vary eg:

aux:mode acl:Append ;
aux:agentClass solid:Owner ;
aux:managedBy solid:server ;
aux:mutable false ;
aux:permanent false ;
aux:createWithAssociatedResource true ;
aux:updateWithAssociatedResource true ;
aux:deleteWithAssociatedResource false ;
aux:uriPersistencePolicy <#persistence-policy> ;
aux:odrlPolicy <#odrl-policy> ;
...

[kjetilk]

Is this codifying what I've proposed in the last editors meeting (re specifying the dimensions for auxiliary resources) :) or am I misreading?

Dunno, my thinking was based on a paper I had at ESWC2012 :-) So, yeah, I agree on an extension mechanism.

[kjetilk]

So, the idea now is that we define the dimensions in #306 and then we return here to define how that will look for the protocol.