Re: AccessControl : update + inference

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