You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creating this issue to track discussion and feedback for a new type of auxiliary resource - Configuration - which would be used to store configurable parameters for a given resource (which could also be inherited as part of a resource hierarchy when set on a container).
For example, whether to maintain Mementos for a given resource, or suggestions to the server about how data within a given resource might be indexed.
The rationale for a configuration auxiliary resource type is that a descriptive auxiliary resource is a catch-all to store anything that can annotate the directly associated solid resource, while a configuration auxiliary resource is meant to influence how servers may process the same, and so there may be good reason to have the configuration auxiliary resource be kept separately with stricter permissions than the descriptive auxiliary resource.
The configuration auxiliary resource type was originally included in the auxiliary resource candidate proposal, but was removed during editorial review until more use cases can be presented that justify the storage of configuration parameters in their own auxiliary resource requiring different permissions.
Proposal for clients requesting to create Memento's URI-R and have the server create URI-M, create/update URI-T: #61 (comment) . Essentially include header:
PUT https://csarven.ca/linked-research-decentralised-webLink: <http://mementoweb.org/ns#OriginalResource>; rel="type"
Creating this issue to track discussion and feedback for a new type of auxiliary resource - Configuration - which would be used to store configurable parameters for a given resource (which could also be inherited as part of a resource hierarchy when set on a container).
For example, whether to maintain Mementos for a given resource, or suggestions to the server about how data within a given resource might be indexed.
The rationale for a configuration auxiliary resource type is that a descriptive auxiliary resource is a catch-all to store anything that can annotate the directly associated solid resource, while a configuration auxiliary resource is meant to influence how servers may process the same, and so there may be good reason to have the configuration auxiliary resource be kept separately with stricter permissions than the descriptive auxiliary resource.
The configuration auxiliary resource type was originally included in the auxiliary resource candidate proposal, but was removed during editorial review until more use cases can be presented that justify the storage of configuration parameters in their own auxiliary resource requiring different permissions.
Related issues / comments / conversations:
The text was updated successfully, but these errors were encountered: