Re: Get rid of foaf dependency in ACLs?

On 1/25/16 2:14 AM, Melvin Carvalho wrote:
>
>
> On 25 January 2016 at 01:55, Kingsley Idehen <kidehen@openlinksw.com
> <mailto:kidehen@openlinksw.com>> wrote:
>
>     On 1/24/16 2:54 AM, Melvin Carvalho wrote:
>>     I wanted to highlight this issue raised by Sandro Hawke relating to
>>
>>     https://www.w3.org/wiki/WebAccessControl
>>
>>     "Servers are required to recognize the class *foaf:Agent* as the
>>     class of all agents. This indicates that the given access is
>>     public. In some cases this will mean that authentication is
>>     therefore not required, and may be skipped. When a resource is
>>     being written, however, it may be necessary to associate the
>>     change with some kind of ID for accountability purposes."
>>
>>     Here is the issue:
>>
>>     https://github.com/solid/solid/issues/35
>>
>>     I think proposal is to change this to rdf : Resource to be more
>>     general.
>>
>>     Any thoughts on this?
>
>     I don't believe ACLs are foaf:Agent specific. When I make an
>     acl:authorization instance, the object of its acl:agent_class
>     relation doesn't have to be a foaf:Agent.
>
>     [1] http://www.openlinksw.com/c/9NVXKWB -- acl:agent_class
>     relation description.
>
>
> Right. 
>
> But as LDP is a webization of the UNIX file system.
>
> WebAccessControl is roughly a webization of UNIX permissions.
>
> In UNIX permissions you have the concepts:
>
> User
> Group
> Everyone
>
> We have a webiziation of User namely WebID, a URI that denotes an
> Agent (not necessarily FOAF, but that is the hint).
>
> Perhaps it's possible to specify everyone and group more clearly?
>
> Everyone -- An Agent?  A FOAF Agent?  anyURI?
> Group -- A FOAF Group or something else? 
>
> As a server, how do we check membership in a group, I think is the
> question?

Ah!

In regards to current WebACL ontology that would require adding
foaf:Group to the range of <http://www.w3.org/ns/auth/acl#agent>.
Naturally, this opens up some issues that could be solved via use of a
schema:rangeIncludes relation that has foaf:Agent and
<http://www.w3.org/ns/auth/acl#agent> as objects.

Alternatively, assuming foaf:Agent and foaf:Group are disjoint (not
what's currently expressed in FOAF Vocabulary) we need to introduce an
agent_group property :

@prefix acl: <http://www.w3.org/ns/auth/acl#> .

acl:agent_group
a rdf:Property ;
rdfs:comment """Used like acl:agent_class, but for associating an
authorization with a foaf:Group [rather than an foaf:Agent]""";
rdfs:domain acl:authorization ;
rdfs:range foaf:Group .

OR

## Looser definition that leverages schema.org

@prefix acl: <http://www.w3.org/ns/auth/acl#> .

acl:agent_group
a rdf:Property ;
rdfs:comment """Used like acl:agent_class, but for associating an
authorization with a group [rather than an foaf:Agent]""";
schema:domainIncludes acl:authorization ;
schema:rangeIncludes foaf:Group, {comma separated list of URIs that
Identify Group oriented Classes defined in other ontologies} .

-- 
Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this