I’m in Portland staying with my good friend and data mentor, Nick Johantgen and his talented and stylish wife, Nina Davis. Nick & Nina and Tamara and I go way back, to Seattle, Philly and now bi-coastal. Roland Tanglao and I are meeting in Portland on the occasion of the O’Reilly Open Source Conference this week. (Flemming‘s moving to France next week, so he’ll be here only in spirit and iChat). Mitch is driving down from Tacoma to join us tomorrow. Our purpose is to hammer out some Xpertweb design details and to get some input from the Opensourcerati.
If Xpertweb does its job, we might one day see an Open Data Conference. “Open Data” is meant to suggest an architecture that mirrors data among participants’ web sites. It formalizes what we already embrace in a random fashion as we scan multiple RSS feeds, blogs, news and research to triangulate what we accept as true. If multiple sources describe roughly the same story, we come to embrace it. Multiple sources implicate the truth while open data explicates it. Our resentment of dead links indicates our commitment to open data, though we’ve not yet committed to an open data standard.
In transactional reporting, the kind of data that our clients and employers pay us to manage, Xpertweb wants to foment identical data in the records of both parties to the transaction. That alone is worthwhile, but the real win comes by making the data also open to other parties, anyone who may want to trade with the parties to this transaction and who would benefit from full disclosure of the character and quality of past undertakings.
I find it ironic that everyone uses open source tools to create closed data. Perhaps the benefits of open data are not obvious.
Lopsided, Balanced or Open Data?
The more technical terms might be Asymmetrical, Symmetrical and Transparent data.
Several years ago, it occurred to me that the world is built on asymmetrical data, where transaction records are maintained and controlled by the designer of the transaction. So, when a buyer and a seller transact, the seller (the designer of the transaction) keeps and controls the data. When an employer and an employee intersect, the employer (designer of their transaction) keeps and controls the data. That’s when I started my quest for a symmetrical data standard, where both parties maintain identical records of their transaction.
And realized how profound is the power to design transactions.
Later I realized that was a partial step. Symmetrical records may help the parties approach parity, but the smaller party will still be subject to the larger party’s, well, largesse. (It sounds like a contradiction in terms. Do we ever see largesse practiced by larger parties?) After some digging, I realized there’s lots of symmetrical data, but it’s hidden from view.
Symmetrical data is built cooperatively when businesses insist on parity of transactional data, using standards like EDI. So far, only largish businesses have had the luxury of symmetrical data, since it has required expensive tools, data servers, staffs and usually lawyers. And there’s nothing inherent in symmetrical data that will keep a GM manager from trashing a supplier as a smart career move.
Open Data is the next step. An ideal Open Data transaction is one where the symmetrical data is published on the web so it requires no permission for any interested party to examine it. Further, the data need to be persistent over the life of a transaction, not just archived at the close of the deal. This encourages the parties to deal as they say they should, since the details of failed transactions will be as visible as successful ones.
We seem to have solved the hard part of the Digital ID challenge, as Doc described after we showed it to him in May. There’s a review of our digital ID system at the end of this post, for those patient enough to wade through it.
We have an ID process, which would seem to be the hard part, but not an ID format, which is harder than it seems. Our naming challenge stems from Xpertweb’s lack of centralization–there’s no central registration authority as for internet domains. Instead we have to rely on each mentor to generate a unique Xpertweb ID for all those who come after her. It’s a little like surnames, where John’s son Dave became Dave Johnson. Too bad that medieval standard wouldn’t scale past the first metadata level.
But the geneology model is compelling. Since we can compare satisfaction ratings for any users or groups of users, then, if each Xpertweb user’s ID contains the IDs of all the mentors who form the user’s “family tree,” so to speak, we can quickly compare any mentor’s effectiveness to any other’s. This seems to me an overarching value. The following method is the least worst we’ve come up with, which Roland describes as “Britt’s method.” Perhaps he’s distancing himself from it…
Simple enough, right? Unique IDs all around. But we need a lot of unique IDs, since Xpertweb means to be a data collector and an alternate economy and globally virulent. Further, each human may have more than one persona, operating in parallel or serially.
The issue is the length of each ID. As we add users, their IDs get longer. At what length does an ID become unwieldy? Are ten digits too many? 15? 20? Does it matter, since each mentor’s web site will point out who begat whom? Theoretically, you can imagine a string as long as the number of users, if they’re added serially. However, since the Xpertweb system depends on each person training several others, (four is the recommended minimum), 4x4x4, etc. yields I
While we need to anticipate every eventuality, such as a thousand people at a meeting, each of whom mentors the person seated to their right (AKA “Ming’s Nightmare”), I feel human nature is on the side of one person mentoring several others, so the digit-length tax on each generation seems likely to earn a four-fold population gain:
Xpertweb has generous rewards for mentoring new users (some say they’re too generous), so it’s likely that many mentors will introduce more than four new users. That’s my story and I’m sticking to it. Unless we can come up with a better story.
Whaddaya think? Does this approach make sense? Do we need a more elegant, computing-intense way to generate IDs? How important is it to provide a simple means to look at ID strings and see within them the ” geneology” of the mentors who trained an Xpertweb user. Please send any comments to Roland.
Why work on an idealized, theoretical economic system?
Is one better off to work directly on the symptoms of the real socioeconomic climate, like getting an Internet-based President elected? Or is it better to fantasize that a novel transaction data model could grow to significance? As you guessed, I like to place both bets.
Clearly, Xpertweb is a delicate, tentative little evolutionary economy. Like all evolutionary species, you can almost hear it gasping and flopping around at the edge of the water hole, wondering if breathing air is really such a great idea. But it’s a little horny, nonetheless.
“Oh well, maybe it’s wo
Current Method for Authenticating an Xpertweb Buyer
Since both parties control web servers containing the ID data they wish to selectively expose, we can use cooperative scripts to identify ourselves to each other, making the steps fairly straightforward. Here’s an example where I might want to buy something from Flemming Funch, but he doesn’t know if I’m the person I say I am.
Now the two of us can transact with high confidence that our reputations are accurately represented. Naturally, no system can guarantee that we’ll behave well. All it can do is report what we say about each other’s behavior.
And that seems like a good start.
[back to the Unique ID discussion]