Skip to content
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

Multiple OCLC Accounts #1

Open
jenmawe opened this issue Mar 31, 2022 · 6 comments
Open

Multiple OCLC Accounts #1

jenmawe opened this issue Mar 31, 2022 · 6 comments

Comments

@jenmawe
Copy link

jenmawe commented Mar 31, 2022

This is just something I thought of during your presentation to MM SIG. We are a consortium where we have 6 OCLC accounts, one for each school and one for our depository. We are migrating to a single instance of FOLIO where we are sharing srs and instance records. An institution can add a holdings to an instance already there because they now have that resource. What we have been doing until recently was to add a 938 to our MARC bib records that triggered an action to set/remove holdings in OCLC and then remove the 938 so it wouldn't be picked up again. We stopped this because we just weren't sure how to do this in FOLIO.

If there is no 938 trigger, you would have to use a trigger for new instances and their holdings, and newly created holdings since we share bibs. This seems rather complex.

@lmccoll44
Copy link

Just some basic questions or maybe ideas?

  • Do each of your institutions within the consortium still need to maintain their own holdings in OCLC even though you are sharing an instance in FOLIO?
  • If so, is there any possibility of the "trigger" being on your holdings record and for that to be the starting point?

@jenmawe
Copy link
Author

jenmawe commented Mar 31, 2022

Each institution does maintain their own holdings, even when we'll be sharing. We can use the trigger on the holdings record. We're using FOLIO holdings. Would it make sense to have a note with note type of "Action", that is flagged as staff only, where we have language such as "set OCLC" and "remove OCLC"? This staff note could then be removed once the action is done.

@lmccoll44
Copy link

That makes sense to me. Is there any value in keeping that so you know by looking at your FOLIO record if the holdings were set or not? Is the reason for removing it so it does not get "triggered" unnecessarily, or is it just useless info to you at that point?

@jenmawe
Copy link
Author

jenmawe commented Mar 31, 2022

I was thinking that we wouldn't want to trigger the process again. It's not really information needed after the action is done really. I'm not sure if others would have a use case for keeping that information.

@maccabeelevine
Copy link
Member

Thanks for the suggestion and for thinking through the metadata details. From the implementation side, and scopes of work:

  1. Check an instance's holdings record(s) for some indication of whether OCLC holdings should be set/withdrawn, and (perhaps) an indication of which OCLC account to use.
  2. Write data back to FOLIO (whether on the instance or holding record) to indicate it's been processed already.

I'm open to implementing the first, assuming you metadata experts can figure out the fields/values to look for. Would be hoping there's still a date field to query on so that we could maintain the default behavior of "items updated yesterday".

Actually writing back to FOLIO is not something the app does currently and would require a ton more testing. So at first look, I'm inclined to consider that as a pull request if someone else wants to implement.

@jenmawe
Copy link
Author

jenmawe commented Mar 31, 2022

With the first one, if you go with FOLIO Holdings Note with a type of Action flagged as staff only, then using the language of set or withdrawn, we could use our school prefixes that we have implemented in FOLIO. In the 5C, we have UM (UMass), AC (Amherst College), HC (Hampshire), SC (Smith), MH (Mount Holyoke). This could be something that people could change based on the institutions that have different OCLC accounts too.

In this scenario, it might be good to take the extra step to make sure to avoid case because people might enter things in upper or lower case. I took a screen shot of this idea. And of course, this is just an idea.

withdrawnHC

setUM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants