> Richard Pyle writes:
>
> > "a central question, which Donald included in his
> > PowerPoint file, is whether the GUID is assigned to the physical
> > object, or to the electronic representation (data record). Most of my
> > comments have been from the standpoint that the GUID applies to the
> > physical specimen. If it is the electronic records that we wish to
> > uniquely identify, then it seems to me that the <objectID> component
> > of an LSID should apply to the physical specimen, and multiple
> > database records should be uniquely identified using the <version>
> > component."
>
> I think this is not practical. Do you mean those GLOPP organism-
> interaction-data that have specimen voucher information can not be
> published/referenced in GBIF until I figure out whether a collection
> has digitized them (most have never digitized elsewhere!)?
Not necessarily. I don't think the issue is whether or not the collection
has been digitized, but rather whether GUIDs have already been assigned to
the vouchers you want to document in the GLOPP dataset. So, if your question
is more along the lines of "do I need to check to see if GUIDs have already
been issued to voucher specimens that I cite, before I issue new GUIDs",
then my answer -- in the long run, at least -- would be, "well....yes!"
That's sort of the fundamental point of the GUIDs, isn't it? But I don't
see this as being necessarily burdensome. For example, if your GLOPP dataset
included unambiguous pointers to specific voucher specimens (e.g., via
InstitutionCode+CollectionCode+CatalogNumber), then it *should* be a
relatively quick and straightforward process to find out if GUIDs have
already been assigned (if it's not quick & easy, then the GUID service would
be horribly inadequate!) If, on the other hand, the GLOPP dataset does not
provide unambiguous pointers to specific voucher specimens, then the
"vouchered" aspect of those specimen citations seems unsupported, in which
case your GUIDs would need to be assigned to virtual/unvouchered "specimens"
(analogous to observation records), and hence non-duplicate.
> Or if I
> find they have not been, when the collection starts to digitize them,
> they would have to create for those that have already been published
> in GLOPP use a new version of the GLOPP LSID?
I would hope that if you assigned GUIDs to GLOPP-relevant voucher specimens
that belong to a collection that is not-yet digitized, you would do the
courtesy of providing the manager of that collection with a listing of the
GUIDs you created for the specific relevant specimens. I would further hope
that, when that collection is eventually digitized, the manager would have
the wherewithal to assign new GUIDs only to those specimens that did not yet
have them.
But, as someone who has worked in a natural history collection for nearly
two decades (and who bore witness to the transition of the collection from
non-digitized to digitized), I certainly do understand the "realities" of
this, and fully recognize that my optimistic perspective is likely to be
overly idealistic. This is why I feel that duplicate assignment of GUIDs is
inevitable (that is, two different numbers for one object; not duplicate
GUIDs), and MUST be accommodated in any GUID system that is developed. My
main point is that such "redundant" GUID issuance should be minimized (i.e.,
never done intentionally), and quickly/easily identified as such whenever it
is discovered.
So....if/when the situation does come up that (for example) GLOPP assigns
GUIDs to vouchers on behalf of a non-digitized collection, and that
collection later (inadvertently) re-assigns redundant GUIDs to the same set
of specimens; that eventual discovery of this duplication should be
accommodated by a mechanism for "retiring" one of the IDs into "objective
synonomy" of the other ID, and automated systems should be implemented in
the resolver service that "auto-forward" the retired ID to the active ID.
If your question is more about whether the collection, when it later becomes
digitized, should use the same <objectID> ID as was assigned for the GLOPP
dataset, but qualify that same Object ID with a unique version number --
then my answer is, "I don't know". That is sort of the question I was
trying to ask ('though I didn't ask it very effectively). Basically, I was
suggesting that/asking whether it would make sense to pin the <ObjectID>
portion of a GUID to the physical object, and using the <version> feature as
a unique identifier to electronic representations thereof?
> The same applies to taxonomic data - most revisions contain voucher
> data.
Same solution, I think.
For the most part, though -- I see these as "growing pains" of a GUID system
during its first years of existence. I would predict that two decades from
now, if one were to do an analysis of redundant GUIDs, one would find the
bulk of those having been issued relatively early on.
Aloha,
Rich
