Profile Information

[Christopher Schmidt]

On Wed, May 18, 2005 at 11:13:55AM +0100, Martin Atkins wrote:
> Despite the drawbacks of the approach, using FOAF did have the advantage 
> that it simultaneously provided (optionally) profile information about 
> the identity being presented. Sites could then use this to populate 
> their "name", "email" and "url" fields for the posted comment assuming 
> these items were specified.

And still can (so long as people put a openid:server tag in the FOAF
file): the FOAF information, if it's there, will still be there. I
personally think that OpenID should encourage the use of FOAF to fill
out profile information, with an alternative of having users enter it
themselves. 

Then again, the more FOAF there is, the happier I am, so I may be biased
;)

> Complicating Yadis with profile exchange is almost certainly the wrong 
> approach, though.  Now that the complications are hidden away behind a 
> pretty URL, perhaps the identity server could optionally return a URL to 
> some RDF (which doesn't have to be FOAF, but probably will be for now) 
> as well as some kind of identifier pointing at the right item in the RDF 
> document.

I think that's a good way of doing it: create a minimal description of a
user, such that it's easy to get data out of it, and return it with the
OpenID response:

<Person xmlns="http://xmlns.com/foaf/0.1/"
        xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <nick>crschmidt</nick>
  <weblog rdf:resource="http://crschmidt.livejournal.com" />
</Person>

(this is valid RDF, but also pretty simple: I doubt too many people
would complain about that as being too verbose, other than the second
namespace declaration.)

This way you're making it clear to sites: "We don't want your whole
file. We don't want every piece of information you have on a person. We
want exactly enough to fill out a profile, and no more."

> The nice thing about using RDF is that a new attribute could be added 
> which says "this entity uses this URL as its Yadis identifier" so that 
> the consumer can find the right RDF entity when lots are present. The 
> drawback is that it's a pain to process RDF, and RDF is more complicated 
> than most people are willing to deal with.

I'd really beg to differ on the RDF front, especially if you're going to
constrain it, which is exactly the right thing to do in this kind of
situation. Some things that are hard to parse, which you can kill right
off the bat, because they're just not needed in the limited use case of
OpenID. See above example: it's no more difficult to parse that in an
XML processor than an RDF processor. (Because of the way most RDF tools
work, with needing to create a model and load into that, it might even
kill one line of code.)

The idea that RDF is always hard to process is a myth. You don't need to
encourage the use of every aspect of the RDF spec: use what you need,
and encourage others to do the same.

-- 
Christopher Schmidt
"I don't work here, I just wish I did."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.danga.com/pipermail/yadis/attachments/20050518/dba8571c/attachment.pgp