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

On 8/11/13 8:49 AM, Andrei Sambra wrote:
>
> 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

+1

This is a very good argument. It makes a crystal clear case for why ACL 
metadata isn't generic metadata.

If we don't want to depend on reasoning and internal store capabilities 
re. ACLs (which is what we already have in Virtuoso and by consequence 
ODS), I don't see any reason for arguing against this particular point 
which keeps the coupling of data from databases/store loose.

So back to my original point, let's harmonize. Right now, it looks like 
<#acl> rdfs:subPropertyOf <#meta> is the shortest path, and least 
disruptive.

-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen