AccessControl : update + inference

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

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