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

<snip>
 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
</snip>
just checking: in your POV, it true that the target of rel="meta" MUST be
an RDF document? this would seem to go beyond common use of the rel (per
5988)[1].

<snip>
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.
</snip>
yes, this is what i think as well. in fact, i'd like to see a
well-constrained way to express ACL information such that clients can have
this "baked in" to their code-base (like support for HTML, PNG, etc.) in
order to make ACL management "free" for clients who support this media-type
and/or profile. It'd be nice if this worked beyond RD clients, but maybe
that's not the goal here.

Cheers.

1[] http://tools.ietf.org/html/rfc5988#section-4



mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen


On Sun, Aug 11, 2013 at 5:09 PM, Tim Berners-Lee <timbl@w3.org> wrote:

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