On Thu, Jul 22, 2010 at 11:50 AM, Terrell Russell
<terrellrussell(a)gmail.com>wrote;wrote:
From
http://en.wikipedia.org/wiki/Zooko's_triangle
Names can have up to two of these three properties:
- Secure (Unique)
- Decentralized (Global)
- Human-meaningful
Decentralized and human-meaningful:
this is true of nicknames people choose for themselves
Secure and human-meaningful:
this is the property that domain names and URLs aim for
Secure and decentralized:
this is a property of OpenPGP key fingerprints
Terrell
/bcc Zooko
Thanks for pointing this out Terrell.
The solution to Zooko's puzzle, as explained on the page, are "petnames."
These petnames are basically the same thing that I am suggesting - there is
never a truly ambiguous case that you cannot disambiguate. Even in the case
when two separate records have exactly the same metadata you can
disambiguate them by flipping a coin and adding an arbitrary a,b,c
incrementer to one of them. In 99.9999999% of cases records won't be exactly
identical, and some piece of the metadata can be incorporated into the key
in order to disambiguate.
The crux of this thread seems to be: There will always be edge cases,
therefore we must rely on meaningless unique hashes in order to index them.
My solution is to create a key that gets almost 100% of all cases, and then
create policies that disambiguate the rest by creating "petkeys" for them
that are used instead of the default key system. This imbues almost all of
our keys with meaning and uniqueness. It also makes it very clear - in the
key itself - when there is ambiguity in a record.
The system that disambiguates nearly-identical records is rather simple. The
community simply needs to create an order of precedence for properties, such
that the bibliographic field that has the highest precedence and is not
ambiguous goes into the key for that record. In almost all cases these
unambiguous fields will be the authors and the date.
Brian