In an e-mail that he allowed me to blog, Pete Rowley says in response to this post:

You set the stage for modeling your business card and then you model something else - data relationships. Look at your business card, it is a set of attribute/value pairs where sometimes the attribute name is missing but can be inferred through context. The only relationship information there is all inferred from that fact that the data is collected together in one record.

He's right: if all I want to capture is the information on my business card, then a business card is the exact right way of capturing that information. That fact has been proven for sure over a few hundred years. (Side note: funnily enough, some early commenters on LID 1.0 said that in their opinion, LID could only be used for business cards. That view seems to have gone away and I have not heard it in a long time; although the architecture of our InfoGrid product and the LID protocol family is identical to what it was then, except that it has grown.)

Back to Pete's comment. The real-world, hard-paper business card also clearly shows the limits of what can be done with it:

• Many times, I meet people who give me more than one business card, because they are affiliated with more than one business, and the only way this situation can be handled is through multiple business cards. When I get home and try to put the business cards away in my rolodex (which is ordered by company, not by name), I have to separate those two cards and the relationship "the same person gave those to me" is lost, which is unfortunate and which is something I wouldn't want to permeate in the electronic universe.
• Some people cram lots of other information on the card, like their particular expertise, awards they got, the slogan of their employer, a picture, the (one, two or more) blogs they are running etc. While one can argue whether the business card is the place where this information should be, it's clear that some people feel very constrained by the format that such a card can have and they would like to point to other information they consider relevant for receivers of the card. (Which is related to the case why using one's blog as an identity is often such an appealing solution.)
• It is also clear that business cards are not good at all for conveying some of the newer kinds of identity information that people want to convey in identity transactions. Dick Hardt, for example, would like to exchange only his list of favorite books in some identity exchanges. I would like to be able to selectively expose my social network etc. etc. In the physical world, we'd struggle to convey that kind of information on a business card because we'd have to have a lot of meta-data and description around it that would help receivers to understand what all of this information means. Which is of course exactly my point about needing semantic richness and before that, a more powerful representation scheme than name-value pairs.

As digital identity breakes out of the stovepipes, it is not surprising that the requirements become much broader than what worked for stovepipes.

To re-iterate: I'm not saying that name-value pairs can't work for some circumstances. I am saying that they do not scale into many other, particular social, circumstances of digital identity, and because an abrupt data representation change would have to be made, they are an architectural dead end. Going forward, let's have less of them rather than more of them, shall we?