Re: Triple Access Control

Am 01.09.2011 10:29, schrieb Danny Ayers:
> On 1 September 2011 01:24, bergi<bergi@axolotlfarm.org>  wrote:
>> I have already mentioned the vocab I'm using for triple access control
>> on the RWW blog.
>
> Link? (You did press "Publish"?)

It was just a comment to the "What is this all about?" blog entry:
http://www.w3.org/community/rww/2011/08/16/what-is-this-all-about/#comment-6

There is a link in this comment to the triple store content of the 
ResourceMe page:
https://www.axolotlfarm.org/svn/bergi/bergnet/php/resourceme-app/trunk/src/data/triplestore.init.rdf.xml

ResourceMe contains already a implementation of an older version of my 
TripleAccessControl proposal. The blog itself is a simple example. Read 
access is granted to the virtual WebID #anybody, write access only to 
the admin group which contains my WebID. There is also an Ajax API.
The "Create new entry" block on the news page for example, is disabled 
if you don't have the rights to create a blog entry. Here the link to 
the page:
https://resourceme.bergnet.org

> This topic is obviously very relevant to the group so I've added a
> page on the Wiki for links&  notes :
> http://www.w3.org/community/rww/wiki/AccessControl

Nice, I plan to create a RDF schema for my vocab the next days. I will 
add a link when it's ready.

>
> My first impressions are that the modelling makes sense - I do like
> the idea of have granular access down to the triple level. I assume
> acl:Control is about being about to modify the ACL itself.

The acl:Control was a copy/paste error. I don't know if it makes sense 
to have the acl:Control mode, because TAC could also handle this.

>
> How would you go about implementing a control system/the access
> itself? The triple-level bit does complicate matters, I can only think
> you'd let the user supply a 'proposed changes' graph (either as a
> SPARQL update or something like Talis' changeset graph) and check
> individual triple changes against the ACL.

Currently I've only implemented checks for single triple changes. But 
this could cause problems with tac:required property if a depending 
triple is part of the change. I think the "proposed changes" graph is 
the way to go.

>
> An alternate approach might be to maintain the graphs over which
> access control is needed as a set of one-triple (or slightly more :)
> named graphs. I'm currently playing with Fuseki and I reckon this
> would be straightforward there as you can configure the SPARQL engine
> to see the default graph as the union of all the named graphs.
> (Although Fuseki itself doesn't yet have any kind of access
> control/security).

I have to think about this. But now I'm not sure if this works or how 
complex this could become.


the bergi

Received on Thursday, 1 September 2011 11:16:26 UTC