-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Agents - better integrate when/where (and doing what?) #5172
Comments
What do you think the benefit would be to 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? |
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 |
See also #5113 (comment), which I haven't quite managed to distill down into a proposal. The above data would be entered
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?? |
This would be nice for birth/deaths as wells. They were born on this date at this place |
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.
Seriously though, is there any way to get the relationships into this same format or is that just crazy thinking? |
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: ***@***.***>
|
That's Tuco's idea from way back when, it seems to be a viable data model....
Meh, just UI.
I've been looking for a way to get there for a long time, keys as attribute values would solve a bunch of problems.
"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. |
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? |
YES! now we only need one thing!
verbatim date? BUT I would still put that in the begin if there wasn't already something there....
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..... |
So do I, but I still don't know how to make it functional.
I don't get it. You know I was alive yesterday through today - how's that tell you anything else?
I was responding to "require agents, dates, etc." |
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. |
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 Need documentation for instantaneous dates "alive now" (just use begin, maybe) Any paired dates need a copy button. what's this thing called?
|
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). |
Make sure this keeps loan (reports in general) addresses good! |
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. |
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).
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?
Yep. And if we can get away from making the preferred name is unique a requirement, maybe that won't be an issue?
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? |
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....")
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)
Same as above, make it easy to understand what (& maybe why) that is.
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...) |
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". |
.... 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. |
See #7182 (comment) - 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:
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). |
Hawt - if in need of some minor expansion/adjustment in some way (that might ultimately influence #6742 and make all attributes more-better).
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....) |
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.... |
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).
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. |
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 "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? |
I've been thinking and maybe this needs a tweak to accommodate relationships?
See also Agent Attribute Experiment |
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. |
Implemented as #7318 |
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. ]
The text was updated successfully, but these errors were encountered: