We desperately need a way to link preparations many-to-one AND many-to-many to Containers which can be linked to the storage tree.
Use Case:
- We have a storage type where there are multiple catalogued lots in a single larger container. For example, lots in a single cabinet drawer, or lots in an oversize box on a shelf.
- We also have a storage type where multiple containers house the specimens of a single preparation of a catalogued lot. For example, a lot of 100 shells that occupies multiple boxes because there are so many.
- Both of these types have an added complication, which is that some preparation types are “paired” logically and are always stored together in the same container. So in those cases, one or more containers contain many preparations of a catalogued lot, but not all of the preparations from that lot. ex.
Dry shell pairs and Dry shell singles are separate preparation types in our DB because of Specify’s baked-in limitations in tracking individual organisms. Those preparations always have the same storage info and will always be in the same container.
- We need to be able to track the number and location of these containers separately from preparations or COs.
- We also need to be able to print labels for these containers from within the database.
One could technically make every single container a node in the storage tree, but this would be extremely difficult and impractical to manage.
We cannot use COG for this, as the relationship of the container is not modeled correctly (at least, I don’t think it can be), because there is no “master” or “primary” object, and the fundamental relationship is between one or more preparations and one or more containers, which are not catalogued objects and should be entirely independent of the CO table.
Furthermore we need to reserve COGs for a different kind of relationship.
Is there any way to accomplish this in Specify 7 at present? If not, is there a potential for this kind of relationship in the near future with the update focusing on Schema changes?
This is functionality we really desperately need. Not having it blocks a ton of our storage data from being imported into Specify.
Hi Nate,
Currently, the storage table is the closest functionality we have, with it being independent from Collection Object and Preparation. However, it sounds like the many-to-one relationship doesn’t fulfill the needs of a lot-based preparation workflow.
I posted this feature request on Github for you. Feel free to add any more details or ideas you have here on the Speciforum or leave a comment on Github: Containers redux · specify/specify7 · Discussion #8381 · GitHub.
– Lexi
Thanks for writing it up. Honestly, it is hard to think of the best way to use the storage tree, or the way it should work in an ideal world. Does any Specify collection in the world actually use it? I haven’t ever seen a good example.
The problems with batch editing tree-based tables in the current version of Specify mean it’s problematic to make many individual storage units and group them hierarchically. This problem compounds when one considers that almost all natural history collections are organized phylogenetically or alphabetically by taxon in Linnaean ranks. This functionally means that in order to appropriately use the storage tree, one needs to maintain a second taxonomic hierarchy within the storage tree that it is impossible to link with the taxon tree, which also must be manually edited whenever changes occur. The problem of correlating taxonomy to physical storage location is thus made more complicated by this structure, not less. And this is further compounded by the fact that many collections have multiple phylogenetic series, for example, both a wet and a dry collection that are organized phylogenetically and thus would need to have independent branches on the tree with the same data, all impossible to batch edit within the software itsself and all impossible to link to eachother.
And of course, as you mentioned, the many-to-one relationship between preps and storage leaves out the possibility that a prep might be split between multiple storage locations, which is a reality for most lot based collections (some lots are just too big to fit in single containers).
One could use multiple preparations of the same prep type to get around that issue, but that would be compromising the quality and utility of the data to fit an inadequate data model. I try to avoid doing that whenever I can.
Hey Nate,
There are indeed many other people that use the storage tree in Specify! The Florida Museum of Natural History, in particular, has documented their method for managing storage using an accessory barcoding app. You can find a proof of concept learn more about the process on their repo: GitHub - FLMNH/SpecifyStorageTreeBarcodeUpdateTool: Allows rapid updating of the Specify Storage Tree with barcode scanning. · GitHub
Bronwyn, this is awesome, I was not aware of this add-on used by the UF collections! @warrenbrown is a wizard. 
This is a great example of an implementation that would ease some of the pain of using the storage tree at present.
One problem with our collection is that I decided pretty early-on that barcodes on our labels do not uniquely identify individual preps, but instead are identical for all parts of a single lot. There are pros and cons to this approach, but the main one is that when printing labels, you do not need to worry about having different labels for wets and dry specimens, all parts of the lot with the exception of tissues and SEM stubs use the same label design.
I have been toying with the idea of using the taxon tree itself with “start” and “stop” positions listed as text fields for various taxa. I wonder if having a table that linked storage and taxon would be a good solution for us and other similarly-set-up collections. Alternatively, I’m sure there’s a way forward with the UF-style scanning app by tweaking how locations get recorded in some rules-based way, since our collection does follow stringent rules about where certain prep types are stored.