Thu 1 Jun 2006
Johannes Ernst has blogged about my email to him concerning his blog on modeling identity data. I pointed out that in his original post he said he was modeling his business card but what he actually modeled were complex relationships not contained on a business card. His reply has three main points, and I will bite.
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.
These issues are a function of the physical limitations of the business card. We are discussing digital identity where such limitations, if imposed, are artificial. Unique identifiers are all that is required to ensure that I know two sets of information refer to the same entity. It is a rare unique identifier indeed that cannot be stored in a name value pair, and an even rarer one that a set of name value pairs are insufficient.
- 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.)
So people want to share their information and what information they wish to share is determined by context. Not seeing an argument against name value pairs here.
- 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.
It really isn’t clear at all to me why Dick Hardt can’t store his list of books in name value pairs, it is a list. Now, without conflating real world - digital world issues I would really like to know what the magic pixie dust is that conveys semantic richness upon XML et al without also having the same effect on name value pairs. Higher intrinsic expressiveness I will grant (along with additional complexity) - but semantic richness? It really doesn’t matter how Dick stores his book list, in order to make sense of it I will have to know what it is and how to work with it. And by the way, the computer will be doing that work.
In any case, let’s not model business cards. I want to see a real case that plausibly knocks name value pairs out of the solution matrix for identity data - not because I don’t think it exists, but because I believe ramping up the complexity requires real justification.
2 Responses to “Modeling Identity Data”
Leave a Reply
You must be logged in to post a comment.

June 2nd, 2006 at 6:59 pm
Intereting points…I am, however, a bit bothered by the assumption that name/value pairs are less complex. I’m not convinced theirs clear basis for that claim.
While name/value pairs look simple, a quick peek below the surface seems to turn up a slew of issues which causes their complexity to skyrocket in any realistic scenario.
* No language independant schema, type system, or ddl
* No query language
* Lack of ability to express relations/hiearchy/graph
* No Namespacing
* What’s the standard serialization?
* Versioning and extention
The simple example of Dick’s favorite books is a great example. Most langauges will type their collections either implcitly in the application, or explicitly (something like generics)…so you now have typed name value pairs in a list. And, it’s not really a simple list, but rather a list of complex types….books have attributes that are interesting to track. Those attributes of course have nuance - is that id an isbn or an asbn? etc etc etc.
All of these (or a fair subset) are realities of actually using name/value pairs, and hence would need to be addressed in a large majority of use-cases. It seems like a flawed foundation that these are actually simpler…real use would probably tease that out quickly.
June 3rd, 2006 at 9:23 am
Hi Chuck,
I am assuming that when we talk of modeling identity data we are really discussing is how it can be transported. It makes little sense to me to try to solve the modeling of identity data for the general purpose case since that is really generic data modeling, not even a true subset. So while I agree that there are other things required to use name value pairs to store data (and that is what happens in real systems), for transport it is sufficient just to get the data from a to b with its meaning in tact, and the reality is that it will be transformed into the receiving ends preferred format no matter how it is transported, whether that be a relational DB, a directory or some other thing.
Of course some of your points apply even in that case and while I could come up with schemes to store Dick’s book list in name value pairs, if I had the choice I would probably use something else.
Thanks for your comment.