BioGUIDs and the Internet Analogy

Tue Sep 28 13:11:43 CEST 2004

I think we just need to be clear that there are on the one hand the BioGUIDs
themselves and how they are created/assigned and on the other hand is the
method to find them later by someone else.  On the Internet there are IP
addresses and how they are assigned (albeit potentially dynamically) and the
method for someone else to find them.  Rarely do you get Internet references
given as an IP address (http://157.140.2.10) (certainly one reason is that
they can be dynamic) but rather as URLs (http://www.tdwg.org) that are then
resolved through the domain resolution process.

This approach enables the two things (number and name) to be managed
separately, yet linked together.

Don't we need the same two mechanisms for BioGUIDs?  Does the LSID spec
address both parts of this?  I guess I had better get over there and read
the whole thing.

Regarding:
>>IP addresses are in no way persistent.
>>IP addresses are not globally unique. [But they are unique on the
Internet]

Making analogies is tough because the details of the example can get in the
way, as in this case.  IP addresses have several attributes.  The point is
not whether IP addresses are analogous to BioGUIDs on the attributes of
static/changeable or universality.  The point is that the IP is analagous
because it is a cryptic non-intelligible and unique number used to locate
another network device by a machine that starts out with no idea where it
is.  That's the analogy - that IP and BioGUIDs are unique, nonintelligible
(ie. semantically opaque) strings of characters/numbers.

The issue is how in the world to you find the BioGUID you are trying to get
to?  Do you just use the nonintelligible string?  Or do we want somewhat
intelligible names as pointers to the nonintelligible?

Regarding:
>>The number of organizations to be issued Bio GUIDs surely is several
orders of magnitude less than those to be issued IPv6 addresses.

True.  But, there are potentially billions of BioGUIDs to be created, which
could exceed the number of IPv6 addresses.  Some institutions would be the
equivalent of a large Internet Registry managing millions of BioGUIDs.

This seems like a big issue to me.  Would GBIF/TDWG or whomever issue
millions/billions of BioGUIDs directly to institution records and not
decentralize by assigning blocks of BioGUIDs to institutions?

Also, when there are billions of something, efficiency becomes an issue.  IP
addresses follow a binary number approach that leads to efficient
processing.  Is there an efficiency issue lurking ahead for the BioGUID?

Regarding:
>>...name resolution protocols matter, but resolution implementations
don't...
This is true when you have working resolution implementations as the
Internet does.  But does LSID have a working resolution implementation now?
If not, creating a new one that works is not that simple I think.  That
would be a good reason for piggy-backing on the existing and working
Internet DNS/domain name resolution system as I've heard mentioned.

Chuck Miller
CIO
Missouri Botanical Garden

-----Original Message-----
From: Bob Morris [mailto:ram at CS.UMB.EDU]
Sent: Monday, September 27, 2004 10:34 PM
To: TDWG-SDD at LISTSERV.NHM.KU.EDU
Subject: Re: BioGUIDs and the Internet Analogy

[For me, the bottom line---which however I nowhere state below---is: There
is /so much/ existing free infrastructure source code---e.g.
http://www-124.ibm.com/developerworks/oss/lsid/--- and (apparently) funding,
and (manifestly) professionally designed specifications for LSID concerns
that I am horrified at the prospect of adopting anything else if LSID comes
even close to being what the community needs. Or, let's forget about LSID
and instead of deploying what satisfies 98% of the needs in six months, we
could roll our own and deploy what satisfies 80% of the needs in a few
years...

To my mind, the only question is this: is LSID good enough? So: first make
the requirements. Then examine existing solutions. Arguing by analogy can
lead to the "hammer" solution, usually attributed to Mark
Twain: When all you own is a hammer, every problem begins to look like a
nail. (Can someone give me an actual /reference/ to that quote????]

-------------------------

The idea of modeling taxonomic uuids on the internet has been around for
about 10 years, and has been written about explicitly for at least 3-4 by
Hannu Saarenma and probably others. See his article in
http://reports.eea.eu.int/technical_report_2001_70/en/Technical%20Report%207
0%20web.pdf

The Tree of Life http://www.tolweb.org is a defacto such model, though
without name authorities or persistence.

The design goals of TCP/IP and DNS, and their implementation, intersect the
requirements of Bio UUIDs only in a very small set, in fact, deep down
perhaps not at all.

These protocols and the associated address syntax were designed primarily
for /routing/, not in any way designed to guarantee that a datum twice
received has any connection between the two occurrences.

IP addresses are in no way persistent.

IP addresses are not globally unique, albeit in several small and varied
ways:

- The "private address blocks" 10.X.Y.Z, 172.16.0-0-172.31.255.255, and
  192.168.X.Y may be assigned to any machine your and my network
administrator care to, as long as neither is served on "the Internet", nor
have an duplication on "an internet".

-every machine implementing IP, besides whatever other addresses it may
have, is always known to itself as 127.0.0.1;

- the addresses in some IP address ranges are reserved to designate /many/
machines (multicast IP)).

In general the design of the IP "nomenclature"---i.e. the IP addresses---is
designed to solve routing problems, not identification problems.  IP address
syntax is intentionally not "semantically opaque", contrary to a requirement
(well, a "should be")  of LSIDs and well it should be. See Section 8 of
http://www.omg.org/cgi-bin/doc?dtc/04-05-01

[If you don't see why IP addressing is not semantically opaque, try this
exercise: With a single machine instruction (on most machines) how can you
determine whether or not an IP address is in the Class B  private address
space(the 172 stuff above)? Sysadmin's, C programmers, and their families
and employees are not eligible for this competition]

In turn, DNS protocols are designed only to aid discovery of IP addresses.
DNS addresses are also far from persistent (in fact, DNS records held
anywhere have a "Time To Live" field which must be counted down until
expiration, at which time the holder must acquire a new instance of the
assignment of an IP address to a domain name.).

[More below, interspersed]

Richard Pyle wrote:

>>Perhaps it would be useful to look at the issues being discussed about
>>a bio identifier/locator/GUID in comparison to the same things that
>>are needed for Internet communications.
>
>
> I've long thought that parts of the DNS system would be extremely
> useful to emulate in some aspects of bioinformatics data management
> (particularly taxonomic names; see below).
>
>
>>IP addresses have to be unique world-wide to make the Internet work.
>>The Internet Corporation for Assigned Names and Numbers (ICANN-
>
> www.icann.org)
>
>>provides that uniqueness by assigning all the IP numbers in unique
>>blocks
>
> or
>
>>ranges of numbers to "Internet Registries".
>
>
> ...exactly the way that I envision an organization like GBIF would be
> charged with the task of issuing UIDs for certain biological objects.
>
>
>>There are Regional, National and Local Internet Registries that
>>subdivide
>
> and
>
>>"license" IP addresses to ISPs, who in turn license IP addresses to
>
> organizations.

Ah, this is accurate mainly for IPv6, which is much less chaotic than IPv4
(most of the current Internet) and in turn from the nearly formless void
that was IPv2. But again, ultimate "licensees" do not get persistent IP
addresses. In the US, virtually all dialup users get a different IP every
time they connect, and most home broadband users only accidently keep their
IP addresses, and only if they don't disconnect very long from the network.

It's well worth comparing the design goals of IPv6 as articulated in
http://www.apnic.net/docs/policy/ipv6-address-policy.html
with those of LSID as articulated in Section 8 of the Draft Final
Specification http://www.omg.org/cgi-bin/doc?dtc/04-05-01

>
> There could be a useful analog for this in bioinformatics
> (particularly in terms of individual institutions serving as regional
> registries for specimen UIDs, or IC_N Commissions serving as
> "regional" registries for taxon name UID assignment) -- but there
> doesn't necessarily have to be.
>

In fact, if the UUIDs are meant to be semantically opaque it matters not one
whit who or how these matters are settled. Exceptions to that are social,
not technical. ("If you don't let me decide X, I am not going to use your
scheme". "OK, then you won't participate in its benefits. That's fine with
me")

If you want to see another example of lack of semantic opacity, read the
ISBN standard ISO/TC 46/SC 9 N 326. Part of certain ISBNs can help you
determine an allegedly common publishing-germaine attribute of the US,
Zimbabwe, Puerto Rico, Ireland, Swaziland, part of Canada, and a few other
"regions".
>
>>So, there is a heirarchy of how the "unique identifiers" are managed.
>
> There is
>
>>in fact a central authority, but it delegates to decentralized
>
> authorities.

But this is mainly to distribute costs and speed issuance. It has nothing to
do with the naming scheme. The number of organizations to be issued Bio
GUIDs surely is several orders of magnitude less than those to be issued
IBv6 addresses. So I doubt any IPv6 issuance mechanisms are instructive, at
least in their purpose (and hence, if well implemented, in their
implementation).

>
> To emulate this in bioinformatics, the "hierarchy" would be achieved
> simply by allowing block-assignment of UIDs to various players -- but
> the important point here is that only *one* organization ensures
> uniqueness (in the case of Internet, of ISPs).  The data to which
> those UIDs apply would be, for the most part, the responsibility of
> the UID recipient, not the UID issuer (in my world view). Thus:
> centralized issuance; delegated application.
>
>
>>Is there an analogy for BioGUIDs to have a central body who divvies
>>out
>
> the
>
>>unique numbers (like IP addresses) to decentralized bodies or large
>
> organizations?

The International ISBN Organization http://www.isbn-international.org/
is roughly the IPv6 model.

>
> GBIF seems to me to be the principle contender.

I enthusiastically agree. Also the /principal/ contender. [Sorry, couldn't
resist. My fingers slip on that one sometimes too.]
>
>
>>Since IP addresses are hard to memorize (and so too would be a
>>BioGUID),
>
> "domain names"
>
>>are used. Starting with a domain name, you can first find the name
>>and/or
>
> IP address
>
>>of a device, called the Domain Name Server, that can locate the IP
>>address
>
> of other
>
>>computers.  This is a form of indirect addressing.  ICANN also manages
>>the
>
> top-level
>
>>namespace for the Internet. They decide what the valid domain
>>"extensions"
>
> are (like
>
>>.com, .uk) so that everybody, everywhere knows where to look them up.
>
> Then, the domain
>
>>name extensions are separated among the Regional, National, and Local
>
> Interent Registries
>
>>around the world.  There is a scheme for where to find the IP
>>addresses
>
> for every domain
>
>>extension (e.g. .com is on the ARIN registry, .com.uk is on the ).

Not exactly. There is one scheme in case your application can't resolve it
in a more nearly "local" facility. There are /lots/ of ways to find an IP
address from a domain name. All those which comply fully with the DNS
protocol, however, can make available two pieces of metadata: the TTL of the
record it is offering, and the IP address of a machine at which you can find
an authoritative record of the assignment of the dns name to the IP address.
This protocol /might/, but you hope on performance grounds usually
/doesn't/, lead you up as far as the root servers, and the "one scheme to
bind them all". If there is any lesson here at all, it is that name
resolution protocols matter, but resolution implementations don't. Yet
another attribute on which, DNS/IP and LSID are not distinguishable.

>>Then there is a layer of Domain Registrars who have been accredited by
>
> ICANN to assign
>
>>domain names for the domain extensions - e.g. tdwg.org.
>>The domain name registrars are told by the owner of the domain where
>>to
>
> find their particular
>
>>Domain Name Servers which may be many to enable redundancy - Primary,
>
> Secondary, Tertiary,
>
>>etc.

Not quite. Normally, the registrant tells the registrar who has agreed to be
the servers. The other case sometimes happens with "retailers" who are
selling individuals domain names and ISP services at the same time.

These redundant Domain Name Servers synchronize with each other at
>
> particular times
>
>>of day and may be located all around the world.

More often, only when the TTLs expire, there being no motivation to do
otherwise.

>They are the main
>
> "switchboard" for a
>
>>particular organizations computer names and associated IP addresses.
>>Then the individual organization can create multiple computers for the
>
> domain name - e.g.
>
>>www.tdwg.org - and add them to the Domain Name Server listing.  There
>>can
>
> be many computers
>
>>for a domain, for instance: info.tdwg.org, www2.tdwg.org,
>>myname.tdwg.org.
>
> Each of these
>
>>can be a different computer with a different IP address.  The
>>redundant
>
> Domain Name Servers
>
>>all contain the list of all these names and what IP addresses they
>>are.

Not usually. The primary and secondary name servers would normally only
cache tdwg.org permanently. They might /acquire/ a record for www.tdwg.org
in response to a request, but they would not in general renew it after it
expired and maybe not even keep it that long. To do so would be hideously
unscalable. If I put 10,000 machines in my domain, my primary and secondary
would be mighty unhappy if they had to keep them all cached.

>
>
> This is analogous in many ways to how I would envision a global
> taxonomic name service.  UIDs are assigned by a centralized body
> (e.g., GBIF; or by the IC_N Commissions) to individual names.
> Analogous to multiple redundant Domain Name Servers (DNS) would be
> Taxon Name Servers (TNS).  Rather than administered by one
> organization (e.g., GBIF, ITIS, Species 2000, uBio,
> etc.) these TSNs would be replicated on dozens or hundreds of servers all
> over the world, and maintained as synchronized within some reasonable time
> unit.  Changes to any one replicate would be automatically propagated to
all
> replicates (either chaotically, or more strictly through one or a few
> defined "hubs").  Instead of Domain names as surrogates for IP addresses,
> there would be fully qualified "Basionyms" (e.g.,
>
"OriginalGenusName.OriginalSpeciesName.OriginalAuthor.DescriptionYear.Page.O
> therOriginalCitationDetailsAsNeeded") representations of the
> less-human-friendly GUIDs (analogues to IP addresses).  Ideally, this
system
> wouldn't be limited to just taxonomic names, but extended to all taxonomic
> concepts, so that the "Domain Name" analogue would be extended to
something
> like:
>
> "OriginalGenusName.OriginalSpeciesName.OriginalAuthor.DescriptionYear.
> Page.O
>
therOriginalCitationDetailsAsNeeded_AppliedGenusName.AppliedSpeciesSpelling.
> ConceptAuthor.ConceptYear.Page.OtherConceptCitationDetailsAsNeeded"
>
>
>>The players in the Internet networking fabric all now play by these
>
> layered rules.
>
>>They all know them and follow them in order to keep the Internet
>>running.
>
> This
>
>>stuff happens out of sight to everyone but the networking people and
>>we
>
> all take it
>
>>for granted and assume it is simple.  But, it's invisible not because
>>it's
>
> simple,
>
>>but rather because it's disciplined.

Agreed. Yet one more attribute where IP/DNS and LSID are not
distinguishable.

>
>
> Excellent synopsis, and (in my opinion), and excellent model to follow
> for at least taxonomic names/concepts data.  Perhaps also for specimen
> data (but seems less intuitive for that.) This comes back to my
> earlier question about whether it is vital that all bioinformatics
> GUIDs be of the same scheme; or whether different schemes might be
> optimal for different classes of objects.
>
> Aloha,
> Rich
>
> Richard L. Pyle, PhD
> Natural Sciences Database Coordinator, Bishop Museum
> 1525 Bernice St., Honolulu, HI 96817
> Ph: (808)848-4115, Fax: (808)847-8252
> email: deepreef at bishopmuseum.org
> http://www.bishopmuseum.org/bishop/HBS/pylerichard.html

------_=_NextPart_001_01C4A586.9BDA1D20
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: BioGUIDs and the Internet Analogy</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I think we just need to be clear that there are on =
the one hand the BioGUIDs themselves and how they are created/assigned =
and on the other hand is the method to find them later by someone =
else.&nbsp; On the Internet there are IP addresses and how they are =
assigned (albeit potentially dynamically) and the method for someone =
else to find them.&nbsp; Rarely do you get Internet references given as =
an IP address (<A HREF=3D"http://157.140.2.10" =
TARGET=3D"_blank">http://157.140.2.10</A>) (certainly one reason is =
that they can be dynamic) but rather as URLs (<A =
HREF=3D"http://www.tdwg.org" TARGET=3D"_blank">http://www.tdwg.org</A>) =
that are then resolved through the domain resolution =
process.</FONT></P>

<P><FONT SIZE=3D2>This approach enables the two things (number and =
name) to be managed separately, yet linked together.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Don't we need the same two mechanisms for =
BioGUIDs?&nbsp; Does the LSID spec address both parts of this?&nbsp; I =
guess I had better get over there and read the whole thing.</FONT></P>

Regarding:
 &gt;&gt;IP addresses are in no way persistent. =

 &gt;&gt;IP addresses are not globally unique. [But =
they are unique on the Internet]
 &nbsp; 
 Making analogies is tough because the details of the =
example can get in the way, as in this case.&nbsp; IP addresses have =
several attributes.&nbsp; The point is not whether IP addresses are =
analogous to BioGUIDs on the attributes of static/changeable or =
universality.&nbsp; The point is that the IP is analagous because it is =
a cryptic non-intelligible and unique number used to locate another =
network device by a machine that starts out with no idea where it =
is.&nbsp; That's the analogy - that IP and BioGUIDs are unique, =
nonintelligible (ie. semantically opaque) strings of =
characters/numbers.&nbsp;

The issue is how in the world to you find the BioGUID =
you are trying to get to?&nbsp; Do you just use the nonintelligible =
string?&nbsp; Or do we want somewhat intelligible names as pointers to =
the nonintelligible?

Regarding:
 &gt;&gt;The number of organizations to be issued Bio =
GUIDs surely is several orders of magnitude less than those to be =
issued IPv6 addresses.

<P><FONT SIZE=3D2>True.&nbsp; But, there are potentially billions of =
BioGUIDs to be created, which could exceed the number of IPv6 =
addresses.&nbsp; Some institutions would be the equivalent of a large =
Internet Registry managing millions of BioGUIDs.</FONT></P>

<P><FONT SIZE=3D2>This seems like a big issue to me.&nbsp; Would =
GBIF/TDWG or whomever issue millions/billions of BioGUIDs directly to =
institution records and not decentralize by assigning blocks of =
BioGUIDs to institutions?</FONT></P>

Also, when there are billions of something, =
efficiency becomes an issue.&nbsp; IP addresses follow a binary number =
approach that leads to efficient processing.&nbsp; Is there an =
efficiency issue lurking ahead for the BioGUID?

<P><FONT SIZE=3D2>Regarding:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;...name resolution protocols matter, but =
resolution implementations don't...</FONT>
<BR><FONT SIZE=3D2>This is true when you have working resolution =
implementations as the Internet does.&nbsp; But does LSID have a =
working resolution implementation now?&nbsp; If not, creating a new one =
that works is not that simple I think.&nbsp; That would be a good =
reason for piggy-backing on the existing and working Internet =
DNS/domain name resolution system as I've heard mentioned.</FONT></P>

<P><FONT SIZE=3D2>Chuck Miller</FONT>
<BR><FONT SIZE=3D2>CIO</FONT>
<BR><FONT SIZE=3D2>Missouri Botanical Garden&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bob Morris [<A =
HREF=3D"mailto:ram at CS.UMB.EDU">mailto:ram at CS.UMB.EDU</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Monday, September 27, 2004 10:34 PM</FONT>
<BR><FONT SIZE=3D2>To: TDWG-SDD at LISTSERV.NHM.KU.EDU</FONT>
<BR><FONT SIZE=3D2>Subject: Re: BioGUIDs and the Internet =
Analogy</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>[For me, the bottom line---which however I nowhere =
state below---is: There is /so much/ existing free infrastructure =
source code---e.g.</FONT></P>

<A =
HREF=3D"http://www-124.ibm.com/developerworks/oss/lsid/---" =
TARGET=3D"_blank">http://www-124.ibm.com/developerworks/oss/lsid/---</A>=
 and (apparently) funding, and (manifestly) professionally designed =
specifications for LSID concerns that I am horrified at the prospect of =
adopting anything else if LSID comes even close to being what the =
community needs. Or, let's forget about LSID and instead of deploying =
what satisfies 98% of the needs in six months, we could roll our own =
and deploy what satisfies 80% of the needs in a few years...

To my mind, the only question is this: is LSID good =
enough? So: first make the requirements. Then examine existing =
solutions. Arguing by analogy can lead to the &quot;hammer&quot; =
solution, usually attributed to Mark

Twain: When all you own is a hammer, every problem =
begins to look like a nail. (Can someone give me an actual /reference/ =
to that quote????]

<P><FONT SIZE=3D2>-------------------------</FONT>
</P>

The idea of modeling taxonomic uuids on the internet =
has been around for about 10 years, and has been written about =
explicitly for at least 3-4 by Hannu Saarenma and probably others. See =
his article in <A =
HREF=3D"http://reports.eea.eu.int/technical_report_2001_70/en/Technical%=
20Report%2070%20web.pdf" =
TARGET=3D"_blank">http://reports.eea.eu.int/technical_report_2001_70/en/=
Technical%20Report%2070%20web.pdf</A>

<P><FONT SIZE=3D2>The Tree of Life <A HREF=3D"http://www.tolweb.org" =
TARGET=3D"_blank">http://www.tolweb.org</A> is a defacto such model, =
though without name authorities or persistence.</FONT>
</P>

<P><FONT SIZE=3D2>The design goals of TCP/IP and DNS, and their =
implementation, intersect the requirements of Bio UUIDs only in a very =
small set, in fact, deep down perhaps not at all.</FONT></P>

<P><FONT SIZE=3D2>These protocols and the associated address syntax =
were designed primarily for /routing/, not in any way designed to =
guarantee that a datum twice received has any connection between the =
two occurrences.</FONT></P>

<P><FONT SIZE=3D2>IP addresses are in no way persistent.</FONT>
</P>

<P><FONT SIZE=3D2>IP addresses are not globally unique, albeit in =
several small and varied</FONT>
<BR><FONT SIZE=3D2>ways:</FONT>
</P>

<P><FONT SIZE=3D2>- The &quot;private address blocks&quot; 10.X.Y.Z, =
172.16.0-0-172.31.255.255, and</FONT>
<BR><FONT SIZE=3D2>&nbsp; 192.168.X.Y may be assigned to any machine =
your and my network administrator care to, as long as neither is served =
on &quot;the Internet&quot;, nor have an duplication on &quot;an =
internet&quot;.</FONT></P>

<P><FONT SIZE=3D2>-every machine implementing IP, besides whatever =
other addresses it may have, is always known to itself as =
127.0.0.1;</FONT>
</P>

<P><FONT SIZE=3D2>- the addresses in some IP address ranges are =
reserved to designate /many/ machines (multicast IP)).</FONT>
</P>

In general the design of the IP =
&quot;nomenclature&quot;---i.e. the IP addresses---is designed to solve =
routing problems, not identification problems.&nbsp; IP address syntax =
is intentionally not &quot;semantically opaque&quot;, contrary to a =
requirement (well, a &quot;should be&quot;)&nbsp; of LSIDs and well it =
should be. See Section 8 of <A =
HREF=3D"http://www.omg.org/cgi-bin/doc?dtc/04-05-01" =
TARGET=3D"_blank">http://www.omg.org/cgi-bin/doc?dtc/04-05-01</A>=

[If you don't see why IP addressing is not =
semantically opaque, try this
 exercise: With a single machine instruction (on most =
machines) how can you determine whether or not an IP address is in the =
Class B&nbsp; private address space(the 172 stuff above)? Sysadmin's, C =
programmers, and their families and employees are not eligible for this =
competition]

In turn, DNS protocols are designed only to aid =
discovery of IP addresses. DNS addresses are also far from persistent =
(in fact, DNS records held anywhere have a &quot;Time To Live&quot; =
field which must be counted down until expiration, at which time the =
holder must acquire a new instance of the assignment of an IP address =
to a domain name.).

<P><FONT SIZE=3D2>[More below, interspersed]</FONT>
</P>

<P><FONT SIZE=3D2>Richard Pyle wrote:</FONT>
</P>

&gt;&gt;Perhaps it would be useful to look at the =
issues being discussed about 
 &gt;&gt;a bio identifier/locator/GUID in comparison =
to the same things that 
 &gt;&gt;are needed for Internet =
communications.
 &gt;
 &gt;
 &gt; I've long thought that parts of the DNS system =
would be extremely 
 &gt; useful to emulate in some aspects of =
bioinformatics data management 
 &gt; (particularly taxonomic names; see =
below).
 &gt;
 &gt;
 &gt;&gt;IP addresses have to be unique world-wide to =
make the Internet work. 
 &gt;&gt;The Internet Corporation for Assigned Names =
and Numbers (ICANN-
 &gt;
 &gt; www.icann.org)
 &gt;
 &gt;&gt;provides that uniqueness by assigning all =
the IP numbers in unique 
 &gt;&gt;blocks
 &gt;
 &gt; or
 &gt;
 &gt;&gt;ranges of numbers to &quot;Internet =
Registries&quot;.
 &gt;
 &gt;
 &gt; ...exactly the way that I envision an =
organization like GBIF would be 
 &gt; charged with the task of issuing UIDs for =
certain biological objects.
 &gt;
 &gt;
 &gt;&gt;There are Regional, National and Local =
Internet Registries that 
 &gt;&gt;subdivide
 &gt;
 &gt; and
 &gt;
 &gt;&gt;&quot;license&quot; IP addresses to ISPs, =
who in turn license IP addresses to
 &gt;
 &gt; organizations.

Ah, this is accurate mainly for IPv6, which is much =
less chaotic than IPv4 (most of the current Internet) and in turn from =
the nearly formless void that was IPv2. But again, ultimate =
&quot;licensees&quot; do not get persistent IP addresses. In the US, =
virtually all dialup users get a different IP every time they connect, =
and most home broadband users only accidently keep their IP addresses, =
and only if they don't disconnect very long from the =
network.

<P><FONT SIZE=3D2>It's well worth comparing the design goals of IPv6 as =
articulated in <A =
HREF=3D"http://www.apnic.net/docs/policy/ipv6-address-policy.html" =
TARGET=3D"_blank">http://www.apnic.net/docs/policy/ipv6-address-policy.h=
tml</A></FONT></P>

<P><FONT SIZE=3D2>with those of LSID as articulated in Section 8 of the =
Draft Final Specification <A =
HREF=3D"http://www.omg.org/cgi-bin/doc?dtc/04-05-01" =
TARGET=3D"_blank">http://www.omg.org/cgi-bin/doc?dtc/04-05-01</A></FONT>=
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; There could be a useful analog for this in =
bioinformatics </FONT>
<BR><FONT SIZE=3D2>&gt; (particularly in terms of individual =
institutions serving as regional </FONT>
<BR><FONT SIZE=3D2>&gt; registries for specimen UIDs, or IC_N =
Commissions serving as </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;regional&quot; registries for taxon name =
UID assignment) -- but there </FONT>
<BR><FONT SIZE=3D2>&gt; doesn't necessarily have to be.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

In fact, if the UUIDs are meant to be semantically =
opaque it matters not one whit who or how these matters are settled. =
Exceptions to that are social, not technical. (&quot;If you don't let =
me decide X, I am not going to use your scheme&quot;. &quot;OK, then =
you won't participate in its benefits. That's fine with =
me&quot;)

If you want to see another example of lack of =
semantic opacity, read the ISBN standard ISO/TC 46/SC 9 N 326. Part of =
certain ISBNs can help you determine an allegedly common =
publishing-germaine attribute of the US, Zimbabwe, Puerto Rico, =
Ireland, Swaziland, part of Canada, and a few other =
&quot;regions&quot;.

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;So, there is a heirarchy of how the =
&quot;unique identifiers&quot; are managed.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; There is</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;in fact a central authority, but it =
delegates to decentralized</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; authorities.</FONT>
</P>

But this is mainly to distribute costs and speed =
issuance. It has nothing to do with the naming scheme. The number of =
organizations to be issued Bio GUIDs surely is several orders of =
magnitude less than those to be issued IBv6 addresses. So I doubt any =
IPv6 issuance mechanisms are instructive, at least in their purpose =
(and hence, if well implemented, in their implementation).

&gt;
 &gt; To emulate this in bioinformatics, the =
&quot;hierarchy&quot; would be achieved 
 &gt; simply by allowing block-assignment of UIDs to =
various players -- but 
 &gt; the important point here is that only *one* =
organization ensures 
 &gt; uniqueness (in the case of Internet, of =
ISPs).&nbsp; The data to which 
 &gt; those UIDs apply would be, for the most part, =
the responsibility of 
 &gt; the UID recipient, not the UID issuer (in my =
world view). Thus: 
 &gt; centralized issuance; delegated =
application.
 &gt;
 &gt;
 &gt;&gt;Is there an analogy for BioGUIDs to have a =
central body who divvies 
 &gt;&gt;out
 &gt;
 &gt; the
 &gt;
 &gt;&gt;unique numbers (like IP addresses) to =
decentralized bodies or large
 &gt;
 &gt; organizations?

<P><FONT SIZE=3D2>The International ISBN Organization <A =
HREF=3D"http://www.isbn-international.org/" =
TARGET=3D"_blank">http://www.isbn-international.org/</A></FONT>
<BR><FONT SIZE=3D2>is roughly the IPv6 model.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; GBIF seems to me to be the principle =
contender.</FONT>
</P>

I enthusiastically agree. Also the /principal/ =
contender. [Sorry, couldn't resist. My fingers slip on that one =
sometimes too.]

&gt;
 &gt;
 &gt;&gt;Since IP addresses are hard to memorize (and =
so too would be a 
 &gt;&gt;BioGUID),
 &gt;
 &gt; &quot;domain names&quot;
 &gt;
 &gt;&gt;are used. Starting with a domain name, you =
can first find the name 
 &gt;&gt;and/or
 &gt;
 &gt; IP address
 &gt;
 &gt;&gt;of a device, called the Domain Name Server, =
that can locate the IP 
 &gt;&gt;address
 &gt;
 &gt; of other
 &gt;
 &gt;&gt;computers.&nbsp; This is a form of indirect =
addressing.&nbsp; ICANN also manages 
 &gt;&gt;the
 &gt;
 &gt; top-level
 &gt;
 &gt;&gt;namespace for the Internet. They decide what =
the valid domain 
 &gt;&gt;&quot;extensions&quot;
 &gt;
 &gt; are (like
 &gt;
 &gt;&gt;.com, .uk) so that everybody, everywhere =
knows where to look them up.
 &gt;
 &gt; Then, the domain
 &gt;
 &gt;&gt;name extensions are separated among the =
Regional, National, and Local
 &gt;
 &gt; Interent Registries
 &gt;
 &gt;&gt;around the world.&nbsp; There is a scheme =
for where to find the IP 
 &gt;&gt;addresses
 &gt;
 &gt; for every domain
 &gt;
 &gt;&gt;extension (e.g. .com is on the ARIN =
registry, .com.uk is on the ).

Not exactly. There is one scheme in case your =
application can't resolve it in a more nearly &quot;local&quot; =
facility. There are /lots/ of ways to find an IP address from a domain =
name. All those which comply fully with the DNS protocol, however, can =
make available two pieces of metadata: the TTL of the record it is =
offering, and the IP address of a machine at which you can find an =
authoritative record of the assignment of the dns name to the IP =
address. This protocol /might/, but you hope on performance grounds =
usually /doesn't/, lead you up as far as the root servers, and the =
&quot;one scheme to bind them all&quot;. If there is any lesson here at =
all, it is that name resolution protocols matter, but resolution =
implementations don't. Yet another attribute on which, DNS/IP and LSID =
are not distinguishable.

&gt;&gt;Then there is a layer of Domain Registrars =
who have been accredited by
 &gt;
 &gt; ICANN to assign
 &gt;
 &gt;&gt;domain names for the domain extensions - =
e.g. tdwg.org.
 &gt;&gt;The domain name registrars are told by the =
owner of the domain where 
 &gt;&gt;to
 &gt;
 &gt; find their particular
 &gt;
 &gt;&gt;Domain Name Servers which may be many to =
enable redundancy - Primary,
 &gt;
 &gt; Secondary, Tertiary,
 &gt;
 &gt;&gt;etc.

Not quite. Normally, the registrant tells the =
registrar who has agreed to be the servers. The other case sometimes =
happens with &quot;retailers&quot; who are selling individuals domain =
names and ISP services at the same time.

<P><FONT SIZE=3D2>These redundant Domain Name Servers synchronize with =
each other at</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; particular times</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;of day and may be located all around the =
world.</FONT>
</P>

<P><FONT SIZE=3D2>More often, only when the TTLs expire, there being no =
motivation to do otherwise.</FONT>
</P>

&gt;They are the main
 &gt;
 &gt; &quot;switchboard&quot; for a
 &gt;
 &gt;&gt;particular organizations computer names and =
associated IP addresses. 
 &gt;&gt;Then the individual organization can create =
multiple computers for the
 &gt;
 &gt; domain name - e.g.
 &gt;
 &gt;&gt;www.tdwg.org - and add them to the Domain =
Name Server listing.&nbsp; There 
 &gt;&gt;can
 &gt;
 &gt; be many computers
 &gt;
 &gt;&gt;for a domain, for instance: info.tdwg.org, =
www2.tdwg.org, 
 &gt;&gt;myname.tdwg.org.
 &gt;
 &gt; Each of these
 &gt;
 &gt;&gt;can be a different computer with a different =
IP address.&nbsp; The 
 &gt;&gt;redundant
 &gt;
 &gt; Domain Name Servers
 &gt;
 &gt;&gt;all contain the list of all these names and =
what IP addresses they 
 &gt;&gt;are.

Not usually. The primary and secondary name servers =
would normally only cache tdwg.org permanently. They might /acquire/ a =
record for www.tdwg.org in response to a request, but they would not in =
general renew it after it expired and maybe not even keep it that long. =
To do so would be hideously unscalable. If I put 10,000 machines in my =
domain, my primary and secondary would be mighty unhappy if they had to =
keep them all cached.

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; This is analogous in many ways to how I would =
envision a global </FONT>
<BR><FONT SIZE=3D2>&gt; taxonomic name service.&nbsp; UIDs are assigned =
by a centralized body </FONT>
<BR><FONT SIZE=3D2>&gt; (e.g., GBIF; or by the IC_N Commissions) to =
individual names.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Analogous to multiple redundant Domain Name =
Servers (DNS) would be </FONT>
<BR><FONT SIZE=3D2>&gt; Taxon Name Servers (TNS).&nbsp; Rather than =
administered by one </FONT>
<BR><FONT SIZE=3D2>&gt; organization (e.g., GBIF, ITIS, Species 2000, =
uBio,</FONT>
<BR><FONT SIZE=3D2>&gt; etc.) these TSNs would be replicated on dozens =
or hundreds of servers all</FONT>
<BR><FONT SIZE=3D2>&gt; over the world, and maintained as synchronized =
within some reasonable time</FONT>
<BR><FONT SIZE=3D2>&gt; unit.&nbsp; Changes to any one replicate would =
be automatically propagated to all</FONT>
<BR><FONT SIZE=3D2>&gt; replicates (either chaotically, or more =
strictly through one or a few</FONT>
<BR><FONT SIZE=3D2>&gt; defined &quot;hubs&quot;).&nbsp; Instead of =
Domain names as surrogates for IP addresses,</FONT>
<BR><FONT SIZE=3D2>&gt; there would be fully qualified =
&quot;Basionyms&quot; (e.g.,</FONT>
<BR><FONT SIZE=3D2>&gt; =
&quot;OriginalGenusName.OriginalSpeciesName.OriginalAuthor.DescriptionYe=
ar.Page.O</FONT>
<BR><FONT SIZE=3D2>&gt; therOriginalCitationDetailsAsNeeded&quot;) =
representations of the</FONT>
<BR><FONT SIZE=3D2>&gt; less-human-friendly GUIDs (analogues to IP =
addresses).&nbsp; Ideally, this system</FONT>
<BR><FONT SIZE=3D2>&gt; wouldn't be limited to just taxonomic names, =
but extended to all taxonomic</FONT>
<BR><FONT SIZE=3D2>&gt; concepts, so that the &quot;Domain Name&quot; =
analogue would be extended to something</FONT>
<BR><FONT SIZE=3D2>&gt; like:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&quot;OriginalGenusName.OriginalSpeciesName.OriginalAuthor.DescriptionYe=
ar.</FONT>
<BR><FONT SIZE=3D2>&gt; Page.O</FONT>
<BR><FONT SIZE=3D2>&gt; =
therOriginalCitationDetailsAsNeeded_AppliedGenusName.AppliedSpeciesSpell=
ing.</FONT>
<BR><FONT SIZE=3D2>&gt; =
ConceptAuthor.ConceptYear.Page.OtherConceptCitationDetailsAsNeeded&quot;=
</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;The players in the Internet networking =
fabric all now play by these</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; layered rules.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;They all know them and follow them in order =
to keep the Internet </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;running.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; This</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;stuff happens out of sight to everyone but =
the networking people and </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;we</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; all take it</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;for granted and assume it is simple.&nbsp; =
But, it's invisible not because </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;it's</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; simple,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;but rather because it's disciplined.</FONT>
</P>

Agreed. Yet one more attribute where IP/DNS and LSID =
are not distinguishable.

&gt;
 &gt;
 &gt; Excellent synopsis, and (in my opinion), and =
excellent model to follow 
 &gt; for at least taxonomic names/concepts =
data.&nbsp; Perhaps also for specimen 
 &gt; data (but seems less intuitive for that.) This =
comes back to my 
 &gt; earlier question about whether it is vital that =
all bioinformatics 
 &gt; GUIDs be of the same scheme; or whether =
different schemes might be 
 &gt; optimal for different classes of =
objects.
 &gt;
 &gt; Aloha,
 &gt; Rich
 &gt;
 &gt; Richard L. Pyle, PhD
 &gt; Natural Sciences Database Coordinator, Bishop =
Museum
 &gt; 1525 Bernice St., Honolulu, HI 96817
 &gt; Ph: (808)848-4115, Fax: (808)847-8252
 &gt; email: deepreef at bishopmuseum.org 
 &gt; <A =
HREF=3D"http://www.bishopmuseum.org/bishop/HBS/pylerichard.html" =
TARGET=3D"_blank">http://www.bishopmuseum.org/bishop/HBS/pylerichard.htm=
l</A>

</BODY>
</HTML>