2017-07-17 Resource Access Meeting Notes

Date

17 Jul 2017

Attendees

Discussion items

Time	Item	Who	Notes
5 min	Housekeeping	Andrea	Note-taker - David Bottorff
55 min	Location	Vince	Review new location concept

Notes

small crew today

Vince presenting circulation modeling update

Presentation is here: https://drive.google.com/open?id=1PpjvykiGK2iQZfW6lOd0U2dCCQNbxTJQi8tvvNTCbR8

4+level hierarchy proposal

1 institution - overall administrative organization
2 campus - geographic location at scale of city
3 Library - building level
4+ Parking - Location details within a particular building, can include many levels of details, expected to be highly variable, several levels of segmentation thus may eliminate the need for a 5th formal layer, non-hierarchical within parking level

Example:

1: region

2: library with unique ILN

3: branch library

4 department and other regular parking fields

DWB: question about how this would interact with the User Mgt discussion of consortia and whether people need to be treated as different borrower types at different institutions within a consortium or multiple consortia

Andrea: collection as something more conceptual or non-hierarchical? Vince - hold that thought

Andrea: codex meeting - flattening the data so holding and item is the same thing and location is different, how does this work within that context?

Vince: holding/item will have several locations associated with it, a permanent one and a temporary one at the very least

why can we get away from having a consortial level, given that we will likely all need/want this at some point?

Vince: consortia are to libraries like collections are to items, and is a complex relationship that may need to be treated separately from this location modeling

Mark: if you're committed to modeling data with one consortia are you stuck?

Vince: VZG, didn't realize this was a consortia, so don't take this as an example. Consortia shouldn't be dealt with within location modeling

examples of northwestern and Boston

variables within parking are not hierarchical. they can be used to define circulation policies, variables can be defined by any library according to needs

If not defined, how does the system know what to do with them?

Interdependency-locations need to be defined before circulation policy can be written

Collections and Consortium relationships are outside of the hierarchy of the physical location due to complex relationships and need to span physical locations

ability to target loan rules against locations, collections, consortia independently, but will require resolution of conflicting loan rules between location, collection, consortia, need to define how to resolve differences

Circulation Desk needs to be clear that there IS always a relation to physical locations, to trigger transit, hold, etc. rules but not needed for loan policy rules

Items could belong to multiple collections.

A collection could be assigned to automatically encompass a given location

Joanne: isn't physical location just at the parking level?

Vince: it's the combination of all of them, levels of granularity

not all institutions need to use all levels of hierarchy

Location is like mailing address, levels of granularity, hierarchical notions

Actually would want what the levels are to be used across FOLIO installs, possibly would want to use all the levels even if not directly relevant

moving data back and forth between FOLIO and other systems how does that interact with other systems, how does this work with NCIP and z39.50, etc.

what about the distinction between location in this sense and location in terms of where something is where it has been scanned and whether it is in transit, etc.

Andrea: reconciliation of conflicting loan rules, how would you manage this, but also how would you handle performance hits?

Vince: performance should be less of an issue than in OLE (per Andrea) because of specific implementation issues.

Vince: has experience with this in other scenarios, you need a prioritization mechanism within the circulation rules engine that determines which rule should take precedence

need an ability to present the operator with non-resolvable conflicts and ability to enter due dates

Andrea: as an administrator, how do I reconcile these conflicting rules

Filip's test function in the circ rules interface would need to work with this.

parking layer is definitely optional

no limit in the parking layer

question of what things are called and controlled vocabulary, etc. is a separate issue

Joanne: I don't get how we get the hierarchical needs we have from this parking location

Andrea: this works the same as voyager, this isn't any difference from that functionality