Changing the GRSciColl model for staff members and contacts #379
To solve that we would change the model: instead of having these staff entities, we would just have “contacts” for each collections. There wouldn’t be any cross linking. One person could be a contact for a collection with one email address and be a contact for a collection for another.
One advantage is that it would be less confusing, users handle contacts at the same time as they update collections (no need to add a staff entry first). And we wouldn’t have to worry about duplicates.
In summary, here is what would need to happen:
The text was updated successfully, but these errors were encountered:
Other benefits are:
What is the model for "contacts"
Does that model fit well with GrSciColl? Types for example is a controlled list (I think) - that would have to be extended I suppose with new types?
Perhaps we could keep the fields used for Staff in GRSciColl?
I am not very familiar with the agents extension but it seems to be like this is more suited for record-level contribution. A lot of the attributes mentioned in the examples have a very fine grain: contribution to that image or identification of this specimen. I think it will be best to have this extension for GBIF records.
The way I imagined the contact new model is: who can answer questions about that collection? (or who can forward it to the relevant people). I don't think we can realistically do anything more granular.
Similarly, I don't think the GBIF contact types would fit here, there wouldn't be many/any
Perhaps if we had to have a contact type (to fit with the dataset contact model), we could just have a default value.
What do you think?
Only the later requires a bit of consideration I would think? We can deduce something about expertise based on the collection that the person is listed under, but really this probably has to be a list of taxa that the person are an expert in. And we would ideally interpret that list to make it searchable.
This is the relevant use cases I could find from other documents. I thought it might be relevant when discussing the model for staff. Ideally we will want to be able to support below questions I suppose.
From ICEDIG report
And they have user stories as a table
I included the last one since that probably also applies to staff.
From TDWG cd use cases
The new suggested staff model will consist of a new contacts table that will be used only for GRSciColl (not shared with datasets, organizations, etc.). As in datasets, contacts won't be reused between several institutions or collections.
A GRSciColl contact might have these fields:
Any other suggestion?
Dataset contacts have a type - which is really like a role? Which i guess is a bit like
I still imagine it being text in the database
But both could work I suppose. One could also search the more unstructured prose. I just assumed we would get better results with a list of single taxa in latin.