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

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 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".

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.

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/
>>>
>>>
>>>
>>
>