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

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.

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