Re: rel="meta" or rel="acl" ? was: Web Access Cntrl Spec?

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