[Archivesspace_Users_Group] Staff users/agents as subjects/creators

Fri Jan 5 11:52:12 EST 2018

You guys are right: if you create user records, they show up as agent records, too. My bad, sorry to confuse matters.

To the best of my knowledge we’ve never had staff add users as linked agents when they weren’t supposed to. No accounting for one-off lapses, of course, but it’s not a systemic problem.

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Friday, January 05, 2018 9:50 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators

Olivia, all:

I’m not sure what documentation suggested to not use users are linked agents, but as far as I’m aware, that’s impossible.  You can only link agents in that respect.  That said, whenever a user record is created, an agent record is also created.  Those records are linked in the database, but they are *not* synched at all in the application.  Here’s an example:

·         I just created a user record in http://test.archivesspace.org/
·         The username (a required field) = username
·         The full name (also required, since it’s used for the corresponding Agent record) = User Namé
·         This action created user 65 in the database; you can edit that record, if you’re logged in as a system administrator, by going to http://test.archivesspace.org/users/65/edit
·         This action also created agent_person 1153 in the database:  http://test.archivesspace.org/agents/agent_person/1153  The name used for this Agent is copied over from the corresponding user record’s “full name” field.  This is just a one-time convenience, though.  I later changed the full name in the user record, but as you’ll see, that has no effect on the Agent record.  And so, that also means that you can edit the Agent record with whatever additional details that you want, including the Authority ID, whatever.
·         And so, those two records are linked (from the context of the user record in the database), but they will never be synched from here on out.
·         Lastly, and importantly, if you delete that user record, it will delete the Agent record.
o   I assumed this would *not* happen if the Agent was linked to another record in the system, but it looks like that’s not the case (I was able to do it just now, so I’d say that’s a bug that needs to be addressed!).  In any event, we have a policy currently of never deleting user records right now, so we’ll definitely need to keep up with that policy 😊.  Maybe the documentation that you read was suggesting not linking user-based Agent records for this very reason.  Regardless, I’d love to check out that documentation if you remember where it came from.
·         However, if you try to delete an Agent record that’s linked to a User record, you won’t be able to do so until the User record is no longer in the system.  So that works as I’d expect!

All that said, we definitely link Agents who have corresponding user records, just like Jordon suggested.  Once ASpace has the ability to synch with external systems such as id.loc.gov and/or SNAC, as detailed in the expanded agent module specifications, we may have to rethink how we do that currently, since we also have a practice of updating our local Agent records with their Yale NetID in one of the Agent’s bioghist notes, but I don’t think that will be too problematic for us since those records are still linked in the database.  I’d also want to make sure that deleting the User record would not use that Agent record, especially if it’s linked to an external system, but that’s another matter altogether.

We also link those Agents to other record types like Events.  For just one example, when our Digital Accessioning Archivist runs scripts during the course of her work, it’s her Agent record in ASpace that is linked to those Events in ArchivesSpace (e.g. a PII scan is conducted on a disk image).  There’s no way to link the user record here.  If she were to edit the description of that archival component, however, then it would be her “username” that is listed as the last user to edit that archival component.

Hopefully that helps,

Mark

p.s. whenever you create a Repository record in ArchivesSpace, an agent_corporate_entity is similarly created, automatically.  See http://test.archivesspace.org/agents/agent_corporate_entity/1

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis
Sent: Friday, 05 January, 2018 12:43 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators

Hi Jordon,

Thank you!! Your response is indeed very helpful and I totally understand the logic behind your decision. Just a little background, we are almost ASpace live. We are about to set up all of our user accounts. At some point along the way, I read ASpace documentation advising not to use users as linked agents. I can't at the moment remember exactly where, but I can see that as useful advice. We ignored it for a couple reasons cited below.

We, in contrast to y'all, have decided to use staff agents for human-initiated collection management activities that may need to be documented in major record types. In particular, events.

I think there were a couple of things throwing us off here. For one, events require some kind of linked agent, and we are using events for various stages of accessioning and the ultimate stages of processing, as you have chosen not to do in all cases (at least through events records which do not use relators). For something like a processing step completed in an event, how would the required linked agent not be some kind of staff user? We also wanted it very clearly documented that certain staff played certain roles in events.

The second is that all users are included in the list of possible candidates when one starts typing in a linked agent in accessions, resources, and archival objects. So below, my record is pulled up because I started typing in my name (in this case in a new accession record) in a new linked agent sub-record:
[Inline image 1]
I was created as simply a user in ASpace, not an agent. Anyone could add me to a record as a creator or subject regardless of an institutional policy not to add users as linked agents. Relooking at ASpace, apparently being a user also makes me an agent in ASpace, with all the functionality ASpace endows to agents. I could edit my agent record's URI or create relationships with other agents, etc.

I'm seeing a lot of pros and cons here. I can give myself as a user a VIAF URI in my agent (not user) record. (It also appears that editing my user "Full name" doesn't automatically update the equivalent "Primary name" field in my agent record). But if you go with a policy that users are not agents and should not be used as linked agents, how do you get staff creating and editing records not to add the users that appear as candidates when they start typing in the linked agent fields as linked agents? Users are options here. Our solution was that "staff" addition.

In terms of authority control, it seems very precarious to allow any user to be added as a linked agent to any record, particularly to a published record. If it's possible to add any user as a linked agent, despite institutional policy not to, someone will. (Months of cleaning up legacy data has made me a skeptic.) Even if that same user has a sanctioned, legit, separate agent record.

Has this been a problem for anyone else? Do you have ambiguous relationships between agents and users? And Jordon, given your library's policy, has this ever been an issue for you... staff accidentally adding users as linked agents? Again, we've got staff members who are regularly creators, subjects, donors, etc.

I'm also curious about the relationship between users and their correlated agent records and how/if various interrelated/common fields are reciprocally updated.

Thanks, and if there is documentation that exists about this apologies!

-Olivia

On Thu, Jan 4, 2018 at 7:18 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Olivia,

Yes, we do use URIs for our agent records, and, like you, they are sourced from VIAF.

We separate user accounts from agent records. A user account is for someone to edit or view ASpace data. An agent record is reserved to document creators or subjects of collections or staff involved in collection-related activities. We’ve discussed and decided not to create and manage agent records for roles related to collection management activities such as processing or updating records; those names just appear as free text in processing notes (or in the audit trail of the ASpace record, which shows the last username to edit a given record). We generally only create agent records for staff to document curatorial activities like acquisition and deaccessioning.

So there could indeed be a scenario where we have an agent record for a staff member and a separate user account for that staff member, which we’ve decided we can live with, especially because agent records are managed in a module separate from user accounts. It’s a similar situation to a library catalog’s authority file, where a staff member may be listed because he or she happened to, like, author a book that the library owns, but that staff member may also have logins managed separately to access library applications. But I understand the gray area—we’ve just decided to accept it.

Hope that helps!

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
Special Collections
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:(410)%20516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis
Sent: Thursday, January 04, 2018 4:29 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Staff users/agents as subjects/creators

Hi Jordon,

Thanks for the response! Do you use URIs for your terms? Forgive me if this was not clear before (or if it was that I am being repetitive). We've been doing a lot of work to clean up normalize data set ourselves up for a linked data universe where we reference all of our names with URIs and we specify the name authorities we are using. In particular, we've chosen VIAF. So say Celine Dion is our Registrar who uses ArchivesSpace daily to create and search for records. She also donated her papers to us. She needs a user account, but we want to refer to her by her URI:
https://viaf.org/viaf/12491209<https://urldefense.proofpoint.com/v2/url?u=https-3A__viaf.org_viaf_12491209&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=JraIp2y8Vq0z_c_1MJ0B9dQv3SQe9zXGwhqxXr-qw-0&e=>
in her papers, in particular to anything we publish. If she has a user account, there is no field for the URI or the authority. If I'm not mistaken, all users who get "Local" rules, but we would want to specify "VIAF" as the source of the term.

Thanks, and again, sorry if I am over-explaining!

-Olivia

[Inline image 1]

On Thu, Jan 4, 2018 at 3:13 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:
Hi Olivia,

We have one agent record and assign different roles or relator terms based on the context. So for a given collection, Person X may have the role “Source” and relator “Curator” if that person was involved in acquiring a collection. If the person was the subject of the collection, we’d re-use the existing agent record and assign the role “Subject.” If we ended up getting that person’s papers, in that scenario, we’d assign the same agent record but with role “Creator.” We think of the agent one entity who may have different roles depending on the collection/event/context.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
Special Collections
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493<tel:(410)%20516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Olivia S Solis
Sent: Thursday, January 04, 2018 3:05 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Staff users/agents as subjects/creators

Hello all,

I was wondering if some of you have a situation we have. Occasionally, some of our staff will appear as subjects/creators in resources and accessions. We have some staff members who are published scholars and appear in name authority files. In such cases, we'd want to use the URIs for those names (no such field in user records). We also have specific rules we follow for local names for subjects/creators.

How do you/do you distinguish between staff members when they are acting in their capacity as staff (e.g. as the recipient of the agreement received event) vs. as subject/creator? Staff users appear to be agents that are selectable in any kind of record type.

Our current strategy is to include a "(staff)" addition to "Full name" for users. For instance, mine would be "Olivia Solis (staff)", the reason being to make it absolutely clear this is not the non-existent "Solis, Olivia" in VIAF who is also an agent, but not a user. I don't like including information that is not part of a name in the name field, but otherwise, I think people would accidentally select the user agent in instances where they should select e.g. the VIAF "Solis, Olivia" with a URI we want to use. Is there a better solution to "staff" for disambiguation purposes? Somehow display the person's title in the type-ahead list that appears when you start typing in a linked agent name? I'm not sure how difficult that would be.

We plan to retire (change passwords for), but not delete staff user accounts when the staff members no longer work here so we don't get rid of their data trail. But in 20 years it would be nice for staff to know that the retired "Olivia Solis (staff)" is also the same person as creator of one of our collections. Or maybe a donor, in which case I would not want to use the user account.

Thanks,
Olivia

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013<tel:(512)%20232-8013>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=fbov0S9K05iUB2atPiBvv7qDkK_4hqnXBgTLQWRoPNI&e=>

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013<tel:(512)%20232-8013>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=inPizVvTeah5UZWIcuzBoomZeq9_0s3T45SUozFtLB8&s=fbov0S9K05iUB2atPiBvv7qDkK_4hqnXBgTLQWRoPNI&e=>

--
Olivia Solis, MSIS
Metadata Coordinator
Dolph Briscoe Center for American History
The University of Texas at Austin
2300 Red River St. Stop D1100
Austin TX, 78712-1426
(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/9faef7c7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 24761 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/9faef7c7/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 42455 bytes
Desc: image002.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180105/9faef7c7/attachment-0001.png>