- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 12 Nov 2012 23:29:40 +0100
- To: Andrei SAMBRA <andrei.sambra@gmail.com>
- Cc: public-rww@w3.org
- Message-ID: <CAKaEYhKLkyXYdMW5uYG-kjtU+_Mygt_xSF5QDv1Qiudx_xF7mw@mail.gmail.com>
On 12 November 2012 23:19, Andrei SAMBRA <andrei.sambra@gmail.com> wrote: > Actually, I wonder if it would be a better idea to move this wiki page (on > AC) to the RWW wiki, given that it is orthogonal to LDP WG's work. I'll > create the stub wiki page and post the link in a reply. Note: we have so far http://www.w3.org/community/rww/wiki/AccessControl > > Andrei > > > On Mon, Nov 12, 2012 at 5:16 PM, Kingsley Idehen <kidehen@openlinksw.com>wrote: > >> On 11/12/12 4:52 PM, Jürgen Jakobitsch wrote: >> >>> hi, >>> >>> since the discussion on AC is apparently taking shape, it might be a >>> good time for my questions. >>> >>> until now we more or less only had examples of AC in action on the >>> data-retrieval side (as far as i know at least). >>> >>> do acl-engines only really work with inference-engines when updating or >>> are there recommended ways of dealing with the following example? >>> >>> prereq.: acl - denies access to resource "x" (say a skos:Concept) >>> >>> what should happen, when i add the triple? >>> >>> resource "y" skos:broader resource "x"? >>> >>> >>> there are several scenarios in which this could take place : >>> >>> 1. should the update request be rejected with full inferencing, because >>> it becomes clear the resource "x" is touched? >>> 2. what happens in a non-inferencing environment? with that is created a >>> relation between the two resources and i could construct (sparql-wise) >>> whatever i want, which brings me to the idea of never trusting >>> application/sparql-results+*..**. >>> >>> >>> so the crucial point seems to be that ACLs can handle updates more >>> flexible, a read and write access denied for a single resource might not >>> be enough. >>> >>> any pointer to the most flexible acl-ontology? >>> i'm thinking about something like : >>> >>> denyWriteAccess where resource "x" is the object. >>> >>> any pointer really appreciated.. >>> >> >> We we do is have SPARQL ASK as an option for determining conditions. That >> way, you handle all your desired scenarios as the data (resource) >> publisher. Basically, we offer: >> >> 1. basic WebID lists >> 2. WebIDs as members of foaf:Groups >> 3. SPARQL ASK -- for most complex conditions and custom conditions. >> >> As for inference, we have this loosely bound to the SPARQL processor >> which is why we use pragmas to enable inference context in our SPARQL >> implementation. I know of not other way to handle the contextual fluidity >> associated with this subject matter :-) >> >>> >>> wkr turnguard >>> >>> >>> >>> >>> >>> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen> >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about> >> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen> >> >> >> >> >> >> >
Received on Monday, 12 November 2012 22:30:07 UTC