Serialize location codes

[saverkamp]

Need to serialize holding location codes as Locations (into a static file for now) for use in NYPL Core data.

Locations at: https://docs.google.com/spreadsheets/d/1pwnVvVX_M22wHW3Mc_DzVYYGHQ9EiSFtFQLjqc2DePw/edit#gid=13

[saverkamp]

Need to add relationship to owning division/center. use nypl:owner with nypl:Organization

[saverkamp]

Added relationship to owning division/center. Need to add ReCAP partner location codes

[saverkamp]

Per our Locations meeting today, we need to change this to 'holding location' to distinguish from 'delivery location' and add relationship to eligible delivery locations.

Property should be: nypl:holdingLocation (instead of nypl:physicalLocation) Class should be: nypl:HoldingLocation (instead of nyplDeliveryLocation)

--OR-- On further thought, if the delivery locations are truly just a subset of the sierra location codes then we could potentially use one set of Location codes and add two different types of relationships: one to indicate eligible delivery locations to send items and one to indicate all possible source locations it can receive items from. A location would have values for either one or the other or both, depending on what the location is used for: storage, use, or both.

TODO:

• decide if we need one or two sets of codes
• decide if we need an "offsite" flag for convenience
• change applicable property and class documentation (@saverkamp)
• update serialized locations (@saverkamp)
• update serialization (@nonword)

[katesweeney]

fyi current location codes sheet is "Updated Delivery Mapping" here: https://docs.google.com/spreadsheets/d/1SwZyCSUMsQ0Lf91t39_LxKpSLbvNNEliOhF1bnyUwcA/edit#gid=940035354

Supporting sheets are in that same workbook.

[saverkamp]

If we want to maintain one list of locations (which is where I'm leaning), we could add one or more of the following properties:

nypl:locationType -- values would be either 'holding' or 'delivery' or both nypl:deliverableTo -- Locations that items held at this location can be delivered to

We are still planning to use two properties to express the holding location of the item (nypl:holdingLocation) and all possible delivery locations (nypl:deliveryLocation), so we don't necessarily need to encode either of these properties in the Location entities. We would either need to maintain the logic in the application that decides how to assign these locations to items and/or maintain the information in the serialized data. (How frequently does this change? Will this be unmanageable?) One benefit of storing these properties in the data would be if you want to query our data to get information about a location.

Thoughts? Any other properties you see as important to store in the Location entities?

cc @nonword @katesweeney @wlla

[saverkamp]

Added nypl:deliveryLocation property and changed nypl:location property to nypl:holdingLocation in Discovery properties and mapping docs. (We may want to change the json context from physicalLocation to holdingLocation.)

[katesweeney]

For the most part, deliverableTo logic is tied to holdingLocation code (rather than an item itself). Phil did mention that curators have asked M2 staff to limit deliverableTo logic for a few individual items in GFA, but I think these requests were reactions to desk staff errors in placing holds. Delivery mapping isn't encoded in Sierra. Almost none of this delivery mapping or location code structure/meaning was documented at all before this project, amazingly -- it was just tacit knowledge ("data:tacit"?)

Re: deliverableTo changes: It seems like there are plans to try to increase the number of places/rooms an item can be delivered to, especially for SASB items. That said, there has been pushback from curators who don't want their items going everywhere (see above M2/GFA), and I don't think there is any strategic plan to systematically open up delivery permissions.

Re: holdingLocation changes: Codes are occasionally added for various reasons -- new physical storage shelf, new subject collection, etc. I think new codes are sometimes created for a brand new set of books, but new codes also affect existing items, like when M2 opened and a bunch of old books got a new code ending in 92. We need some long-term method to keep our data/mapping aligned with changes in codes and delivery permissions.

If an item's holdingLocation code changes to another code, it will just inherit deliverableTo logic from its new code. An upcoming example is that the holdingLocation codes starting with "q" will be phased out later in 2017 or 2018. Those are non-ReCAP offsite items that are being brought into Milstein 2, so they will just change over to related and (mostly?) existing M2 codes like "mal92" and others that end in "92".

[saverkamp]

After talking with @nonword and @katesweeney we decided to add nypl:deliverableTo and nypl:requestable to Locations. This will allow us to store some of the logic of assigning item.deliveryLocation and item.requestable in the location entities rather than having to maintain a separate lookup table in the application.

nypl:requestable as a property of nypl:Location means: items held at that location can be requested through a hold button. This is the default state that can be overridden by a particular itemtype and/or access (opac) message. If requestable is set to 'n' the item might still be able to be served in a reading room but the request would need to be staff-mediated.

TODO:

• update documentation (@saverkamp)
• reserialize and upload to github (@saverkamp)