Locations and Service Points (UXPROD-771)

[UXPROD-2321] BE: Effective location property on the holdings record Created: 12/Mar/20  Updated: 16/Sep/21  Resolved: 30/Apr/21

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: R2 2021
Parent: Locations and Service Points

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Skärmavbild 2021-01-25 kl. 17.48.19.png    
Issue links:
Defines
is defined by MODINVSTOR-669 BE: Add effective holdings location a... Closed
is defined by MODINVSTOR-670 BE - update inventory-hierarchy and r... Closed
Duplicate
is duplicated by UXPROD-2339 Enhance Effective location to includ... Closed
Gantt End to Start
has to be done before UXPROD-3056 FE: Effective location property on th... Closed
Relates
relates to MODOAIPMH-283 Provide effective location and effect... Closed
Epic Link: Locations and Service Points
Front-End Confidence factor: Low
Back End Estimate: XL < 15 days
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: As the Elastic Search PoC has not been evaluated at this time, it is not known how searching is going to work in inventory. Depending upon the outcome of that decision, the estimate may need to change
Development Team: Prokopovych
PO Rank: 75
PO Ranking Note: 2021-01-25: Bumping ranking for possible consideration in Juniper due to intersection with OAI-PMH support needs. - Erin
Cap Plan Fix Version (DO NOT CHANGE): R2 2021
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: GBV (MVP Sum 2020): R4
Rank: hbz (TBD): R4
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

The current "Effective location" property currently exists on the item record.

The purpose of this feature is to define a similar property, Holdings Effective Location, to be set on the holdings record and be populated according to a similar algorithm.

The primary use case is to assure that a computed location is available for holdings that do not have items.

But, given that items may be moved off and on holdings during tech services workflows, having a value that only exists in certain use cases may lead to inconsistent search / UI / data behavior. The strong preference from the SME group was to have the holdings effective location value always be present, even if items are on the record.

Use cases where a holdings effective location would be used include:

  • special collection materials
    • sometimes item records may be added later (when cataloging is complete) but the holdings record should be visible in discovery before that point
    • sometimes item information is maintained in another system of record, like AEON or ArchiveSpace, and not in the ILS;
  • electronic items (eBooks, journals, databases)
    • these items don't circulate and don't really have physical equivalents, so many libraries don't create item records since the work doesn't seem to be needed;
    • if libraries plan to rely on FOLIO for a discovery layer extract, they want electronic holdings to be in Inventory;
    • if libraries want those electronic holdings to be discoverable in a discovery layer with a location facet (e.g., location = "Online"), then the holding record needs location information
  • other materials
    • microfilm - since patrons generally don't have microfilm readers at home, microfilm usually doesn't circulate, so many libraries did not create item records for them
    • periodicals (single and bound) - because libraries don't want journals to leave the building because they are expensive and can be hard to replace, they usually do not circulate, and so don't have item records.
    • government documents - similarly, because they don't generally leave the building, they don't circulate, and so may not have item records.

Requirements:

  • Create an attribute that is on the holdings record for the Holdings Effective Location that is a computed value, based on the values in the holdings permanent location and/or holdings temporary location, as follows.
Holdings Permanent Location Holdings Temporary Location Holdings Effective Location
A   A
Holdings Permanent Location Holdings Temporary Location Holdings Effective Location
A B B  

Other notes

The holdings effective location will not be used in any circulation workflows, since circulation requires an item record, and those workflows are already reliant on the item effective location which has already been built. That means no changes are needed to the circulation rules system.

Search / filter needs in Inventory

In Inventory, library staff will want to be able to filter to find all the things in a given location. The MM SIG (in consultation with other SIGs) will need to decide how holdings location search should behave with the addition of the holdings effective location attribute.

Right now (Honeysuckle), the location search options (as separate filters) in the holdings pane are

  • Effective Location (items)
  • Holdings Permanent Location

In discussion with the SMEs who have helped flesh this out in asynchronous discussion, they were comfortable with two possibilities for changing to search on the Holdings pane, including:

  • Option 1
    • Effective Location (holdings)
    • Holdings Permanent Location
  • Option 2
    • Effective Location (item)
    • Effective Location (holdings)
      So both scenarios would add a search for effective location (holdings), but may end up removing the option on the Holdings pane to search Effective location (items).

