Location data - RA, RM, MM SIGs

I don’t know how to make this show up as a discussion across several SIGs, so I’m posting it to RA SIG and trying to tag with RM and MM SIG.

I take part in the RM SIG (which mainly covers selection and acquisitions) and to a lesser extent the MM SIG. I don’t take part in the RA SIG, but read the notes sometimes.

When it comes to the structure of location, item, and holdings data, it seems like that crosses into all 3 SIGs. I wonder if it would be useful to have an inter-SIG discussion about those topics at some point.

The one that particularly caught my eye is the location work going on in the RA SIG:
• What do we actually need to accomplish with the location hierarchy?
• How do we create a structure that leaves us open to future needs?

Digging back through some notes, it looks like location is conceived of as a very hierarchical structure, e.g. institution, campus, building, collection, shelving location. Would there be any value to flattening this out and having fewer levels? Is there value in discussing in the other SIGs? The locations will impact acquisitions (particularly if ordering/financial permissions are tied to particular locations, or if libraries are receiving shelfready materials) and metadata. Or is there a decision that RA SIG will define location structure, and the other apps of FOLIO will structure location-related work based on that design?

Thanks,
Ann-Marie

Hi Ann-Marie,

I think this is the document to which you are reacting: https://wiki.folio.org/display/RA/Circulation+components

I don’t feel like we’ve gotten far enough in our Resource Management SIG discussions to consider the implications of hierarchy for acquisitions functions. I think some basic principles we’d want to have in place:

• flexibility: maybe some libraries would like to have many levels, maybe some only need a some levels. Maybe location could even be applied in some sort of tagging function, although you could end up with non-sensical locations, if a subcollection got assigned to a major collection, so maybe that’s not a good idea.
• permissions control: I agree the scenario of pemissions allowing for ordering only in a certain location or locations (at some level in the hierarchy) makes a lot of sense. Like an individual with authority to order for the Law Library can’t order items for the Main Library or vice versa

I did see @andrealoigman’s email and I’d like to quote it here, because I think the idea of floating collections is quite interesting. The idea come up in another context as a way consortia could simplify the “collective collection.” Public libraries do this all the time, so I’m sure there are models (although maybe no system handles it elegantly). Not really an area where I am an expert:

I’d love to have a cross SIG discussion about this. I don’t think that there has been any decision about which group gets to define this, it’s just that RA is trying to ensure that we have the flexibility to create circ policies that meet
the needs of all types of institutions.

The exemplars we’ve been looking at include:

• University of Chicago uses 3 levels (though OLE allows for up to 5),
• VZG currently uses 5 levels,
• Duke uses 3 levels (but only 2 are truly functional for circ rules which forces a crazy number of item types and rules).

Some of the things we’re trying to make sure that we account for are floating collections and shared collections, which none of our systems can currently handle well. We’ve been pretty specific that no institution would be required to use all 5 levels. But you are quite right, the possible effect of this on acquisitions does need to be considered.

I’d also note that you should ignore the names of the levels. The nomenclature is there for convenience sake, but we’re
aware that these terms will not be useful for all institutions.

This web forum software does not provide a way to make a single topic of discussion appear in more than one category. One can, however, use the notification function to receive replies by email. At the bottom of this thread of conversation is the notification setting. By default it will be “Normal: You will be notified if someone mentions your @name or replies to you.” You can change that to “Watching” to receive email replies (or even to “Muted” if this thread of conversation is not of interest to you).

@Ann-Marie: what I think you did was a good idea – start the topic in one of the categories on Discuss, then send a message about it to the mailing lists that might be interested in the topic.

@kmarti: thanks for posting @andrealoigman’s email reply from the discussion list here.

I’m concerned that a hierarchical structure for locations based mental model of physical items might cause issues if it is applied to digital collections. For instance, when having descriptions of items in an institutional repository, the location hierarchy would deviate at the Campus level into differentiators of campus computing units and/or instances of software.

• Institution
• Campus
  • Department (e.g. ‘academic computing’ or ‘college of fine arts’)
    • Software Instance (e.g. ‘campus-wide DSpace’ or ‘departmental Omeka server’)

I think this would argue for the need for some flexibility with the location hierarchy.

Does there need to be hierarchy, or do there just need to be locations? If there was just a list of locations, without hierarchy at all, what all would that break? You could build permissions - whether those permissions are ordering, financial, circulation, electronic access, whatever - by picking which locations were appropriate for a particular permissions group. This may be far too simplistic a view, so if it’s not helpful, tell me that, and I’ll quit asking about it.

No, no – I think this is a good discussion. In fact, I think that this sounds a great deal like the data model and implementation we are using for permissions in FOLIO. So I’m wondering if the code that is storing permissions could be applied to storing locations as well. I’m going to loop @cateboerema to this topic.

Are we talking about locations in the sense of holdings data, or is this a broader discussion that includes the operational locations (circulation desk, processing locations, etc.) also mentioned in the circulation document that Kristin mentioned? If the latter, this would also become a discussion about workflow.

