Having determined that acp:access is the inverse of wac:accessTo in issue 129: acp/wac diff the ACR document, I end up with the mapping between wac and acp

wac:accessTo owl:inverseOf [ 
        owl:propertyChainAxiom ( wac:accessControl :authorizes )
      ] .

being equivalent to

acp:access owl:propertyChainAxiom ( wac:accessControl :authorizes )

The idea was that we could infer the inverse of acp:accessTo from following a wac:accessControl Link and an :authorizes link. Looking at this from the point of view of acp:access suggests that an ACR is its own ACR as the statement

<> acp:access <#p1> .

then would be equivalent to

<> wac:accessControl <> . 
<> :authorizes <#p1> .

But we notice now that we can no longer distinguish Policies that apply to the ldp:Resource linking to the ACR and those that apply to the ACR itself.

For, let us imagine that every ACR has a Link: rel="acp" relation to itself (ie <> acp:accessControl <>) Then the same acp:Policys would apply to the ACR as to the Resource that it is meant to protect.
So for example in this picture we have Tim Berners-Lee's foaf profile that links to the ACR. But now there would be no way - with only these tools - to make the ACR readable only to Tim, without also limiting access to his foaf profile... In this case it seems like it's ok, but there will be other use cases where it won't be quite what is needed.

So it seems that we actually can't get rid of the wac:accessTo relation, and that furthermore ACP does not do it. It just replaces it with the inverse acp:access.

But then we can now write out what should appear in Tim's profile using just acp:access were he to want to be the only one to read it.

# this applies to the ACR itself as per current ACP doc dumps
<> acp:access <#TimsPolicy> .

<#TimsPolicy> a acp:Policy;
            acp:allow acp:Read, acp:Write;
            acp:anyOf <#TimRules>  .

# This applies to TimBL's profile 
<card> acp:access [ a acp:Policy;
             acp:allow acp:Read;
             acp:anyOf foaf:Agent ];
       acp:access <#TimsPolicy> .

<#TimBLRules>  acp:agent </People/Berners-Lee/card#i> .

So why not define acp:access to just relate a Resource to the Policy that applies to it?
Like this:

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

Ie we could then have an ACR that looks like this: