Re: [foaf-protocols] ACL Append
Melvin Carvalho wrote: 2010/6/18 Nathan 'If I want to say that I want to be your friend, for example, I could write that as a simple one-line statement into a "friend requests" file which you allow me write access to. In fact, I only need append access, and not even read or general write access to that list.' What would the one line statement equivalent to 'I want to be your friend' be? Following up (rather quickly).. I think we might have the makings of a semantic inbox here.. Given that to Append any information you need to be Identified, thus through FOAF+SSL, the triple accepting process will already know the data the request was made, and the WebID of the Person who's Appending the information. Thus this could simply be a generic triple accepting process which can be used for virtually anything.. if the triple is: <#you> foaf:knows <#me> . then the system or human can read that you know me, your webid can be dereferenced to ensure this is true, and then optionally the human can (or direct the system to) foaf:knows you back. <#you> foaf:knows <#me> . then the system or human can read that you have requested i add this triple to whatever resource I please, it's a statement you want me to make again appropriate action afterwards (if any). <#post> foaf:maker <#me> . A publishing system has just notified that I have been stated to be the creator of something, I can then update the appropriate resource to say I made <#post>, or contact the publisher to argue about the fact I didn't make the post! <#account> sioc:account_of <#me> . Just opened up an account in an application, app has pinged back to say so, I can update appropriately (or be informed that somebody else is trying to open an account in my 'name'). _:b a x:Message ; sioc:content 'how are ya mate!'@en . foaf:maker <#you> . You just send me a message to my semantic inbox.. s p o . Anything! Almost endless scope here - thoughts?? Best, Nathan
Re: [foaf-protocols] ACL Append
Melvin Carvalho wrote: 2010/6/18 Nathan 'If I want to say that I want to be your friend, for example, I could write that as a simple one-line statement into a "friend requests" file which you allow me write access to. In fact, I only need append access, and not even read or general write access to that list.' What would the one line statement equivalent to 'I want to be your friend' be? Good question, needs some though I think - technically is it even a friends request? asking somebody to say that they 'know' you. I think we can safely say that the one line statement should be a single triple, as for the precise contents of it, the webid will need to be in either the ?s or ?o position, and I guess the obvious candidates are: (where #you is the requester, and #me is the the person who is being requested) <#you> foaf:knows <#me> . this one is inverted, but a statement that I know you, thus double functionality - 1 it gives us the ping back to say who is saying they know you, and 2 it can double as a friends request because the human thing to do is 'ahh i know <#you> too so I'll add you to my foaf' <#me> foaf:knows <#you> . depending how you look at it, this ones inverted too, it's basically saying the triple you want me to add to my foaf, I guess this way also has it's own benefits, in that it's like a change request stream to a graph which you can simply run over and approve or disapprove, could have many uses. <#you> x:friendRequest <#me> . Pretty obvious, requires a new ontology and suchlike, limited uses but very specific. _:b a x:FriendRequest ; x:from <#you> ; x:date '2010...' ; x:comment 'how are ya mate, thought we better connect!'@en . Again, very specific, but has the added benefit of strapping on the date, adding in a comment, and whatever else, so quite extendible. Changesets Obvious, handle everything, extendible, could be used as a diff stream, simply append on requested changes. Basically append 1+ reified triple(s) with some annotations to an update request uri. Others? Best, Nathan
Re: [foaf-protocols] ACL Append
2010/6/18 Nathan > Following the recent update of a few of the design issues, one change to > the 'Socially Aware Cloud Storage' [1] introduced (among many other > interesting updates) the following sentence: > Great spot. > > 'If I want to say that I want to be your friend, for example, I could > write that as a simple one-line statement into a "friend requests" file > which you allow me write access to. In fact, I only need append access, > and not even read or general write access to that list.' > What would the one line statement equivalent to 'I want to be your friend' be? > > Hand in hand with this, the ACL Ontology has been updated to to include > a new acl:Append (in addition to the existing :Control, :Read, :Write) > > http://www.w3.org/ns/auth/acl#Append > 'Append accesses are specific write access which only add information, > and do not remove information. > For text files, for example, append access allows bytes to be added onto > the end of the file. > For RDF graphs, Append access allows adds triples to the graph but does > not remove any. > Append access is useful for dropbox functionality. > Dropbox can be used for link notification, which the information added > is a notification that a some link has been made elsewhere relevant to > the given resource.' > > Best, > > Nathan > > [1] http://www.w3.org/DesignIssues/CloudStorage.html > ___ > foaf-protocols mailing list > foaf-protoc...@lists.foaf-project.org > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols >
Re: [foaf-protocols] ACL
> rel="http://www.w3.org/ns/auth/acl#accessControl";; ... > Even if a WAC link relation value was registered, it'd have to state to > expect some form of RDF ACF in response else problems would arise, hence > creation of the aforementioned^^ :) the registry exists to allow authors to make whatever claims they wish about the nature of the response for the registered link relation value. using a 40+ byte URI instead of a 3 byte string makes no difference on the expectations of the caller or the behavior of the responder. but it makes a hell of a difference on the overall bandwidth and network traffic. mca http://amundsen.com/blog/ http://mamund.com/foaf.rdf#me On Fri, Jun 18, 2010 at 17:53, Nathan wrote: > Yup, that's what this is for > > Link: ; > rel="http://www.w3.org/ns/auth/acl#accessControl";; > title="Access Control File" > > as per > http://tools.ietf.org/html/draft-nottingham-http-link-header-10#section-4.2 > > 'Applications that don't wish to register a relation type can use an > extension relation type, which is a URI' > > Even if a WAC link relation value was registered, it'd have to state to > expect some form of RDF ACF in response else problems would arise, hence > creation of the aforementioned^^ :) > > Best, > > Nathan > > mike amundsen wrote: >> >> rel=meta is insufficient. >> >> rel=http://www.w3.org/ns/auth/acl#accessControl is better. >> >> better still would be a registered link relation value [1] (e.g. "WAC"). >> >> [1] >> http://tools.ietf.org/html/draft-nottingham-http-link-header-10#section-6.2 >> >> mca >> http://amundsen.com/blog/ >> http://mamund.com/foaf.rdf#me >> >> >> >> >> On Fri, Jun 18, 2010 at 17:41, Nathan wrote: >>> >>> ACL Ontology has been updated, thus we now have: >>> >>> http://www.w3.org/ns/auth/acl#accessControl >>> 'The Access Control file for this information resource. >>> This may of course be a virtual resource implemented by the access >>> control system. Note also HTTP's header Link: foo.meta ;rel=meta >>> can be used for this.' >>> >>> Best, >>> >>> Nathan >>> >>> Nathan wrote: 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: ; rel="http://www.w3.org/ns/auth/acl#";; title="Access Control File" >>> ___ >>> foaf-protocols mailing list >>> foaf-protoc...@lists.foaf-project.org >>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols >>> >> >> > >
Re: [foaf-protocols] ACL
Yup, that's what this is for Link: ; rel="http://www.w3.org/ns/auth/acl#accessControl";; title="Access Control File" as per http://tools.ietf.org/html/draft-nottingham-http-link-header-10#section-4.2 'Applications that don't wish to register a relation type can use an extension relation type, which is a URI' Even if a WAC link relation value was registered, it'd have to state to expect some form of RDF ACF in response else problems would arise, hence creation of the aforementioned^^ :) Best, Nathan mike amundsen wrote: rel=meta is insufficient. rel=http://www.w3.org/ns/auth/acl#accessControl is better. better still would be a registered link relation value [1] (e.g. "WAC"). [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-10#section-6.2 mca http://amundsen.com/blog/ http://mamund.com/foaf.rdf#me On Fri, Jun 18, 2010 at 17:41, Nathan wrote: ACL Ontology has been updated, thus we now have: http://www.w3.org/ns/auth/acl#accessControl 'The Access Control file for this information resource. This may of course be a virtual resource implemented by the access control system. Note also HTTP's header Link: foo.meta ;rel=meta can be used for this.' Best, Nathan Nathan wrote: 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: ; rel="http://www.w3.org/ns/auth/acl#";; title="Access Control File" ___ foaf-protocols mailing list foaf-protoc...@lists.foaf-project.org http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
Re: [foaf-protocols] ACL
rel=meta is insufficient. rel=http://www.w3.org/ns/auth/acl#accessControl is better. better still would be a registered link relation value [1] (e.g. "WAC"). [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-10#section-6.2 mca http://amundsen.com/blog/ http://mamund.com/foaf.rdf#me On Fri, Jun 18, 2010 at 17:41, Nathan wrote: > ACL Ontology has been updated, thus we now have: > > http://www.w3.org/ns/auth/acl#accessControl > 'The Access Control file for this information resource. > This may of course be a virtual resource implemented by the access > control system. Note also HTTP's header Link: foo.meta ;rel=meta > can be used for this.' > > Best, > > Nathan > > Nathan wrote: >> 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: ; rel="http://www.w3.org/ns/auth/acl#";; >> title="Access Control File" >> > ___ > foaf-protocols mailing list > foaf-protoc...@lists.foaf-project.org > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols >
Re: [foaf-protocols] ACL
ACL Ontology has been updated, thus we now have: http://www.w3.org/ns/auth/acl#accessControl 'The Access Control file for this information resource. This may of course be a virtual resource implemented by the access control system. Note also HTTP's header Link: foo.meta ;rel=meta can be used for this.' Best, Nathan Nathan wrote: 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: ; rel="http://www.w3.org/ns/auth/acl#";; title="Access Control File"
Re: [foaf-protocols] ACL Ontology and Discussion
Joe Presbrey wrote: > On Tue, Apr 20, 2010 at 2:49 PM, Story Henry 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: [foaf-protocols] ACL Ontology and Discussion
On Tue, Apr 20, 2010 at 2:49 PM, Story Henry 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
> 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 > Organization: webr3 > Reply-To: > Date: Tue, 20 Apr 2010 15:05:38 +0100 > To: Michael Hausenblas > Cc: Linked Data community , foaf-protocols > > 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 - > acl:acl 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: ; 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
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 - acl:acl 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
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 >> Organization: webr3 >> Reply-To: >> Date: Mon, 19 Apr 2010 22:37:41 +0100 >> To: Linked Data community , foaf-protocols >> >> 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: ; 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
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 > Organization: webr3 > Reply-To: > Date: Mon, 19 Apr 2010 22:37:41 +0100 > To: Linked Data community , foaf-protocols > > 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: ; 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