Additional functionality that will be needed (added in additional features)

  • Support for OAI-PMH for institutions that will rely on that functionality to support discovery layer integration (see comments from TAMU, MSU)
  • In reports, filters to find all the things in a given location

Further questions

Is there something on a holdings record that automatically tells you if the holdings record has associated items? Is that what holdingsItems is?

Discussed in MM SIG meeting on 2020-03-12
Follow-up discussion on location filtering from 2020-03-19: https://folio-org.atlassian.net/wiki/display/MM/2020-03-19+Metadata+Management+Meeting+notes

Discussed January 2021 in temporary Slack channel #holdings-without-items
Discussed January 2021 in RA SIG channel (sharing for input)



 Comments   
Comment by Cate Boerema (Inactive) [ 18/Mar/20 ]

Some notes based on side discussion with Marc Johnson in Slack:

  • The current effective location element is part of an item, if there are no items, there is nowhere for it to go.
  • That said, locations are already in a reference table - we could introduce an intermediary so it could be used by holdings, but we would need to figure out when holdings should be in that intermediary table.
  • Some options:
    1. We could design it so holdings only have an effective location when they contain no items OR
    2. We could always allow holdings to have an effective location but make is so that effective location filters only pay attention to holding effective location when "items on holdings count" is 0.
  • Option 1 is awkward but possible
  • Option 2 is less clear in that it may not even be possible to construct a CQL query for option 2, in that it would some how need to know about the presence of items, and that isn’t how the instance-centric searches in inventory work.
    • For example, when we search for item.effectiveLocation==x what that does behind the scenes is link up the instances with items, filter each based upon the item, and then de-duplicate the instances which remain.
    • This is different, admittedly subtly, to saying find me the instances where there is either an item with effectiveLocation==x or a holdings record with effectiveLocation==x and no items at all.
  • Need to ask SMEs:
    1. Is there any reason we need to maintain an Effective location for Holdings even when the Holdings record has items? This would be complicating (see option 2)
    2. Let’s say we have an instance with a holdings record A with effective location X and that has an item with effective location Y. When we search for effective location X, what should happen? Current understanding from is that this instance should not be in the search results?
Comment by Cate Boerema (Inactive) [ 20/Mar/20 ]

I spoke with Kelly Drake and Anya to see if they thought this was a must-have feature for round II libraries. I wanted to get their thoughts on whether this feature might be needed to appropriately display location in discovery. They thought that it likely wasn't needed for this purpose, but we'll know more as they progress with their discovery setups. They agreed it would certainly be nice for filtering in Inventory but that use case is not a must-have for round II libraries to go live.

Comment by Erin Nettifee [ 28/Apr/20 ]

This looks like it might be a duplicate of https://folio-org.atlassian.net/browse/UXPROD-2339 (or perhaps that one is a duplicate of this one) Cate Boerema Charlotte Whitt

Comment by Charlotte Whitt [ 28/Apr/20 ]

Hi Erin Nettifee - yes you're right. I have now closed UXPROD-2339 Closed . Thanks for catching this

Comment by Charlotte Whitt [ 08/May/20 ]

Hi Cate Boerema, this feature is marked as Open, but it's not been defined by any stories yet. It probably should be changed to be: Draft.

Comment by Cate Boerema (Inactive) [ 11/May/20 ]

Actually Open indicates that it's waiting to be picked up by a PO (not that it's dev-ready). See workflow description: https://folio-org.atlassian.net/wiki/display/COMMUNITY/Getting+Started+for+Product+Owners#GettingStartedforProductOwners-UXPRODEpicandFeatureWorkflow/StatusUXPRODWorkflow

Comment by Charlotte Whitt [ 11/May/20 ]

Oh, I see. Thanks Cate Boerema

Comment by Erin Nettifee [ 22/Jan/21 ]

Discussion with Anne L. Highsmith at TAMU about their ranking this as R1:

".... if there's no item record attached, OAI-PMH returns no location or call number info for the holdings. Which means I don't know what EDS/VuFind would display as location and you wouldn't be able to include it in a location-based filter. We have 2.3M holdings with no items, mostly, but not all, electronic .... we have [a location filter for electronic items] now in voyager and it's popular."

Magda Zacharska what are your thoughts on this vis-a-vis OAI-PMH and discovery? Have you heard of / had a chance to look at this issue?

Comment by Erin Nettifee [ 22/Jan/21 ]

Duke's need for this is to accommodate a large collection of microfilm, for which there are holdings but no item records, with holdings in multiple locations.

Comment by Magda Zacharska [ 22/Jan/21 ]

Erin Nettifee there is MODOAIPMH-283 Closed for this functionality but I believe this should be resolved globally and not each app re-implementing the effective location logic. Is lack of the effective location when there are no items affecting only OAI-PMH?

Comment by Erin Nettifee [ 25/Jan/21 ]

Hi Magda Zacharska. I agree that this should be resolved globally and not within each app.

AFAIK, this affects OAI-PMH and it also affects Inventory search behavior (as outlined in the story.)

Charlotte Whitt - has this come up at all in any recent Inventory discussions?

Comment by Charlotte Whitt [ 25/Jan/21 ]

Hi Erin Nettifee - I'm not aware of any recent discussions, but the question was raise early last year, and the web page for Calculation of the Effective Location Logic (ring down algorithm) was enhanced with the last two examples - see: https://folio-org.atlassian.net/wiki/display/RA/Effective+Location+Logic

Comment by Brooks Travis [ 25/Jan/21 ]

Since this is needed to address OAI-PMH handling of holding-only instances, I’ve bumped our ranking from R3 to R1.

Comment by Erin Nettifee [ 25/Jan/21 ]

Also, Magda Zacharska is there a feature for the fact that call number is not returned to OAI-PMH in this scenario either? See Anne L. Highsmith's comment above (which I copied and pasted in from a Slack.)

Comment by Erin Nettifee [ 26/Jan/21 ]

Marc Johnson and Zak Burke - I'm looking to get this feature estimated. I'm a new PO to the process, so is what we have here enough to do an estimate? What do you need from me?

Marc it looks like Cate discussed it with you back in March and some of your conversation is captured in her comment above, but since then, Magda and TAMU have found that OAI-PMH does not handle the current location structure well for holdings w/o items - see https://folio-org.atlassian.net/browse/MODOAIPMH-283 for that.

Comment by Marc Johnson [ 26/Jan/21 ]

Erin Nettifee

I'm looking to get this feature estimated. I'm a new PO to the process, so is what we have here enough to do an estimate? What do you need from me?

Thanks for reaching out. It really depends upon the feature. If the feature is fairly self-explanatory then folks tend to go ahead provide a high level estimate without much more detail. If it isn't, then we tend to need to understand more.

Marc it looks like Cate discussed it with you back in March and some of your conversation is captured in her comment above, but since then, Magda and TAMU have found that OAI-PMH does not handle the current location structure well for holdings w/o items

Cate and I did discuss this feature. IIRC I didn't really understand it. At the moment, the effective location is a (derived) field for each item.

I'm not sure I really understand what it means for there to be an effective location not associated with an item. I think Cate and I discussed the possibility that it was a field for a holdings record, however I think it wasn't that simple.

Is the scope of this only to introduce a new derived effective location field for holdings records?

cc: Zak Burke

Comment by Erin Nettifee [ 26/Jan/21 ]

I'm not sure I really understand what it means for there to be an effective location not associated with an item.

It comes back to the idea that for many/most libraries, the holding is where the true location lives, and for things like electronic holdings, they don't really consider them to have "items". There's not really a physical instantiation equivalent for an eBook with a 20-user concurrent license, for example.

But at the same time, libraries have used the holding as a way to show that they have those things anyway, like in a discovery layer with a filter for "get this online."

Is the scope of this only to introduce a new derived effective location field for holdings records?

I'm not sure, honestly. It makes sense to me to try to extend the location model to account for these scenarios, since they do impact a number of libraries.

