How to treat label headings (Herbarium/collection of provenance)

[igranzow]

A most common practice of herbaria, and many individuals for their own collections and in a variety of other, is to state "ownership”, or as the “originator” of a specimen as a heading on the label. Such specimens eventually become distributed and re-distributed as part of exchanges, gifts, etc., often repeatedly.

Now, the question is: If one wants to record this information –for whichever reason, regardless of he value preserving such info mu have– … where to store it?

This info at the heading of a label may refer to personal herbaria, a research program, al expedition, or many other scenarios, but has nothing to do with an exsiccata (despite appearing in the same place on a label). These specimens, once part of a unified collection that was broken up long ago, now disseminated, its components now disseminated and far from each pother, may land at one’s herbarium after hopping around other herbaria. Thus they are not part of their own accession (but, rather, mixed with others with very different histories).

Any suggestion on a table/field in Specify –other than remarks fields which by no means should be within the CollectionObject table– appropriate to house this info?

Many thanks

[NielsKlazenga]

We (at MEL) have been thinking of using the Exsiccata and Exsiccata Item tables for this, as they have the right relationship with the Collection Object table, i.e. many-to-many relationship between Collection Object and Exsiccata. However, at the time, these tables were not fully implemented in the client, so we did not get very far, also not with proper exsiccata.

[joaquimsantos]

At Coimbra Herbarium (COI) we defined recently one of the custom fields on Preparation table (Text2) to record that information (ex herbarium, distributed by, communicavit, dedit, etc), along with a couple other fields to record associated info, such as the original accession number or date.

[rdrinkwater]

At Edinburgh we use a text field in Preparation to record Label Header. This is a field we had in our previous database that we carried into Specify. In our previous system this field was used when printing labels, as well as recording this information from other specimens in the collection.

[igranzow]

Thanks so much Niels, Joaquim and Robyn for your responses.
I see that Joaquim and Robyn resort to the same solution: a customized text field in the Prep table. At MA (Real Jardín Botánico, Madrid) we thought of this at one point, but has the drawback of loading the database with many many (identical) replicates for every string of text, even when referring to the same herbaria of provenance / communicavit / distributed by, etc… I.e., the string “Herbario Stationis Agronomica…” –using Joaquim’s example– is written in the DB many times, once per specimen (albeit in the Preparation table). Doing it this way one doesn’t benefit from the Relational DB principle of having a string of info written ONLY once. Instead, one has theText2, “ex herbarium” field in the Prep table containing many iterations of the exact same string.

On the other hand, MEL’s solution of using a field in the Exsiccata table (I wouldn’t know WHERE in the ExsiccataItem table given its paucity of fields) is what we’re currently trying at MA. It doesn’t incur in that n-plication because a specimen is related to a single ExsiccataItem and Exsiccata. In any case, this table (Exsiccata) also has VERY FEW fields. Its SCHEDAE field could be somewhat appropriate (rather, it’s the only available one as there’s no customizable Text1). However, the problem is that the current Specify model REQUIRES the field TITLE (in the Exsiccata table) to always be populated (even when there’s no “title”, because we are not talking of a true exsiccata). Niels, how do you resolve this? I can’t find a way around.

The Fascicle or Number fields (the only usable fields in the ExsiccataItem table) are obviously not pertinent to designate a “herbarium of provenance” either. What complicates things further is that when forced to pretend an “ex herbarium” or “from XXX’s collection” bear a TITLE as if it were an exsiccata, is that you’re also forced to provide a formal REFERENCE. …That’s too much pretending.

The truth of the matter is that there are many flavors of information that may be construed (sensu latissimo) as exsiccatae, including Joaquim’s examples: ex herbarium, distributed by, communicavit, dedit…, presented by, expeditio. They are far from being one and the definitively have no reference/publication associated.

My suggestion is:
1st and foremost: Do without forcing (Exsiccata) Title to be mandatorily populated.
2nd: Add one (or more) fields in either the Exsiccata or ExsiccataItem tables to house that info. Schaeda could work for some instances, but providing at least a couple custom TextN fields should suffice.
Thanks for bearing with me
Íñigo

[NielsKlazenga]

Hi Inigo,
Sorry I did not see your question earlier. Before answering, please bear in mind it is a long time ago that I looked at this and we did not take it all that far, as at the time we could not get the Exsiccata form to work. I still think it can work nicely though.

For us, it was never about label headings, but provenance, and we want the many-to-many relationship between Collection Object and Exsiccata (there is a one-to-many relationship between Collection Object and Exsiccata Item and a many-to-one relationship between Exsiccata Item and Exsiccata, so a many-to-many relationship between Collection Object and Exsiccata).

For collections, we would use the Title field in Exsiccata for the name of the collection, for example, we’ve got the Sonder collection (Herb. Sonder). So, for us Title being required makes sense. Yes, having to create a Reference Work record for a collection was a bit annoying at first, but it does give you some extra fields and also the ability to link to an Agent record. A few extra fields in Exsiccata and Exsiccata Item would indeed be awesome. I cannot remember the Schedae field (in Exsiccata) and I cannot immediately see what its intended usage is, so I would probably put a pick list in it indicating whether the record is for an exsiccata series or a collection (or something else again).

As I said, I could not get it to work about ten years ago, but I found that in the more recent versions of Specify 7 I am able to do things that I could never get to work in Specify 6 – I got Collection Relationships to work this afternoon – so I might try again soon.

Also noting that Project has perhaps a more straightforward many-to-many relationship with Collection Object, so that might work better for your situation, but for me the fields are more problematic than in Exsiccata + Exsiccata Item. I also already use Projects for all sorts of lists, for example for specimens sequenced for the GrassBoL project (and similar projects) or batches of type specimens for which we sent images to JSTOR for the Mellon/Global Plants Initiative project.

PS. I do something similar to what Joaquim and Robyn do with the collection name, but then with the type status string that we want to print on the labels (or packets actually) for our types. People do not get to fill that in themselves though, but I have two functions and a procedure (don’t worry @JimBeach, no trigger) to populate the fields in Preparation with the relevant information from the Determination and Taxon tables.

[igranzow]

I’ve parked it for some time but need to resurrect the Exsiccata vs. Provenance of specimen topic.

I think most of the problem could be solved if in the table Exsiccata the requirement for RefernceWork was lifted. I’ve been convinced by @NielsKlazenga reasoning that Exsiccata.title could be used also for non-true-exsiccatae, thus disregarding the schaedae field, which I assume is designed for “collection of provenance” when not a “true” exsiccata (I’d much rather use schaeda for this purpose, however).
But if my suggestion of making Exsiccat.tittle NOT required is not an option, at least referenceWork must be NON required.

Working these days with zoological collections I realize there’s often the need for stating provenance of a specimen on a specimen-per specimen basis that’s not so different from our botanical exsiccataItem + Exsiccata model.
Here’s a common example. In an accession of N specimens from a given institution/collection X, some individual specimens may have had a prior provenance that’s not necesarily shared among the N specimens in the accession. I.e., the origin of some specimens could be traced back to older, preceding accessions from institution/collection X-1 to institution/collection X. Such “provenenance” is not accession-specific but specimen-specific, although it could be shared with other specimens across accessions. Our ExsiccataItem + Exsiccta model (desirably with no required RefWork) accommodate info on this kind of historical traceability, which is needed in most disciplines and that so far I’ve been unable to find by other means.

Any chance that ExsiccataItem + Exsiccata could be slightly tweaked (by suppressing Exsiccata.title and/or Exsiccata>RefWork) to accommodate “specimen provenance” if the Specify model is to be reviewed in the coming months?