Quotes in the 245 field cause Anaylze MARC to report an error

[lmccoll44]

If a MARC file is loaded with a title that has quotes, the Analyze MARC feature gives the following error:

It is acceptable to have quotes in the 245 field.

Thank you.

[nielserik]

Yes, that's acceptable, or rather, it should be.

What happens is, that the record has no ISBN, which would have been used to potentially link the order to a existing Instance. So the tool checks if there is another instance with the same title in FOLIO already, to display an alert about the missing linking if there is.

This lookup is what goes wrong. For what it's worth, it's the combination of a quoted section AND a forward slash that throws FOLIO's CQL parser off. Leave either of them out and the lookup will parse alright, and also find the given title (if it exists).

Since the query works with the quotes left out, I suppose we could have the tool strip quotes from the title query before URL encoding the query and sending off the request to FOLIO.

[nielserik]

This is what it looks like, if the record has no ISBN and the tool then strips quotes from the title before sending of a query to check for an existing instance by that title.

[nielserik]

I have a pull request with that solution if we think it's good. #42

[lmccoll44]

I think it will work for us. I would want that to work for Chicago as well of course. To be honest I'm still struggling with dealing with that matching. My understanding is that it will be able to be turned off with Lotus. We're stripping out potential match points right now so we do not get an accidental match. I thought I would mention that in case it affects others' view of this process. Thank you for the explanation too, Niels. That is really interesting.

[maccabeelevine]

Seems good to me as well!

[nielserik]

Thanks guys.

@lmccoll44 Are you stripping off match points from the incoming MARC records? UChicago has reduced the identifiers that they use for matching to just ISBN in their mapping - the "chi" mapping:

folio-order-import-tool/src/main/java/org/olf/folio/order/mapping/MarcMapChi.java

Line 56 in 90ac8dc

public List<String> applicableProductIdentifierTypeIds() {

. They don't need to take identifiers out of the MARC for that.

The other two mapping variations, "sigma" and "lambda", however, use the default set, which is

folio-order-import-tool/src/main/java/org/olf/folio/order/mapping/MarcToFolio.java

Line 620 in 90ac8dc

public List<String> applicableProductIdentifierTypeIds() {

If everybody actually wants to go by only ISBN for matching, we can implement that across the board. This doesn't limit what identifiers are populated on the Instance, it only limits which of them that are used as product identifiers in Orders' matching logic.

[lmccoll44]

@nielserik - Unfortunately the ISBN for us I think is the most likely to cause a false match since ISBNs for multiple formats of a work are frequently included in one record. We already had this happen - a print book order found an ebook in FOLIO and attached itself to that record. I'll have to think through the process better. Ideally we would have a warning of a match and the opportunity to say "yes" or "no" before the match was made.

[nielserik]

@lmccoll44 Ah, I see. I don't suppose omitting the ISBN and go with some of the other identifiers would work for you either?

I hear you regarding an interactive mode, I suppose that would be for another generation of the tool (and the tool is officially still a temporary remedy so I don't know how many "generations" there will be)

[nielserik]

I'm wondering how crucial an interactive mode would be for you. If it's a major thing, might it be something that @maccabeelevine would consider looking into developing by any chance?

[maccabeelevine]

I think I missed the initial suggestion of an interactive mode, will chat with @lmccoll44 but yes if needed I could find the time to build that. I tend to agree with @nielserik 's point about this being a temporary tool, but who knows what temporary means.

[lmccoll44]

I am totally aware that the tool is a patch to get us through- and it’s a good one too. I wouldn’t expect complex development.

On Tue, Feb 15, 2022 at 12:12 PM Niels Erik ***@***.***> wrote: @lmccoll44 <https://github.com/lmccoll44> Ah, I see. I don't suppose omitting the ISBN and go with some of the other identifiers would work for you either? I hear you regarding an interactive mode, I suppose that would be for another generation of the tool (and the tool is officially still a temporary remedy so I don't know how many "generations" there will be) — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACPNBDHHNFEXVDYM3AOKBTDU3KCOZANCNFSM5OL6LTWQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Lisa McColl* *Metadata Services Librarian* *Lehigh University* *610-758-2639*

[nielserik]

Right, I mention temporary because making the import stop and have the user decide how to proceed in given circumstances (when multiple ISBNs?) seems like it could be a not entirely trivial extension to develop.

[lmccoll44]

Makes sense!