Journal tags: xfn

8

sparkline

XEN

I’ve published a transcript of the panel I moderated at South by Southwest this year. The subject was Building Portable Social Networks and I had a blast moderating, mostly due to my great co-panelists, Chris Messina, Leslie Chicoine, David Recordon and Joseph Smarr.

During the panel, I made reference to an ongoing joke by Brian and myself to do a negative version of — an XHTML Enemies Network. I always thought of it as a frivolous idea but sometimes I wonder if there might be the occasional real-world use case.

Suppose, for instance, that I wanted to link to Mike “The Dick” Arrington’s latest bit of bollocks over on TechC*nt? Well, now I can add some extra semantic richness to that link by throwing in the appropriate rel value.

I give you the XEN 1.0 profile.

Please note the fine print:

XEN is not a microformat. It is a joke.

MicroformatID

Tom Morris was in town today today so I invited him to take shelter from the miserable weather ‘round at Clearleft Towers. Which reminds of something Tom showed me at BarCamp Brighton that I’ve been meaning to share for a while now.

Tom has an hCard on his blog. By default the information provided is fairly basic: an email address, a URL and a vague physical address. Right by the hCard, there’s a simple form that allows you to log on using OpenID. If you log on and you’re on a white list of Tom’s friends, the hCard is updated to reveal more information: telephone numbers and a complete physical address.

That’s pretty clever. And when you consider that OpenID is a URL-based authentication system and XFN is also based around URLs, it would be pretty easy to have the white list correspond to an XFN list on the same page as the hCard.

hCard | OpenID | XFN… it’s like Unix pipes for the Web: small pieces, loosely joined.

Portability

In case you hadn’t noticed, I’ve got a real thing about portable social networks. And I’m not the only one. At a recent meetup in San Francisco a bunch of the Web’s finest minds got together to tackle this issue. You can track the progress (and contribute) on the microformats wiki.

Ever since then, Brian Oberkirch has been doing a sterling job documenting the issues involved:

Head on over there, read what Brian has to say and join in the conversation in the comments.

Lest you think that this is some niche itch that needs to be scratched, I can tell you from personal experience that everybody I’ve spoken to thinks that is a real issue that needs tackling. Heck, even Wired News is getting upset in the article Slap in the Facebook: It’s Time for Social Networks to Open Up:

We would like to place an open call to the web-programming community to solve this problem. We need a new framework based on open standards. Think of it as a structure that links individual sites and makes explicit social relationships, a way of defining micro social networks within the larger network of the web.

Weirdly, the same article then dismisses XFN, saying Trouble is, the data format doesn’t yet offer any tools for managing friends. That’s kind of like dismissing HTML because it doesn’t offer you a way of managing your bookmarks. XFN is a format—a really simply format. Building a tool to manage relationships would be relatively easy. But you have to have the format before you can have the tool.

Mashed

It sounds like Mashup Camp was a hive of very productive activity. Kevin Lawver gave a presentation on portable social networks but instead of just talking about it, he wrote some Ruby code. Kevin is using OpenID for log in, followed by hCard parsing and XFN spidering (see also: Gavin Bell’s work). Superb stuff!

Meanwhile, Plaxo is now supporting OpenID and microformats thanks to the efforts of Kaliya and Chris.

And just in case you think that this is still a niche geek thing, here are the job details for Program Manager of Internet Explorer over at Microsoft:

Does the idea of redefining the role of the Internet browser appeal to you? Do the terms HTTP, RSS, Microformats, and OpenID, excite you? If so, then this just might be the opportunity for you.

Bedrolling

One of the great things about having an international event like @media taking place in London is that I get to see so many of my North American friends without having to cross the Atlantic. I made the most of the opportunity to hang out with Dan, Tantek and Shawn while they were in town. I even went so far as to abduct Jason and Joe and bring them down to Brighton.

