[Nhcoll-l] Unique IDs for museum objects versus specimens

[Dean Pentcheff]

[I have just discovered that I never hit "Send" on this comment. Sorry!]

How significant my objection is would be a matter of opinion...

But here it is. What's outlined there is, in effect, a two-level system.
There are "first class" specimen IDs (e.g. "INST-123456") and then one
"derived" level (e.g. "INST-123456.077"). This is analogous to Doug's
system described earlier.

There are several appealing aspects to that. One is that it's apparent on
inspection that the ".077" item is directly descended from the "123456"
item. Cool. Another is that it's easy to gather together all the objects
that came from "INST-123456" by inspection if they're in front of you,
intermixed with other objects.

There are some downsides, though. One is that, in situations where there
can be multiple levels of derivation, we move to the more generalized
system as outlined by Lena above (e.g. 123456 <- 123456.077 <-
123456.077.012 <- 123456.077.012.003 ...). There's an increasing problem of
length and complexity with this scheme. (This is not academic, by the way,
we really do have quite a few examples where this many or more levels of
derivation happen with objects in our collections.)

The particular scheme you propose also has an implicit limit to the number
of derived objects. The "-077" implies to me that up to 999 items can be
derived at a single level. Though that's probably fine for nearly every
case, I think we'd agree that dropping one number and going with "-77" is
insufficient. So we have a nearly-always-useless "0" floating around with
every ID.

These are the sorts of concerns that sway me back towards a single,
numerical, opaque identifier for every "thing" that needs tracking. It's up
to a data system somewhere to keep track of the relationships (and they can
also be printed on permanent labels where that is practical).

-Dean
-- 
Dean Pentcheff
pentcheff at gmail.com
dpentche at nhm.org


On Thu, Aug 14, 2014 at 1:55 PM, Colin Favret <ColinFavret at aphidnet.org>
wrote:

> Thank you to everyone participating in this interesting discussion. I'm at
> least relieved to know that there is no community standard, yet, and so I'm
> not off kilter having developed my own solution. As I understand it,
> palaeontologists assign separate unique identifiers to the different fossil
> specimens in/on a single object (?). And Specify seeks a solution to
> disambiguate "Containers" from specimens.
>
> But unique identifiers referring to museum objects or specimens are not
> "dumb" in the same way that they are for localities, collection events,
> taxa, etc. They refer to physical objects located in a collection that bear
> a label with that unique identifier. That unique identifier is thus part of
> the object retrieval process for collection users, in addition to being for
> data retrieval.
>
> So can we envision a system where the unique identifier for the 77th
> specimen on a microscope slide can also be used as part of the object
> retrieval process? Or have we decided that, given a unique identifier for
> the 77th specimen, I'm better off having to go to the database to reference
> the museum object's ID before heading into the compactors? Does anyone have
> a significant objection to the decimal INST-123456.077 to uniquely refer to
> the 77th specimen in/on museum object INST-123456?
>
> Thanks for the continued discussion!
>
> Colin
>
> _______________________________________________
> Nhcoll-l mailing list
> Nhcoll-l at mailman.yale.edu
> http://mailman.yale.edu/mailman/listinfo/nhcoll-l
>
> _______________________________________________
> NHCOLL-L is brought to you by the Society for the Preservation of
> Natural History Collections (SPNHC), an international society whose
> mission is to improve the preservation, conservation and management of
> natural history collections to ensure their continuing value to
> society. See http://www.spnhc.org for membership information.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.yale.edu/pipermail/nhcoll-l/attachments/20140822/ed3ae6d8/attachment.html