[foaf-dev] for more information please log in
dave at brondsema.net
Mon Jan 14 04:31:39 GMT 2008
Story Henry wrote:
> On 14 Jan 2008, at 00:21, Michael Wechner wrote:
>> Henry wrote:
>>> <> openid:loginForMoreInfo </login> .
>>> --------------------end minimal public foaf----------------------------
>>> A client that retrieves this representation and that recognises the =
>>> relation (or whatever is decided is the best solution to this =
>>> problem), may decide that it is worth it identifying itself (how
>>> would it decide that? Perhaps this is where if I added the bloom
>>> filter described in
>>> http://blogs.sun.com/bblfish/entry/my_bloomin_friends to the above
>>> representation the client could decide that authentication is worth
>>> the trouble...)
>>> Anyway so let us say the client ( Beatnik perhaps ) that is owned by =
>>> Dan Brickley authenticates at <http://bblfish.net/login> with his =
>> how does the client know this URL? Via the openid:loginForMoreInfo
> yes. that was the simple version. At the end of the email I propose
> something a little more general, which does not require different
> representations to be returned, but allows for more information to be
> present in different files. A more sophisticated version of rdfs:seeAlso
>> As said I think via service would be more appropriate, because there
>> are more services than authenticate for more info, but I am very fine
>> to start with something very simple which we can agree on for a
>> prototype ;-) and then start enhancing
> What about:
> <> more:infoAt [ forGroup FriendsOfMyFriends;
> see <http://bblfish.net/people/card/henryFriends>;
> login </login>],
> [ forGroup Family;
> see <http://bblfish.net/people/card/henryFamily>;
> login </login>] .
> </login> a OpenidLoginService .
I like the way this suggestion is headed. I am interested in such a
system as well, as I am planning a webapp for my family to manage
contact info and facilitate communication. It'll be using foaf and I'd
like to expose the RDF in differing amounts to different people.
I assume we could have alternative login types besides
OpenidLoginService. This would allow different authentication systems
to be employed (e.g. oauth, or site-specific one like LinkedIn).
Two small suggestions: I would make the "forGroup FriendsOfMyFriends"
part optional. In some cases it may not be practical to name the group,
and I don't see the advantage of naming the group (except human
readers). For example, if the authentication-required foaf is generated
dynamically there may be complex sets of rules for all sorts of people
and no need or way to name groups.
Secondly, is there a way to use rdfs:seeAlso, so that clients that
already understand that predicate can possibly use this as well? Perhaps:
<> rdfs:seeAlso <http://bblfish.net/people/card/henryFriends>
<http://bblfish.net/people/card/henryFriends> login </login>
<> rdfs:seeAlso <http://bblfish.net/people/card/henryFamily>
<http://bblfish.net/people/card/henryFamily> login </login>
</login> a OpenidLoginService .
If a client doesn't understand the login predicate and optional
OpenidLoginService, it will still request henryFriends and depending on
its handling of the authentication in place it may be able to retrieve
Dave Brondsema : dave at brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 890 bytes
Desc: OpenPGP digital signature
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080113/3b=
More information about the foaf-dev