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