Literature Table/ madule to handle accession related references?

[rintoult]

Can one of you let me know if there will be a separate literature table/module to handle associated literature and accession related references? As I asked last week – if this is not a separate module than I need to have the object store work for me for that kind of application as well and this will directly affect the comments I give about the object module.

Thanks for the info, Tara Rintoul

[dshorthouse]

@rintoult – I see at least two part answers to your question & they depend to a degree on public availability of those documents & the legalities of storing/serving them.

The first is "associated literature", which I assume you mean references to journal articles, books, grey literature, etc. containing all their parsed metadata as well as their PDFs with any cited use of a specimen. To do this well, we'd need a Literature Module comparable to the dozens of desktop-based (or partially web-based) software like Zotero, EndNote, or Mendeley that have tricks to capture the metadata and a thorough metadata model to store it. I'm sure you've seen local database projects try to emulate these & they've been flops. DINA would unlikely be different.

The second is "accession related references". I assume you mean documents like import and collecting permits, tax receipts, communications with donors, agreements & contracts, etc. Here, we have to be cautious because of Protected A/B material. We CANNOT store this material anywhere in DINA even while the application will remain hidden from public view.

So...

May I get you to refine your wishes if I've not characterized them?

Here's what we discussed as an option, to be explored as an interim solution. If the Multimedia Module had a managed attribute "links" to store copied/pasted http/https URLs to the landing page or some other identifying representation of the document, would that work? For a link to a modern scientific paper, we'd paste the https DOI. To a Protected A/B document, that might be a link to a SharePoint item. We might need additional metadata to describe what kind of link something is when pasted so we'd know how to take action on it such as suppressing it from view when we eventually have a public portal.

[rintoult]

In this case I wasspecifically talking about scientific references/literature that relates to accessions. If the object module is what will be used to store information like this than yes "links" to the references would work for that. And the additional metadata would also be necessary. This is what I was going to say was a shortcoming of the object module in my feedback if that module also has to cover off specific PDF types or links to references. At this point I will add my requirements for metadata to my comments on the object module - hopefully these could be populated directly from a citation export from one of the software and online databases you mentioned.

I am worried by your statement that Import permits and the like will not be able to be stored in DINA - or did you just mean anything that would fall under protected material could not be stored. Import permits are not protected - we paste them on the outside of boxes! Any associated documentation like that needs to be directly associated to each accesssion they are associated to - I am suffering greatly from the lack of such associations in the past.

[dshorthouse]

or did you just mean anything that would fall under protected material could not be stored. Import permits are not protected

Yes, that's exactly what I meant. However, do these require capture of additional metadata not presently accommodated in the Multimedia Module, comparable to what you'd require for reference management metadata?

[rintoult]

The import permits no - their title is enough - but for references I would want a quick visual cue to the name of the reference and a second metadata field with reference to the accessions they are related to - it has been a while since I looked at the module but I have notes I made about what I would expect as a user for that instance.

[jmacklin]

In regard to the "protected" information associated with documents, we had to decide early on that we could not store these (could not afford it, literally). Thus, these documents will need to be stored in an appropriate digital repository that has the required protection like Sharepoint (or a location like a file cabinet in someone's office if old-school). The good news is that internal users will be able to resolve these links and access the protected documents. For all docs that are not protected, they can live in the object store itself and as we are discussing here, will need some metadata to allow for discovery/searching and whether the docs can be public or not.

[rintoult]

So to confirm - there will be no literature module in DINA and I will need to use the object module to manage that sort of associated information/records to my accessions?

[dshorthouse]

If I can be so bold as to speak on behalf of the devel. & planning team, you are correct to say there are no immediate plans for a bespoke literature module in DINA. However, that does not mean DINA remains ignorant of literature if we are able to accomplish most of what needs to be done through linking to stable, externally referenceable data objects (eg DOIs) where the metadata are appropriately stored and easily accessed. That said, smart links to stuff elsewhere do not really help with search because metadata are not held locally to feed a search index – that's a problem.