At first, the news about how LinkedIn is going to start charging for tying job listings into its social network didn't strike me as blogworthy. But the more I thought about it, the more I wondered what the long-term prognosis will be for companies like LinkedIn, Ryze, and Plaxo that run hub-n-spoke relationship management databases. You're the hub to yourself but a spoke to your contacts; your contacts are spokes to you, but hubs to themselves. If we chain hub and spokes together, then--via Kevin Bacon-like six degrees of separation--you could get introduced to a friend of a friend (by the second friend) or a friend six times removed with the chain of people in the middle whispering into each other's ear and handling the introductions. It's like what happens when a single guy attending a wedding spots a single girl that he wants to meet and has to figure out the chain of people he must go through to get introduced. The bride or groom are usually the fastest route, but not always accessible. With networks like LinkedIn, there's always an alternative path.
Not a week goes by where I don't get an invitation from one of these or other services like Orkut and Accucard to update an electronic Rolodex card that someone else is keeping about me. If I register with the services and set up my own Rolodex cards on each of the 18 services (or whatever the number is), then theoretically, my inbox won't be littered with so many requests. That's because the people on LinkedIn who are trying to keep track of me can just point to the LinkedIn Rolodex card that I maintain for myself -- rather than each of them maintaining their own card for me. (Rolodex must be hating how I'm using their brand name the way Kleenex is used to describe all tissues, Vaseline is used to describe all petroleum jellies, and Band-Aid is used to describe all self-adhesive bandages.)
Unfortunately, having to maintain central Rolodex cards on 18 different services doesn't make my life that much easier. First, I can't keep track of what I'm agreeing to when I enter information into all of these sites. Second, I have enough trouble remembering my login IDs and passwords for all the different sites I already visit. Now, I have to remember to visit 18 different social networking sites to maintain my personal data everytime something about me changes? Well, actually, that is better than having hundreds of people from each of those 18 sites asking me to update the private Rolodex card they're keeping for me. I'd much rather keep my own Rolodex card somewhere, say, on my blog, where I don't have to pay anybody for anything and the only thing I need to agree to is what's in my head. Then, you should have a choice of how to connect to that information from your online presence. Maybe that's your blog. Or maybe it's just your contact management software.
The blog-to-blog connection is an interesting one. Today, there's a lot of back-and-forth hyperlinking, trackbacking, and pingbacking between blogs. Based on that pointing, we can imply, at bare minimum, a unidirectional awareness relationship. I can't really point to you unless I'm aware of you. You could enter a comment on my blog (or use trackback) that indicates your awareness of me, but just because you're showing up on my blog doesn't automatically imply that I have any pre-existing knowledge of you. In this sort of loosely coupled world, services like LinkedIn and Plaxo take the "loose" out of loosely coupled. But moving forward, could a protocol instead of a service handle the coupling?
The reason I ask this is because of a handy little microformat known as XFN. XFN stands for XHTML Friends Network and, as the name implies, it's a union of a protocol (XHTML) and the concept of friends. Without going into too many technical details, XFN makes it possible for me to describe the nature of my relationship to someone else when I point to their virtual presence on Internet (Web site, blog, etc.). Using the XFN microformat, I can encode into any hyperlink that the person I'm hyperlinking to is a sweetheart, a colleague, a family member (child, parent, etc.), an acquaintance, etc. (there's a more complete list of currently permitted values known as the XFN profile). Now, imagine that instead of joining Plaxo, LinkedIn, Friendster or any one of the other umpteen social networking services, everybody was just pointing to everybody with these very granular and freely usable tags.
Not only wouldn't Harry have to discover the six degrees of separation needed to meet Sally (any link crawler could do that for Harry) and not only wouldn't we need all those services to keep track of the relationships, we'd have much more information about the nature of the relationships. This, in turn, enables some interesting ideas. For example, as a description of a type of romantic connection, "crush" is one of the permitted XFN values. Theoretically, not only can Harry indicate that he has a crush on Sally, but he can see, based on who else has made the same indication, who he must "elimidate" in order to win Sally's exclusive affections.
One of the most common uses of XFN will be in blogrolls -- those long lists of links that bloggers use to point to other bloggers. The various pages on XFN talk about this usage. However, as easy as it looks to implement, some changes have to be made to various authoring tools before people will adopt the idea en masse. For example, the blog authoring tool I'm testing for my media transparency channel (Radio Userland) auto-generates blogrolls using a built-in outliner. But, in the course of entering the information that results in my auto-generated blogroll, there's no easy way to enter any optional hyperlink attributes such as alt or rel (the rel attribute is what's used to indicate an XFN-based relationship). So, for now, my blogrolls are XFN-less. Ultimately, blogroll generators should come with explicit XFN support. For example, I can imagine an XFN menu in the dialogue box. Web-based RSS aggregation provider Blo.gs is one company that's ahead of the curve in this respect, explicitly providing XFN support in its blogroll generator (I haven't tested it).
By now, you might have noticed that there's one thing that the Plaxo-like sites have that XFN does not: structured contact data (address, phone number, etc.). This problem could be easily solved by standardizing on a way to find my XML-based contact record -- an idea that dates back to 2001 when some people first started thinking about the marriage of the vCard contact record standard to XML. The O'Reilly Network has a year-old post entitled Getting in Touch with XML Contacts that does a really good job of explaining the progress that's been made in the area of XML-based contact data, including mention of a 2001 proposal to the W3C which doesn't appear to have advanced through the standards setting process. (Let me know if you know differently. Update: In response to this blog entry, Technorati's Tantek Celik, the primary author of the XFN microformat wrote to me in e-mail to tell me about the lastest incarnation of XML-based vCards known as hCards. His blog provides more details.) There has, however, been some more recent activity on the Perl front when it comes to generating XML vCards.
Suppose that most blog and Web presence authoring tools had the ability to generate XML-based vCards hCards . (Heck, even Outlook could be the authoring tool.) Then the only question would be how to make them easy to find by others (a problem that's so easily overcome in a number of ways, I'm not going to bother discussing it). But the proof that we can do it is showing up in the OPML world where, for example, by way of transclusion, entire directories are being built off of separately maintained (and located) OPML files. The automated directory-building code just needs to know (and in many cases does) where the OPML can be reliably found. In other words, it should be relatively simple for some piece of software that isn't written yet to crawl the multiple degrees of the XFN network (I'm an acquaintance of Harry who has a crush on Sally) and, by way of transclusion, create and keep up to date my very own private version of Plaxo without ever needing Plaxo in the first place.
For me, this makes a lot more sense because I only have to update my XML vCard hCard and the rest takes care of itself. At the bottom of the XFN info page is a section called "Delusions of Grandeur" that has two bullet items in it. The first of these says:
For the sake of disclosure, "Friendorati.com" is registered to Wordpress chaperone Matthew Mullenweg who is a CNET Networks employee and, from the looks of the XFN site, is also a contributor to the XFN specification. CNET Networks is the parent company to ZDNet. Mullenweg and I have never discussed XFN. (But I can imagine how I might have been enable to encode that disclosure using XFN!)
Update: Looking at the XFN profile, it suddenly dawned on me that perhaps there should be an XBN/XB2BN that's strictly for the relationships between businesspeople/businesses. Thoughts?