|55 min||Location||Vince||Review new location concept|
small crew today
Vince presenting circulation modeling update
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
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