- From: Andrei SAMBRA <andrei.sambra@gmail.com>
- Date: Mon, 12 Nov 2012 17:38:22 -0500
- Cc: "public-rww@w3.org" <public-rww@w3.org>
- Message-ID: <CAFG79ehsmL5sAkSWj_MdHkpb9ELJ1RXXqY9Q+==8B80KyM13vQ@mail.gmail.com>
I have created http://www.w3.org/community/rww/wiki/AccessControl_Usecases. I think we could continue to add use cases to this wiki page, and eventually merge the two once we get some results. I've already added some stuff there. Andrei On Mon, Nov 12, 2012 at 5:33 PM, Jürgen Jakobitsch < j.jakobitsch@semantic-web.at> 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. > > 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#" >
Received on Monday, 12 November 2012 22:39:09 UTC