Before bundling them on a coastbound train, Jessica and I showed them the treasures of the British Library, a collection to warm the heart of any typography geek. We browsed through documents ancient and new, peering at the letters written down for posterity (Scott’s journal always give me the heebie-jeebies, opened as it is on the last page which reads “For God’s sake look after our people.”)

Once we reached my adopted hometown, they engaged in all the usual tourist activities, mostly involving tea and beachfront promenading. Despite my best efforts, I couldn’t convince Jason to try jellied eels.

I have a tradition here at adactio.com. Whenever I have a guest over, I add them to my bedroll; kind of like a blogroll but with a higher barrier to entry. Needless to say, this bedroll is marked up with XFN to describe my relationships to each guest, and hCard to supply contact information.

Usually when I mark up somebody’s name, I can use fn optimisation, like this:

<li class="vcard">
<a rel="friend met colleague"
href="http://joeclark.org/" class="fn url">
Joe Clark
</a>
</li>

Technically speaking, the n property is required in a vcard (and hCard is a 1:1 representation of vcard) but when fn is applied to a string like this, parsers can assume that the string before the space is the given name (Joe) and that the string after the space is the family name (Clark). This pattern fits the 80/20 rule pretty well: it works for about 80% of use-cases. There is an implied n value.

This will work as long as there is a string with a single space in the middle of it. Jason’s name throws up an interesting case. There are two spaces in “Jason Santa Maria.” How should parsers interpret this? Is it safe to assume that “Santa” is a middle name? Clearly not in this case.

So I have to explicitly mark up Jason’s given and family name like this:

<li class="vcard">
<a rel="friend met colleague"
href="http://jasonsantamaria.com/" class="n url">
<span class="given-name">Jason</span>
<span class="family-name">Santa Maria</span>
</a>
</li>

Mind you, “Jason Santa Maria” is his formatted name so I can still add the fn value:

<li class="vcard">
<a rel="friend met colleague"
href="http://jasonsantamaria.com/" class="fn n url">
<span class="given-name">Jason</span>
<span class="family-name">Santa Maria</span>
</a>
</li>

Jason has one of those double-worded family names, like Thomas Vander Wal. But it’s completely different to other three-word names such as “Mark Norman Francis”:

<li class="vcard">
<a rel="friend met colleague"
href="http://cackhanded.net/" class="fn n url">
<span class="given-name">Mark</span>
<span class="additional-name">Norman</span>
<span class="family-name">Francis</span>
</a>
</lI>

See, Norm!’s middle name is defined as additional-name.

hCard still has enough semantic richness for me to add Jason’s middle name—which I happen to know is “Andrew”—should I wish to:

<li class="vcard">
<a rel="friend met colleague"
href="http://jasonsantamaria.com/" class="fn n url">
<span class="given-name">Jason</span>
<span class="additional-name">Andrew</span>
<span class="family-name">Santa Maria</span>
</a>
</li>

So hCard scales up pretty well to some edge-case scenarios. That said, there is no confirmation-name property so I can’t easily add that particular bit of extra information. Jason’s confirmation name is… Andrew.

That’s right: his full name is Jason Andrew Andrew Santa Maria.

See, it’s traditional at confirmation time to choose a new middle name. But Jason obviously felt that he had enough words in his name. So his logic runs like this… “If, for my confirmation name, I choose the name Andrew—which is already my middle name—then it won’t actually count as a new name.” Alas, the system doesn’t quite work that way. And so Jason ended up with the same name (Andrew) repeated twice in the middle of his name.

I suppose I could double up both Andrews into a singe additional-name field like this:

<li class="vcard">
<a rel="friend met colleague"
href="http://jasonsantamaria.com/" class="fn n url">
<span class="given-name">Jason</span>
<span class="additional-name">Andrew Andrew</span>
<span class="family-name">Santa Maria</span>
</a>
</li>

