Z39.50 support (UXPROD-990)

[UXPROD-560] Z39.50 support MVP Created: 07/May/18  Updated: 24/Sep/20  Resolved: 24/Sep/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q3 2020
Parent: Z39.50 support

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: Lehigh(round_ii+mvp), cap-mvp, data-import, external_sys_int, library_dependent, po-mvp, resourceaccess, round_ii
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Microsoft Word z39.50 OPAC response examples for Cornell.docx    
Issue links:
Defines
is defined by ZF-3 Support returning OPAC records Closed
is defined by ZF-5 Get MARC records directly from linked... Closed
is defined by ZF-7 Improve query-mapping Closed
is defined by ZF-17 Create client documentation for FOLIO... Closed
is defined by ZF-6 Get the basic server working Closed
is defined by ZF-9 Z39.50 server MVP - scope of work Closed
is defined by ZF-12 Generate OPAC record from holdings/it... Closed
is defined by ZF-20 Add config to specify which indexes s... Closed
is defined by ZF-1 Support for sorting Closed
Gantt End to Start
has to be done before UXPROD-2682 Z39.50 refinement work Closed
has to be done before UXPROD-2386 Z39.50 support. Post MVP Draft
Requires
is required by UXPROD-1764 ILL between FOLIO libraries Open
Potential Workaround: HK: Workaround, harvest the catalog via OAI-PMH and if live availability data is needed, FOLIO now has multiple API's for both Vufind and EDS that can be used as well. Also, it might make sense to wait on this until code has stabilized on SRS, MARCcat and inventory.
HM: This is needed so that citation management tools like EndNote are able to search FOLIO directly to find items to interest to be extracted and loaded into the citation management tool.
Epic Link: Z39.50 support
Front End Estimator: Jakub Skoczen
Back End Estimate: XXL < 30 days
Back End Estimator: Jakub Skoczen
Estimation Notes and Assumptions: Assuming front-end for settings only.
Development Team: Thor
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R1
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: Leipzig (Full TBD): R1
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Act as a Z39.50 server to support citation management tools and union catalog searching.

For MVP the focus is on query handling, pulling MARC records from SRS, and collating holdings information from the holdings/items structures.
And then defer dealing with instances with no underlying MARC records, for now.

Stories are tracked in the ZF Key project: https://folio-org.atlassian.net/projects/ZF



 Comments   
Comment by Ann-Marie Breaux (Inactive) [ 20/Jun/18 ]

May also be needed for some batch import work. See 4th column of https://folio-org.atlassian.net/wiki/display/MM/Sources+of+Batch+Files

Comment by Sebastian Hammer [ 28/Jun/18 ]

[assuming that the initial focus is just on a Z39.50 server] Since Index Data has probably built or configured most/all of the clients that need to interoperate with this, we speculate that we can do this very quickly, with just a few days of work. We just need input from early adopters on what configuration options they desire. Perhaps a tight, informal process between ID and a couple of early adopters without the need for separate PO cycles to be locked up?

Note, without stored MARC records, there is a need for an inventory-->MARC mapping. If we need to support a scenario in v1 where there are no stored MARC records, we either have to block on the MARC export feature or build a simple mapping.

Comment by Cate Boerema (Inactive) [ 02/Jul/18 ]

Perhaps a tight, informal process between ID and a couple of early adopters without the need for separate PO cycles to be locked up

Agreed, Sebastian Hammer, this could be a perfect one to run without a PO and a great choice for ID!

Comment by Ann-Marie Breaux (Inactive) [ 02/Jul/18 ]

Cate Boerema Sebastian Hammer It would be good to understand what is being planned. Where would the search launch from? What would it retrieve, how would it bring back the record(s), and where? This is important to the batchimport folks, especially with regards to importing individual records from source databases.

Comment by Cate Boerema (Inactive) [ 09/Jul/18 ]

Changing all the external system integration features into epics. While this will extend the epic list by 7 items, these really are all mini-projects that can be assigned to teams and have POs and priorities. In that regard, they make sense as epics. I will deprecate the old External Systems Integrations epic.

Comment by Cate Boerema (Inactive) [ 09/Jul/18 ]

Actually, I should just clone these features to create epics. I will convert this back to a new feature and link it to the cloned epic: UXPROD-990 Open