At the same time, given that location information fields already exist on the holdings record, is it a more appropriate approach to expect other modules / apps talking to Inventory to deal with the scenario? E.g., make oai-pmh compute the effective location value? But that doesn't necessarily solve the Inventory filter issues that I think caused this issue to come up in the first place.

I am going to try and recruit a few people from the metadata management SIG to flesh this out more with me, and hopefully get more details.

Comment by Marc Johnson [ 26/Jan/21 ]

Erin Nettifee Thanks for the additional context.

It comes back to the idea that for many/most libraries, the holding is where the true location lives, and for things like electronic holdings, they don't really consider them to have "items". There's not really a physical instantiation equivalent for an eBook with a 20-user concurrent license, for example.

But at the same time, libraries have used the holding as a way to show that they have those things anyway, like in a discovery layer with a filter for "get this online."

Way back when, I had hoped that this would be resolved by FOLIO modelling access to electronic resources differently to being in possession of copies of physical resources.

I'm not sure, honestly. It makes sense to me to try to extend the location model to account for these scenarios, since they do impact a number of libraries.

What do you mean by extend the location model?

At the same time, given that location information fields already exist on the holdings record, is it a more appropriate approach to expect other modules / apps talking to Inventory to deal with the scenario? E.g., make oai-pmh compute the effective location value? But that doesn't necessarily solve the Inventory filter issues that I think caused this issue to come up in the first place.

If folks have a need for a derived effective location for both holdings and items, then this is possible and can be done in inventory. My vague recollections of the conversations I had with Cate about this feature make me think there was more to it than that.

I am going to try and recruit a few people from the metadata management SIG to flesh this out more with me, and hopefully get more details.

Thank you.

Comment by Ann-Marie Breaux (Inactive) [ 26/Jan/21 ]

Magda Zacharska Is effective location a data element that can be exported as part of MARC Export? If yes, then this Jira might trigger some data element changes in DE. If no, then nothing to worry about.

Totally different topic, I was playing with effective location last night - trying to decide if it makes more sense to put a temp location in the holdings record or in the item record when there is only one item associated with a holdings. Finally decided it probably doesn't matter, as long as I'm consistent

Comment by Erin Nettifee [ 01/Feb/21 ]

Marc Johnson I've finished discussions with a SME group and updated the feature above. They have a strong preference for having the holdings effective location always be populated, even when the holding had item(s) attached to it. I'm hoping that makes things somewhat simpler to do technically.

Is the info above enough to estimate this feature? Magda Zacharska, would this feature take care of the needs in https://folio-org.atlassian.net/browse/MODOAIPMH-283?

Essentially right now there are no UI elements to this, just backend. They would be added in Inventory at some point, but I'm not sure if I would build that out as associated stories to this, or if Charlotte would build another feature for it (Charlotte Whitt?)

Comment by Marc Johnson [ 02/Feb/21 ]

Erin Nettifee

Essentially right now there are no UI elements to this, just backend

This suggests that the scope of this feature is only to introduce the new derived property in the back end.

It would not include presenting it in UI inventory (or any other part of FOLIO) or being able to search using it.

Am I understanding this correctly?

Comment by Erin Nettifee [ 02/Feb/21 ]

This suggests that the scope of this feature is only to introduce the new derived property in the back end. It would not include presenting it in UI inventory (or any other part of FOLIO) or being able to search using it.

Marc Johnson that's correct. We would build additional features for UI display and searching as needed, but they are not part of this feature.

Right now, the location search options (as separate filters) in the holdings pane are

  • Effective Location (items)
  • Holdings Permanent Location

In discussion with the SMEs who have helped flesh this out in asynchronous discussion, they were comfortable with two possibilities for changing to search on the Holdings pane, including:

  • Option 1
    • Effective Location (holdings)
    • Holdings Permanent Location
  • Option 2
    • Effective Location (item)
    • Effective Location (holdings)

So both scenarios would add a search for effective location (holdings), but may end up removing the option on the Holdings pane to search Effective location (items).

Comment by Jacquie Samples [ 03/Feb/21 ]

