Re: [foaf-protocols] ACL
Nathan, That sort of reminds me of something [1] ;) So, I asked a round a bit [2] and the answer essentially was: go register one ... fancy doing it together? Cheers, Michael [1] http://webofdata.wordpress.com/2010/03/04/wod-access-control-discovery/ [2] http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0218.html -- Dr. Michael Hausenblas LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html From: Nathan nat...@webr3.org Organization: webr3 Reply-To: nat...@webr3.org Date: Mon, 19 Apr 2010 22:37:41 +0100 To: Linked Data community public-lod@w3.org, foaf-protocols foaf-protoc...@lists.foaf-project.org Subject: [foaf-protocols] ACL Hi All, I'm just trying to get an implementation of web access control [1] off the ground and have hit upon a small issue. I'm planning on exposing links to acl files via the Link header as directed, however I've realised there is no rel= for it, hence i was opting for a custom temporary type. On a first look a relation of acl:acl looks to be the one, but after checking the actual ontology the acl:acl link simply isn't there, thus in the meantime I've opted for: Link: /.wac/everyone.n3; rel=http://www.w3.org/ns/auth/acl#;; title=Access Control File Any improvements, or refinements welcome, as the above is just a temporary measure. Best, Nathan ___ foaf-protocols mailing list foaf-protoc...@lists.foaf-project.org http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
Re: [foaf-protocols] ACL
On 20 Apr 2010, at 08:47, Michael Hausenblas wrote: Nathan, That sort of reminds me of something [1] ;) So, I asked a round a bit [2] and the answer essentially was: go register one ... fancy doing it together? The latest document draft-nottingham is here btw http://cidr-report.org/ietf/idref/draft-nottingham-http-link-header/ One could just register it by adding the relation in the acl ontology such as acl:rules a rdf:Property; rdf:domain foaf:Document; rdf:range foaf:Document; ... As you can see in the 5.5 examples, you can have a rel value as a URL. ( So in this it is similar to atom). The only disadvantage then is that you don't get the nice shorthand, for inclusion in Atom XML, and other documents. So I suppose the best would be to add the relation first to the ontology, work out a good wording for it, test it out, then ask for the IETF shorthand, the put an owl:sameAs link to the ietf one, which hopefully we can then convince them to serve up as linked data. I'd be happy to support a document for the link. It seems to me the Atom folks could find that very useful. Not sure yet how cold they are towards rdf still. Henry Cheers, Michael [1] http://webofdata.wordpress.com/2010/03/04/wod-access-control-discovery/ [2] http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0218.html -- Dr. Michael Hausenblas LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html From: Nathan nat...@webr3.org Organization: webr3 Reply-To: nat...@webr3.org Date: Mon, 19 Apr 2010 22:37:41 +0100 To: Linked Data community public-lod@w3.org, foaf-protocols foaf-protoc...@lists.foaf-project.org Subject: [foaf-protocols] ACL Hi All, I'm just trying to get an implementation of web access control [1] off the ground and have hit upon a small issue. I'm planning on exposing links to acl files via the Link header as directed, however I've realised there is no rel= for it, hence i was opting for a custom temporary type. On a first look a relation of acl:acl looks to be the one, but after checking the actual ontology the acl:acl link simply isn't there, thus in the meantime I've opted for: Link: /.wac/everyone.n3; rel=http://www.w3.org/ns/auth/acl#;; title=Access Control File Any improvements, or refinements welcome, as the above is just a temporary measure. Best, Nathan ___ foaf-protocols mailing list foaf-protoc...@lists.foaf-project.org http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
GI INFORMATIK 2010 Workshop on Web Science
**Apologies if you receive multiple copies of this CFP** ==INFORMATIK 2010 Workshop on Web Science== co-located with GI-Jahrestagung 2010 http://aksw.org/WebScienceWorkshop Web science is often referred to as the science of decentralized information systems. While novel technologies such as semantic web, web services, and cloud computing are germane to the broad proliferation of Web technologies, we also need to understand phenomena of the Web in the small as well as in the large, in order to retain its usefulness and benefit to people. This is in the center of attention of Web science and includes besides the mentioned technological approaches, research related to online communities, information diffusion on the Web, Web governance, global network structures beyond the individual communities on the Web, growth analysis, incentive and monetization systems. This workshop provides a platform for researchers and practitioners to exchange preliminary results, new concepts and methodologies in this area. ===Topics of interest === * Web Governance incl. Provenance, Licensing, Data Security, Access Control * Open Knowledge ecosystems on the Web, such as Open Governmental Data, Open Scientific Data * Information quality assessment * Quality, coherence and user interaction on the Linked Data Web * Social computing applications such as collaborative filtering, community-based information retrieval and recommendation, collaborative bookmarking, tagging and multi-agent systems * Static and dynamic models of Web structure and Web growth * Analysis of network structures within and beyond individual communities on the Web * Incentive and monetization systems * Information diffusion on the Web, * Web and Web application governance, * Novel visualisation techniques for Web related data * Integrating computational network analysis and semantic web techniques, for example to enhance the mainly structure-based network analysis by semantic information * Case studies of communities such as Wikipedia, Facebook, Twitter, World of Warcraft, open source software as well as empirical findings in social computing-related applications In particular, we aim at collecting a set of requirements, architectural styles and metaphors for Web science. It is the target of such terminology and figures to build bridges of understanding between the different communities serving the need to appropriately //analyse// and //develop// social Web applications. ===Important Dates=== * 07.05.2010 **Paper Submission** * 24.05.2010 **Acceptance Notification** * 30.06.2010 **Final paper version due** * 28.09.2010 **Workshop in conjunction with the GI-Jahrestagung** ===Contact and Organisation=== Sören Auer, AKSW, University of Leipzig Claudia Müller-Birn, Software Research, Carnegie Mellon University Steffen Staab, WeST, University of Koblenz-Landau ===Website=== http://aksw.org/WebScienceWorkshop
Re: [foaf-protocols] ACL
Michael Hausenblas wrote: Nathan, That sort of reminds me of something [1] ;) Indeed! I've started implementing it last night (figured it was time to do it, rather than ponder and debate it!) So far it's been relatively easy and have managed to get basic ACL / ACF implemented and working. Also made a non-sparql dependant FOAF+SSL implementation which I'll be adding to libAuthenticate w/ Lazlo, Melvin etc over the next week or so. So, I asked a round a bit [2] and the answer essentially was: go register one ... fancy doing it together? Yup certainly do :) ACL Ontology wise afaict what's needed is the inverse of acl:accessTo - resource acl:acl acf or suchlike. However, I've also got another couple of suggestions for the acl ontology which I'll send through under different cover. Cheers, Michael Likewise, Nathan [1] http://webofdata.wordpress.com/2010/03/04/wod-access-control-discovery/ [2] http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0218.html Other related reading for the archives: http://esw.w3.org/WebAccessControl http://esw.w3.org/Talk:WebAccessControl http://esw.w3.org/WebAccessControl http://www.w3.org/DesignIssues/CloudStorage.html http://www.w3.org/DesignIssues/ReadWriteLinkedData.html http://dig.csail.mit.edu/2009/Papers/ISWC/rdf-access-control/paper.pdf http://dig.csail.mit.edu/2009/presbrey/UAP.pdf http://linkeddata.deri.ie/sites/linkeddata.deri.ie/files/rw-wod-tr.pdf
Re: [foaf-protocols] ACL
Story Henry wrote: On 20 Apr 2010, at 08:47, Michael Hausenblas wrote: Nathan, That sort of reminds me of something [1] ;) So, I asked a round a bit [2] and the answer essentially was: go register one ... fancy doing it together? The latest document draft-nottingham is here btw http://cidr-report.org/ietf/idref/draft-nottingham-http-link-header/ One could just register it by adding the relation in the acl ontology such as acl:rules a rdf:Property; rdf:domain foaf:Document; rdf:range foaf:Document; ... As you can see in the 5.5 examples, you can have a rel value as a URL. ( So in this it is similar to atom). The only disadvantage then is that you don't get the nice shorthand, for inclusion in Atom XML, and other documents. Yup that's what I went for too :) Link: /.wac/everyone.n3; rel=http://www.w3.org/ns/auth/acl#;; title=Access Control File So I suppose the best would be to add the relation first to the ontology, work out a good wording for it, test it out, then ask for the IETF shorthand, the put an owl:sameAs link to the ietf one, which hopefully we can then convince them to serve up as linked data. related discussion for those hunting the archives: http://markmail.org/thread/h26pwafhr6suzvm4 I'd be happy to support a document for the link. It seems to me the Atom folks could find that very useful. Not sure yet how cold they are towards rdf still. Likewise (if the input is needed) Best, Nathan
Re: [foaf-protocols] ACL
Indeed! I've started implementing it last night (figured it was time to do it, rather than ponder and debate it!) +1 Where? :) Cheers, Michael -- Dr. Michael Hausenblas LiDRC - Linked Data Research Centre DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html From: Nathan nat...@webr3.org Organization: webr3 Reply-To: nat...@webr3.org Date: Tue, 20 Apr 2010 15:05:38 +0100 To: Michael Hausenblas michael.hausenb...@deri.org Cc: Linked Data community public-lod@w3.org, foaf-protocols foaf-protoc...@lists.foaf-project.org Subject: Re: [foaf-protocols] ACL Michael Hausenblas wrote: Nathan, That sort of reminds me of something [1] ;) Indeed! I've started implementing it last night (figured it was time to do it, rather than ponder and debate it!) So far it's been relatively easy and have managed to get basic ACL / ACF implemented and working. Also made a non-sparql dependant FOAF+SSL implementation which I'll be adding to libAuthenticate w/ Lazlo, Melvin etc over the next week or so. So, I asked a round a bit [2] and the answer essentially was: go register one ... fancy doing it together? Yup certainly do :) ACL Ontology wise afaict what's needed is the inverse of acl:accessTo - resource acl:acl acf or suchlike. However, I've also got another couple of suggestions for the acl ontology which I'll send through under different cover. Cheers, Michael Likewise, Nathan [1] http://webofdata.wordpress.com/2010/03/04/wod-access-control-discovery/ [2] http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0218.html Other related reading for the archives: http://esw.w3.org/WebAccessControl http://esw.w3.org/Talk:WebAccessControl http://esw.w3.org/WebAccessControl http://www.w3.org/DesignIssues/CloudStorage.html http://www.w3.org/DesignIssues/ReadWriteLinkedData.html http://dig.csail.mit.edu/2009/Papers/ISWC/rdf-access-control/paper.pdf http://dig.csail.mit.edu/2009/presbrey/UAP.pdf http://linkeddata.deri.ie/sites/linkeddata.deri.ie/files/rw-wod-tr.pdf
ACL Ontology and Discussion
Hi All, I'd like to propose a few new additions to the ACL Ontology, I won't be specific on names but will describe each one and the associated need. The addition of groups - personally I see no need to define a set ontology for what constitutes a group when dealing with ACL, however it would be fantastic to be able to point to the URI of a Group of WebIDs and the relation, or predicate, that should be used. For example: [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentGroupSource http://webr3.org/nathan#me ; acl:agentGroupLink foaf:knows . in this scenario the agentGroupSource is a foaf:Person (me) and the relation to be used as members who have acl:Read access is everybody i foaf:knows. [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentGroupSource /groups#working-group-members ; acl:agentGroupLink sioc:has_member . in this scenario the agentGroupSource is a sioc:Usergroup and the relation to be used as members who can Read,Write is sioc:has_member. I'm very aware that there are inverse relations here (sioc:member_of), but strongly feel that we can't be trusting anything in somebodies foaf profile document for ACL, so thus have negated entirely :) I've also given the above pretty poor names of agentGroup* in the examples, purposefully to get some input on better names! Next up is acl:agentClass, I'm actually going to suggest deprecation or reserving it for future use, because afaict everything which is requesting access to a resource must be an agent of some kind, and if we were to distinguish between Classes of Agent then the only place we can find out what Class an Agent has, is in their foaf profile - which they control. So for example you can say that access can only be granted to ex:Admin and I can say I am a foaf:Person, ex:Admin and gain access. In addition access control is a pretty critical issue, and adding in things which bring up many design issues about inference etc when they aren't strictly needed (as in groups and lists of WebIds suit the purpose and always have - imo) may not be the best course of action. (You've no idea how humbly I say that, but figure it best to bring it up). This does however bring up the issue of how to say read access for anybody with a webid - is there any wild card syntax that could be used for acl:agent or suchlike? And finally, some form of doesn't have access - in many cases and on many systems I've implemented there has been very strong, non-optional, requirements to effectively ban or restrict access to certain people. Often access is granted to everybody who is logged in but not to person-x and person-y. It seems that some for of acl:Unauthorisation is needed - but I'll leave it there for those more intelligent than me to pick up :) /end-of-list Out of all the above, the first issue group access is the one I'd most like to get out of the way asap, or even ideas on a temporary work around as keen to be progressing with the acl implementation. Best Regards, Nathan
LOD Camp at WWW2010....
This is just a reminder that there will be an LOD camp at the WWW Conference next week in Raleigh: http://www.w3.org/2010/04/w3c-track.html you should sign up on http://esw.w3.org/topic/LODCampW3CTrack you can also add your favourite topic right now on the wiki page, or leave for the discussion over there... Ivan Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf smime.p7s Description: S/MIME cryptographic signature
Re: LOD Camp at WWW2010....
Hi Ivan, So it looks like students could go to the entire day of Linked Open Data Camp by paying $75.00? //Ed On Tue, Apr 20, 2010 at 12:19 PM, Ivan Herman i...@w3.org wrote: This is just a reminder that there will be an LOD camp at the WWW Conference next week in Raleigh: http://www.w3.org/2010/04/w3c-track.html you should sign up on http://esw.w3.org/topic/LODCampW3CTrack you can also add your favourite topic right now on the wiki page, or leave for the discussion over there... Ivan Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Re: ACL Ontology and Discussion
On 20 Apr 2010, at 15:52, Nathan wrote: Hi All, I'd like to propose a few new additions to the ACL Ontology, I won't be specific on names but will describe each one and the associated need. The addition of groups - personally I see no need to define a set ontology for what constitutes a group when dealing with ACL, however it would be fantastic to be able to point to the URI of a Group of WebIDs and the relation, or predicate, that should be used. For example: [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentGroupSource http://webr3.org/nathan#me ; acl:agentGroupLink foaf:knows . I think you can get what you want by using owl reasoning @prefix owl: http://www.w3.org/2002/07/owl# . @prefix acl: http://www.w3.org/ns/auth/acl# . [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentClass :myfriends . :myfriends owl:equivalentClass [ a owl:Restriction; owl:onProperty [ owl:inverseOf foaf:knows ]; owl:hasValue http://webr3.org/nathan#me ] . in this scenario the agentGroupSource is a foaf:Person (me) and the relation to be used as members who have acl:Read access is everybody i foaf:knows. [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentGroupSource /groups#working-group-members ; you probably want a acl:agentGroupSource /groups/#userGroup1 ; acl:agentGroupLink sioc:has_member . [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentClass :wkgrp. :wkgrp owl:equivalentClass [ a owl:restriction; owl:onProperty sioc:member_of; owl:hasValue /groups/#userGroup1 . in this scenario the agentGroupSource is a sioc:Usergroup and the relation to be used as members who can Read,Write is sioc:has_member. I'm very aware that there are inverse relations here (sioc:member_of), but strongly feel that we can't be trusting anything in somebodies foaf profile document for ACL, so thus have negated entirely :) That is not a question of the direction of the realtion, but a question of which information you take as reliable. If you don't trust the information from the user's profile, don't merge it into the graph you use to decide who get access to some resource. I've also given the above pretty poor names of agentGroup* in the examples, purposefully to get some input on better names! Next up is acl:agentClass, I'm actually going to suggest deprecation or reserving it for future use, because afaict everything which is requesting access to a resource must be an agent of some kind, Not sure why you think so. The point of agentClass is to link to the set of agents that have access. Seems pretty reasonable to me. and if we were to distinguish between Classes of Agent then the only place we can find out what Class an Agent has, is in their foaf profile - which they control. The agent class is not a way of defining the type of the agent, it is a way to define the type of people who will be given access. agentClass a rdf:Property; rdfs:label agent; rdfs:comment A class of persons or social entities to being given the right; rdfs:domain Authorization; rdfs:range rdfs:Class. # Must be subclass of foaf:Agent. So for example you can say that access can only be granted to ex:Admin and I can say I am a foaf:Person, ex:Admin and gain access. That is why one would not use information from your foaf file to decide what class you are in. Presumably the class could be one defined either directly by a URL, which could list all its members, and presumably would be access controlled by someone reliable, or as above indirectly as your friends. In addition access control is a pretty critical issue, and adding in things which bring up many design issues about inference etc when they aren't strictly needed (as in groups and lists of WebIds suit the purpose and always have - imo) may not be the best course of action. (You've no idea how humbly I say that, but figure it best to bring it up). This does however bring up the issue of how to say read access for anybody with a webid - is there any wild card syntax that could be used for acl:agent or suchlike? If you want that you would do as the note in the acl ontology points out, you would use the class of foaf:Agent And finally, some form of doesn't have access - in many cases and on many systems I've implemented there has been very strong, non-optional, requirements to effectively ban or restrict access to certain people. You can use set operators defined here http://www.w3.org/TR/2004/REC-owl-guide-20040210/#SetOperators to define sets of people who are not allowed access. Often access is granted to everybody who is logged in but not to person-x and person-y. It seems that some for of acl:Unauthorisation is needed - but I'll leave it there for those
Re: [foaf-protocols] ACL Ontology and Discussion
On Tue, Apr 20, 2010 at 2:49 PM, Story Henry henry.st...@bblfish.net wrote: I think you can get what you want by using owl reasoning authz_webid can't currently reason about OWL. I currently get this done with roqet+rapper in a Makefile near my ACLs and FOAF using CONSTRUCT. See http://presbrey.pastebin.com/wyPSdU36 if you're interested. I run 'make' after I change my FOAF (adding or dropping foaf:knows) and my FOAF and ACLs are always up to date. I've also toyed with activating the script from crontab, new user signup, pubsubhuhbbub push, and others. I had an agentASK-like predicate in an early version of authz_webid. It was the ugliest thing: a url-encoded SPARQL statement supporting $ENV substitutions but it was awesome stuff. The expressiveness of SPARQL ASK and boolean result made it seem like the obvious Right Way to delegate authz to a full/custom semweb stack that CAN reason (and cache!). This does however bring up the issue of how to say read access for anybody with a webid - is there any wild card syntax that could be used for acl:agent or suchlike? This is precisely what I use acl:agentClass to do (namely: [] acl:agentClass foaf:Agent) assuming that you can't be an Agent without having a WebID and don't care about the distinctions between client, server, agent, and person. Best regards, -- Joe Presbrey
Re: [foaf-protocols] ACL Ontology and Discussion
Joe Presbrey wrote: On Tue, Apr 20, 2010 at 2:49 PM, Story Henry henry.st...@bblfish.net wrote: I think you can get what you want by using owl reasoning authz_webid can't currently reason about OWL. I currently get this done with roqet+rapper in a Makefile near my ACLs and FOAF using CONSTRUCT. See http://presbrey.pastebin.com/wyPSdU36 if you're interested. ty for the pointer, and likewise can't reason with owl (and in many ways don't want to, want ACL to be as quick and painless as possible for both man and machine. I run 'make' after I change my FOAF (adding or dropping foaf:knows) and my FOAF and ACLs are always up to date. I've also toyed with activating the script from crontab, new user signup, pubsubhuhbbub push, and others. I had an agentASK-like predicate in an early version of authz_webid. It was the ugliest thing: a url-encoded SPARQL statement supporting $ENV substitutions but it was awesome stuff. The expressiveness of SPARQL ASK and boolean result made it seem like the obvious Right Way to delegate authz to a full/custom semweb stack that CAN reason (and cache!). very good idea, I like that :) [re ASK] This does however bring up the issue of how to say read access for anybody with a webid - is there any wild card syntax that could be used for acl:agent or suchlike? This is precisely what I use acl:agentClass to do (namely: [] acl:agentClass foaf:Agent) assuming that you can't be an Agent without having a WebID and don't care about the distinctions between client, server, agent, and person. Snap (picked up the example from your paper!) was more thinking about staying clear of owl reasoning inferencing etc, but as henry has pointed out using restrictions etc is a decent way of making things happen - even if I can't personally support it at the minute. Nathan
Re: ACL Ontology and Discussion
Story Henry wrote: On 20 Apr 2010, at 15:52, Nathan wrote: I'd like to propose a few new additions to the ACL Ontology, I won't be specific on names but will describe each one and the associated need. The addition of groups - personally I see no need to define a set ontology for what constitutes a group when dealing with ACL, however it would be fantastic to be able to point to the URI of a Group of WebIDs and the relation, or predicate, that should be used. For example: [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentGroupSource http://webr3.org/nathan#me ; acl:agentGroupLink foaf:knows . I think you can get what you want by using owl reasoning @prefix owl: http://www.w3.org/2002/07/owl# . @prefix acl: http://www.w3.org/ns/auth/acl# . [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentClass :myfriends . :myfriends owl:equivalentClass [ a owl:Restriction; owl:onProperty [ owl:inverseOf foaf:knows ]; owl:hasValue http://webr3.org/nathan#me ] . in this scenario the agentGroupSource is a foaf:Person (me) and the relation to be used as members who have acl:Read access is everybody i foaf:knows. [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentGroupSource /groups#working-group-members ; you probably want a acl:agentGroupSource /groups/#userGroup1 ; acl:agentGroupLink sioc:has_member . [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentClass :wkgrp. :wkgrp owl:equivalentClass [ a owl:restriction; owl:onProperty sioc:member_of; owl:hasValue /groups/#userGroup1 . I'd really like to invest some time in to making better use of owl restrictions, ranges etc however a couple of things are stopping me (at the minute). 1: how do I implement this? I've not seen any tools yet that can handle this level of owl, inferencing and reasoning at runtime easily (to be realistic any implementation would need to have done it's work in a few milliseconds at most to be usable). If there are tools that can do this (even slowly) at runtime at the minute then I'm all ears! :) 2: how does this play with agentClass # Must be subclass of foaf:Agent? Also, even though this is a possibility surely some way of handling groups with simple to calculate methods would be a useful addition to the ontology? - I know that what I've suggested could be implemented with a simple forloop and if-match and that it would cover a huge range of functionality (most use cases I can think of / need at the least). in this scenario the agentGroupSource is a sioc:Usergroup and the relation to be used as members who can Read,Write is sioc:has_member. I'm very aware that there are inverse relations here (sioc:member_of), but strongly feel that we can't be trusting anything in somebodies foaf profile document for ACL, so thus have negated entirely :) That is not a question of the direction of the realtion, but a question of which information you take as reliable. If you don't trust the information from the user's profile, don't merge it into the graph you use to decide who get access to some resource. I've also given the above pretty poor names of agentGroup* in the examples, purposefully to get some input on better names! Next up is acl:agentClass, I'm actually going to suggest deprecation or reserving it for future use, because afaict everything which is requesting access to a resource must be an agent of some kind, Not sure why you think so. The point of agentClass is to link to the set of agents that have access. Seems pretty reasonable to me. point taken, i like the owl route (for research, future implementations etc), but for realistic quick implementations of ACL now surely a keep it simple additional option would help? and if we were to distinguish between Classes of Agent then the only place we can find out what Class an Agent has, is in their foaf profile - which they control. The agent class is not a way of defining the type of the agent, it is a way to define the type of people who will be given access. agentClass a rdf:Property; rdfs:label agent; rdfs:comment A class of persons or social entities to being given the right; rdfs:domain Authorization; rdfs:range rdfs:Class. # Must be subclass of foaf:Agent. So for example you can say that access can only be granted to ex:Admin and I can say I am a foaf:Person, ex:Admin and gain access. That is why one would not use information from your foaf file to decide what class you are in. Presumably the class could be one defined either directly by a URL, which could list all its members, and presumably would be access controlled by someone reliable, or as above indirectly as your friends. In addition access control is a
Re: ACL Ontology and Discussion
On 20 Apr 2010, at 21:13, Nathan wrote: Story Henry wrote: On 20 Apr 2010, at 15:52, Nathan wrote: I'd like to propose a few new additions to the ACL Ontology, I won't be specific on names but will describe each one and the associated need. The addition of groups - personally I see no need to define a set ontology for what constitutes a group when dealing with ACL, however it would be fantastic to be able to point to the URI of a Group of WebIDs and the relation, or predicate, that should be used. For example: [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentGroupSource http://webr3.org/nathan#me ; acl:agentGroupLink foaf:knows . I think you can get what you want by using owl reasoning @prefix owl: http://www.w3.org/2002/07/owl# . @prefix acl: http://www.w3.org/ns/auth/acl# . [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentClass :myfriends . :myfriends owl:equivalentClass [ a owl:Restriction; owl:onProperty [ owl:inverseOf foaf:knows ]; owl:hasValue http://webr3.org/nathan#me ] . in this scenario the agentGroupSource is a foaf:Person (me) and the relation to be used as members who have acl:Read access is everybody i foaf:knows. [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentGroupSource /groups#working-group-members ; you probably want a acl:agentGroupSource /groups/#userGroup1 ; acl:agentGroupLink sioc:has_member . [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentClass :wkgrp. :wkgrp owl:equivalentClass [ a owl:restriction; owl:onProperty sioc:member_of; owl:hasValue /groups/#userGroup1 . I'd really like to invest some time in to making better use of owl restrictions, ranges etc however a couple of things are stopping me (at the minute). 1: how do I implement this? I've not seen any tools yet that can handle this level of owl, inferencing and reasoning at runtime easily (to be realistic any implementation would need to have done it's work in a few milliseconds at most to be usable). If there are tools that can do this (even slowly) at runtime at the minute then I'm all ears! :) You probably don't need to do the reasoning every time. You just need to do it every so often, when you one of the resources you are relying on has changed. Then you fill out the class with all the members and you are done. It all depends how you use it. 2: how does this play with agentClass # Must be subclass of foaf:Agent? foaf:Agent is the set of all agents, if you want. then any class you place as the object of the acl:agentClass relation must be a set of agents, ie a subset of foaf:Agent. That fits in well. In any case what was proposed there is not that different from your proposal. It's just already documented and ready to roll. Also, even though this is a possibility surely some way of handling groups with simple to calculate methods would be a useful addition to the ontology? - I know that what I've suggested could be implemented with a simple forloop and if-match and that it would cover a huge range of functionality (most use cases I can think of / need at the least). You could implement something basic with a for loop perhaps. It's a good exercise. Are you trying to read any restriction that could be found anywhere on the internet? Or are you going to be in charge of the acls? If you are somewhat in charge of the acls, then you can make sure not to create too complex restrictions. You can probably get some of the Java reasoning tools to help you. They do some reasoning, and you can probably get quite far by using owl class descriptions to get you a listing of all the members of your class. That is at its most basic what these owl reasoners do really. in this scenario the agentGroupSource is a sioc:Usergroup and the relation to be used as members who can Read,Write is sioc:has_member. I'm very aware that there are inverse relations here (sioc:member_of), but strongly feel that we can't be trusting anything in somebodies foaf profile document for ACL, so thus have negated entirely :) That is not a question of the direction of the relation, but a question of which information you take as reliable. If you don't trust the information from the user's profile, don't merge it into the graph you use to decide who get access to some resource. I've also given the above pretty poor names of agentGroup* in the examples, purposefully to get some input on better names! Next up is acl:agentClass, I'm actually going to suggest deprecation or reserving it for future use, because afaict everything which is requesting access to a resource must be an agent of some kind, Not sure why you think so. The point of agentClass is to link to the set of agents that have access. Seems pretty reasonable to me.
Re: ACL Ontology and Discussion
Story Henry wrote: On 20 Apr 2010, at 21:13, Nathan wrote: Story Henry wrote: On 20 Apr 2010, at 15:52, Nathan wrote: I'd like to propose a few new additions to the ACL Ontology, I won't be specific on names but will describe each one and the associated need. The addition of groups - personally I see no need to define a set ontology for what constitutes a group when dealing with ACL, however it would be fantastic to be able to point to the URI of a Group of WebIDs and the relation, or predicate, that should be used. For example: [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentGroupSource http://webr3.org/nathan#me ; acl:agentGroupLink foaf:knows . I think you can get what you want by using owl reasoning @prefix owl: http://www.w3.org/2002/07/owl# . @prefix acl: http://www.w3.org/ns/auth/acl# . [] a acl:Authorization ; acl:accessTo /pictures-of-me ; acl:mode acl:Read ; acl:agentClass :myfriends . :myfriends owl:equivalentClass [ a owl:Restriction; owl:onProperty [ owl:inverseOf foaf:knows ]; owl:hasValue http://webr3.org/nathan#me ] . in this scenario the agentGroupSource is a foaf:Person (me) and the relation to be used as members who have acl:Read access is everybody i foaf:knows. [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentGroupSource /groups#working-group-members ; you probably want a acl:agentGroupSource /groups/#userGroup1 ; acl:agentGroupLink sioc:has_member . [] a acl:Authorization ; acl:accessTo /working-group ; acl:mode acl:Read , acl:Write ; acl:agentClass :wkgrp. :wkgrp owl:equivalentClass [ a owl:restriction; owl:onProperty sioc:member_of; owl:hasValue /groups/#userGroup1 . I'd really like to invest some time in to making better use of owl restrictions, ranges etc however a couple of things are stopping me (at the minute). 1: how do I implement this? I've not seen any tools yet that can handle this level of owl, inferencing and reasoning at runtime easily (to be realistic any implementation would need to have done it's work in a few milliseconds at most to be usable). If there are tools that can do this (even slowly) at runtime at the minute then I'm all ears! :) You probably don't need to do the reasoning every time. You just need to do it every so often, when you one of the resources you are relying on has changed. Then you fill out the class with all the members and you are done. It all depends how you use it. 2: how does this play with agentClass # Must be subclass of foaf:Agent? foaf:Agent is the set of all agents, if you want. then any class you place as the object of the acl:agentClass relation must be a set of agents, ie a subset of foaf:Agent. That fits in well. In any case what was proposed there is not that different from your proposal. It's just already documented and ready to roll. Also, even though this is a possibility surely some way of handling groups with simple to calculate methods would be a useful addition to the ontology? - I know that what I've suggested could be implemented with a simple forloop and if-match and that it would cover a huge range of functionality (most use cases I can think of / need at the least). You could implement something basic with a for loop perhaps. It's a good exercise. Are you trying to read any restriction that could be found anywhere on the internet? Or are you going to be in charge of the acls? If you are somewhat in charge of the acls, then you can make sure not to create too complex restrictions. Okay, I'll give it a bash :) had considered implementing for data validation on RDF anyway so maybe now's time to make a start, will report back in a couple days! You can probably get some of the Java reasoning tools to help you. They do some reasoning, and you can probably get quite far by using owl class descriptions to get you a listing of all the members of your class. That is at its most basic what these owl reasoners do really. in this scenario the agentGroupSource is a sioc:Usergroup and the relation to be used as members who can Read,Write is sioc:has_member. I'm very aware that there are inverse relations here (sioc:member_of), but strongly feel that we can't be trusting anything in somebodies foaf profile document for ACL, so thus have negated entirely :) That is not a question of the direction of the relation, but a question of which information you take as reliable. If you don't trust the information from the user's profile, don't merge it into the graph you use to decide who get access to some resource. I've also given the above pretty poor names of agentGroup* in the examples, purposefully to get some input on better names! Next up is acl:agentClass, I'm actually going to suggest deprecation or reserving it for future use, because afaict everything which is requesting
owl:Restrictions in ACL - was Re: ACL Ontology and Discussion
Request for a bit of help / clarification - started implementing.. see
in-line from here..
Story Henry wrote:
On 20 Apr 2010, at 21:13, Nathan wrote:
Story Henry wrote:
On 20 Apr 2010, at 15:52, Nathan wrote:
I'd like to propose a few new additions to the ACL Ontology, I won't be
specific on names but will describe each one and the associated need.
The addition of groups - personally I see no need to define a set
ontology for what constitutes a group when dealing with ACL, however it
would be fantastic to be able to point to the URI of a Group of WebIDs
and the relation, or predicate, that should be used. For example:
[] a acl:Authorization ;
acl:accessTo /pictures-of-me ;
acl:mode acl:Read ;
acl:agentGroupSource http://webr3.org/nathan#me ;
acl:agentGroupLink foaf:knows .
I think you can get what you want by using owl reasoning
@prefix owl: http://www.w3.org/2002/07/owl# .
@prefix acl: http://www.w3.org/ns/auth/acl# .
[] a acl:Authorization ;
acl:accessTo /pictures-of-me ;
acl:mode acl:Read ;
acl:agentClass :myfriends .
:myfriends owl:equivalentClass [
a owl:Restriction;
owl:onProperty [ owl:inverseOf foaf:knows ];
owl:hasValue http://webr3.org/nathan#me
] .
managed to get the above implemented and working, basically this equates
to find the triple:
http://webr3.org/nathan#me foaf:knows users-webid .
if it's there then grant access, else not.
is that correct?? or should it equate to looking for:
users-webid foaf:knows http://webr3.org/nathan#me .
in this scenario the agentGroupSource is a foaf:Person (me) and the
relation to be used as members who have acl:Read access is everybody i
foaf:knows.
[] a acl:Authorization ;
acl:accessTo /working-group ;
acl:mode acl:Read , acl:Write ;
acl:agentGroupSource /groups#working-group-members ;
you probably want a
acl:agentGroupSource /groups/#userGroup1 ;
acl:agentGroupLink sioc:has_member .
[] a acl:Authorization ;
acl:accessTo /working-group ;
acl:mode acl:Read , acl:Write ;
acl:agentClass :wkgrp.
:wkgrp owl:equivalentClass [
a owl:restriction;
owl:onProperty sioc:member_of;
owl:hasValue /groups/#userGroup1 .
managed to get this one in too.. equates to needing:
users-webid sioc:member_of /groups/#userGroup1 .
(hopefully)!
but what I needed in the first place was the opposite, to find the
following triple:
http://example.org/usergroups#group1 sioc:has_member users-webid .
my first thought was..
[] a acl:Authorization ;
acl:accessTo https://ssl.data.fm/index.php ;
acl:agentClass _:group ;
acl:mode acl:Read .
_:group owl:equivalentClass [
a owl:Restriction ;
owl:hasValue http://example.org/usergroups#group1 ;
owl:onProperty [ owl:inverseOf sioc:member_of ]
] .
is that correct?
if so then the foaf:knows implementation above is a bit of a special
case isn't it.. because the inverse of { a foaf:knows b } is { b
foaf:knows a } but the inverse of { c sioc:member_of d } is { d
sioc:has_member c } - different predicates.
I could be (and probably am) wildly wrong here, any clarification?
Best,
Nathan
Re: [foaf-protocols] owl:Restrictions in ACL - was Re: ACL Ontology and Discussion
Nathan wrote:
Request for a bit of help / clarification - started implementing.. see
in-line from here..
Story Henry wrote:
On 20 Apr 2010, at 21:13, Nathan wrote:
Story Henry wrote:
On 20 Apr 2010, at 15:52, Nathan wrote:
I'd like to propose a few new additions to the ACL Ontology, I won't be
specific on names but will describe each one and the associated need.
The addition of groups - personally I see no need to define a set
ontology for what constitutes a group when dealing with ACL, however it
would be fantastic to be able to point to the URI of a Group of WebIDs
and the relation, or predicate, that should be used. For example:
[] a acl:Authorization ;
acl:accessTo /pictures-of-me ;
acl:mode acl:Read ;
acl:agentGroupSource http://webr3.org/nathan#me ;
acl:agentGroupLink foaf:knows .
I think you can get what you want by using owl reasoning
@prefix owl: http://www.w3.org/2002/07/owl# .
@prefix acl: http://www.w3.org/ns/auth/acl# .
[] a acl:Authorization ;
acl:accessTo /pictures-of-me ;
acl:mode acl:Read ;
acl:agentClass :myfriends .
:myfriends owl:equivalentClass [
a owl:Restriction;
owl:onProperty [ owl:inverseOf foaf:knows ];
owl:hasValue http://webr3.org/nathan#me
] .
managed to get the above implemented and working, basically this equates
to find the triple:
http://webr3.org/nathan#me foaf:knows users-webid .
if it's there then grant access, else not.
is that correct?? or should it equate to looking for:
users-webid foaf:knows http://webr3.org/nathan#me .
in this scenario the agentGroupSource is a foaf:Person (me) and the
relation to be used as members who have acl:Read access is everybody i
foaf:knows.
[] a acl:Authorization ;
acl:accessTo /working-group ;
acl:mode acl:Read , acl:Write ;
acl:agentGroupSource /groups#working-group-members ;
you probably want a
acl:agentGroupSource /groups/#userGroup1 ;
acl:agentGroupLink sioc:has_member .
[] a acl:Authorization ;
acl:accessTo /working-group ;
acl:mode acl:Read , acl:Write ;
acl:agentClass :wkgrp.
:wkgrp owl:equivalentClass [
a owl:restriction;
owl:onProperty sioc:member_of;
owl:hasValue /groups/#userGroup1 .
managed to get this one in too.. equates to needing:
users-webid sioc:member_of /groups/#userGroup1 .
(hopefully)!
but what I needed in the first place was the opposite, to find the
following triple:
http://example.org/usergroups#group1 sioc:has_member users-webid .
my first thought was..
[] a acl:Authorization ;
acl:accessTo https://ssl.data.fm/index.php ;
acl:agentClass _:group ;
acl:mode acl:Read .
_:group owl:equivalentClass [
a owl:Restriction ;
owl:hasValue http://example.org/usergroups#group1 ;
owl:onProperty [ owl:inverseOf sioc:member_of ]
] .
is that correct?
if so then the foaf:knows implementation above is a bit of a special
case isn't it.. because the inverse of { a foaf:knows b } is { b
foaf:knows a } but the inverse of { c sioc:member_of d } is { d
sioc:has_member c } - different predicates.
I could be (and probably am) wildly wrong here, any clarification?
figured a bit out i think..
above..
:myfriends owl:equivalentClass [
a owl:Restriction;
owl:onProperty [ owl:inverseOf foaf:knows ];
owl:hasValue http://webr3.org/nathan#me
] .
would equal:
users-webid foaf:isKnownBy http://webr3.org/nathan#me .
if such a thing existed, but it doesn't so to check if users-webid is
known by :me then we have to
http://webr3.org/nathan#me foaf:knows users-webid .
but I think I've just inferred that last bit of knowledge myself, and
that it'd be impossible for a machine to figure that bit out.. because
surely in the case of:
_:group owl:equivalentClass [
a owl:Restriction ;
owl:hasValue http://example.org/usergroups#group1 ;
owl:onProperty [ owl:inverseOf sioc:member_of ]
] .
I'd have to dereference sioc, see if there was an inverse property of it
and then look for:
users-webid sioc:has_member http://example.org/usergroups#group1 .
which isn't what i want and means the two cases above seem impossible to
me at the minute.. looks like I don't need onProperty hasValue but
rather some other something..?
back to owl spec!
Nathan
Re: [foaf-protocols] owl:Restrictions in ACL - was Re: ACL Ontology and Discussion
Nathan wrote:
Nathan wrote:
Request for a bit of help / clarification - started implementing.. see
in-line from here..
Story Henry wrote:
On 20 Apr 2010, at 21:13, Nathan wrote:
Story Henry wrote:
On 20 Apr 2010, at 15:52, Nathan wrote:
I'd like to propose a few new additions to the ACL Ontology, I won't be
specific on names but will describe each one and the associated need.
The addition of groups - personally I see no need to define a set
ontology for what constitutes a group when dealing with ACL, however it
would be fantastic to be able to point to the URI of a Group of WebIDs
and the relation, or predicate, that should be used. For example:
[] a acl:Authorization ;
acl:accessTo /pictures-of-me ;
acl:mode acl:Read ;
acl:agentGroupSource http://webr3.org/nathan#me ;
acl:agentGroupLink foaf:knows .
I think you can get what you want by using owl reasoning
@prefix owl: http://www.w3.org/2002/07/owl# .
@prefix acl: http://www.w3.org/ns/auth/acl# .
[] a acl:Authorization ;
acl:accessTo /pictures-of-me ;
acl:mode acl:Read ;
acl:agentClass :myfriends .
:myfriends owl:equivalentClass [
a owl:Restriction;
owl:onProperty [ owl:inverseOf foaf:knows ];
owl:hasValue http://webr3.org/nathan#me
] .
managed to get the above implemented and working, basically this equates
to find the triple:
http://webr3.org/nathan#me foaf:knows users-webid .
if it's there then grant access, else not.
is that correct?? or should it equate to looking for:
users-webid foaf:knows http://webr3.org/nathan#me .
in this scenario the agentGroupSource is a foaf:Person (me) and the
relation to be used as members who have acl:Read access is everybody i
foaf:knows.
[] a acl:Authorization ;
acl:accessTo /working-group ;
acl:mode acl:Read , acl:Write ;
acl:agentGroupSource /groups#working-group-members ;
you probably want a
acl:agentGroupSource /groups/#userGroup1 ;
acl:agentGroupLink sioc:has_member .
[] a acl:Authorization ;
acl:accessTo /working-group ;
acl:mode acl:Read , acl:Write ;
acl:agentClass :wkgrp.
:wkgrp owl:equivalentClass [
a owl:restriction;
owl:onProperty sioc:member_of;
owl:hasValue /groups/#userGroup1 .
managed to get this one in too.. equates to needing:
users-webid sioc:member_of /groups/#userGroup1 .
(hopefully)!
but what I needed in the first place was the opposite, to find the
following triple:
http://example.org/usergroups#group1 sioc:has_member users-webid .
my first thought was..
[] a acl:Authorization ;
acl:accessTo https://ssl.data.fm/index.php ;
acl:agentClass _:group ;
acl:mode acl:Read .
_:group owl:equivalentClass [
a owl:Restriction ;
owl:hasValue http://example.org/usergroups#group1 ;
owl:onProperty [ owl:inverseOf sioc:member_of ]
] .
is that correct?
if so then the foaf:knows implementation above is a bit of a special
case isn't it.. because the inverse of { a foaf:knows b } is { b
foaf:knows a } but the inverse of { c sioc:member_of d } is { d
sioc:has_member c } - different predicates.
I could be (and probably am) wildly wrong here, any clarification?
figured a bit out i think..
above..
:myfriends owl:equivalentClass [
a owl:Restriction;
owl:onProperty [ owl:inverseOf foaf:knows ];
owl:hasValue http://webr3.org/nathan#me
] .
would equal:
users-webid foaf:isKnownBy http://webr3.org/nathan#me .
if such a thing existed, but it doesn't so to check if users-webid is
known by :me then we have to
http://webr3.org/nathan#me foaf:knows users-webid .
but I think I've just inferred that last bit of knowledge myself, and
that it'd be impossible for a machine to figure that bit out.. because
surely in the case of:
_:group owl:equivalentClass [
a owl:Restriction ;
owl:hasValue http://example.org/usergroups#group1 ;
owl:onProperty [ owl:inverseOf sioc:member_of ]
] .
I'd have to dereference sioc, see if there was an inverse property of it
and then look for:
users-webid sioc:has_member http://example.org/usergroups#group1 .
which isn't what i want and means the two cases above seem impossible to
me at the minute.. looks like I don't need onProperty hasValue but
rather some other something..?
back to owl spec!
figured it - finally.. (?)
_:group owl:equivalentClass [
a owl:Restriction ;
owl:hasValue http://example.org/usergroups#group1 ;
owl:onProperty [ owl:inverseOf sioc:has_member ]
] .
which leaves you looking for the following :
users-webid _:y http://example.org/usergroups#group1 .
_:y owl:inverseOf sioc:has_member .
which afaict does not entail:
users-webid sioc:member_of http://example.org/usergroups#group1 .
because that would be specified by:
_:group owl:equivalentClass [
a owl:Restriction ;
owl:hasValue http://example.org/usergroups#group1 ;
owl:onProperty sioc:member_of
] .
thus in
Re: [foaf-protocols] owl:Restrictions in ACL - was Re: ACL Ontology and Discussion
There has been a lot of work on modeling and using policies of various kinds in RDF and OWL. Some of this goes back to the days of DAML! It's all been researchy and not used outside of research prototypes and demonstration systems, at least to my knowledge. I like the idea of trying to develop something intended for practical use. A few recent research items are the special issue of the Journal of Web Semantics on the Semantic Web and Policy [1], work in the MIT DIG group [2], and an effort to use OWL for role based access control [3]. Maybe some of these, or related work by others, would be helpful. But, it might also be good to start with a clean slate and a focus on usefulness and see what develops. Tim [1] JWS special issue on The Semantic Web and Policy, 2009. http://www.sciencedirect.com/science?_ob=PublicationURL_tockey=%23TOC%2312925%232009%2329998%23800051%23FLA%23_cdi=12925_pubType=J_auth=y_acct=C50221_version=1_urlVersion=0_userid=10md5=45d3a9edef2c6047daf4173151cb40ff [2] http://dig.csail.mit.edu/2009/04/publications.html [3] http://ebiquity.umbc.edu/paper/html/id/387/ROWLBAC-Representing-Role-Based-Access-Control-in-OWL -- Tim Finin, Computer Science and Electrical Engineering, University of Maryland, Baltimore County, 1000 Hilltop Circle, Baltimore MD 21250 http://umbc.edu/~finin fi...@umbc.edu 410-455-3522 fax:-3969 http://ebiquity.umbc.edu/ tfi...@gmail.com
