Agent cleanup - agents of type "other agent"

[Jegelewicz]

I'm guessing that about half of the agents of type "other agent" are actually people or organizations. It appears that some people are entering all of their new agents (or at least a lot of them) as this type. I know this can happen occasionally by mistake, but we have a lot of cleanup to do here. @ArctosDB/agents-committee

A LOT of people can add agents one by one - maybe we need some better training? Or maybe we need to ask people if they are sure they want to add an agent of type "other agent"? There really shouldn't be that many agents of this type added anyway.

[dustymc]

half of the agents of type...

I suspect most of them don't need to be Agents at all.

better training?

Always, but 4554 would mitigate much of what actually causes problems.

[Jegelewicz]

I suspect most of them don't need to be Agents at all.

Yes, many of them are initials only, a single (last) name, or something that should be a project (Hantavirus stuff, zoology class, etc.) As for ArctosDB/arctos#4554 I don't think the community is ready for that - I really did try at the issues meeting, but absolutely zero people were in any kind of agreement.

[lin-fred]

agents committee check back on this after the verbatim agent purge

[Jegelewicz]

Most will get verbatimed in the Great Agent Purge - we will deal with rest after.

[ewommack]

We probably need to change the documentation for "other agent" in the code table:
"Mishmash of garbage largely synonymous with "unknown." Examples: "native", "crab boat", "student", "WIT 48", "Post."'

I'm thinking we particularly want to remove student. If they are a student of someone, then that should go in the agent relationships now right?

[dustymc]

change the documentation

To NULL, as we delete the type....

[dustymc]

ping @mkoo

[Jegelewicz]

I say we change all of these to organization and remove other from the code table. They have no functional difference, so other does not seem necessary?

[dustymc]

Agreed, except 'other' are generally lower-quality at the moment and in my happy little fantasy world the @ArctosDB/agents-committee would take a swing at cleaning them up before removing that flag.

[Jegelewicz]

happy little fantasy world the @ArctosDB/agents-committee would take a swing at cleaning them up before removing that flag.

We do not have enough resources (TMP - time, money, people)

[Jegelewicz]

@dustymc is this even a thing anymore? I cannot search by agent type, so I can't see if there are any....

[dustymc]

We do not have enough resources

Sure we do, we just choose to spend them on other things - which seems like a decent call at the moment, very tentatively closing, here's a current-data dump.

temp_other_agent(1).csv.zip

[Jegelewicz]

@dustymc can you modify these records so that the identification determiners are:

1. Takehito Ikejiri
2. Chelsea Coman

and remove the "group" determiner Takehito Ikejiri and Chelsea Coman?

Once that is cleaned up, I can get rid of the "group" agent.

Let me know if that makes no sense....

[Jegelewicz]

Any way we can convert the A. Smentana's to Ales Smentana? Sometimes it isn't possible (when the group is the determiner of an attribute or assigns an event...)

[dustymc]

There's no Smentana (and I can't embiggen your image).

[dustymc]

and remove the "group" determiner Takehito Ikejiri and Chelsea Coman?

done and done

[Jegelewicz]

Here is another set

https://arctos.database.museum/agent/21345102?deets=true

[Jegelewicz]

There's no Smentana (and I can't embiggen your image).

My bad - Smetana

[dustymc]

another set

I got the identifications, updating collector failed because some record uses the group and at least one member.

ERROR:  duplicate key value violates unique constraint "iu_collector_coid_order_role"
DETAIL:  Key (collection_object_id, coll_order, collector_role)=(30788276, 1, collector) already exists.

I don't have the attention span to sort that out right now, I can get it later or the bulk tools can probably handle it.

[dustymc]

Smetana

That's better but now I'm lost - you want half of the 4 groups or ???? I can do that, but also see above - kinda-converting makes future-things no fun.

[Jegelewicz]

kinda-converting makes future-things no fun.

Agree, and some of these cannot be converted because there aren't places for two agents. I can't do anything with the Smetana's because it's all UAM stuff that I cannot edit - but I can see in the other agents that the A. Smetana in them is Ales Smetana (because they are an associate of the other agent). The other half of the various other agents could be handled similarly.

If that makes no sense and you don't have time - no worries, just change all of those other agents to organizations and move on?

[Jegelewicz]

I am working through the list of agents that aren't a list of people, or a group or project to get them switched to organization or person (yes, there are some people in this list!) and to verify them if possible.

[Jegelewicz]

https://docs.google.com/spreadsheets/d/1qIo91Y4AvCbhrMuV7pdkcB1NonENkM-T/edit?usp=drive_link&ouid=115457622099601875930&rtpof=true&sd=true

[Jegelewicz]

FWIW, I spent about 5 hours on April 22nd working on these until my brain was melting. I decided to step away, but it continues to nag at me.

[dustymc]

I knew viruses were capable of some amazing things, but I had not considered this possibility....

nag at me.

Me too, not just here. We need some sort of big-picture Community consensus. I could help clean these up, but I don't want to waste my time either. Is this (and ArctosDB/arctos#7649 and etc.) just us, do we have any sort of quality guidelines/requirements/whatever to aim for (enforce, whatever), etc., etc. ??

[dustymc]

The definitions were recently updated, but I can't see any functional distinction between https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_type#other_agent and https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_type#organization in current or past definitions, nor in the data. Unless someone has a better functionality-based solution by the next time I find this, I'm going to declare this a matter of denormalization and

• for all agent.agent_type of 'other agent' insert a curatorial remarks [ link ] attribute of value 'formerly agent type other agent'
• update all agent.agent_type of 'other agent' to 'organization'
• remove the then-unused type

[AJLinn]

The distinction is a formal & organized body of agents vs an informal collective gathering of agents.

In doing a search for agent type "other agent" it seems like many of these are expeditions and projects, which are not "organizations" though the sponsoring agent of those expeditions and projects would be an organization. I also see a bunch of agents that are UNM Mammalogy Classes, which again, are not "others" but look to have been previously categorized as agent type "group" based on the info in the "other" column. There are likely privacy issues with listing individual students in that class (FERPA) therefore the "other agent" tag.

And certainly the "unknown" agent is not an organization any more than it is a person (as you questioned when I initially created the "unrecorded" person agent).

I think it's worth holding off with a merge until the creators of those agents and those affected and weigh in on the issue. There aren't that many...

[dustymc]

formal & organized body of agents vs an informal collective

If that could be formalized and enforced it might make sense. We would need clear definitions and a migration plan; that's clearly not how the data have been used.

"other agent" it seems like many of these are expeditions and projects

https://arctos.database.museum/agent/21350488 - not consistent, I think ANY example will have a few members on the other side.

previously categorized as agent type "group"

That was functional, not a "typing." (And no longer necessary, relationships do all the former type did and more.)

therefore the "other agent"

Na, those that ended up here were just not-great data. If there's some sort of curatorial-or-whatever filter needed, please file an Issue; such things are not effective when compounded with this type, but are easily and explicitly handled by the current model.

"unknown" agent is not an organization

Well it's a loose one anyway....

I don't think an outlier (or group of them) is sufficient reason to retain what's clearly sorting similar data into two piles.

and those affected

There is none that I can see; this is not used in a way which can support any function. What I proposed would retain all existing functionality, but it's not something that could be consistently asserted post-migration - happy to use some more-permanent attribute if there's a need.