One caveat to having effective location based on Holdings data. For electronic resources, there are no holding records and we do not anticipate creating them or using FOLIO electronic holdings. I think that the situation with Bound-withs is complicated by the fact that they may, or may not, have holdings or item records. The "parent" record will have both, but the "children" may have holdings, may have items, but usually have neither. The development of items so that many instances can be linked to one item, may help with the bound-with situations and effective locations, though.

Since electronic resources do not have holdings or items, then perhaps they don't need effective locations to display correctly in the discovery interface? The discovery layer should be able to show "online" with an embedded link from bibliographic records.

Comment by Erin Nettifee [ 03/Feb/21 ]

Hey Jacquie Samples - as far as I've understood it, there are adopting schools that will have holdings for electronic records (but not items). For those schools, OAI-PMH needs to be able to pull locations data from the holding when the item record isn't present.

In any case, this feature is simply to define the effective location as a new holding attribute, computed from holdings permanent or holdings temporary location info; it will be up to the individual institutions to decide if they need to use it in their discovery layer, or if they can choose to ignore it based on their discovery layer tool.

Comment by Ann-Marie Breaux (Inactive) [ 04/Feb/21 ]

Hi Jacquie Samples and Erin Nettifee That's my experience too - that schools with Instances for eResources will likely have Holdings records for them as well, and the local URL will be in the Electronic Access field of the Holdings record. It may or may not also be retained in the Instance.

The idea of a default location for Instances that do not have a Holdings or Item is a good one, but probably needs to be a separate feature/requirement from the idea of effective location for the holdings record.

Comment by Jacquie Samples [ 09/Feb/21 ]

Hi Ann-Marie and Erin,
I appreciate your thoughts here. I suppose I should have been more specific to say that for the most part, Duke Libraries does not include holding or item data for electronic resources. I am aware that other institutions do create that data. I just wanted to be sure that whatever is developed won't mean we will "have to" create those data for the records to work in FOLIO the way they do currently for us.

Since the majority of the URLS for our electronic resources come from a 3rd-party MARC record service, they live in the bibs, not holdings.

Thanks again for the conversation and prioritizing this work!

Comment by Holly Mistlebauer [ 26/Feb/21 ]

Erin Nettifee and Charlotte Whitt :  This feature doesn't include any front-end work.  Won't there be UI stories to use the Effective Location?  Or is there another feature for the front-end work?  We are planning Juniper right now and need to know how large this feature really is.  Thanks...

Comment by Holly Mistlebauer [ 26/Feb/21 ]

Kelly just noticed that this is indeed only for the BE work.   We will have a lot of FE dev capacity in Juniper, so it would good to do the FE work too.   Who will work on those stories?  Thanks...

Comment by Charlotte Whitt [ 01/Mar/21 ]

I'll do the FE stories. 

Comment by Erin Nettifee [ 01/Mar/21 ]

Thanks Charlotte Whitt - yes, Holly Mistlebauer - this was initially scoped only as BE because that was what was needed for OAI-PMH. We intentionally were deferring the front-end stories to another feature. Or I suppose they could be attached to this feature too.

Magda Zacharska note that this is now scheduled for Juniper.

Comment by Holly Mistlebauer [ 05/Mar/21 ]

Erin NettifeeCharlotte Whitt:  Thanks for the info.  We have a lot of FE capacity left in Juniper, so it will be good to work on the FE stories then.  You can add them to this feature or create a new one, depending on what makes the most sense.   Just let me know what is decided and when the stories are ready.  Thanks much!

Comment by Holly Mistlebauer [ 29/Apr/21 ]

Charlotte Whitt: The two user stories defining this feature are completed.  May we close this feature now?

Comment by Charlotte Whitt [ 30/Apr/21 ]

Hi Holly Mistlebauer - yes the BE work is done.

As Erin Nettifee writes above:

We intentionally were deferring the front-end stories to another feature.

Catching up on adding the needed UI stories Erin Nettifee and I should follow up on and get into the pipeline of new work for our FE developers.

Generated at Fri Feb 09 00:22:59 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.