[Dev] human readable petname object IDs

[rys mccusker]

I wrote this page yesterday while doing research, so I might as well send
it out today while I am posting messages:
http://wiki.osafoundation.org/bin/view/Main/DbHumanReadablePetnameIDs

human readable petname object IDs

This page addresses the disconnect between human readability and using highly 
conflict resistant unique IDs, which are usually 128 bit integers with a random 
character.

object IDs

Elsewhere (see the development mailing list) we have discussed the use of universally 
unique IDs (uuids, a.k.a. globally unique IDs = guids) in order to identify objects 
stored in a chandler repository.

Such IDs are excellent for avoiding naming collisions when assigning object identity 
in a repository without needing any global or centralized knowledge of object IDs 
used in other repositories.

However, 128 bit IDs just look like random 32 digit hexadecimal numbers. This is 
exceptionally hard for a human being to remember, so such IDs make terrible URL 
components that a human might want to remember.

human readable URLs

Chandler intends to use URLs to designate objects stored in a chandler repository. If 
such URLs are based upon uuids, the result will not be very human readable. So 
chandler might want to support a way of providing nicknames, or pet names, which mean 
the same thing as the more precise uuids, but are more human readable.

This general problem is one that is already been addressed in the context of 
designing human readable names for objects in capability based systems, which also 
tend to use identities based on long random looking integers.

All of the material above is essentially an introduction to the link in the section 
below.

pet name markup language

The web page at http://www.erights.org/elib/capability/pnml.html describes this 
general problem and a reasonable solution for using names friendlier to human beings.

The application inside a chandler context requires some design and thinking. Perhaps 
this page will inspire someone to think about the problem.

url example

Suppose the integer fe8d4ef49b69874763f6dab30cbb6292 is the uuid for an object which 
represents a person named Zooko in your repository. When you use a chandler URL which 
refers to this repository entry, instead of a URL which stands in 
"?id=fe8d4ef49b69874763f6dab30cbb6292", you might instead prefer a URL which ends in 
"?pn=Zooko".

That's just an example. The general idea is that you can substitute a shorter name 
that is easier to remember, provided the form of the URL indicates which namespace 
should be used for lookup -- e.g. uuids vs petnames.

practical issues

When one object in a chandler repository refers to another, the user interface might 
want to have a way to reveal what is on the other side of a reference which means 
something sensible to the user.

One planned future chandler feature might auto recognize references to objects in a 
Chandler repository by recognizing related plain English text phrases which seem to 
refer to the objects. This feature might have a basis in user selected pet names for 
important items in a repository, when no other names are very obvious.