- From: bergi <bergi@axolotlfarm.org>
- Date: Thu, 01 Sep 2011 13:15:16 +0200
- To: Danny Ayers <danny.ayers@gmail.com>
- CC: public-rww@w3.org, fritztho@gmail.com
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