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

On 11 Aug 2013, at 17:13, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> On 11 August 2013 14:49, Andrei Sambra <andrei.sambra@gmail.com> wrote:
> Hi all,
> 
> Here's my take on this subject.
> 
> On Sat, Aug 10, 2013 at 10:21 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> 
> 
> On 10 August 2013 10:56, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 10 Aug 2013, at 00:18, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 
> >> When talking about this with Alexandre Bertails he thought that rel="meta" was
> >> not the right relation and that rel="acl" would be more correct.
> >
> > Yes.
> >
> > It will be fixed.
> 
> We need to get those who have implementations to agree on this first. :-)
> 
> And I am not sure what forum is available where we can agree on edits to
> the acl ontolgy or the http://www.w3.org/wiki/WebAccessControl wiki page,
> so I am sending this mail a bit widely around. The WebAccessControl wiki
> page suggests that the RWW Community Group is the place to discuss this.
> 
> I suppose for the moment the WebAccessControl wiki page plays the role of a
> spec. It says:
> 
> [[
>   The client follows, for example, an HTTP header field:
> 
>   Link: <meta/profile.meta>; rel=meta
> ]]
> 
> Alexandre Bertails once argued that meta is too general, and that this should
> be an "acl" link. Neither "acl" nor "meta" are registered in the iana document
> http://www.iana.org/assignments/link-relations/link-relations.xhtml
> which is I think where this needs to be registered.
> See http://tools.ietf.org/html/rfc5988#section-6.1
> 
> For us to register this we should probably have something a bit more
> spec like than the wiki page.
> 
> I also would like to add to the ontology
>  - support for regular expressions on urls
>  - a acl:include relation to include acls from other documents
> 
> 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 agree with Tim here that as far as possible one should not introduce unecessary distinctions. And where it
not for the very convincing argument by Andrei below I would opt for using meta too.

> 
> 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?
> 
> 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.
> 
> These are both good points, however, there is an added complexity introduced imho having both "acl" and "meta".  

yes, but if you do not have this added complexity then you have the problem of not being able to have the metadata for a resource
be edited by anyone else than the person who should have the rights to edit the acl. It then is not easy to tune who can see what, 
and you open a privcay and confidentiality problem. 

Given that we are dealing with issues of privacy and confidentiality here - or else why have access control - the extra flexibility
seems very much worth the price of what seems like a minor increase in complexity.

> 
> You may have different flavours of "meta", "meta-acl", "meta-xyz" for something we havent thought of yet, maybe a tree structure with sub properties as kingsley suggests, or a well known list of meta types.  You'll need to document what goes in which file and explain that to everyone.  This is all doable but were are light on resources, and it's one more thing to maintain.  If someone has time to write this up and gather consensus, of course, change is possible.

It is quite easy to work out: the acl link is the one that determines access control issues. Metadata is everything else.

> 
> While I see the advantages, I agree towards Tim's position of keeping the status quo.  
>  
> 
> 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.
> 
> Andrei
>  
> 
> http://dig.csail.mit.edu/irc/dig/2013-08-10#T20-19-21
>  
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/