To my mind, it’s any location that you want to be able to record a physical or electronic item as being at, either on a temporary or permanent basis. If there are no items at that place (2nd floor closet of the main library), then for the purposes FOLIO, that would not be a location. If it’s a temporary place (in processing, at bindery, at circ desk), then those would be locations for FOLIO purposes, though perhaps not all FOLIO libraries would choose to use those temporary locations, or would use them in the same way.

Should they be locations? one of the issues i’ve seen in library management systems is that we use concepts that have a meaning such as location or patron to represent other things such as process. it would be nice to think that in FOLIO we could separate these concepts to allow them to be used and reported on correctly and cleanly.

Fine by me whether we call them temporary locations or workflow stages, or however else you might want to distinguish them. My guess is that not all libraries will use them the same way, so allowing for various categories or flows would be good. I’ve also seen situations where libraries create a “patron” called bindery, and then check out books to that patron - so not really using the location concept at all.

Back on locations. What if there were no levels to locations at all? What if there was just one giant list, ensuring that there is a unique value for each location? the you could mix and match them as needed for loan policy, cataloging permissions, acquisitions permissions, and reporting purposes. Maybe you want to apply the same circ policies to the reference locations in Main, Law, Med, and Div. Maybe you want to allow ordering permissions for all of the Law-related locations, but none of the others. Maybe you want to report on the percentage of print and E resources, or the percentage of circulation across all the Medical locations (across multiple libraries) within a consortium.

Another thing I’ve been wondering. Will electronic resources be considered to have a “location”? In some systems I’ve worked with, they have a location like “electronic”. In other systems, there’s no concept of location. Without a location concept, then clarifying access policies for e-resources for various libraries within a consortium might need to be triggered by some other data element.

One of the… let’s call them challenges… I’ve run into over many years and many ILSes is the complexity of the ways that statuses, locations, etc are defined/constructed/conceptualized, how they’re used in real life, and how comprehensible they are to external systems.

In Aleph land we had item statuses, item process statuses, item locations (temp and perm) and each affected the behavior of the items in Aleph but other than the straightforward location (in holdings or item) they were maddeningly opaque to external systems, including to the ostensibly fully compatible Primo. Item process status was largely invisible to external systems.

In Alma land we had work orders which often looked a bit odd to external systems.

In Voyager land I’ve now also become aware of the Patron Status Group, which makes my head hurt, but which can be very meaningful when you’re trying to locate a physical item. And like Aleph item process status it appears to be 100% invisible in API transactions (can we call z39.50 an API? It’s Friday afternoon, so I’m going to let it be an API for the weekend)

All this rambling is to try to say - there are many things we currently use to denote a “location” of something. However we do it in FOLIO we need to be able to expose that in a comprehensible way to outside services.

Sorry to be so late to the conversation . . . no levels to location would mean having to black or white list every considered location for every single loan rule. There’s nothing that prevents our current systems from doing the mix and match that you suggest now (unless your current system limits location levels for this function like Aleph), but the hierarchical structure also lets me control groups of related locations at the same time.

From my perspective, the hierarchical nature of locations is similar to the way archives can catalog boxes of materials. I can refer to every single piece of paper in a box one by one or I can talk about the box. Both are valid ways to describe the collection, but they’ve got different purposes.

Thanks for the additional info, Andrea – I guess I’m thinking you might want to group different locations in different groupings, depending on what you were trying to do with the permissions.

If you just had a flat list of location codes, they could be assigned tags (which building, which format, circulating or not), and then you could use those tags to gather all the locations with a certain characteristic, in order to assign a rule or permission to them.

For example:
Gather all the locations related to this one building, and assign a rule.
Gather all the reference/non-circulation locations, no matter which building or campus, and assign a rule.
Gather all the locations related to physical audio materials, and assign a rule.
Gather all the archival locations, and assign a rule.
Gather all the “online” locations (if FOLIO has a location concept for virtual resources) and assign a rule.

In any event, it’s not something I’m incredibly wedded to. It just seems like we have an opportunity to simplify if we’re starting from scratch in FOLIO, especially if the circulation and movement of physical items is a smaller and smaller percentage of an academic library’s usage each year. I do understand, though, that many academic libraries have multi-million item, widely-varied physical collections that will need ongoing storage and maintenance, so maybe continuing more complex, hierarchical location structures are still applicable.

Thanks,
A-M

Hi Ann-Marie. The UI that Filip has designed allows us to do this. We can white or black list individual locations, but the hierarchy allows us a much simpler way to do the bulk of our work. Vince has proposed a 4 level hierarchy with additional conceptual areas around ‘collections’ and ‘consortia’. Though we’ve got a few questions, RA SIG is overall pleased with both the UI and the model. The Consortia SIG was supposed to see it last week, but I haven’t heard their feedback yet.

In general I agree with the principal of removing unnecessary and legacy system behaviors, but we need to be careful to differentiate between simplifying a data model and simplifying workflows. In my experience, these are frequently contradictory goals.

You can see Vince’s proposal at: