Agents - better integrate when/where (and doing what?)

[jtgiermakowski]

How to Use This Form
This is a template with examples and guidance on how to best communicate with the Arctos Working Group. Please delete this section along with anything in square brackets [ ] below before submitting.

[ Instructions for reference: ]
[ Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html ]

[ Code Table Documentation is https://handbook.arctosdb.org/how_to/How-to-Use-Code-Tables.html ]

[Video Tutorial - Submit a Code Table Request]

Goal
Add a degree conferred by a University to person agent in Arctos. for example

student of "UNM" degree: B.Sc.

optionally, a year (if known)

Context
there's no drop down menu or field for "student of", seems that relationship only assumes that "student of" relates to a person but if we know that the person was a student of a certain university, and hopefully, their degree, it helps to disambiguate agents

Table
[ Code Tables are http://arctos.database.museum/info/ctDocumentation.cfm. Link to the specific table you are requesting changes to here. ]

https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_relationship

Proposed Value
"degree conferred" ?

Proposed Definition
academic degree, must have at minimum the university or college as agent in Arctos, optionally a year conferred

Collection type

all

Attribute data type

categorical

Attribute value
B.A.
B.Sc.
M.S.
Ph.D.
etc... see https://en.wikipedia.org/wiki/Academic_degree

Attribute units
[ For number+units attributes, code table controlling units ]

Available for Public View
No

Priority
[ Please choose a priority-label to the right. ]

[Nicole-Ridgwell-NMMNHS]

What do you think the benefit would be to having a separate field for this rather than just put this information in remarks?

[ewommack]

having a separate field for this rather than just put this information in remarks?

That's what I do, with a note on their study field if possible. Maybe @jtgiermakowski you can think of a reason to need to search on it? Or it would lead to a change in its display?

[jtgiermakowski]

What do you think the benefit would be to having a separate field for this rather than just put this information in remarks?

Same reason as any other data field. The biggest benefit is being able to search/report/output for stats. It would be really nice to be able to tie agents to universities, degrees, etc. Also, we have a lot of collectors/preparators/etc. that were students in a class as opposed to being graduate students. I like the idea of atomizing the data in fields so that we can have:

student of -> L. Agassiz
student of -> Harvard University degree conferred -> Ph.D. date -> 1868

[dustymc]

See also #5113 (comment), which I haven't quite managed to distill down into a proposal. The above data would be entered

• some date (harvard bits buried in remarks where they can't help get at 'is that this person' questions), or
• harvard (date-bits buried in remarks where they can't help get at 'is that this person' questions)

or MAYBE both, but there's no capacity to fully express "at Harvard in 1868."

I think this proposal is just asking for one more standardized bit in that chain: "At Harvard, getting a Ph.D, in 1868."

In general, I think we need to (somehow) change our two-component (address and status) and a wish (this issue) model into one three-component (probably all optional) model, involving when, where, and what (all attached to who).

When is easy, it's just a date-pair.

What could be some synthesis of https://arctos.database.museum/info/ctDocumentation.cfm?table=ctaddress_type, https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_status, and whatever else might come along (such as "getting a Ph.D") - just a list/code table. (Or not, or maybe not only - do we want "getting a Ph.D" or "getting a Ph.D in botany, so this probably isn't your lizard collector"?)

I think "where" is still fine as a string (plus the coordinates which have always been there), but if we want to get super fancy it could potentially get linked to localities or something.

That's all addresses and status and this proposal is for relationships; maybe those could somehow be dragged into the same "activity" model??

[lin-fred]

This would be nice for birth/deaths as wells. They were born on this date at this place

[Jegelewicz]

Call me crazy - but EVERYTHING is an event (who, what, when, where, how). I've been starting to think that Arctos should just be a huge table of linked up events...

Enough crazy talk. Should we merge status and addresses (but also relationships?)? I think that would make life easier. Why not just make all of these things "agent attributes" where each one has attribute type, attribute value, begin date, end date, location (linked to an Arctos locality???), source, determiner, determined date (the last two auto filled with the Arctos username of the person creating the attribute and the date it is created)

FWIW - I think all address (or wheres) should be linked to localities - that's a brilliant idea! Of course, it may not be very easy (I have to create a locality for any new address), but it could make re-using addresses easier. It's probably too much to ask right now....

So for me some things would look like this.

attribute type	attribute value	begin date	end date	location	source	remark	determiner	determined date
employee of	https://arctos.database.museum/agents.cfm?agent_id=1014941	2019-10-04	2020-09-30	https://arctos.database.museum/place.cfm?action=detail&locality_id=11036845	self reported	Digitization Technician	jegelewicz	2020-09-30
associate of	https://arctos.database.museum/agents.cfm?agent_id=21318826	2017-07-01	2019-06-30		AWG	Treasurer	jegelewicz	2017-07-01
ORCID	https://orcid.org/0000-0002-1970-7044				https://orcid.org		jegelewicz	2017-07-01
status	alive	2017-07-01			self reported	being the Arctos Treasurer, I hope I was alive	jegelewicz	2017-07-01

Seriously though, is there any way to get the relationships into this same format or is that just crazy thinking?

[campmlc]

I agree - either an event or an assertion, both of which require agents, dates, etc. I like this

…

On Thu, Oct 27, 2022, 3:17 PM Teresa Mayfield-Meyer < ***@***.***> wrote: * [EXTERNAL]* Call me crazy - but EVERYTHING is an event (who, what, when, where, how). I've been starting to think that Arctos should just be a huge table of linked up events... Enough crazy talk. Should we merge status and addresses (but also relationships?)? I think that would make life easier. Why not just make all of these things "agent attributes" where each one has attribute type, attribute value, begin date, end date, location (linked to an Arctos locality???), source, determiner, determined date (the last two auto filled with the Arctos username of the person creating the attribute and the date it is created) FWIW - I think all address (or wheres) should be linked to localities - that's a brilliant idea! Of course, it may not be very easy (I have to create a locality for any new address), but it could make re-using addresses easier. It's probably too much to ask right now.... So for me <https://arctos.database.museum/agents.cfm?agent_id=21300608> some things would look like this. attribute type attribute value begin date end date location source remark determiner determined date employee of https://arctos.database.museum/agents.cfm?agent_id=1014941 2019-10-04 2020-09-30 https://arctos.database.museum/place.cfm?action=detail&locality_id=11036845 self reported Digitization Technician jegelewicz 2020-09-30 associate of https://arctos.database.museum/agents.cfm?agent_id=21318826 2017-07-01 2019-06-30 AWG Treasurer jegelewicz 2017-07-01 ORCID https://orcid.org/0000-0002-1970-7044 https://orcid.org jegelewicz 2017-07-01 status alive 2017-07-01 self reported being the Arctos Treasurer, I hope I was alive jegelewicz 2017-07-01 Seriously though, is there any way to get the relationships into this same format or is that just crazy thinking? — Reply to this email directly, view it on GitHub <#5172 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBFBQNEYBQ6FWETKZJDWFLWNTANCNFSM6AAAAAARFNCQK4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dustymc]

huge table of linked up events.

That's Tuco's idea from way back when, it seems to be a viable data model....

localities ... not be very easy

Meh, just UI.

attribute value

I've been looking for a way to get there for a long time, keys as attribute values would solve a bunch of problems.

require agents, dates, etc

"Alive in 1945" or "Chicago" are currently enough to maintain an agent. Requiring "alive in Chicago in 1945" would raise the bar. I think I'd support that, but certainly needs a dedicated Issue.

[Nicole-Ridgwell-NMMNHS]

I think I like @Jegelewicz's idea. The one suggestion I would make is to add another date, some kind of intermediate or interim date. That way, if I only know a relationship/address/status was valid on a specific date, but don't know the range, I can enter that. It think would also simplify status because then alive with begin and end dates would just be birth and death dates?

[Jegelewicz]

then alive with begin and end dates would just be birth and death dates?

YES! now we only need one thing!

another date, some kind of intermediate or interim date. That way, if I only know a relationship/address/status was valid on a specific date, but don't know the range, I can enter that.

verbatim date? BUT I would still put that in the begin if there wasn't already something there....

"Alive in 1945" or "Chicago" are currently enough to maintain an agent. Requiring "alive in Chicago in 1945" would raise the bar. I think I'd support that, but certainly needs a dedicated Issue.

Don't require both things and you can still say alive in Chicago or alive in 1945.

Of course you can always say alive in No specific locality recorded. in 1945.....

[dustymc]

like @Jegelewicz's idea

So do I, but I still don't know how to make it functional.

one thing!

I don't get it. You know I was alive yesterday through today - how's that tell you anything else?

Don't require both things

I was responding to "require agents, dates, etc."

[Nicole-Ridgwell-NMMNHS]

verbatim date? BUT I would still put that in the begin if there wasn't already something there....

Not verbatim, because it would need to be in the standard format, but somewhere I could enter some intermediate date if I don't know began and end dates. For example a visiting student - I know that they were a student of University of X during their visit, but I don't know when they started school, and I don't know when they left school. Basically the same thing we currently use the alive and dead statuses for, but for other things.

[dustymc]

Agents committee discussed, idea of one "there doing that then" table/object seems to make sense

Make sure this doesn't mangle anything related to loan shipping addresses.

Need documentation for instantaneous dates "alive now" (just use begin, maybe)

Any paired dates need a copy button.

what's this thing called?

• Life event
• status
• info
• ???

[Jegelewicz]

These will all be status, then we will need a new code table for agent statuses to add the controlled vocabs for address type and event types (including those mentioned by @jtgiermakowski above).

[Jegelewicz]

Make sure this keeps loan (reports in general) addresses good!

[dustymc]

Relevant to this: https://arctos.database.museum/agents.cfm?agent_id=21285400, relationship remarks contains a DOI.

Maybe not so relevant to this: There's a lot of info that doesn't agree between those resources, I'm not sure if I should believe it or not, I can't see the justification for that particular relationship, I can't find the Arctos agent from the name on the publication. We need better training/documetation, or this issue is still missing something, or ?????????

#5113 seems sorta-related in that the information doesn't quite seem like it's in the right place (which is always potentially an indication that the correct place doesn't exist).

#4554 (comment) is very related in that info buried in a remark isn't very useful in the awesomification.

[Jegelewicz]

contains a DOI

I view these relationships as assertions. Jessica sees "Jack C. von Bloeker, Jr." as the author of the paper and assumes it is the same as the agent J. C. von Blocker. Maybe the agent name is misspelled in Arctos? The collection dates and date of the paper seem very closely linked as do the kinds of things collected/published on (mammals).

We need better training/documetation, or this issue is still missing something, or ?????????

Don't we always? And won't there always be times when people make mistakes?

If I had done this, I would have changed the spelling of the name in Arctos and added a verbatim agent to the affected records with the other spelling. I would do this for UCM, but I do not have access to their collections. Our documentaion is always dicey because nobody has time to write good documentation, but even if someone did, half of the time it will not be read. For this one, why not open an issue and ask Jessica to do what I suggested, or remove the relationship?

indication that the correct place doesn't exist

Yep. And if we can get away from making the preferred name is unique a requirement, maybe that won't be an issue?

info buried in a remark isn't very useful in the awesomification

I don't disagree, but I am not sure how to get people to "do the right thing" when they are attached to "their" people.

I really don't see any way around these issues. Agents, like taxonomy, will always be messy. Collections who curate their people well will have better data and be able to play in the world of aggregated and linked data. Collections who don't may find their agents merged when they shouldn't be or converted to verbatim as we tighten the rules about what is necessary to create a "research grade" agent.

We are working toward that goal, we can't do it all at once. Is there something we MUST do in order to keep the process moving forward on your end?

[dustymc]

assertions

Absolutely, but it seems this could be better. For the purposes of this issue, I think we need some sort of 'authority' - not the determiner, but what the determiner used. That's probably got to be free text, but if we can do better here's the place to figure out how.

For documentation - I'm not sure, maybe something about bringing in all name variations?

And back to modeling, maybe we need agent_name_remarks? ("This name was used in bla but bla bla....")

Don't we always? And won't there always be times when people make mistakes?

Yup, and I'll about always assume those mistakes are from a lack of knowledge and easily fixed by documentation/mentoring/etc. (And #2550 would help - I got there from an error log, it ideally would have gone to mentors and collection managers and etc. too)

not sure how to get people to "do the right thing"

Same as above, make it easy to understand what (& maybe why) that is.

Is there something we MUST do in order to keep the process moving forward on your end?

Must-to-move: no, I don't think so, we've made HUGE progress.

To move more: I'm not sure, I think we're still getting a lot of 'probably alive while they were collecting' agents that from here just look like clutter, I'm not sure people understand the goals. (But maybe they're coming back with more info, either way I think this is a social, not technical, issue.) I think just the never-ending plea for MORE! (balanced by the understanding that everyone has lots of other things to get done...)

[Jegelewicz]

It's totally social and it will never be solved, no matter how much documentation we write or pleas we make for high quality assertions. People can become attached to name strings and will do about any amount of finagling to keep them "important".

After this first clean-up, perhaps the @ArctosDB/agents-committee should pick one low-quality batch of things to look at. Maybe agents that only include an "alive" date with the remark "collected then" or the like. If we can't add something more substantial - those agents get verbatimized and the "alive" remark gets put in the verbatim agent remark. We can move through these a step at a time and it may take a while, but we will get to something more "research grade".

[dustymc]

After this first clean-up, perhaps the https://github.com/orgs/ArctosDB/teams/agents-committee should

.... keep doing stuff, yes, agreed.

Along with "research grade" I think a goal should be to have 9 "John Doe"s COMFORTABLY coexisting. I actually have no idea how we've made it this far without at least two of them insisting we address them as they prefer to be addressed, and I have no real idea what's required of the data for that comfortable coexistence. Pretty sure that what we have now is closer than what we had a few months ago anyway.

[dustymc]

See #7182 (comment) - adding intervals (and ???) to names is actionable.

[Jegelewicz]

adding intervals (and ???) to names is actionable.

OK - but maybe we can use this as an opportunity to move toward the agent attributes model? Perhaps we transition names to attribute-like things:

agent_attribute_type	agent_attribute_value	agent_attribute_begin_date	agent_attribute_end_date	agent_attribute_determined_date	agent_attribute_determiner	agent_attribute_method	agent_attribute_remark
name	Teresa Jegelewicz	1966	1989	2024-01-05	Teresa J. Mayfield-Meyer	personal knowledge	yes, I think I know myself...but you be the judge

attribute field	description
agent_attribute_type	controlled by a code table. I envision having at least name and status (maybe address and identifier - but we can cross that bridge later)
agent_attribute_value	free text
agent_attribute_begin_date	ISO date formats, asserted date the name was initially valid
agent_attribute_end_date	ISO date formats, asserted date the name was no longer valid
agent_attribute_determined_date	ISO date formats, date the assertion is being made (maybe also use this for scenarios described in #5172 (comment))
agent_attribute_determiner	agent making the assertion
agent_attribute_method	source of the assertion (put your DOI or whatever here)
agent_attribute_remark	say more if you need to

Require nothing but type and value, attributes lacking the rest can be viewed as less robust. Also record the username of the person adding the attribute and the date it is added (keep a history).

[dustymc]

Hawt - if in need of some minor expansion/adjustment in some way (that might ultimately influence #6742 and make all attributes more-better).

select
    agent_id,
    null::int as some_additional_key_thing,
    agent_name_type as attribute_type,
    agent_name as attribute_value,
    null as attribute_begin_date,
    null as attribute_end_date,
    null as attribute_determined_date,
    null as attribute_determiner,
    null as attribute_method,
    null as attribute_remark
from 
    agent_name where agent_id=21300608
union select
    agent_id,
    null::int as some_additional_key_thing,
    agent_status as attribute_type,
    null as attribute_value,
    null as attribute_begin_date,
    null as attribute_end_date,
    status_reported_date as attribute_determined_date,
    status_reported_by as attribute_determiner,
    null as attribute_method,
    status_remark as attribute_remark
from 
    agent_status where agent_id=21300608
union select
    agent_id,
    null::int as some_additional_key_thing,
    address_type as attribute_type,
    address as attribute_value,
    start_date as attribute_begin_date,
    end_date as attribute_end_date,
    null as attribute_determined_date,
    null as attribute_determiner,
    null as attribute_method,
    address_remark as attribute_remark
from 
    address where agent_id=21300608
union select
    agent_id,
    related_agent_id as some_additional_key_thing,
    agent_relationship as attribute_type,
    getpreferredagentname(related_agent_id) as attribute_value,
    relationship_began_date as attribute_begin_date,
    relationship_end_date as attribute_end_date,
    created_on_date as attribute_determined_date,
    created_by_agent_id as attribute_determiner,
    null as attribute_method,
    relationship_remarks as attribute_remark
from 
    agent_relations where agent_id=21300608

 agent_id | some_additional_key_thing |   attribute_type   |                        attribute_value                        | attribute_begin_date | attribute_end_date | attribute_determined_date  | attribute_determiner | attribute_method |                                          attribute_remark                                           
----------+---------------------------+--------------------+---------------------------------------------------------------+----------------------+--------------------+----------------------------+----------------------+------------------+-----------------------------------------------------------------------------------------------------
 21300608 |                           | birth name         | Teresa Ann Jegelewicz                                         |                      |                    |                            |                      |                  | 
 21300608 |                           | correspondence     | Museum of Southwestern Biology\r                             +|                      | 2022-08-16         |                            |                      |                  | End date unknown; converted from valid_addr_fg=false.
          |                           |                    | Division of Genomic Resources\r                              +|                      |                    |                            |                      |                  | 
          |                           |                    | MSC03 2020\r                                                 +|                      |                    |                            |                      |                  | 
          |                           |                    | 1 University of New Mexico\r                                 +|                      |                    |                            |                      |                  | 
          |                           |                    | Albuquerque, NM 87131                                         |                      |                    |                            |                      |                  | 
 21300608 |                           | notification email | jegelewicz66@gmail.com                                        |                      |                    |                            |                      |                  | 
 21300608 |                           | ORCID              | https://orcid.org/0000-0002-1970-7044                         |                      |                    |                            |                      |                  | 
 21300608 |                           | GitHub             | https://github.com/Jegelewicz                                 |                      |                    |                            |                      |                  | 
 21300608 |                  21322030 | associate of       | Hannah Cantrell                                               | 2019-10-04           |                    | 2021-07-16 21:42:29.342396 |                    0 |                  | 
 21300608 |                           | middle name        | J.                                                            |                      |                    |                            |                      |                  | 
 21300608 |                  21335682 | associate of       | Arctos Taxonomy Committee                                     | 2018-09-01           |                    | 2021-11-19 13:05:47.399016 |             21300608 |                  | Convener
 21300608 |                  21327088 | associate of       | Arctos Code Table Administrators                              | 2018                 |                    | 2021-10-07 08:35:06.189788 |             21300608 |                  | Manager, Committee Organizer
 21300608 |                  21318826 | associate of       | Arctos Working Group Officers                                 | 2017-07-01           | 2019-06-30         | 2021-08-19 15:37:09.101676 |             21300608 |                  | Treasurer
 21300608 |                           | phone              | 214-693-9269                                                  |                      |                    |                            |                      |                  | 
 21300608 |                           | aka                | 0000-0002-1970-7044                                           |                      |                    |                            |                      |                  | 
 21300608 |                           | last name          | Mayfield-Meyer                                                |                      |                    |                            |                      |                  | 
 21300608 |                           | login              | jegelewicz                                                    |                      |                    |                            |                      |                  | 
 21300608 |                  21314876 | associate of       | Arctos Working Group                                          | 2016-05-16           |                    | 2021-08-04 09:37:52.122922 |             21300608 |                  | 
 21300608 |                           | correspondence     | 635 Cougar Loop NE\r                                         +|                      |                    |                            |                      |                  | 
          |                           |                    | Albuquerque, NM 87122                                         |                      |                    |                            |                      |                  | 
 21300608 |                           | first name         | Teresa                                                        |                      |                    |                            |                      |                  | 
 21300608 |                  21277509 | employee of        | University of Texas - El Paso                                 | 2016-02-08           | 2018-01-31         | 2021-07-16 21:42:29.336408 |                    0 |                  | Collection Manager
 21300608 |                           | email              | jegelewiczt@unm.edu                                           |                      | 2022-08-16         |                            |                      |                  | still active but prefer other email address | End date unknown; converted from valid_addr_fg=false.
 21300608 |                           | preferred          | Teresa J. Mayfield-Meyer                                      |                      |                    |                            |                      |                  | 
 21300608 |                   1014941 | employee of        | New Mexico Museum of Natural History and Science              | 2019-10-04           | 2020-09-30         | 2021-07-16 21:42:29.339427 |                    0 |                  | Digitization Technician
 21300608 |                           | email              | jegelewicz66@gmail.com                                        |                      |                    |                            |                      |                  | 
 21300608 |                  21334341 | employee of        | Arctos Consortium                                             | 2021-08-01           |                    | 2021-09-28 17:54:29.320198 |             21300608 |                  | Project Coordinator
 21300608 |                  21298561 | employee of        | Museum of Southwestern Biology, Division of Genomic Resources | 2018-02-19           | 2019-09-30         | 2021-07-16 21:42:29.306361 |                    0 |                  | Collections Assistant
 21300608 |                           | aka                | Teresa J. Mayfield                                            |                      |                    |                            |                      |                  | 
 21300608 |                           | shipping           | University of Texas at El Paso\r                             +|                      | 2022-08-16         |                            |                      |                  | End date unknown; converted from valid_addr_fg=false.
          |                           |                    | 500 West University Avenue\r                                 +|                      |                    |                            |                      |                  | 
          |                           |                    | El Paso, TX 79902\r                                          +|                      |                    |                            |                      |                  | 
          |                           |                    | Biology Bldg. #222\r                                         +|                      |                    |                            |                      |                  | 
          |                           |                    |                                                               |                      |                    |                            |                      |                  | 
(26 rows)

Having one place for everything would also provide a mechanism for history: don't ever update, just 'hideme' flag the old and insert a new row. (Which may be a dumb idea, but one way to find out....)

[Jegelewicz]

don't ever update, just 'hideme' flag the old and insert a new row. (Which may be a dumb idea, but one way to find out....)

If I actually find the birth date of someone who already has a death date, updating the existing attribute seems cleaner than creating a whole new one? Still, I can also see the value in just adding an attribute because I would need to report where the information was obtained. Also, this is assuming status = alive instead of status = born which would only have one date and is maybe better....

[dustymc]

updating the existing attribute seems cleaner than creating a whole new one?

For minor corrections (date off by 3 days, oops!) - sure, mostly just clutter. For changing the meaning of the agent ("I'm not going to consider that this might be someone else, I'm just going to change their birth date by 150 years so the notification goes away") - critical information that will help someone understand why their records are attached to the agent (it was shaped very differently before it was vandalized).

status = alive instead of status = born which would only have one date and is maybe better....

Yes, but not always accessible. I'm pretty sure you're alive right now, that doesn't help me know when you might have been born. Born is MUCH better, the documentation should be clear on that. And method is super-important - 'someone with a sorta-similar name was collecting on this date, according to these labels with maybe-sometimes-correct dates on them' and "I'm looking right at them right now" are wildly different assertions.

[dustymc]

I'm trying to determine if this is actionable and if what's been proposed as a solution sufficiently addresses what's been discussed. I'm not sure, random comments below. I think we need some sort of Community discussion - probably after #6813 has been resolved. HELP!

Changing my some_additional_key_thing to associated_agent_id REFERENCES agent.agent_id in #5172 (comment) would accommodate relationships. (And might be used in very weird - or unexpectedly awesome! - ways for non-relationship-attributes??)

"at Harvard" (attribute value) "in 1868" (bracketed by dates) is handled in the proposed model.

"getting a Ph.D" (activity at place-at-time) isn't QUITE handled, but it could be semi-standardized in method or etc. by documentation.

" nice for birth/deaths as wells. They were born on this date at this place" - again not EXACTLY linked, but there's more available structure in the proposed model and maybe it's sufficient to get the idea across?

Current addresses have a place for coordinates, not clear if that should be a method (or??) or added to the structure above, or ?? - I don't know that anyone's ever actually done anything with those data, and lots of things (USPS's API, most any AI, Google's API) can probably figure that out on demand. Very tentatively suggest we just just drop coordinates unless someone has some tangible use case (and perhaps accompanying support).

"EVERYTHING is an event " - @Jegelewicz proposed that and the above not-so-eventish model, ???????

Sorting would be much better with everything in one "container" as proposed.

"relationship remarks contains a DOI." - not sure where I was going with that or if this will accommodate, the example seems to have been deleted (so let's assume it wasn't important and everything's happy!?!).

"relationships as assertions" - "Also record the username of the person adding the attribute and the date it is added" + attribute_determiner seems entirely sufficient.

"need some sort of 'authority' - not the determiner, but what the determiner used" - method sufficient?

[Jegelewicz]

I've been thinking and maybe this needs a tweak to accommodate relationships?

attribute field	description
agent_attribute_type	controlled by a code table. I envision having at least name and status (maybe address and identifier - but we can cross that bridge later)
agent_attribute_value	free text
agent_attribute_begin_date	ISO date formats, asserted date the name was initially valid
agent_attribute_end_date	ISO date formats, asserted date the name was no longer valid
agent_attribute_related_agent	Link to a related Arctos agent
agent_attribute_determined_date	ISO date formats, date the assertion is being made (maybe also use this for scenarios described in #5172 (comment))
agent_attribute_determiner	agent making the assertion (add related agent here)
agent_attribute_method	source of the assertion (put your DOI or whatever here)
agent_attribute_remark	say more if you need to

See also Agent Attribute Experiment

[dustymc]

needs a tweak to accommodate relationships?

You'll have to explain to me how that maintains referential integrity. (My last comment proposes something that does but maybe it's not doing whatever you're trying to do??)

See also #2131 (comment) for column names - I can see no reason to make this any more non-standard than we must.

[dustymc]

Implemented as #7318