- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 07 Aug 2014 11:48:27 +0100
- To: public-ldp-wg@w3.org
- Message-ID: <53E3597B.5060406@openlinksw.com>
On 8/6/14 9:34 PM, Ashok Malhotra wrote: > Some quad stores provide access to individual triples. Yes, Virtuoso does that. > I know that Oracle allows that and our product folks would like to > provide access control at the triple level. Virtuoso supports ACLs scoped to named graph IRIs. For all the reasons already outlined in prior posts from Sandro, Henry, and I. > Thus, I am reluctant to remove this requirement. Sorry, but the requirement reflects misunderstanding of the role of named graphs in relation to triples. Look at it this way, from an RDBMS that supports RDF perspective: 1. A named graph denotes an internal document identifier -- remember, a Table is a document in an RDBMS (because a database != rdbms system; they are distinct things) 2. You protect documents not specific sentences and paragraphs in documents -- redaction isn't the same thing as ACLs, in the case of ACLs you are (like in the real world) controlling access to documents in a folder, cabinet, cube, building etc.. all of which relate directly to the subject at hand here. Even if you tried to implement triple scoped ACLs, it would die of inflexibility and horrific performance. Scalability is not even a discussion. Here's an example of a Named Graph ACL template, represented in Turtle Notation: ## Protected (Private) Resource Authorization denoted by the IRI <{ACL-IRI}> ; ## created by the Identity Principal denoted by the IRI <{Rule-Creator-WEBID}> ; ## granting Read/Write privileges to the Named Graph denoted by the IRI <{Target-Named-GRAPH-IRI}> ; ## to identity principals denoted by the following IRIs list <{GROUP-or-AGENT-IRI-1}>, <{GROUP-or-AGENT-IRI-N}>, PREFIX oplacl: <http://www.openlinksw.com/ontology/acl#> PREFIX acl: <http://www.w3.org/ns/auth/acl#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> <{ACL-IRI}> a acl:Authorization ; rdfs:label "ACL based Data Access Policy Example" ; rdfs:comment """An ACL based Data Access Policy used to control access to a specific named graph, denoted by a named graph IRI that functions as the object of an ac:accessTo relation. This particular policy grants Read and Write privileges to Identity Principals denoted by the list of URIs functioning as the object of the acl:agent relation. """ ; foaf:maker <{Rule-Creator-WEBID}> ; oplacl:hasAccessMode oplacl:Read, oplacl:Write ; acl:accessTo <{Target-Named-GRAPH-IRI}> ; acl:agent <{GROUP-or-AGENT-IRI-1}>, <{GROUP-or-AGENT-IRI-N}> ; oplacl:hasScope oplacl:PrivateGraphs ; oplacl:hasRealm oplacl:DefaultRealm . Kingsley > All the best, Ashok > > On 8/6/2014 2:11 PM, Sandro Hawke wrote: >> On August 5, 2014 5:52:45 AM EDT, Kingsley Idehen >> <kidehen@openlinksw.com> wrote: >>> On 8/5/14 10:02 AM, henry.story@bblfish.net wrote: >>>> On 4 Aug 2014, at 23:32, Ashok Malhotra<ashok.malhotra@oracle.com> >>> wrote: >>>>>> Henry: >>>>>> We decided to remove access control for attributes (parts of >>> triples) >>>>>> We did not discuss removing access control for triples. >>>>>> We can discuss this if you wish. >>>> I don't see how you can do access control on parts of triples at all. >>>> >>>> The argument as I understand it is that one can only give access or >>> not >>>> at the HTTP layer to a resource. What state of the resource you show >>>> is another topic: call it filtering. That could be an orthogonal >>> spec. >>>> It is best to keep things simple and distinct to arrive at a >>> consensus. >>>> Henry >>>> >>> +1 >> +1 >> >> >> > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 7 August 2014 10:48:50 UTC