Re: AccessControl : update + inference

On 11/12/12 5:33 PM, Jürgen Jakobitsch wrote:
> hi,
>
> you are right (i somehow felt i'm missing something, when writing the
> mail), i can of course ASK for more or less anything and determine
> access rights.
>
> the problem, is that i hardly can ASK for all possibilities everytime.
>
> please note that i have this usecase in mind where different people in
> different roles (incubator, domain-expert, publisher) are working on a
> server that hosts different projects (skos-thesauri or blogs,...)
>
> there might be possibilities with ~"functional acls", for example
> where the object of an access predicate is a sparql query (-template)
> itself.

Yes, that's what I mean by SPARQL ASK based access control. That's what 
we do right now with inference controlled via pragmas.

Kingsley
>
> at least i now know what i do at witching hour in the coming weeks ;-)
>
> wkr jürgen
>
>
>
>
> On Mon, 2012-11-12 at 17:16 -0500, Kingsley Idehen 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
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen