Re: AccessControl : update + inference

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.

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
> >
> >
> >
> >
> >
> 
> 

-- 
| Jürgen Jakobitsch, 
| Software Developer
| Semantic Web Company GmbH
| Mariahilfer Straße 70 / Neubaugasse 1, Top 8
| A - 1070 Wien, Austria
| Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22

COMPANY INFORMATION
| web       : http://www.semantic-web.at/
| foaf      : http://company.semantic-web.at/person/juergen_jakobitsch
PERSONAL INFORMATION
| web       : http://www.turnguard.com
| foaf      : http://www.turnguard.com/turnguard
| g+        : https://plus.google.com/111233759991616358206/posts
| skype     : jakobitsch-punkt
| xmlns:tg  = "http://www.turnguard.com/turnguard#"