- From: Henry Story <henry.story@bblfish.net>
- Date: Fri, 9 Dec 2011 15:02:00 +0100
- To: Baptiste Lafontaine <baptiste33@gmail.com>
- Cc: foaf-protocols@lists.foaf-project.org, public-rww@w3.org, WebID Incubator Group WG <public-xg-webid@w3.org>
- Message-Id: <690CB97E-674C-46F6-83FE-9C9F4D6FA2BE@bblfish.net>
On 9 Dec 2011, at 14:44, Baptiste Lafontaine wrote: > I though of a quite different approach : we could define a new ontology (more or less like the ACL one), but defining which website (or something more general) has access to which property of the FOAF Agent. What you are doing here is trying to come up with a way of filtering graphs. Bergi has started work on this so you may want to speak to him on the read-write community group about that. He was thinking of adding relations to the ACL ontology for that. There are many ways one can do that. The issue is not how do you come up with a way of doing it, but whether you need other people to agree with you if you want your service to work. Ie: do other services need to know how you filter your triples? Well I am not sure that is essential for interoperability at the moment. You'd have to come up with a scenario where it was. Your initial question did make a good interoperability point. Every server need an agent to know that they can get more information somewhere if they are authenticated. Since the WebID Profile should not be the one to require Authentication as otherwise we have the potential deadlock situation I mentioned earlier ( you try to get the identity of someone logging onto your web site which asks for your identity then tries to get it from your profile which asks for your identity,.... ) the WebId Profile needs to say that more information is available somewhere else. refs:seeAlso does that, but is very general. It would be very useful to have agreement on this relation. > > It may require the server serving the FOAF file to do a SPARQL query (or something similar) instead of a "basic" server serving a static file. These are all good options to discuss on the read-write-web list. Your point as said above that we need a pointer from the profile to some other document is a good one that we do need agreement for interoperability for the simple reason that we need to be able to tell robots where they can get more information if they authenticate. > > I think I can write up a prototype before the middle of next week. > > Tell me if it sounds stupid or useless. > > > 2011/12/9 Kingsley Idehen <kidehen@openlinksw.com> > On 12/9/11 6:51 AM, Henry Story wrote: >> >> >> On 9 Dec 2011, at 12:03, Baptiste Lafontaine wrote: >> >>> Hello, >>> >>> During the 5th step of actual spec, the WebID verifier contact a distant webserver to get the FOAF file. >>> >>> Obviously, some people don't want to share the same pieces of information depending on who is asking. >>> For instance : >>> - For facebook.com I just want to share my first and last name. >>> - For twitter.com I want to share my friend list >>> - For linkedin.com I don't want to share anything >>> - A more common rules for website I don't know. >>> >>> Is there any work (such as an ontology) done related to this? I've searched in the list archive without success. >> >> >> Good point. That is why currently in the spec (latest editor's draft here >> http://bblfish.net/tmp/2011/12/06/index-respec.html ) >> >> the image has an rdfs:seeAlso to a protected resource. >> >> But I don't think that was discussed, and though it is not wrong, it is probably too general a relation. >> ( Also we don't have it in the rdf serialisations ) >> >> So I think you raise a good point. >> >> The WebID Profile document should not be automatically protected or otherwise we have the potential of deadlocks >> occurring. >> >> Perhaps this should also be specified. >> >> But here I think we need more discussion. > > We need a property in a owl:subPropertyOf relation with rdfs:seeAlso that offers a pathway to an ACL protected resource. > > You can also use owl:sameAs relations, but that brings in a need for reasoning capability on the part of a WebID verifier. This issue is basically ultimately about authorization that factors in pseudonyms via handling of co-references etc.. > > Kingsley >> >> Henry >> >> PS. perhaps that is something the read-write-web group is interested in helping us out with? >> >>> >>> >>> >>> Thanks. >>> >>> Best regards, >>> -- >>> Baptiste Lafontaine >>> Etudiant Télécom SudParis >>> CV : http://magnetik.org/fr/curriculum-vitae/ >>> Mobile : +33 (0) 6 75 30 15 33 >>> >>> _______________________________________________ >>> foaf-protocols mailing list >>> foaf-protocols@lists.foaf-project.org >>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols >> >> Social Web Architect >> http://bblfish.net/ >> >> >> >> _______________________________________________ >> foaf-protocols mailing list >> foaf-protocols@lists.foaf-project.org >> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols > > > -- > > 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 > > > > > > _______________________________________________ > foaf-protocols mailing list > foaf-protocols@lists.foaf-project.org > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols > > _______________________________________________ > foaf-protocols mailing list > foaf-protocols@lists.foaf-project.org > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols Social Web Architect http://bblfish.net/
Received on Friday, 9 December 2011 14:02:35 UTC