Really Simple People

Posted to the social-network-portability mailing list, December 14, 2007.

Ben Werdmuller wrote:
I would argue, strongly, that user data needs a more flexible,
permissive format: an RSS for people, rather than something rigid and
RDF based. Where it makes sense to add extra format detail to a field,
like locations or contact details, it should let you do so. But no
data should ever be rejected because it doesn't fit into the model.

Seconded. This domain is becoming needlessly complicated.

I have argued in the past for a 'Really Simple People' format. RSP.

Here's one:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<name>Stephen Downes</name>

This file should be located in some obvious places. If you have an OpenID, for example,

put it here:

or put the address in the head your home page ( here, right beside your RSS:

<link rel="alternate" type="application/rsp+xml" href="" />

and in your RSS file, put it in the head (as the author of the feed) or the item (as the author of the item):

<author rsp="" />

or put the OpenID in the same place, since it leads to RSP

<author OpenID="" />

this is dead simple and introduces agency to the (semantic) web. Numerous graphs can be generated by tracing connections between resources and authors and back again. Friend list can be *derived* from such agency, rather than explicitly created.

But if you want to create friends:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">

<friend rsp="" />


<friend OpenID="" />

If you wish, you can add a typology to friends. Some examples:

<friend OpenID="" relation="family" />

<friend OpenID="" type="best friend"/>

<friend OpenID="" topic="knitting"/>

That's it. That's the whole of the specification.

Oh, sure, you could add some obvious fields to RSP, like:

<home phone>

and the like. There's no reason to be really precise about this list, especially at first. See what falls out in actual usage.

And additionally, it would be possible to extend the specification using namespaces, just likie RSS. So you could add API for messages and comments, iTunes playlists, more...

<?xml version="1.0" encoding="UTF-8"?>
<rsp version="1.0"

I understand why things in the OpenID space and the social network portability space have become so complicated so quickly. We want to be ale to do a lot, and do do it reliably and securely.

But open and simple should be the default. Don't make the tightly secured athenbtication required etc etc version the default. Even simple things - like, say, email sha1sum, are a real pain for people who don't care to encrypt their email. Allow the use of an email sha1sum field, certainly, but don't make it the default in the format.

Anyhow, end of rant. If you did this, you'd get your portable social graph. Or conversely, to the extent that you're not doing this, you are pushing a portable social graph further and further from reality, pushing it into the hands of specialized agencies such as Facebook and Google.


  1. I wrote up something similar to this last March -- although I looked at it from the place of storing the data first and then generating the xml from that stored data. This info needs a user-controlled place to call home, and without the ability for people to easily install a front-end to manage this info, we're more or less back where we started: with a great mechanism for carrying our social graph that is beyond the reach of all but the more technical web users, or of companies that build a web app that supports these protocols (ie, making the open standard into another tool used by content silos).

    My initial writeup is here -- I haven't really touched it much since last spring.

    My thinking is that having this as part of a tool that could be installed within Wordpress, Drupal, etc, would go a long way toward making this accessible for a larger number of people.

  2. I don't understand Ben's comment at all. RDF is much more flexible than plain XML. RDF parsers will happily ignore ignore unexpected data. If you toss a FOAF file with other random RDF statements into an RDF data store, it'll organize and store all the extra data, and if you give it the relevant RDF schemas, it'll draw inferences based on it. Or just ignore it, if that's ok with you.

    XML parsers, on the other hand, are much more likely to be brittle.


Post a Comment

Your comments will be moderated. Sorry, but it's not a nice world out there.

Popular Posts