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

[Dean Pentcheff]

Unsorted deep-sea dredge lot
=> all anomurans pulled out into a single jar
=> anomurans sorted into one jar per known species, unidentified left behind
=> individuals of one species each separately examined by a parasitic
isopod worker
=> parasitic bopyrid isopod from a leg of one of them: new species!

We've still got one or more jars or vials for each level somewhere on a
shelf (probably on different shelf banks and possibly in different
buildings).

>From the point of view of publication, could we get away with a single
reference number for all those objects, or maybe two levels? Realistically:
probably.

What does give me the creeps about minting neither a hierarchical number
nor a different arbitrary numerical ID for each level is that we then have
multiple "things" in multiple locations, all of which are identified with
the same ID.

When I reference an ID, I want to know if it references a gallon jar of
gunge or a single tiny vial, not "any/all of the above scattered about the
premises".

(And, indeed, thanks! It's perversely fun trying to think through all this
clearly!)

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


On Sat, Aug 23, 2014 at 2:40 PM, Colin Favret <ColinFavret at aphidnet.org>
wrote:

> Hi Dean,
>      Thanks for clicking send! Your perspective is food for thought. I
> admit to not being completely comfortable with my decimal system, hence my
> query to the group. On the other hand, I have not been able to think of a
> situation where a *fully processed museum object*, one whose database
> record is worthy of serving to others and being referenced in a
> publication, would be broken down any further than one level in a hierarchy
> (museum object > specimen).
>
> Thanks again for everyone's insights! Colin
>
>
>
>
> On Fri, Aug 22, 2014 at 7:01 PM, Dean Pentcheff <pentcheff at gmail.com>
> wrote:
>
>> [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/20140824/49adff5d/attachment.html