acp:apply* relations are confusing

[bblfish]

I am having difficulty understanding the role of acp:apply, acp:applyMembers, acp:applyMembersProtected.
These all appear in the ACR document. Are they really needed?

Theoretically confusing

In programming terms we find the notion of application when applying arguments to a function. Functions are known in Category Theory as exponential objects, and the apply function is also known as eval. These exist in Categories like Set where objects are Set and morphisms are functions, but not it seems in Rel the category where objects are sets and morphisms are relations, which best models RDF. As we are here working with relations, this concept does not apply, so to speak. So I am not sure what work it is doing...

Is it needed, pragmatically?

We find in the use cases document the following example right at the top:

<>
  acp:access :podControl ;
  acp:accessMembers :podControl .

<#myPodAccess>
  a acp:AccessControl ;
  acp:applyConstant :podControl ;
  acp:applyMembersConstant :podControl .

But I don't really see why the first two statements would not be enough, explicity:

<>
  acp:access :podControl ;
  acp:accessMembers :podControl .

See for example issue 128 and my comment on adapting the ontology.

Two levels of Access Control: Object and Meta?

It seems that what is going on, is that the role of the apply* statements is really to set the access control rules on the propagated statements. So we seem to have two levels of access control rules.

1. Access Control Statements for the resource
2. Access Control Statements for the access controlled statements themselves

I think one should make this distinction clear in the doc and ontology - reworking it somewhat - as it is quite confusing currently, as ACP is mixing the object level and the meta level.

If that is the right diagnosis, we could brainstorm to see if there are clearer ways of doing things.

[bblfish]

First I am not sure why there needs to be applyMembersLocked in addition to applyMembersProtected. The applyMembersLocked is a special case for the root container, why not special case for each of the levels? What is special about root?

If we are left with applyMembersProtected then the distinction is very simple and one could just add to any container where the access rules are locked by the container ACR file something as simple as:

<>
  acp:access :podControl ;
  acp:accessMembersProtected :podControl .

Ie we don't seem to need more than 3 acp:access* relations:

• acp:access for constraints limited to any ACR
• acp:accessMembers for constraints that get inherited by children, but can be modified by those
• acp:accessMembersProtected for constraints that get inherited by all children but can never be altered without changing the ACR in which that statement appears.

[bblfish]

Another way to think of the relation is that acp:accessMembers is really about adding Access Control Statements to an ACR on creation. Whereas acp:accessMembersProtected is about affirming the existence of certain Access Control Statements in all documents related transitively by the ldp:contains relation to the container for that ACR in which appears, at that time.
The first acp:accessMembers makes a statement about what is there on creation, the other about what appears now.

[bblfish]

Ok, so on looking at the definition of acp:access in the current ontology carefully again, I see that

acp:access a rdf:Property ;
    rdfs:label "access"@en ;
    rdfs:comment "The access property identifies the access policies that apply to the ACR itself."@en ;
    rdfs:range acp:Policy ;
    rdfs:isDefinedBy acp: .

where the key phrase is that apply to the ACR itself .

This means that my suggestion that acp:access is equivalent to my proposed wac:authorizes is incorrect.

Because acp:access relates the document it is meant to protect to the acp:Policy/acl:Authorization I suggest we have

acp:access owl:inverseOf wac:accessTo .

[emmettownsend]

It seems I'm late getting to this an you have potentially come to the answer yourself.
I'll try to add some clarity here just in case.

acp:access
Specifies the policies that protect the ACR
acp:accessMembers (only relevant on an ACR for a container C)
Specifies the policies that are propagated to acp:access and acp:accessMembers in the ACR for children of the associated container C.

acp:accessProtected
Specifies the policies that determine the ability to create statement using acp:applyProtected and acp:applyMembersProtected
acp:accessMembersProtected (only relevant on an ACR for a container C)
Specifies the policies that are propagated to acp:accessProtected and acp:accessMembersProtected in the ACR for children of the associated container C.

acp:accessLocked
Specifies the policies that determine the ability to create statement using acp:applyLocked and acp:applyMembersLocked
acp:accessMembersLocked (only relevant on an ACR for a container C)
Specifies the policies that are propagated to acp:accessLocked and acp:accessMembersLocked in the ACR for children of the associated container C.

acp:apply
Specifies the policies that protect the resource
acp:applyMembers (only relevant on an ACR for a container C)
Specifies the policies that are propagated to acp:apply and acp:applyMembers in the ACR for children of the associated container C.

acp:applyProtected
Specifies the policies that protect the resource. But these policies can only be removed by an agent if that agent has:

• write access from the policies specified using acp:accessProtected on the ACR for the resource
• AND write access from the policies specified using acp:accessProtected on the ACR from which the Policy was originally propagated. Therefore if the resource is /a/b/c/d and the Policy was propagated originally from /a/b then the agent would need write access from acp:accessProtected on the ACR for /a/b/c/d and write access from the acp:accessProtected on the ACR for /a/b. This allows an organisation to apply a policy to all the children (to any depth) of a container C that can only be remove from an individual resource by somebody with permission to remove the policy from the resource in question and from the container C.
  acp:applyMembersProtected (only relevant on an ACR for a container C)
  Specifies the policies that are propagated to acp:applyProtected and acp:applyMembersProtected in the ACR for children of the associated container C.

acp:applyLocked
Specifies the policies that protect the resource. But these policies can only be removed by an agent if that agent has write access from the policies specified using acp:accessLocked on the ACR for the root container. This allows the owner of the Pod (or anybody who has been delegated access to root) to apply policies anywhere in the container that cannot be removed unless the agent has the appropriate access on the root container. The difference between Protected and Locked: Protected policies can be removed by anybody who has the appropriate access to the container where the policy was originally added, whereas locked policies can only be removed by people who have appropriate access to the root container. In an organisation this allows delegated access to trusted agents to subsets of the entire container, but also allows policies to be added to arbitrary resources that even agents who are trusted in that part of the container cannot remove.
acp:applyMembersLocked (only relevant on an ACR for a container C)
Specifies the policies that are propagated to acp:applyLocked and acp:applyMembersLocked in the ACR for children of the associated container C.

Note that this allows configurations where an agent is allowed to add locked policies but not allowed to remove locked policies.

[bblfish]

Thanks for the feedback. I think it would be good to see if one can equate these relations to a few core relations. I'll see if I can come up with something.

[bblfish]

I opened issue 151: Consider ACRs on ACRs, which helps explain how one could get the same functionality but with a simpler architecture.

[bblfish]

I'll close this, and see if by developing issue 151 one can get something simpler.