But that’s probably overkill and anyway, Jason probably doesn’t want to broadcast his full, somewhat repetitive name. So it’s probably best if I don’t even mention the whole “Andrew Andrew” thing. Forget I ever said it.

In any case, it’s my pleasure to add Stan to the bedroll. Joe was already on there: he has the distinction of being the only one to have stayed over at my previous flat as well as my current abode.

I wonder if I should make the bedroll more like a tag cloud: the more often you stay, the larger your name appears. Brian, Joe and Norm!—all of whom have stayed more than once—would then all appear in a larger font size while Elsa—who just napped on the sofa—would be rendered smaller.

Nah… silly idea. But I will keep the bedroll going when I move into my next flat which hopefully won’t be too traumatic a move. I’ll be looking at some more potential properties tomorrow. Wherever I lay my sofa-bed—and unfold it when my fellow geeks come to visit—hat’s my home.

More thoughts on portable social networks

I’m not the only one thinking about portable social networks:

There are some good comments on these posts ‘though I keep noticing the trend for things to get too complex too quickly. Tom Carden mentions FOAF but I have a number of issues with that:

  1. Publishing XML is hard, certainly harder than publishing HTML.
  2. Out of sight is out of mind. I’ve actually got a FOAF file here at adactio but I haven’t updated it in years. Invisible metadata rots.

A lot of people are talking about the need for some kind of centralised service (ala Gravatar) for storing a social network. But surely the last thing we need is yet another walled garden or roach motel?

I’d much prefer a distributed solution and, frankly, I wish Gravatar had gone down that route given its often slugglish ways. I realise that a centralised service is needed for people who don’t have their own URL but it should, in my opinion, be second choice rather than default.

In any case, I think we may be barking up the wrong tree with all this talk of needing something new. Personally, I don’t think the solution need be complicated it all. It’s within reach right now and it doesn’t require the creation of any new service.

Suppose, just suppose, that…

… were marked up with XFN (update: or more importantly, hCard—see below). Now all I have to do is provide one of those URLs to the next social networking site I join.

Far fetched? Two of the sites I listed are already walking the walk. All that’s needed is for the sign-up form on the next fadsite I join to at least include the option of importing a buddy list by pointing to a URL.

Sure, it won’t work perfectly. People might have different names from site to site. But that’s okay. It’ll work good enough. It will probably get 80% of my contacts imported. And that’s a lot better than the current count of zero.

We don’t need yet another centralised service. The information is already out there, it just needs to be explicitly marked up.

Once you populate a network on one site, that information should be easily portable to another site. That’s doable. It isn’t even that hard: all it requires is the addition of a few rel attributes and possibly some hCard encoding.

Let’s not go chasing a complicated solution when a simpler one will do.

So here’s my plea—nay, my demand—to the next Web X.X social networking doohickey that wants me to join up:

  1. Give me a simple input field for entering a URL that lists my contacts.
  2. Parse that URL for people and relationships.
  3. Voila! I’ve added a bunch of friends. I may repeat from step one with a different URL.
  4. Markup my contacts on your doohickey in an easily exportable way.

Who wants to get the ball rolling? Why can’t this become as ubiquitous as gradients, closed betas, giant text and wet-floor reflections?

For all the talk of social media and the strength of weak ties, there isn’t much action being taken to really try to “harness collective intelligence®”. Within the confines of their own walls, these Web X.X sites might be all about social this and social that, but I want to see more sites practice what they preach on a wider scale… the scale of the World Wide (semantic) Web.

Update

Following on from some comments and Twitter chat, I wanted to clarify a few points:

  1. Yes, social networks differ depending on context. That’s why I want the ability to point at more than one URL. If I join up to a new music site, I might want to point to my Last.fm contacts, but not my Flickr contacts. If I join a new site about food or drink, I’d probably want to point to my Cork’d drinking buddies, but not my Linkdin network. Or I might want to point to any combination thereof: Flickr + Twitter - Last.fm, for example.

  2. The issue of whether the people you’re adding even want to be your friend is a red herring. That’s an issue regardless of portability. I can quite easily add people as my friends on Flickr who don’t want to reciprocate. The same goes for Twitter. Portability will allow me to add friends en masse but it won’t ever automatically add me as a friend to the people I’m importing: that’s still up to them.

  3. No, this won’t move 100% of contacts from network to network. But it will move a lot. My user name is adactio on Flickr, Last.fm, Twitter, Upcoming, Technorati and Cork’d. I suspect a lot of people use the same user name across sites. For sites that use real names, there’s an even greater chance of portability.

  4. None of this portability is irreversible, it’s just a shortcut. If I get false positives—people imported that I don’t want as contacts—I can just remove that relationship. Likewise if I fail to import some people automatically, I’ve still got the old-fashioned way of doing it by hand (which we all have to do now anyway).

  5. Forget about XFN for a minute. The important thing is that I’m pointing to a page and saying, “any people listed on this page are contacts I want to import.” Now, there is no <person> element in HTML so how does it know which strings are people? Well, we need some way of saying “this is a real name”, or “this is a nickname”. We have that already: class="fn" and class="nickname". These are properties of hCard. So I guess it’s hCard usage that really matters. That said, XFN can added an extra level of granularity: contact vs. friend, at least. But I stand corrected: the really important formatting issue here is marking up “who are the people on this page?” rather than “what are the relationships on this page?” The URL itself contains the information that everyone listed is a contact.

Just take a look at these URLs:

  • http://corkd.com/people/adactio/buddies/
  • https://www.flickr.com/people/adactio/contacts/
  • http://last.fm/user/adactio/friends/

A semantic consensus is already emerging across sites in URL structure:

http://site name/[people|user]/username/[buddies|contacts|friends]/

All that’s needed is to explicitly mark up any people on those pages. That’s easily done with hCard. All these sites have to do is edit a template. For extra relationship richness, XFN can help.

Backnetworking

Reading through the post-d.Construct buzz, I see a number of recurring themes:

  1. The seats were too narrow.
  2. The badge incorporating the programme was ingenious.
  3. The Backnetwork rocked.

I’m certainly in agreement with that third point. Every conference should have an app like the Backnetwork.

I exchanged a couple of business cards over the weekend but really, it wasn’t something I needed to worry about. I knew I could just go into my network and download any vCards (via hCards) that I wanted.

It’s fun watching the Backnetwork fill up with Flickr pics, blog posts and reviews as attendees document their time at d.Construct. For my part, I’ve been updating my list of contacts to incorporate more people that I met over the weekend.

Thanks to the magic of XFN, here’s a microformatted incomplete list of the wonderful people I know from d.Construct, copied and pasted from my profile:

Bedroll

The blogroll is a common component to many blogs. It’s a sociable idea: a sort of recommended reading list of blogs by other people.

To North Americans, the word blogroll is a nice play on words on logroll. To European English speakers, however, it sounds regrettably similar to bog roll (bog as in toilet, roll as in paper).

I’ve never had a blogroll here at Adactio, but I have decided to a list of links to other blogs. Here’s the catch though: I’m only linking to people who have stayed in my house. I’m calling it my bedroll.

It is, of course, XFN friendly, even though it’s a foregone conclusion that everyone will have rel="met".

I’ve also marked everyone up with hCards. If you have a blog/bog/bed roll, I encourage you to the same. Here’s an example:

<li class="vcard"> <a class="fn url" href="http://designrabbit.com/" rel="friend met">Cindy Li</a> </li>

Wanna get on the ‘roll? Well, ya gotta come visit me. Wanna come visit me? Well, you might have to hold off for a little while… Jessica and I will be moving in to a new place at the start of next month. First thing we’ll do is get a nice comfy sofa. After that, normal service will return at Geek Central Station… we’ll be sure to register our new abode at Can I Crash?