Locations and Service Points
(UXPROD-771)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||
| 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:
Requirements:
Other notesThe 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 InventoryIn 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
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:
Additional functionality that will be needed (added in additional features)
Further questionsIs 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 Discussed January 2021 in temporary Slack channel #holdings-without-items |
| Comments |
| Comment by Cate Boerema (Inactive) [ 18/Mar/20 ] |
|
Some notes based on side discussion with Marc Johnson in Slack:
|
| 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
|
| 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
|
| 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 ] |
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.
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 ] |
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."
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.
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.
What do you mean by extend the location model?
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.
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 ] |
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 ] |
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
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:
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, 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 Nettifee & Charlotte 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:
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. |