Comment by Sebastian Hammer [ 26/Aug/18 ]

Ann-Marie Breaux, I think your comments would refer more to a Z39.50 client function, which would support copy-cataloging and such by FOLIO catalogers. I think the intent of this issue (see description) was to cover a Z39.50 server which is a go-live requirement for libraries participating in many resource sharing consortia that use Z39.50 to do real-time availability checking..

I think we should have separate issues for the Z39.50 client and server functions... the client side needs to be integrated into the cataloging workflow in some manner, and this definitely has UX implications and needs discussion.

Comment by Mike Taylor [ 06/Dec/18 ]

We briefly discussed this in Malaga. Either Mike or Adam could build it. We are thinking it might take about five to ten man-days, rather than the twenty in the official estimate. That's for a server only, not a client such as Ann-Marie Breaux was discussing in an earlier comment.

Comment by Mike Taylor [ 06/Dec/18 ]

I've made a start on a Z39.50 server at https://github.com/MikeTaylor/Net-Z3950-FOLIO/

Further bulletins as events warrant.

Comment by Mike Taylor [ 07/Dec/18 ]

Now successfully authenticating and searching. No way to get records back yet.

Comment by Mike Taylor [ 07/Dec/18 ]

Oh, we should note: we know this is not on the Q1 roadmap. We are contributing it to the project pro bono, outside of our existing commitments.

Comment by Sebastian Hammer [ 07/Dec/18 ]

Somoe thoughts on requirements. Feel free to move from this comment into something else:

1) Returning MARC records from Inventory records in the situation where there is no linked MARC is MVP for this. Charlotte and/or the MM SIG will be able to provide a crosswalk, but because the mapping can get fiddly, it would be wise to map the inventory record to XML and then use XSLT to map to MARCXML... this would allow for the necessary flexibility and will allow a practitioner to hand-tune the mapping in great detail. Because the inventory format is community-fixed, I think it would be acceptable for the mapping to be fixed across tenants for MVP.... a more dynamic scheme allowing tenant control of the mapping could be introduced later if there is a need. YAZ GFS should be able to generate MARC21/ISO2709 from MARCXML, which is what most Z clients will be looking for.

2) Type-1 (and CQL standard set) mapping to Inventory's CQL qualifiers can similarly be static, at least initially.

3) Being able to return the OPAC wrapper around MARC, including item-level location and status information is similarly MVP. Talk to Adam or look at doc for YAZ-GFS's ability to turn an OPAC-XML record (with embedded MARCXML) into an OPAC record (with embedded MARC). This is what most discovery layers and resource sharing systems will be looking for. It would be smart to only do the item lookup when the client asks for it, and to be mindful about reasonable optimization of the lookup of item-level information per record when many records are requested. A quality ILS should be able to dig out item-level information for 20 records without choking up.

Comment by Sebastian Hammer [ 07/Dec/18 ]

1a) It would be nice if, when there is a linked MARC record, that we pull that MARC record in lieu of the inventory record, but in my opinion it's not as important a the general case of pulling metadata from MARC.

Comment by Mike Taylor [ 07/Dec/18 ]

Thanks, Seb, these are useful insights.

On #2, I'm already using a configurable mapping that's specified in a JSON config file. But it's the same across tenants. Just means it can be tweaked by SMEs without needing to mess with code.

On #3, "It would be smart to only do the item lookup when the client asks for it" – that's when the requested record-type is OPAC, right?

Also, am I right in thinking that there's nothing we can usefully do with element-set name? At least, not unless we introduced the notion of configuring in the gateway itself what we mean by a "brief record", because there is no such concept in FOLIO itself?

Comment by Mike Taylor [ 07/Dec/18 ]

Another thought: we want to do different FOLIO WSAPI requests depending on whether the user wants MARC or OPAC records – straight to inventory-storage/instances in the former case, and via GraphQL in the latter. Which means that we don't know what search we should have done until the fetch happens. Not sure what to do about this. I could simply postpone the back-end search until the the fetch request comes in, but that means bad searches will seem to succeed, only to be followed by a search error in response to the fetch request. Maybe I should always do the lightweight inventory-storage search, considering it a cheap write-off in the case when we're going to have to do a much more heavyweight instance-and-its-holdings-and-their-items search.

Comment by Sebastian Hammer [ 07/Dec/18 ]

On #3, "It would be smart to only do the item lookup when the client asks for it" – that's when the requested record-type is OPAC, right?

That's right, the client basically indicates that it wants item-level information by requesting OPAC as the record syntax.

Also, am I right in thinking that there's nothing we can usefully do with element-set name? At least, not unless we introduced the notion of configuring in the gateway itself what we mean by a "brief record", because there is no such concept in FOLIO itself?

To me this sounds right, I can't think of any useful differentiation of behaviors on element set name. It's pretty common for servers to blithely ignore them, or to ignore "B", or "F" or an empty value and reject everything else as unknown.

Another thought: we want to do different FOLIO WSAPI requests depending on whether the user wants MARC or OPAC records – straight to inventory-storage/instances in the former case, and via GraphQL in the latter. Which means that we don't know what search we should have done until the fetch happens. Not sure what to do about this. I could simply postpone the back-end search until the the fetch request comes in, but that means bad searches will seem to succeed, only to be followed by a search error in response to the fetch request. Maybe I should always do the lightweight inventory-storage search, considering it a cheap write-off in the case when we're going to have to do a much more heavyweight instance-and-its-holdings-and-their-items search.

This is right. You have to respond to the "search" callback from YAZ GFS/Simpleserver with a hitcount without knowing anything about what kind of records the client is looking for. I thought the GFS might have some way to optimize for a piggy-backed present request or SRU request where the retrieval parameters are known right upfront, but I don't see it in the APIs.... phooey.

You'll have to use best judgment to get a balance of quick performance and good data back.. obviously it's critically important to get the balance right.

Comment by Sebastian Hammer [ 07/Dec/18 ]

Btw when you do your query mapping, you could do worse than looking to support these attribute combinations as well as you can using the inventory backend (you'll have to revise it when better search functions are introduced):

http://www.ukoln.ac.uk/interop-focus/activities/z3950/int_profile/bath/draft/stable1.html#5.A.1.%20Functional%20Area%20A:%20Level%201%20Basic%20Bibliographic%20Search%20and%20Retrieval%20Emphasizing%20Precision

And reject the ones you can't support using inventory. It's good to have defaults for all attribute types and to be agnostic about the order of attributes in the list... this would help people provide predictable search experiences in discovery systems.

Comment by Mike Taylor [ 10/Dec/18 ]

We now have a Jira project for this: https://folio-org.atlassian.net/projects/ZF/issues/ZF-7?filter=allopenissues

I don't know what that means for the present issue. I suppose we'd like to block it not on any specific issue but on that project as a whole. Cate Boerema, should this one be closed or left open?

Comment by Anya [ 29/Mar/19 ]

Comment from March Meeting: needed for ILL - FOLIO needs to be search able by ILL

Comment by Mike Taylor [ 30/Mar/19 ]

Does ILL need to be able to retrieve OPAC records, or will MARC records suffice?

Comment by Anya [ 30/Mar/19 ]

ILLiad needs to be able to do a z39.50 search of the marc records I believe to see if it is held.

Comment by Mike Taylor [ 30/Mar/19 ]

OK, good — that is supported right now.

Comment by Hkaplanian [ 14/Jun/19 ]

Mike Taylor, It appears work started. Wondering if it's done.

Comment by Jakub Skoczen [ 13/Aug/19 ]

Holly Mistlebauer Hkaplanian Guys, I spoke with Mike Taylor and the estimate based our conversation for completing z39.50 support is 20 days (there's not value in drop-down to represent that so I left that at 15). There are two outstanding development tasks: ZF-3 Closed and ZF-8 Open . The estimate represents remaining work.

Comment by Holly Mistlebauer [ 13/Aug/19 ]

Jakub Skoczen: Thanks for checking. I have made this an MVP feature, but we can move it to Q1 2020.

Comment by Jakub Skoczen [ 15/Aug/19 ]

Thanks Holly, I bumped the estimate to 30 because otherwise it underestimated the required effort. Plus more discussion revealed some uncertaintity about the direction of UXPROD-1397 Closed which is likely a dependency for this work.

Comment by Jenn Colt [ 04/Oct/19 ]

At Cornell we've been gathering use cases because we want to be clear how important this protocol is for us. Not having z39.50 would make it impossible for us to participate in Borrow Direct is my understanding. We have these current known use cases:

#1 Used to present real time holdings in WorldCat discovery
#2 Used to present bib and holdings to BorrowDirect
#3 Used an alternative method to search our bibliographic data when we are doing batch processing

#3 requires that we be able to robustly configure which fields are available in z39.50. It also offers a potential workaround for this period of time when searching in FOLIO is not all that we would like it to be.

Attached is what Relais sent us when we asked them what fields they are using from our current Voyager z39.50

Comment by Kelly Drake [ 04/Oct/19 ]

Thank you Jenn Colt

I don't have all the details but...

At FLO we require z39.50 for participation in the ComCat. The statewide Discovery and borrowing and lending system developed by Auto Graphics.
Our plan is to use ComCat at go-live to compensate for FOLIO's current lack of cross-tenant borrowing and lending

I will see if I can come up field specific documentation.

Comment by Tod Olson [ 04/Oct/19 ]

For Chicago we have:

  1. allow searching and real-time item information for our two ILL consortia, this is in use 24×7.
Comment by Tod Olson [ 04/Oct/19 ]

I have a question about implementation strategy. Would FOLIO implement a Z39.50 server directly in Java, or might we supply an SRU responder and expect to use Metaproxy as a gateway? This was actually a very successful strategy in OLE. It did not take as much time to build the SRU responder and it would for a Z30.50 with its on-the-wire ASN.1/BER records. And it is one of most robust Z39.50 set ups in our two consortia. It might be a good strategy for FOLIO.

Comment by Sebastian Hammer [ 04/Oct/19 ]

Todd, this is by no means an indication of a strategy as such, but quite some time ago we at ID started down a path of putting together a basic Z39.50/SRU server using the YAZ SimpleServer Perl interface, which wraps some of the same capabilities as MetaProxy using Perl as a glue language. We didn't intend for it to be the be-all and end-all but rather a way to get a quick win in terms of integration with some external systems, including resource sharing. We approached it as something that could be put together as a PoC, but ultimately we put it on hold because the mapping from the Inventory schema to MARC would require some effort (assuming no MARC records present), and we thought it better to wait on shared tooling for that purpose. That is the 'direction' that Mike Taylor is presently owning in this issue.

The big gotcha I saw in the recent comments would be deep configurability in terms of what is searched, and how it is mapped. Such functionality would definitely push this out of the realm of a quick win and into something that will require real thought in terms of how to manage the configuration, how to express it against the Inventory and/or MARC capabilities of FOLIO.

In my opinion, it is likely that we can meet the needs of most resource sharing systems and citation managers with a sensible, shared configuration. I wonder if we might be able to establish a working consensus around such a thing for MVP (Summer of 20) and defer a more configurable solution till later).

I do agree with you that building an SRU server in Java or some other language is a workable strategy... the appeal of the SimpleServer (Perl) solution was its extremely low cost in terms of development time, and fair simplicity in operation (one endpoint for Z39.50 and SRU). The investment in the current Perl-based solution probably is not so great that we couldn't pivot to another approach.

Note also that building an SRU server on top of inventory is potentially simplified because SRU and FOLIO share the CQL query language... and MetaProxy is capable of doing query transformations that might help alleviate any peculiarities of FOLIO that wouldn't make sense to a vanilla SRU/Z client.

Comment by Jenn Colt [ 04/Oct/19 ]

WRT config, we definitely prioritize resource sharing over internal searching, so we're certainly willing to help keep things on an MVP track if that is an issue.

Comment by Sebastian Hammer [ 04/Oct/19 ]

Thanks Jenn. I really think we're extremely close to having a capability sufficient for resource sharing... honestly the big hurdle is just record mapping. It felt like a waste of time to build translation code or a style sheet if the import/export parts of the project were going to produce something reusable... but the thinking was if nothing reusable emerged, it would be fairly quick to build something.... the crosswalks to MARC already exist, it's just capturing them in XSLT or some other form.

What's also slowed it down has been a concrete drive for testing. We had in mind to do some integration testing with our discovery layers, but we had no purpose other than just to say, look what FOLIO can do! If any early adopter wants to engage in full interop testing with, say, BorrowDirect, that's a different story.

Comment by Ann-Marie Breaux (Inactive) [ 04/Oct/19 ]

FYI - in case it's of help - we had a group from MM SIG that worked out the appropriate mappings from Inventory Instance format to MARC Bib format (for Instances that do not have underlying SRS MARC). It has not yet been developed, but the intellectual mapping work has been done, and is waiting for dev resources and to make it to the top of the priority heap. See UXPROD-1397 Closed

Comment by Sebastian Hammer [ 04/Oct/19 ]

Provided it has a clean API so it can be hit from the Z server, that would be just the ticket.

Comment by Kelly Drake [ 05/Oct/19 ]

Some of this is totally lost on me, but am I correct in assuming that if FLO provides the connection info and mapping that AutoGraphics (Shareit) needs, that this can be 'hardcoded' into an API until such time as a more configurable z39.50 connector is created?

....even typing this I'm not sure my understanding is correct...

Comment by Cate Boerema (Inactive) [ 22/Oct/19 ]

Just catching up on the comments here. This feature was assigned to Core Functional but it looks like Index Data is handling the development. Is that right Sebastian Hammer? If so, I think we should probably just leave the development team blank or possible assign it to the Course Reserves team. Thoughts?

Comment by Sebastian Hammer [ 22/Oct/19 ]

Cate Boerema I think that is fine – assigning to the CR team, but I'd say for now it's blocked waiting for the development of the Instance->MARC function that Ann-Marie Breaux referred to.

Comment by Cate Boerema (Inactive) [ 22/Oct/19 ]

Thanks Sebastian Hammer! I assigned this issue to Course Reserves team and marked it blocked awaiting UXPROD-1397 Closed

Comment by Mike Gorrell [ 26/Feb/20 ]

I updated the fix version to Q2 2020 as this is our plan.

Comment by Magda Zacharska [ 19/Mar/20 ]

Sebastian HammerMike Taylor could you provide more details what do you expect from UXPROD-1397 Closed so you are unblocked. Thanks! cc: Kruthi Vuppala and Igor Gorchakov

Comment by Mike Taylor [ 19/Mar/20 ]

Hi, Magda Zacharska. In a completely ideal world, there would be a simple WSAPI that we could use to request the MARC rendering of an instance record — so instead of using the existing call to pull back an SRS MARC record, we could use an analogous one to pull back a MARC record translated on-the-fly from the instance in inventory.

Is it the plan in UXPROD-1397 Closed to provide such a WSAPI?

If not, then we could also work with a machine-readable specification of the required translation: then the Z39.50 server would have to add code to perform that translation, driven by the specification, on instance records obtained from the inventory module. We'd prefer to avoid this, as there is little appeal in writing duplicate code, but it is an option.

Comment by Magda Zacharska [ 20/Mar/20 ]

Thank you Mike Taylor for your quick feedback. We'll be in touch in the next iteration.

Comment by Mike Taylor [ 27/Jul/20 ]

Hello, product owners! I see from the Issue Links above that the present epic "defined by" the low-level issues ZF-2 Closed , ZF-3 Closed , ZF-5 Closed , ZF-6 Closed , ZF-7 Closed , ZF-9 Closed and ZF-11 Closed . But all seven of these issues belong to the prequel epic UXPROD-990 Open (Z39.50 support).

Is this just a mistake, or is there a distinction between "defined by" and "belongs to" that I am missing?

Comment by Mike Taylor [ 27/Jul/20 ]

Also, I notice that ZF-1 Closed (Support for sorting) and ZF-8 Open (Create FOLIO-to-MARCXML translation stylesheet) are not linked to the present epic as "defined as": is that a deliberate choice, or an oversight? Thanks!

Comment by Ann-Marie Breaux (Inactive) [ 27/Jul/20 ]

Hi Mike Taylor Why are you asking all the POs? Who is the PO for Z39.50? Different POs handle the relationships between UXPROD Epics and Features slightly differently, so asking the Z39.50 PO is best. Also, we didn't have the "defines" and "is defined by" relationship links early in the FOLIO project, so some POs didn't use them, and even now may still not use them.

We had a similar issue with MARCcat UXPRODs. It took several hours of cleanup to get the Epics and Features straightened out so that the MARCcat POs and Devs felt that they were organized properly. If Z39.50 hasn't been worked on much yet, and is just now starting to get some attention in Jira, there's probably some basic cleanup and relinking that needs doing by the Z3950 PO.

Comment by Magda Zacharska [ 27/Jul/20 ]

In scope of UXPROD-1397 Closed we created a shared library https://github.com/folio-org/generate-marc-utils

Comment by Mike Taylor [ 27/Jul/20 ]

Hi, Ann-Marie Breaux. Yep, the Z39.50 PO is the one I needed. "Hello, product owners!" was an over-broad greeting. It looks like Charlotte Whitt is now tweaking these issues. The main thing I'd missed was that only UXPROD-990 Open is an Epic; the other two UXPRODs are features within that epic.

Comment by Mike Taylor [ 27/Jul/20 ]

Magda Zacharska That is unfortunate: it appears, then, that there is no straightforward way for the Z39.50 server to use that work. However:

The generated record will be base on the mapping provided by Metadata Management SIG: Instance to MARC 2019 tab in https://docs.google.com/spreadsheets/d/11lGBiPoetHuC3u-onVVLN4Mj5KtVHqJaQe4RqCxgGzo/edit#gid=1166940623

Did the project generate a machine-readable representation of those mapping rules which your software executes to generate the record? If so, then I may be able to re-use that ruleset and write a new engine to interpret it.

Comment by Ann-Marie Breaux (Inactive) [ 27/Jul/20 ]

Hi Mike Taylor - sounds good. If Charlotte Whitt is the PO for Z39.50, then that should get added to this wiki page: https://folio-org.atlassian.net/wiki/display/COMMUNITY/Directory+of+Product+Owners+by+Area+of+Focus

Comment by Magda Zacharska [ 27/Jul/20 ]

Mike Taylor Concorde - Instance to MARC 2019 tab of the spreadsheet you mentioned contains the full list of implemented mappings with related user stories and (links to PRs) I hope this will help in your work.

Comment by Mike Taylor [ 27/Jul/20 ]

Hi, Magda Zacharska. No, a human-readable description of the mapping is no (direct) use to me — but I assume your developers actually implemented this mapping, presumably by encoding it a machine-readable from such as an XSLT stylesheet: something their software could use to drive it. That is what I am seeking.

Comment by Charlotte Whitt [ 27/Jul/20 ]

Hi Magda Zacharska - maybe you can refer Mike Taylor to the GitHub documentation. Thanks

Comment by Magda Zacharska [ 27/Jul/20 ]

Mike Taylor the mappings are stored in json file: https://github.com/folio-org/mod-data-export/blob/master/src/main/resources/rules/rulesDefault.json

Comment by Mike Taylor [ 27/Jul/20 ]

@magda, that's great news — just the kind of thing I was looking for! Thank you.

Comment by Charlotte Whitt [ 27/Jul/20 ]

Hi Magda Zacharska thank you for sending the default mapping file for mapping instance to MARC.

Do you also have a link to the GitHub documentation for mapping holdings and item to MARC - which we are currently working on in the Data Export meetings.

Comment by Magda Zacharska [ 27/Jul/20 ]

Charlotte Whitt - holdings and items mappings that we've discussed during data export meetings are a part of the mapping profile functionality that we are building in Q3. The mappings will be provided by the user as a part of the mapping profile setup and the mapping file will be created on the fly.

Generating MFHD records on the fly ( UXPROD-1396 Closed ) that would require default mapping rules for MFHD is planned for Q4.

Comment by Mike Taylor [ 04/Sep/20 ]

Jenn Colt or maybe Charlotte Whitt: in the attached document "z39.50 OPAC response examples for Cornell", there is a sample display at the bottom of page five that shows "LoanPolicy: 01". Which part of the holdings record gave rise to that? It looks like it's the value from the AvailableThru field, but that can't be right, can it?

Also: "If a value is output in the Temporary Location field it overwrites what is output in the Shelving Location field and becomes the requestable location." But the contents of the "Shelving Location" as displayed is actually a combination of two OPAC-record fields, "localLocation" and "shelvingLocation". Should the temporary location, when present, override one of these (which one?) or both?

Comment by Charlotte Whitt [ 04/Sep/20 ]

Hi Mike Taylor - let me reach out to Jenn Colt and figure out what's the requirements on this. We'll get back to you shortly.

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