- From: Tim Berners-Lee <timbl@w3.org>
- Date: Sun, 11 Aug 2013 17:09:06 -0400
- To: Andrei Sambra <andrei.sambra@gmail.com>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Henry Story <henry.story@bblfish.net>, Read-Write-Web <public-rww@w3.org>, Alexandre Bertails <bertails@w3.org>
On 2013-08 -11, at 08:49, Andrei Sambra wrote: > Hi all, > > Here's my take on this subject. > > [...] > FYI: some comments from Timbl on #dig > > <timbl> I think rel=meta is a better choice > <timbl> because we have running code which picks it up > <timbl> and fragmenting the market does less damage. > <timbl> I can see also an ACL file having other stuff (like ownership, provenance, licence etc) and my gut feeling is that one flexible bag is better than trying to defined lots of rigid bags and al algorithm for what triples go in what. > > I personally believe that ACLs should be handled differently. Let me present two counterarguments: > > 1. Imagine you have a photo with a caption represented as metadata. An app may be allowed to modify the meta contents (update a description for a picture maybe?), but it may or may not be allowed to modify the ACL rules for it. How do you configure you ACL policies to enable this kind of behavior if the ACL rules are also inside the meta document that can be edited by the app? In the rel=meta design, rel=meta is really for adding things at a low level of protocol, a hook, like HTTP headers in a way, which allows one to branch into a bag of slowly-changing slowly-growing new features. If you have a file and some data about the file, and you have foobar.png the picture foobar-desc.ttl the metadata like caption, etc etc I understand you need to bootstrap a way of finding foobar-desc.ttl from foobar.png, and in that case you could I suppose put a single triple into foobar.png's meta data: <foo.png> xxx:describedBy <foobar-desc.ttl> . I think it is is important that as much as possible of the design is just done with linked data, not using HTTP headers or rel=meta except when one is forced to (like having an image file). General data about files can in general go in files. It is IMHO a bad design to instantiate a two-level system, where everything has to decide whether to be data or meta-data. (See long rant on Books and Dictionaries - http://www.w3.org/DesignIssues/NamespacesAreResources.html) > 2. How can you limit visibility only for your ACL rules? Say you allow a list of friends to view a photo of you at the bar, but there is someone who you don't want to see it. If your ACLs are visibile, that person will be able to see that he/she was excluded. I think that having both the ACL rules and the metadata in the same file opens the door for privacy issues. The ACL ontology has three classes of access, - Read This allows someone to read the file itself - Write This allows someone to write or delete the file itself - Control This allows someone to read and write the access control information for the file. See http://www.w3.org/ns/auth/acl#Control This is precisely to prevent you from getting to the foo.acl.acl.acl loop! > > To conclude, while I agree with timbl that a flexible bag is always nice to have, we should make an exception in the case of ACLs. Putting the ACLs in a separate bag doesn't, it seems to me, actually solve the problem of controlling access to the ACL, unless you use acl:Control However, let me now argue *for* the rel=acl form. I would be for making up a new rel=acl relation if it was associated with a very solid an testable protocol in RWW, in which client can read and change ACLs, so that we get solid interop between stores and all kinds of clients, including apps which need to create a series of resources with varying access by varying groups. So the spec for rel=acl would not be "points to some access conrol information" but "Indicates that the server commits to following the RWW-AC: protocol. That would be worth a new relationship. And in that case, as the ACL resource pointed to would be used in very tightly controlled way, there would be no sense in mixing it with a rather fluid rel=meta bag, and I would agree to go with rel=acl timbl > > Andrei > > > http://dig.csail.mit.edu/irc/dig/2013-08-10#T20-19-21 > > > > Social Web Architect > http://bblfish.net/ > > > >
Received on Sunday, 11 August 2013 21:09:15 UTC