Access Mode Extensions

[csarven]

The ACL ontology ( http://www.w3.org/ns/auth/acl ) defines acl:Read, acl:Write, acl:Append, and acl:Control access modes.

This is a general issue, a study, to document common operations and new access modes (based on use cases).

[csarven]

Documentation of operations and access modes from discussions.

• Write (class of write operations - acl:Write)

  • Append (to add information to resource state - acl:Append)
  • Create (to create resource)
  • Delete (to delete resource)
  • Replace (to replace resource state)
  • Update (to modify resource state)

• Read (class of read operations - acl:Read)

  • List (to read an index or pagination)
  • Query (to read processed information)

• Control (class of control operations - acl:Control)

  • ControlRead (to read an access control resource)

[csarven]

The WIP table here can be used to get a deeper understanding of operations and access modes. Operations may be determined by the nature of an HTTP request but they are not strictly limited to HTTP requests.

For the time being, the table uses CRUD terms for simplicity and the purpose of this discussion - do not bother to nitpick on this. Happy to switch to use a different variation, RFC terms, or introduce 50 very specific terms. WAC ED loosely uses CRUD terms for common operations but it is not fixed to that.

• Important to not conflate resource-level e.g. create or delete resource, and content-level operations, e.g. add or remove information.
• A request may entail one or more operations, including a processing operation depending on target resource that breaks down to specific operations on one or more resources.

I'm not sure what to do with this table yet / where to put it but we can figure something out alongside solid/specification#14 (comment) (even if it just serves to catch bugs or our assumptions).

Request	Operation	Access Modes	Level
GET /C/R	Read	acl:Read	Resource
HEAD /C/R	Read	acl:Read	Resource
OPTIONS /C/R	Read	acl:Read	Resource
POST /C/	Create + Update	acl:Append [1]	Resource, Content
PUT /C/R + If-None-Match	Create, Read	acl:Write, acl:Read [2]	Resource
PATCH /C/R + If-None-Match + INSERT	Create, Read	acl:Write, acl:Read [2]	Resource, Content
POST /C/R	Update	acl:Append (or acl:Write)	Content
PUT /C/R	Create?, Update	acl:Write [2][3]	Resource
PATCH /C/R + INSERT	Create?, Update	acl:Write [2][3]	Resource?, Content
PATCH /C/R + DELETE + INSERT	Create?, Read, Update	acl:Write, acl:Read [2][3]	Resource?, Content [4]
PATCH /C/R + DELETE	Update, Read	acl:Write, acl:Read	Content
DELETE /C/	Delete	acl:Write, acl:Read	Resource
DELETE /C/R	Delete	acl:Write [5]	Resource

[1] POST /C/ is to "perform resource-specific processing on the request payload" (RFC 7231). The semantics in Solid Protocol: server-assigned name for resource to be created as member of container, and to update containment statements. So, Create operation of /C/R and an Update operation on /C/.

[2] Requires Append (or Write) on /C/ and Write on /C/R to Create.

[3] Requires Write on /C/R to Update.

[4] PATCH /C/R + DELETE + INSERT could be interpreted as a specific content-level update (or modify) operation where DELETE s1p1o1 and INSERT s1p1o2 - I don't know what the practice/terminology is out there for this. We can come back to this later.

[5] Requires Write on /C/ and /C/R.

[bblfish]

Very helpful. Just a reminder that there is simple easy to understand argument to remove the Control Mode, with more logical/mathematical arguments to support that in Specification issue #303.

Also, it should be possible to model your table using mathematical work on Lenses, to get at precisely why the different modes exist, and how they interact with the HTTP methods.