I suppose it might come as a surprise that I’ve decided to question, if not reject, XFN as the format for expressing portable friends or contact lists. I’m not throwing out the baby in the bathwater here, but rather focusing on the problem that needs to be solved and choosing to redouble my efforts on an elegant solution that builds on existing work and implementations.
My thinking on this crystalized yesterday during the Building Portable Social Networks panel that I shared with Jeremy Keith, Leslie Chicoine, Joseph Smarr and David Recordon. I further defined my realization last night on Twitter and when Anders Conbere pinged me about a post he’d written more or less on the subject, I knew that I was on to something.
The idea itself is pretty simple, but insomuch as it reduces both complexity and helps narrow the scope of evangelism work needed to push for further adoption, I think the change is a necessary one.
→ Quite simply, contact list portability can be achieved with only rel-contact and rel-me. All the rest is gravy.
Here’s the deal: as it is, we have a pretty nasty anti-pattern that a number of us have been railing against for some time (and, as it turns out, with good friggin’ reason). As I pointed out on the panel yesterday, people shouldn’t be penalized for the fact that the technology allows them to be promiscuous with their account credentials; after all, their desire to connect with people that they know is a valid one and has been shown to increase engagement on social sites. The problem is that, heretofore, importing your list of contacts from various webmail address books required you to provide your account credentials to an untrusted third party. On top of that, your contact list is delivered as email addresses, which I call “resource deficient” (what else can you do with an email address but send messages to it or use it as a key to identify someone? URLs are much richer).
The whole mechanism for bringing with your friends to new social sites is broken.
Enter microformats and XFN
The solution we’ve been harping on for the last couple years is a web-friendly solution for marking up existing and (predominantly) public lists of friends, using 18 pre-defined rel values. WordPress supports XFN natively and is one of the primary reasons we started with WordPress as the foundation of the DiSo Project:
Reading up on the background of XFN, you realize that one of the primary goals of XFN was simplicity. Simplicity is relative however, and you have to remember that XFN’s simplicity was in contrast to FOAF, a much denser and complex format based on RDF.
Given all the values (that is, the existing XFN terms) and the generally semantic specificity of XFN, I decided to contrast the adoption of XFN by publishers and by consumers with the competing (and more ubiquitous) solution for contact list portability (i.e. email address import).
If you use Google’s new Social Graph API and actually go looking for XFN data (for example, on Twitter or Flickr or others), you’ll find that, by and large, the majority of XFN links on the web are using either rel-contact or rel-me.
If you’re lucky, you might find some rel-friends in there, but after rel-me and rel-contact, the use of the other 16 terms falls off considerably. Compound that fact with the minor semantic distinction between “contacts” and “friends” on different sites (sites like Dopplr dispense altogether with these terms, opting for “fellow travelers”) and you quickly begin to wonder if the “semantic richness” of XFN is really just “semantic deadweight”.
And, in terms of evangelism and potential adoption, this is critical. If 16 of the 18 XFN terms are just cruft, how can we maintain our credibility, especially when arguing against the email import approach, in which there are little to no semantic descriptors at the time of import (instead, you basically get a dumb list of email addresses — with no clues whatsoever as to which addresses are “sweethearts”, “crushes”, “kin” or the like). It’s not that XFN in and of itself is bad, it’s that, when compared with the reigning tactic of email import, we look as complicated and convoluted as FOAF did. The reality is, even if it’s “heinous” to data purists or pragmatists, email import works today, and what works, wins.
Defining Contact List Portability
The more I talk to Leslie (of Satisfaction), the more sensitive I become to the language that we use when we talk about the technologies that we work on. I mean, what the fuck is an “XFN”? Even “social network portability” probably causes rational people to break out in hives when they hear the phrase (not like we’ve hit mainstream or anything). I mean, from a usability perspective, the words we use to describe this stuff is about as usable as Drupal was five years ago (zing!). I can only imagine that when we technologists open our mouths, this is what goes through most people’s heads:
SO, I’m not advocating ditching XFN altogether; on the contrary, compared with FOAF, I think we’ve achieved a great deal of mindshare, at least in gaining the support of technologists who work on fairly large social sites (though that’s apparently being disputed). The next stage of the process should be to simplify, and to focus on what people are already doing and on what’s working. If we simply want to defeat the email import approach (which I think is a good idea, albeit with the caveat that we still need a notification mechanism — perhaps something easily ignorable like Facebook-app invites?), then I think we need to consolidate our efforts on rel-contact and rel-me and let people discover (and optionally implement) the remaining 16 values if they’re bored. Or have free time. As far as I’m concerned, they offer little to no actual utility when it comes to contact list portability.
So to the definition of contact list portability, I would suggest that it’s the ability to take a list of identifiers (read: URLs, formerly email addresses) that represent people that you know and connect with them in a new context (bonus points if by “taking” you read that as “subscribing” (but not “syncing”)).
This is consistent with Joseph’s Practical Vision for Friends-List Portability. It also importantly ignores the non-overlapping problems of groupings/relationship semantics and permissioning (things which should not be conflated!).
What’s next
Kveton agrees with me; Recordon dissents, wanting more extensibility.
I get Dave’s point, but before we worry about extensibility, we have to look at what minimal bits of XFN are being picked up. By only specifying that an outgoing link is either a “contact” or “another link of mine”, we greatly reduce the cognitive tax of grokking the problem that XFN set out to solve and minimize the implementation tax of rolling out the necessary logic and template changes. Ultimately, it also simplifies the dataset, and pushes the semantics of relationships deeper into applications where I’d argue they belong (again, looking at the Dopplr model as well as Pownce (friends, fans, fan of) and Twitter (following, followers). While the other 16 XFN values are certainly not off limits, their marginal value is negligible compared with the cost of explaining why anyone should care of about them (let along understand them — i.e. “muse”??). And, compared with emails for identifiers, URLs are definitely the future.
So, with that, I’m no longer going to both with advocating for the complete adoption of XFN. Instead, I’m going to advocate for supporting Contact List Portability by implementing rel-me and rel-contact (a “subset” of XFN). And that’s it.
This won’t solve the problems that Anders is talking about, but I think it’s radical simplification that’s been long overdue in the effort towards social network portability.
Factory Joe 
rel=contact and rel=me are the musts – the starting lines. They’re all services like Facebook, Myspace, and Twitter normally give you. I do like the flexibility of marking rel=kin or rel=friend though. Even rel=met.
Not that I disagree or agree with you at this point, but I wonder if some of the problem right now is that there is little to distinguish if someone is a friend (close tie) as opposed to someone that is either an acquaintance or simply someone with an interest in what I have to say.
Social networks seem to not deal with this well. I have information I want to share with friends, but not always with those that are merely interested in what I have to say.
Wouldn’t it be better to have “friends” tagged in a more granular way?
I agree that rel=me and rel=contact are the essentials for weaving the “social graph”. All the other xfn attributes (along with tags) are somewaht more private data and should only used by me to organize the contacts.
I’m not sure wether anyone beside me should now, who belongs to my family. And if it is not for public eyes, why should be it in the markup anyway?
I dig it. When I did my own XFN wire-up, I did use stuff like “friend” and “muse”, but I had to stop and think…is he a friend? What about a muse…yada yada. In the end, rel-contact and rel-me identify the endpoints, and the rest of the stuff can emerge from the relations. Great idea…make it as easy as possible.
It’s like you’re retroactively applying the microformats process (cowpaths).
FWIW, I think most of XFN isn’t that valuable. It’s too complicated and subjective to be obvious but not complete and structured enough (like FOAF) to be useful. rel-me + rel-contact solves the 90% case.
Instead of necessarily trying to capture, define and classify human relationships (WTF muse?) simply capturing the existence of a relationship (rel-contact) is a good first step.
I think more advanced contact list portability work should be centered around user-tagged groups. LiveJournal, Pownce and Facebook all allow users to define groups/sets/lists of contacts and then control privacy and publishing on their content based on those lists.
This is effectively allowing users to tag their relationships. I think that’s an incredibly powerful, useful concept. It’s important to remember that it’s different from tagging a person – I might mark you as “ex-coworker”, but that doesn’t say anything about you – just about our relationship.
We can build all the concepts of XFN on top of this if we need them – and most importantly we can just watch and see what the millions of users already creating this kind of data out there on the web are doing.
Ian
I’m with you. Extensibility is a good thing but it needs a base. Two simple attributes make good base for future extensions.
Complex and convoluted? You read the FOAF spec? It’s got one person-to-person relationship – foaf:knows. It originally had foaf:knowsWell and foaf:friend too but these were dropped.
Chris, I literally began digging into microformats last week. My initial feeling was that rel=”me” and rel=”friend” were pretty much all that is needed.
Question: Once we get DataPortability of private data, can microformats be used to specify levels of privacy? Are the permissions tied globally to people, or is there a special type of permission per content piece? Not sure this is well though through yet, but it sounds like it’s a good time to think this through.
Cheers,
Mike
Tom Morris » Sigh. Why is it that whenever I say something with a 0.01% mention of RDF, you ignore the main point and focus on that minor and inessential component? You could have pointed out that I’m admitting that XFN *is* convoluted! Oy. Anyway, if FOAF was only “knows”, then we could talk. 😉
I take “muse” to mean “fan of,” at least that is how I have been using it. But you are right, I might treat muse, contact, and friend all the same way.
Rather than try and get rid of all of the other attributes that are already out in the wild (and I am guessing you are not suggesting this), maybe it should be the responsibility of the XFN parsing app developers to treat everything as a rel=”contact” except for rel=”me.”
Maybe it is time to put all XFN declarations behind an OAuth layer. Having them out in the public helped XFN to gain traction, but maybe more can be done with them once they are private. This could be a feature in DiSo.
Chris: because that’s my area of interest and understanding. I am not calling into question your main point (it’s probably a lot easier to get rel-contact and rel-me out to social network site owners than the full set of XFN predicates). I’m just trying to make sure we keep the facts straight.
Sorry if it came across as being being petty or squabbly. That was not the intention.
Hmm. I get what you’re saying, but I think it’s insignificant in the face of the broader problem with XFN and other microformats. If I understand you correctly, you’re saying that the complexity of XFN adds so much cognitive load that it will interfere with the adoption of XFN. I just don’t buy that. Here are the types of people who implement XFN.
Group 1: Standardistas and semantic web folks who write libraries that produce and consume XFN.
Group 2: Vanguard developers who write other application libaries and frameworks.
Group 3: People who use what Groups 1 and 2 produce.
Group 4: People who write out or consume XFN by hand.
Group 4 is extremely small and they’re mostly semantics enthusiasts doing one-off implementations for their blogs anyway, so they don’t mind. Group 3 doesn’t care about the complexity you’ve described because they’re mostly abstracted away from it anyway. That leaves Groups 1 and 2.
It seems unlikely that the maverick standardistas in Group 1 are daunted by the prospect of implementing the additional granularity of XFN. And if they are, well, it’s “your” fault.
Yep, I said it. It’s “your” fault where “you” are any person responsible for steering the Microformats effort. When you publish a standard, you’ve got an obligation to provide a set of reference implementations for it, if you want anyone to use it. While I admire the efforts that have lead to the penetration of XFN into the likes of WordPress and Technorati, the folks pushing XFN and other Microformats (as well as many of the folks pushing RDF-based semantics) have unfortunately not done the best job of providing, or at least publicizing, implementations for their standards. And by providing reference implementations, I don’t mean web interfaces like XFN Creator, which are useful for Group 4 developers.
Once you’ve got a set of reference implementations, you can evangelize the standard to Group 2 developers — the David Heinemeier Hanssons, the Adrian Holovatys, etc. Any user who’d be deterred by the complexity of the XFN implementation ought not be seeing it in the first place. Gutting the standard ’til it’s nearly meaningless is a cop-out and will only retard the goals of the Microformat in the long run.
Applications that are generating XFN lists, other than WP, do so based on their own relationship models: you, your contacts. They don’t care if X is your colleague. They care if you want to receive notifications from X, and that’s out of the XFN scope.
But from the user perspective, and this should be about user-centricity, a family-centric social network, or a collaboration application, should be able to subscribe to the relevant portions of an XFN list: kin, colleagues or co-workers.
So, according to your definition of contact list portability, I don’t think you should advocate the use of rel-me and rel-contact only. You should advocate the virtues of XFN subscription. Meaning users having well formed XFN lists at an URL and applications knowing how to filter them. It’s a lot harder, but it’s the real deal, me thinks.
In the meanwhile, considering what isn’t rel-me to be rel-contact might good enough for both users and developers. We’ll still have to agree to who we want to connect to in every application, right? We’ve barely started playing with standards-based social software; we should be user-centric all along the way.
@Jim King: It isn’t just that there’s no much to distinguish between a friend, contact, acquaintance and the like… it’s that there aren’t many use cases that demonstrate the value of porting that kind of data. I mean, let’s presume that there were a meaningful distinction, as in co-worker and co-resident; I can’t think of any site where having access to that data would be all that useful — not on a wide scale anyway. So sure, describing the relationship correctly is a good thing (in general) to do, but as to real data portability, there’s just little value as far as I can see.
@Ian: +1. I didn’t talk about groups or “groupings” but I agree with you, and is also part of the benefit of this stripped down approach. I keep going back to my AIM BuddyLists and how it stores groups that I put people in — using my own language. Whatever kind of groups or tags we apply to people should follow that model.
@Mike Reynolds: While you *can* do that, it’s probably not wise. I just don’t like to mix the semantics of relationships with permissions to “do stuff”. For example just because I add you as a friend on Flickr, it doesn’t mean that I want you to be a friend in another context, with the access permissions of another domain/context. In general I would say that permissions is an order of magnitude more complicated, and as such, once we have contact list portability, we can look at how best to assign the ability to perform certain actions.
@Nick Dynice: Well, that’s how I took it, but I got in trouble in a past relationship for linking to another woman as a “muse”, worse, with a link that existed BEFORE that relationship had begun. So, let’s just say I’d rather avoid any other kinds of interpretation in the semantics of relationships. It’s complicated.
Conflating all other XFN values into “contact” might not hurt, but I’m not sure it’s a great idea just yet. I’d rather focus on promoting rel-contact generally and using that specific data.
As for OAuth, there’s no reason we can’t do that today, and it’s actually what we’re doing with DiSo. So, you can publish whatever public link relationships you want, but also conceal other relationships behind an OAuth gateway.
@Pius Uzamere: I’m saying that 95% of XFN doesn’t do anything useful compared with simply implementing rel-contact and rel-me. The “taxes” that I’m talking about are the perceived costs of doing that implementation; for example, if a developer looks at the docs and has to figure out how to map their existing contact and permission system into XFN, I think they’ll balk and walk away. Instead, if all they have to do is add rel-contact to friends and rel-me to a person’s homepage, it gets a lot easier for me to evangelize.
So, I contest your argument that it’s about libraries. Libraries help if you’re solving a general problem. As I see it, 16 of the XFN values are not universal. And, in terms of “not providing implementations or reference implementations”, you might check out the implementations page on the microformats wiki. In addition, there aren’t lots of implementations because, as I’m arguing here, the entire XFN schema isn’t providing a lot of useful value — and you’re right: if *we* can’t provide compelling use cases and implementations, why on earth would anyone else?
Two points:
– At SmugMug, we have a significantly large percentage of rel-kin in addition to rel-friend. I think that’s valuable data, and shouldn’t be ignored.
– I think you may be confusing “the current state of XFN implementations” with “the future state implementations that XFN allows”.
Many sites, SmugMug included, weren’t built initially to have the granularity that XFN allows. It’s not because we didn’t want to – but because we didn’t realize we could and that it’d be useful in the future. Now that I’ve seen the light, we plan on allowing for better categorization of relationships because I think other apps would find it useful.
I know I, for one, would much rather import XFN with a variety of detailed rel links rather than just rel-me and rel-contact. I get to do better, richer stuff with less user-interaction as a result.
@Don MacAskill: Well, you’re a model citizen then! 😉 I wish that there were more people who shared your vision and interest in the granularity you’re talking about. I still see a problem of transcending contexts, especially if people blindly apply permission models based on XFN values. That said, it would be very neat if Flickr published rel-kin links which could be imported or subscribed to within SmugMug… SmugMug shouldn’t necessarily provide elevated permissions or access to that group, but make it possible for me to apply different levels of access based on those pre-defined groups.
Still, another concern that I have is if I go to import a bunch of “contacts” from Basecamp because I want to share some event photos with them, rel-co-worker doesn’t map to existing semantics within Flickr (or SmugMug). In that case, we now have a lossy data exchange.
I dunno, would love to continue this conversation and if you can provide a compelling implementation example, I’d *love* to see it! 😉
great point. rel=me *by itself* has a lot of power. using a single URL as the entry point to a cluster of URLs that describe me, I can be described by a diverse set of profile pages/services.
i started to write more but it grew into its own post on doncam.livejournal.com. Thank god for David R. to give some tech cred for posting technical topics on a livejournal blog. ha.
@Chris Messina: Thanks for responding.
You directed me to the Implementations page on the Microformats wiki. I’ve followed the wiki for some time, but I revisited it to ensure I haven’t missed anything. I think you’re conflating “implementations in the wild” with “reference implementations.” Let me elaborate on the distinction, as it’s an important one.
Implementations in the wild are the several examples of big players using Microformats. That’s one place where the team is doing a great job. People like you, Tantek, et al do a great job getting the high-profile friends you’ve made at SXSW, FOWA, BarCamps, FooCamps, and all of the other avant garde conferences to adopt your formats. Conversely, the hardcore RDF folks convince all their friends at W3C consortia, #swig, et al to use RDF. That’s also useful.
The problem is that those are not reference implementations. A reference implementation is a library I can install into my app as a baseline for supporting the standard. A standard without a set of reference implementations for the average developer to use is as good as dead. At best, it *only* slows down adoption. We’re seeing that with Microformats. In almost every other firmware/software based industry (and I can personally vouch for the film industry and the government IT industry) the people who write the standards either create the reference implementations themselves or pay people to do it.
OpenID has reference implementations. So does OAuth. As a Ruby developer, I can install gems that quickly get me up and running with the standards. That’s great! Those kinds of libraries need to be created or publicized more for microformats and RDF.
The people who bashed RDF for being too complex were missing the point, so they pushed Microformats and made the same mistakes as the RDF people. That’s why Microformats aren’t used by the average developer even though they’re literally orders of magnitude simpler than RDF-based formats. If Joe Sixpack has to write his own library to implement your standard, he ain’t gonna use it. Joe Sixpack needs a Rails, Symfony, or Django plugin to use, ideally as part of the core framework view helpers.
On the RDF side, I’m trying to do my part with my pre-release library, Tamarind (http://github.com/pius/tamarind/tree/master). Maybe we’ll add Microformats to it.
As to your other point about the other attributes being deadweight . . . speak for yourself! 😉 I’m with Don MacAskill on this: I find the other attributes useful. In my case, I actually use the XFN attributes as a default for my relationship schema! One needs to look no further than Facebook to see a use case for having granular relationships.
As I said before, I think stripping the semantics out of the format is a cop-out. If the cognitive load for XFN is so much, it means you either need to restructure your documentation or improve your reference implementation (or lack thereof). I think rather than take the damaging step of using your influence to get people to dumb down the standard, you should use the influence to rewrite the documentation of the format so that it does not overwhelm implementations or ask the really talented developers behind the current implementations in the wild to open source their libraries so that they can be used and improved.
Oops, “conversely” in the above ought to be “similarly.”
@Alexandre Loureiro Solleiro: Good point. I like the idea of subscribing to subsets of your contact list based on relationships… however, while I agree that defining a subset before hand will help us gain wider adoption, it’s unclear whether that approach is ultimately superior to subscribing to self-defined sets of friends, a la Pownce. The problem I see with a lot of the XFN values is that they seem just as arbitrary (when you expand the use cases beyond blogs, which is the context that XFN was extracted from) as user-defined tags, so why not simplify down to something that a lot more sites are likely to adopt?
THEN, once we’ve convinced them that rel-contact and rel-me are useful, we can begin to add additional granularity.
It isn’t that I don’t value richer semantic links to contacts, only that, in the amount of time we’ve been advocating their adoption, we’ve had little web-wide adoption or even interest (compared, again, with the basic rel-contact and rel-me values). I suppose at this point I’d rather get those two adopted *very* widely and then come back again and see what the semantics of the relationships that are being expressed in the wild are.
Then again, with DiSo perhaps we can demonstrate how this stuff could and should work, and we’ll be able to drive further adoption of the full spectrum of XFN values; in the meantime, I’m just not convinced that it’s worth my effort right now.
@Pius Uzamere: Maybe I should have pointed you here?
http://microformats.org/wiki/parsers
Still, I take your point, and what you’re describing is why Steve Ivy and I started the DiSo Project. I agree that we need reference implementations to demonstrate both use cases and how this stuff should be done. Unfortunately, not being a developer myself, I’m a little hamstrung, being able to primarily contribute mindshare, attention and peer pressure. 😉
So your point about finding the other values useful: any reason why you can’t do the same thing with an xfolk-like contact list schema that supports tags?
All I know, is that when one of my ex’s or previous hookups finds me on Facebook, it’s damn awkward. The cognitive factor alone of trying to appropriately classify a relation with someone is reason enough to go bare bones. Classifying people is a socially awkward excerise.
Good discussion above, thank you.
I agree that I also usually make very low use of the these attributes except me or contact. I also agree that many of the others are maybe not that much meant for public assumption.
But what I’d actually like is a more freeform approach to tag my relationships and port them across networks. E.g. on network X I could say “import everything tagged with business and family”. Or I can use this information to give certain permissions to my assets on a network (think of flickr’s friend and family settings).
To me this fixed list of possibilities if also too limited and expressing what I want to filter, I personally might also like to state from which community I know this contact etc.
So one idea would be to only make “me” and “contact” publically available but also provide custom tags for consumption after another service gets authorized to retrieve them (e.g. via OAuth).
But using custom tags for your contacts would probably be a different standard.
@Pius Uzamere – OAuth and OpenID are /protocols/ XFN et al are /formats/. How could one give a drop-in library for generating XFN? Give it an array of urls and values and get HTML? That’s seems /harder/ for developers.
It might be helpful to think about “WWFD” (What Would Facebook Do? — and if you hate Facebook, insert your favorite site there). Say I’m making a social networking site about pickle lovers called p.ckle (borrowing inspiration from a coworker) and I want to use XFN. I can think of two places I’d immediately need to add it (for in and out):
1. In: When picklelover79 import contacts from somewhere, I use “rel=me” for identity and any other non-empty rel links (maybe even ones that aren’t part of XFN), figure out which ones have p.ckle accounts, and add them as pickle pals. Since users might not want to import everyone (“I don’t think sxalexander understands my passion for pickles”) I would then give them fine-grained control over which of the contacts p.ckle found to import (think a bunch of names and checkboxes).
2. Out: On a user’s public (or private) pickle page that enumerates picklelover79’s pickle pals, I might do two things. If I was lazy, I might list everyone as “rel=contact”. Otherwise, I would just duplicate the XFN tags from the page I imported them from.
I see one big usability problem with how I implemented p.ckle: when importing a lot of contacts, I have no good way to import specific sets of contacts (“I have 500 friends and only 40 of them enjoy pickles”). If tags were completely user defined, when I first added my friends on twitter, I might have tagged them as “pickle-enthusiast”. When I found out about p.ckle it then becomes much easier to import what I want. Each social application could even autotag individuals based on whatever (twitter-import, for instance).
It might be helpful to think about “WWFD” (What Would Facebook Do? — and if you hate Facebook, insert your favorite site there). Say I’m making a social networking site about pickle lovers called p.ckle (borrowing inspiration from a coworker) and I want to use XFN. I can think of two places I’d immediately need to add XFN functionality (for in and out):
1. In: When picklelover79 import contacts from somewhere, p.ckle uses “rel=me” for identity and any other non-empty rel links (maybe even ones that aren’t part of XFN) as potential contacts, figure out which potentials have p.ckle accounts, and then add the ones that do as pickle pals. Since users might not want to import everyone (“I don’t think sxalexander understands my passion for pickles”) p.ckle would give them fine-grained control over which of the contacts p.ckle found to import (think a bunch of names and checkboxes).
2. Out: On a user’s public (or private) pickle page that enumerates picklelover79’s pickle pals, I might do one of two things. If I was lazy programmer, I might list everyone as “rel=contact”. Otherwise, I would just duplicate the XFN tags from the page I imported them from.
I see one big usability problem with how I implemented p.ckle: when importing a lot of contacts, I have no good way to import specific sets of contacts (“I have 500 friends and only 40 of them enjoy pickles”). If tags were completely user defined, when I first added my friends on twitter, I might have tagged them as “pickle-enthusiast”. When I found out about p.ckle it then becomes much easier to import what I want. Each social application could even autotag individuals based on whatever (twitter-import, for instance).
rel=tag FTW
You are incorrect with regards to usage patterns. rel-me is in a different league than rel-contact, which actually does compete with (in this order) rel-friend, rel-colleague, rel-met, and rel-co-worker in terms of usage.
Q.v. http://microformats.org/discuss/mail/microformats-discuss/2008-March/011814.html
rel=contact or rel=me . Simple.
You’re probably right that, for contact list portability, that’s all of XFN that’s needed. The rest of what exists in XFN has very little to do with contact-list portability, though. It was about paving the cowpaths of people expressing their human relationships via hyperlinks, which is a different thing.
So I love that you’re taking the same approach here. As you know, the Microformats ethos absolutely encourages taking pieces of XFN and spinning it off into XPCL (XHTML Portable Contact Lists), or whatever. In fact, doing so with a v1.0 with just those two values meets the immediate practical needs while also leaving the door open to extensibility in future versions, assuming new values are found to be needed.
Plus One for this post.
Let’s take a moment to think about the poor developer writing applications to consume this data. All they’re interested in is rel=”contact” and rel=”me” (and foaf:knows). When they come across rel=”crush” what are they going to do? Another google search to find documentation of whether “crush” is a sub-class of “contact”, followed by yet another case statement. I’m all for adding richness and extensibility but not at the expense of the consumer developer. If we’re going to have sub-types then perhaps the markup should be doubled up. Put both in.
Chris says: “And, compared with emails for identifiers, URLs are definitely the future.” Well, yes, but, most of the use cases for contact list portability involve matching up what you find with what you already know. Unfortunately email addresses are rather good for that and URLs less so. In an awful lot of sites the “Home Page URL” field is either missing or gets filled with a generic company URL. That’s not a very good unique identifier. But even though email is not perfect people always have to put it in, and most people use a single email address on all sites. And again, it’s not perfect but mbox_sha1sum is a pretty good way of passing the unique email identifier while reducing it’s openness to abuse. It’s unfortunate that there’s no obvious way of adding it to the xfn markup.
BTW. Is the OpenID code doing V2 discovery correctly? It picked up the lower priority (higher numeric) entry in my xrds.