W3C home > Mailing lists > Public > public-rww@w3.org > November 2012

AccessControl : update + inference

From: Jürgen Jakobitsch <j.jakobitsch@semantic-web.at>
Date: Mon, 12 Nov 2012 22:52:59 +0100
To: "public-rww@w3.org" <public-rww@w3.org>
Message-ID: <1352757179.5241.35.camel@linux-1rgw.site>

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

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

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

| web       : http://www.semantic-web.at/
| foaf      : http://company.semantic-web.at/person/juergen_jakobitsch
| 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#"

Received on Monday, 12 November 2012 21:53:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:04 UTC