Re: AccessControl : update + inference

On 11/12/12 5:19 PM, Andrei SAMBRA 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.
+1

Kingsley
>
> Andrei
>
>
> On Mon, Nov 12, 2012 at 5:16 PM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto: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/%7Ekidehen>
>     Twitter/Identi.ca handle: @kidehen
>     Google+ Profile: https://plus.google.com/112399767740508618350/about
>     LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>


-- 

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