No Determiners Left Behind

Often a determination is made/signed/claimed by more than one person. Currently ONLY ONE can be recorded in Specify as a “THE” determiner (which may upset those left out). Is there a way that multiple determiners (individual agents) could be included as “co-authors” of the determination, just as multiple collectors in a collecting event can?

Creating a group to include all of them (often just 2, ocasionally 3) would be most undesirable.

Hi Inigo

Saludos from Middle Earth. Good question, I recall that we have circled around this issue at least a few times in the past, but I’ll have to wait until Monday to get the collective memory of the group on situations where there are people (names), that are not deserving of Agent status, and going the Group Agent method as you say is overkill. I should not even be suggesting options, with the real practitioners out of the office today, but is it possible to use a text field for Determiner’s names and give up some of the spell checking, duplicate avoidance, formatting consistency, indexing and relational integrity that comes with them being Agents? Theresa is probably cringing as she reads this, but thought I would say hello and stir the paella.

I would be crying too, Jim :wink: as I try to minimize reliance on custom text fields; only as a last resort.
I may have misnamed the topic as “additional Determinets”. I should have rather called it “co-determiners”, as in most cases of two (or more) Determiners, they are all equally worth of Agent status. Usually they are all existing and well established Agents and it’s not obvious (from the order) who’s the “principal” one, with the implecation taht the rest are “second tier” persons of dubious Agent worth.

I’m staring to realize that having determinations roll through “co-determiner” Agents, like Specify does with collectors, may be a technical nightmare. I’ll understand and won’t insist.

However, if sucumbing to what you propose for other “co-determiners”: using a custom text field that can give up some of the spell checking, duplicate avoidance, formatting consistency, indexing and relational integrity that comes with them being Agents… well that’s better than bagging other co-determiners altogether.

Thanks for your efforts. I’ll stay put for the feedback from the real practitioners in this Monday meeting (agenda allowing).

Hi Inigo –

We had a discussion of your appeal on behalf of all of the Lost Determiners.

Los Determinantes Desaparecidos?
No Determiners Left Behind!
Make Determiners Great Again!
That should cover the political spectrum. :smiley:

As you know, for several other Agent roles in Specify we modeled a many-to-many relationship between Agents and their respective roles. For example, Collector is M-M with Agent, so in the database schema Collector is implemented as a join table between Agent and Collecting Event, which enables more than one Collector to be recorded in the database and shown on the forms.

With the Determination table, we included a relationship to Agent that was M-1, with no join table to support a M-M relationship and thus no multiple (Agent=person) Determiners in the interface. We thought Determiners could be handled as strings without Agent status, as our emphasis was on people involved in the creation and handling of specimens, over the roles of researchers in adding value to specimens, in this case by naming them. In retrospect, we probably should have anticipated the need to recognize the role of Determiners more directly. And perhaps other roles like the specimen preparers and mounters who could arguably be considered Agents as contributors to the specimen curation process.

It’s interesting that as the “extended specimen” and the “digital specimen object” concepts start to emerge, there will likely be more ‘Agents’ who will impact the data associated with a specimen and need to be associated with collection object records. It is still an open question where that attribution and data linking will occur, within the CMS or outside of it, although there are people and organizations thinking about such architectural things (e.g. GBIF, DiSSCo), particularly in the context of advancing their global vision for collections data.

The staff was sympathetic to your plea, and are considering extending the Specify data model in a future release to allow for multiple determiners as Agents. It would probably be late 2022 at the earliest when we would be able to do that. We would move existing Determiner records to the new relationship, but unless we can figure out away around it that update would break most existing data forms, which would need to be tweaked in the form system to handle multiple values for the Determiner field.

For any SCC member reading this thread, it would be useful to have your feedback on how important this change would be, and whether you would take advantage of it for cataloging new specimens. Here is the instant survey:

  1. We would begin cataloging multiple Determiners right away as Specify Agents!
  2. Might be nice, but we don’t really need to treat Determiners as discrete Agents in our Forms.
  3. Recording multiple Determiners is not an important part of our collection database activities.

Jim Beach

igranzow

1 thought on a workaround - one of the ways we are looking at handling this is to enter multiple determinations - 1 for each determiner. - these can be easily created (using clone) and just the determiner needs changing between them.
thanks
Ben

I think it is important to deal with collectors and determiners consistently, but I would go the other way. The big advantage of having a single (Group) Agent is that it can be reused. Rather than being overkill, the Group Agent actually saves work (and probably errors), especially when there are many collections or identifications by the same group of people or when the group is large. It also makes for a cleaner data model, I think.

I would probably not throw out the Collector table, as some collections might have stuff in there that applies to a single Collecting Event–Agent combination, but it would be nice to have a CollectorID field in the Collecting Event table as an alternative, so we can have a query box on the Collecting Event form rather than having to include a Collector form, which has to be filled in every time (which also causes a lot of duplication in the data).

Since there is no Determiner table in Specify yet, I would suggest not adding it. I think people like the idea because they are used to it for the collectors, but it is a legacy way of modelling and recording things. It will cause another many-to-many relationship in the data model and unnecessary bloat in the data model and API – which will also become less standards compliant and thus less usable – and further down the track.

Sorry, always the recalcitrant one.

Being able to record multiple determiners in a determination record is something that would be helpful to us and that we would be using frequently.

1 Like

We have been aiming to reduce the number of agent groups in Specify, restricting these to expeditions defined by a distinct number series. The ability to add multiple determiners individually to a determination (similar to the functionality of collectors) is therefore a priority for us.