Re: [Fwd: Re: ACL for subtrees]

On Mon, Mar 07, 2005 at 03:01:13PM +0100, Stefano Debenedetti wrote:
> this seems to have been eaten by my (buggy) mail server (probably because 
> of the wrong archive address) so I send it again, I also fwded a copy of 
> your original mail to the right archive address
> 
> -------- Messaggio Originale  --------
> Oggetto: Re: ACL for subtrees [fixed Cc: list]
> Data: Sun, 06 Mar 2005 01:28:02 +0100
> Da: Stefano Debenedetti <ste@demaledetti.net>
> A: Eric Prud'hommeaux <eric@w3.org>
> CC: Dominique Dominique Hazaël-Massieux <dom@w3.org>,  w3c-archive@w3.org
> Referenze: <42234CC3.4090402@demaledetti.net> 
> <20050305230042.GA22697@w3.org>
> 
> Hello Eric, 
> 
> thank you for opening this up and taking the time for the explanation, it 
> is indeed very interesting.
> 
> Eric Prud'hommeaux ha scritto:
> [..]
> >We don't express our recursive rules in RDF. Instead, we create a
> >.default-acl file. I guess the cvs commit backend walks up the
> >directory tree to the tightest containing directory with a
> >.default-acl (most often there is none) and sets newly created
> >documents to that ACL.
> [..]
> >- it only works for files committed after or at the same time as the
> >.default-acl file
> >- it's dumb, so if you change the value in .default-acl or if you remove
> >the file, that won't have any effect; you need to contact webreq to
> >actually change the default acl
> [...]
> 
> Ouch, my requirements include that this is all expressed in RDF to be used 
> in conjunction with some OWL ontologies (I am therefore thinking about an 
> OWL ontology for describing URLs...) and dynamic so that it keeps track of 
> ACL defaults changes on existing resources.

Apart from intertia, there's no reason we can't do the same. Looking at
the ICRA work on pics labels [PICS], an schema like this springs to mind:

... ran into you in IRC, 

> Plus, I am not using Apache/SQL at all but a Python Twisted server backed 
> by a SPARQL[1]-enabled RDF data store.

Cool! I didn't know there *was* a python SPARQL.
(We may have a syntax change to bring us closer to TURTLE and N3.)

> Anyway I'd be glad to let you know of further developments of my 
> experiments on this subject when they have some aspects in common with your 
> system. For example I tried to use your vocalulary as-is in my system but 
> have found that it's hard to make OWL tools play well with your HTTP 
> methods definitions, which are not even seen as regular instances of 
> anything, so I started home-brewing an OWL ontology out of it [2].

If you have a large number of users, the SQL schema could still be of
use to you, as well as the libraries or the SQL code that calculates
the closure for group inclusions:

  { ?who memberOf ?g1 .
    ?g1 memberOf ?g2 }
  =>
  { ?who memberOf ?g2 }

We have a 32K principals in 1K groups, with a total of 120K transitive
memberships in groups so we maintain this closure in the SQL tables
rather than in an RDF database.

> Thanks again, ciao
> ste
> 
> [1] SPARQL, which I forgot mentioning in my previous mail, despite it being 
> my current favorite in the set of your amazing creations which I had a 
> chance to look at :-)
> 
> [2] 
> http://demaledetti.net/ns/2005/02/acl.owl
> http://demaledetti.net/ns/2005/02/http.owl    
> (another requirement would be to leverage the same ACL system for other 
> protocols too)

yeah, I'd hacked an IRC server to use ACLs too, but I lost track of
that. Anyways, inventing new URIs for protocol verbs is easy.
Hmm, I should split the HTTP protocol verbs out of the chacl namespace;
maybe put them in the Annotea HTTP protocol namespace...


[PICS] http://www.w3.org/2004/12/q/doc/rdf-contentlabels.html
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.