Location/Classification question (also for RM/MM SIGs)

Hi RA SIG folks,

In the Metadata Management/Codex Workgroup meeting yesterday, we had a conversation about location and the individual classification/call number for a physical piece that is shelved someplace. RA SIG has done more work on location data than any of the other SIGs, so I’m hoping you can help with something I’m not understanding.

Here’s the PowerPoint showing the location background info discussed in RA SIG: https://drive.google.com/open?id=1PpjvykiGK2iQZfW6lOd0U2dCCQNbxTJQi8tvvNTCbR8

Is it expected that the call number for an individual physical piece (a book, CD, archival box, etc) - will be part of that last level of the location hierarchy (parking data), or will it be one level further down in granularity? Put another way, is RA SIG expecting the call number to be part of the parking categories for the library, or for there to be a different field/data element for call number?

Thanks,
Ann-Marie

Honestly Ann-Marie, we hadn’t discussed it in this way, and we aren’t entirely clear on what Vince intends parking to be. But we are pretty clear that there isn’t meant to be a lower level of granularity since parking is somehow multipart in and of itself. I’m waiting for the Consortia SIG to weigh in to see if they think that 4 levels will be enough and then we’ll try to wrap our heads around this and figure out if it will work at all.

That being said . . .

I don’t think call number is a function of location at all. Items have the same call number regardless of which location they reside in. From the RA perspective locations exists to control circ rules/policies and item behavior, call numbers have no connection with that.

I’ve got serious concerns about moving any data into a FOLIO specific field where z39.50, NCIP/SIP2 and other standards can’t recognize them. RA functionality relies very heavily on sharing data through these standards and mechanisms. For this, among other reasons, there are still serious questions about whether or not item and holding are one thing or separate elements.

Honestly, I don’t understand the benefit of putting item and holding together. As near as I can understand it means repeating holding data over and over again for serial runs and multi-volume sets and will make it almost impossible for us to use existing discovery layers like VUfind and Blacklight. I’ve proposed that item and holding be separate, with items generally inheriting location data. Items would only need separate location data when a temp location is needed. Kuali OLE works this way and despite all of OLE’s flaws, this piece works incredibly well.

I wish that I had been aware that the Codex Workgroup was meeting or I would have joined in. Is the Codex group now simply a part of MM?

Hope this helps.
Andrea

Thanks for this info, Andrea. The Codex WG has been meeting for several weeks. MM SIG has been generous enough to offer up their meeting time on Thursdays for the past few weeks. You can find notes in the most recent 3 MM SIG meetings on the MM SIG site of the wiki, or listen to the recordings at https://drive.google.com/drive/folders/0B7G8S7WF6N20YUM4My1oRTIxSHM.

Hi. I run the Voyager system at Texas A&M and I watched recording of the 10/19/2017 RA SIG meeting at the request of one of the A&M SIG members. I have a couple of thoughts I’d like to share.

First, the “Assigning a location” slide states, “When assigning location(s) to items or holdings, simply type the location code into a text box.” That statement implies that each location has a unique code (and there was discussion about this point during the SIG meeting). If that is the case, what is the point of a having a hierarchical location arrangement? As long as the hierarchical combination of elements is unique, why do you need a unique code? No one would remember those unique codes – at our libraries we have 500 unique location codes. We would want to call a reserve location ‘reserve’ regardless of the building in which it’s located, because the hierarchy would differentiate. In the example given, our staff would most likely always use the assignment popup

We also need at least some of the levels of hierarchy available for CRUD operations for Temporary shelving locations also. In our case, we would want to be able to use Temporary locations at the Library level and all levels below. Here’s a screen shot which exemplifies the issue:

image792×496 113 KB

1. The permanent location of the serial Small Business Sourcebook is in the Evans Library Building (main library).
2. The latest edition of the SBS, however, is always kept in the West Campus Library Reference dept. (A separate building across campus).
   Therefore, when assigning a temporary location for the latest edition, we’d have to be able to assign Library = ‘West Campus Library’, location level 1 = ‘Reference’. The Assignment Popup slide shows “Select permanent location” only; we’d need another part of the screen to show a Temporary Location hierarchy.

Hi Anne!

Thanks so much for your comments. First off, I wanted to share the link to the presentation from the meeting your are referencing: https://docs.google.com/presentation/d/1-mI410cAuAo69Wo9seQ3_s_DIy3DpVrJxtRHgN3KDz4/edit#slide=id.g27fcdba85d_0_10

Now to your questions.

If (each location has a unique code), what is the point of a having a hierarchical location arrangement?

The hierarchy does a couple things that I can think of. First, it makes it possible to logically drill down to find a location when you don’t know the code (as shown in the assignment pop-up). It also allows loan rules to be assigned at a higher level of the hierarchy and then inherit down to the lower levels. Perhaps the question you are really asking is ‘why have unique codes for locations when there is a hierarchy’? And the answer to that is that the location codes are purely for ease of data entry. While your institution may always use the assignment popup, other institutions have told us they would only use the codes (and are doing so today). I wonder if A&M could even make use of sensible codes? The codes are custom so you can create whatever mnemonic you want. You could, for example, create a code for Main Campus > Evans Library > Reference that is “M/EL/R”. Once you type in the “M”, the auto-complete will offer up all codes beginning with M (so all the codes for libraries on the main campus). Type in M/EL and auto-complete would offer all the codes beginning with M/EL (so all the codes for locations in the Evans Library). Do you think something like that might work?

We also need at least some of the levels of hierarchy available for CRUD operations for Temporary shelving locations also

Definitely! The idea was that all the options available for assigning permanent locations would also be available for assigning temporary ones.

Thanks, Cate, for the clarification. Yes, the question I was really trying to ask was “why have unique codes for locations when there is a hierarchy?” And in some cases we could use codes for assignment, as some of them are short and familiar enough to be memorable. Glad to hear that assignment of temp locations will also support all levels of hierarchy.

Good to have some additional info on this. I’m still not quite convinced of the need for hierarchy, but I can live with it. A more flexible model would seem to be a flat list of unique locations that can be tagged with various tags that would allow them to group hierarchically or not. That way, you could group all the locations in a specific building using that building tag and then assign rules. Or you could group all of the reference locations regardless of building using a ref tag, and then assign rules. Or group all the audio locations or archival locations using a specific tag, and then assign rules. But it seems like the earlier SIG work decided that hierarchy was the best structure. I guess I’ll just need to better understand how it acts as we get deeper into playing with FOLIO.

I completely agree on unique location codes for each location within a FOLIO site. When it comes to passing location data back and forth in order and cataloging data, having unique codes will definitely make everything simpler.

Hi Ann Marie,
The RA SIG asked for hierarchical locations in part because it creates the most commonly used groupings without any additional work. The use of hierarchies wouldn’t preclude the kind of ad hoc organization you’re proposing. It just makes quite a bit of it unnecessary.

Does that make sense?

Andrea