[Archivesspace_Users_Group] Staff users/agents as subjects/creators

[Olivia S Solis]

Thank you, Jordon and Mark, for your detailed response. Mark your detailed
explanation is *extremely *informative and will help us determine how to
handle staff records — both user and agent — particularly ones that appear
as creators and subjects. I have some testing to do to see how merging
affects the linkage in the database.

Apologies for responding so late, Mark, but I wanted to locate where I read
the information about not linking staff to records. I remembered reading it
somewhere, but it took me a while to locate. When we embarked on our
adoption/migration many moons ago, we were not paying Lyrasis members and
so did not have access to all the documentation. I was looking for
information anywhere I could get it. I remember reading a lot of the specs
clearly labeled "DRAFT", which is apparently where I got this idea, the
Agent Specifications from 2012:

http://archivesspace.org/wp-content/uploads/2017/01/Agent-Specification-20120323.pdf

In the "Linking to Other Records" section, it states: "Repositories or
staff users cannot be linked to archival object records as the creator,
source, or subject of that archival object."

And:
"Agent records of type “person”, “family”, or “corporate entity” to an
accession record as either “creator”, “source,” or “subject” (except if the
record is also a staff user or repository);"

Obviously this is a draft and things have since changed. And technically,
the staff user cannot be linked. The associated agent record is.

Again, I really appreciate your feedback.

On Fri, Jan 5, 2018 at 8:49 AM, Custer, Mark <mark.custer at yale.edu> wrote:

> 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
>    <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
>    <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.
>       - 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] *On Behalf Of *Olivia
> S Solis
> *Sent:* Friday, 05 January, 2018 12:43 AM
>
> *To:* Archivesspace Users Group <archivesspace_users_group@
> 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:
>
> [image: 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> 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 <(410)%20516-5493>
>
> jsteele at jhu.edu
>
>
>
> *From:* 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@
> 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
>
>
>
> [image: Inline image 1]
>
>
>
> On Thu, Jan 4, 2018 at 3:13 PM, Jordon Steele <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 <(410)%20516-5493>
>
> jsteele at jhu.edu
>
>
>
> *From:* 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@
> 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 <(512)%20232-8013>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> 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 <(512)%20232-8013>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> 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 <(512)%20232-8013>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
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/20180109/b970b2de/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 42455 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/b970b2de/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 24761 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180109/b970b2de/attachment-0001.png>