Design, Studied
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.
What's in a Name? We had no ID...
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...
Procedure
for Assigning a New Xpertweb ID
(implemented by the Mentor's Registration form)
|
- The New User's ID will be an extension of the Mentor's ID
- The last character
of the new user's ID will be a single A-Z character (ASCII 65-90
or 97-122) for the first 26 New Users sponsored by the Mentor.
- All IDs shall be
assigned in the order of the date and time of the Mentor Agreement
by which they are created.
- There is no provision
for a Mentor to assign Xpertweb IDs to more than 26 New Users.
EXAMPLE:
James Franklin's ID is ADCGEFH.
The first 7 characters (inheritance code) of the user ID for all
Franklin's New Users is ADCGEFH
If Mary Smith is Franklin's 5th New User, Mary's ID would
be: "ADCGEFHE": her inheritance code + "E".
If Mary is Franklin's 26th new user, her ID would be "ADCGEFHZ".
|
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 IDs about 16 digits long. Not bad, and we get
to keep the geneology model.
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:
#
Chars
|
Population
|
#
Chars
|
Population
|
1
|
4
|
1
|
6
|
2
|
16
|
2
|
36
|
3
|
64
|
3
|
216
|
4
|
256
|
4
|
1,296
|
5
|
1,024
|
5
|
7,776
|
6
|
4,096
|
6
|
46,656
|
7
|
16,384
|
7
|
279,936
|
8
|
65,536
|
8
|
1,679,616
|
9
|
262,144
|
9
|
10,077,696
|
10
|
1,048,576
|
10
|
60,466,176
|
11
|
4,194,304
|
11
|
362,797,056
|
12
|
16,777,216
|
12
|
2,176,782,336
|
13
|
67,108,864
|
|
|
14
|
268,435,456
|
|
|
15
|
1,073,741,824
|
|
|
16
|
4,294,967,296
|
|
|
|
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 worth it. Let's find someone to
transact with..."
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.
- I'm attracted by FFUNCH's reputation and click
on a product link.
- The product page asks me to enter my unique Xpertweb URL.
- Upon submitting a URL, FFUNCH's site visits the URL and
discovers there IS an Xpertweb site present with a properly formatted me.xml file
at the root level and a script that says it's ready to play nice with his
script. Only then does FFUNCH's script learn that I say I'm BRITTB.
- FFUNCH's script still doesn't know if I'm BRITTB, so
his script notes the current time, the visitor's IP number, composes a
unique
ID for
this contact and places a cookie on the visitor's browser, something like:
taskid FFUNCH.BRITTB.1054746754; IP 66.65.84.10 and
some product info
(a task ID = both users' IDs + the Unix epoch [# of
seconds
since 12/31/1969])
- FFUNCH's script directs my browser to the URL I presented
- The script at BRITTB's site asks me (still unverified)
to enter BRITTB's name and password.
- If I pass the challenge, we need a stateless
way to confirm to FFUNCH's script that I am indeed BRITTB.
- BRITTB's script looks in its buystuff/sellers directory for a subdirectory
labeled FFUNCH.
[If absent, it creates a buystuff/sellers/FFUNCH
directory]
It creates FFUNCH.BRITTB.1054746754.xml in
buystuff/sellers/FFUNCH
... listing the now-current
epoch, BRITTB's IP # and the product info
- BRITTB's script returns me to the FFUNCH site
- FFUNCH's script visits BRITTB's site and notes that the properly formatted
file was created in the proper directory at a time shortly after the task
ID creation, from a browser at the known IP number.
- FFUNCH's script looks in its sellstuff/buyers directory for a subdirectory
labeled BRITTB.
[If absent, it creates a sellstuff/buyers/BRITTB
directory]
It creates FFUNCH.BRITTB.1054746754.xml in
sellstuff/buyers/BRITTB
... listing the current epoch,
BRITTB's IP # and the product info
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]
9:31:45 AM 
|
|
