[tdwg-guid] An approach to Abstract LSIDs[Scanned]

[Richard Pyle]

> Isn't this where I came in last week Rich?

Sort of....but we weren't clear back then about the role of the "Abstract"
LSID that would encompass all of the many database-record LSIDs.  I know
this is almost a no-brainer for those who have been part of the LSID
discussions over the years, but I think part of our confusion is that we're
talking about data-bearing LSIDs applied to database records as if *they*
would be the LSIDs we also use to represent the abstract notion of "the
name".

> The LSID urn:lsid:indexfungorum.org:names:178962 is assigned 
> to the IF database record for Amanita phalloides (the 
> deathcap - used as one of the EoL sample species pages [well 
> done EoL]). 

Right -- so this is really a "Name Usage" instance -- that is, the usage of
the name "Amanita phalloides" by Index Fungorum.  Or, maybe it's a usage
instance from some other publication that IF index, like the original
description (=protologue) of the name "Amanita phalloides".

> If I recall correctly the
> getData() returns "Amanita phalloides" 

Not according to Kevin (who agrees with me on the data-less LSIDs for names)
-- but he can answer that himself when he gets back to his email (I think he
and Sally are just now getting onboard a plane leaving Hawaii as I type
this).

> [not the primary key 
> of the database record, which is 178962 - Rich, why did you 
> restrict the getData() to returning a PK?]

My rationale is this:  If getData() returns a bytestream (rather than
nothing), then pretty-much by definition the LSID identifies a digital
object -- not an abstract object.  The "name" is an abstract object, with no
digital (or even physical) manifestation.  So, if the LSID returns binary
data via getData(), then the LSID identifies a digital object, which in the
scenario I described would be a computer database row (reocrd).  I suggested
the PK as a "natural" binary representation for a database record because
it's the attribute of a database record that is LEAST likely to even need to
be changed.  Technically, if the PK changes, then you're really talking
about a *different* database row, and as such, it would be a different
digital object, and as such, it would need a new LSID.

In most cases, the content of other columns (fields) in a database record
are more subject to change.  If you embedded content of other columns/fields
into the "data" part of the LSID, then you would be duty-bound (per LSID
specs) to generate a new LSID everytime you changed any part of any
column/field that was included within the scope of "data" returned by
getData().

Because I like he idea of GUID reusability, my inclination would be to
follow a protocol that least necessitated the generation of new GUIDs for
objects that I would otherwise intuitively think to be the "same" thing.
Frankly, the biologist in me is FAR more interested in GUIDs for abstract
objects (i.e., objects without inherent digital manifestation, such as taxon
names, specimens, etc.), than I am interested in GUIDs that identify
specific database records.

> Is this your proposed solution Rich?

Not exactly....but I only had 5 hrs sleep last night, and it's been a REALLY
long day (11pm now), so it's probably best for everyone concerned that I
shut up now and go to bed....

:-)

Aloha,
Rich