OPAC titles are truncated when query string present

We see the same issue with $h in the 245 in 3.1.7

This was discussed on IRC before Feb 28. There doesn't seem to be a bug report about it, however. Since I'm not on IRC, I can't be more specific. Chris looped me in. I do know that Michele Morgan came up with a solution that has something to do with this table. Chris applied it and then had to reingest to see success.

  id | field_class | name | label | xpath | weight | format | search_field | facet_field | browse_field | browse_xpath | facet_xpath | restrict | authority_xpath | browse_sort_xpath | joiner | display_xpath | display_field
------+-------------+----------------+-----------------------------+-------------------------------------------------------+--------+---------+--------------+-------------+--------------+--------------+-------------+----------+-----------------+-------------------+--------+---------------+---------------
 1045 | keyword | responsibility | Statement of Responsibility | //marc:datafield[@tag='245']/marc:subfield[@code='c'] | 1 | marcxml | t | f | f | | | f | | | | | t
(1 row)

Just wanted to set the record straight that it was a combined effort of NOBLE staff members Martha Driscoll, Christine Morgan, Suzanne Paterno, Elizabeth Thomsen, Beth Willis and myself to identify the issue and come up with a solution to what we thought was a more local problem than it's turning out to be.

Marking Confirmed.

I'll see if I can put a branch together for consideration.

Wasn't it an intentional design choice not to display the 245$c when using display fields? Those who want to show the 245$c can add the extra config.metabib_field entry, but for anyone who wants it suppressed (as intended?), the display will still be inconsistent as long as display fields are used inconsistently.

What was the reasoning behind the design choice to not display 245|c?

Hi,

245$c is excluded because we use MODS to pull the title out of the record. That's been the case all along for display fields, fwiw. The MODS mapping can be seen at [1] and the xpath in question is:

 //mods32:mods/mods32:titleNonfiling[mods32:title and not (@type)]

NOTE: The "Nonfiling" part is a specialization we added to fold the normally-separated nonfiling characters into the single title string, which avoids some indexing trouble especially for French. It works in the same way as the regular titleInfo element otherwise, though. Subfields included are

So, that's just MODS standard. I believe the original reason we believed that was good when we were working on display fields (long before highlighting, where it's used in this case) is that $c is duplicative of at least one of the various author fields in nearly all cases (and creates a suboptimal display in those very cases).

In contrast, when not using the display fields for OPAC display (that is, when there is no search-related URL component with which to drive highlighting, or when highlighting is actively disabled), all the fields come from hard-coded (and, in some cases, search-disrupting) field combinations. IOW, one of the benefits of using display fields is that they're also indexed in the same way they're displayed, so you can't build links that won't actually get you results. This is indeed often the case with series links on the record detail page using the old code, unless steps are taken in each instance to address the problem.

I think the most-correct way forward, to get the benefits of simpler configuration (no hard-coded xpath) and always-working links is to push toward using display fields for /all/ OPAC display construction, and not just when we can do highlighting because there's a query in play. Then sites can adjust their display fields as they see fit, highlighting always works, and everywhere that we show strings from records we do so in a consistent way. This would also let us move away from using UnAPI calls to get the record XML, which would significantly speed up OPAC rendering. I believe this is exactly one of the main reasons the new Angular staff search is so fast. (Bill, is that correct?)

FWIW, display fields are now used as the "simple record" reporting source, for the record summary in the web client (and various other places in the client), and in the OPAC when there is a search. Teaching the direct-record-OPAC view to use display fields is one of probably just a very few remaining non-display-field locations in the code now.

[1] http://www.loc.gov/standards/mods/mods-mapping-3-2.html#title

um... "Subfields included are: a, b, f, g, and k".

Hi Mike, yes the Angular catalog is using display fields instead of UNAPI for bib record metadata.

FYI, it is using UNAPI for the holdings summaries (the {holdings_xml} format).

One reason we want to see the 245c is for when the author's name originates from a non-roman alphabet. The authorized form in the 100 frequently does not match the spelling on the title page. We need to see both versions of the name represented in the public bib record display.

An example:
Maḥfūẓ, Najīb,$d1911-2006. (authorized romanization)
Naguib Mahfouz (as appears on the title page)

I'm gratified to know that we can configure the display locally to suit our needs.

SCLENDS is seeing this on 3.1, and we are also interested in having 245 $c display.

There appears to be a similar problem with query strings and multiple 505 fields. Only 1 shows up. I suspect the root cause is the same, but if everyone thinks this should be a separate bug, I'll make one.

Jason, I'd like to see the multiple 505 fields as a separate bug.
Thanks,
Janet

Insert the keyword entry and reingesting as suggest by Elaine Hardy in comment #2 does NOT fix the issue for me on an Evergreen 3.2 test system.

Hello, could I get a new paste of the config.metabib_field info from comment 1? The current paste seems like it was taken over by spam.

"http://paste.evergreen-ils.org/10003"

We are running into the fact that the ordering of the subfields in mods is not what we are used to.

Josh

Josh,

I'm attaching a text file with the config.metabib_field row that we added for statement of responsibility. It's the same as what's in comment 2, but possibly a bit easier to read.

Thank you Michele. I don't understand how adding the 245c to the keyword index changes the data that the display fields extract for the title entry. Is there any chance that there is another part to this, adding the responsibility display field info to the templates/opac/parts/record/summary.tt2?

Did you modify the config.metabib_field entry for title (id=6)?

Josh

I'm not sure if this bug is the best place for this, but we are also noticing that the displayfield title seems to sort the subfields alphabetically when it outputs them. Or at least doesn't follow the order that we are used to.

For example:
http://egcatalog.larl.org/eg/opac/record/330156

When viewing directly, the title is ordered like we expect, as well as including the 245c.
"Miles Morales. #2 : with great power / writer, Brian Michael Bendis ; artists, David Marquez, Pepe Larraz, Sara Pichelli ; color artist, Justin Ponsor ; letterer, VC's Cory Petit."

With a query, using the displayfield code, no 245c and the subfield n is placed after subfield b.
http://egcatalog.larl.org/eg/opac/record/330156?query=330156;qtype=keyword;locg=1;detail_record_view=0;expand=marchtml#marchtml
"Miles Morales. with great power #2"

The 245 looks like.
=245 10$aMiles Morales.$n#2 :$bwith great power /$cwriter, Brian Michael Bendis ; artists, David Marquez, Pepe Larraz, Sara Pichelli ; color artist, Justin Ponsor ; letterer, VC's Cory Petit.

The marc standard seems to say to me that the order should be
a.$n,$p$h[ ] : $b /$c.

So it looks like mods must use it's own ordering for subfields? I'm not sure if the mods standard doc is showing the order? So because the 245 $b comes before the 245 $n, the $b gets placed before the $n?

245 $a$f$g$k <title> with no <titleInfo> type attribute and
245 $b <subTitle>
245 $n (and $f$g$k following $n) <partNumber>
245 $p (and $f$g$k following $p) <partName>
245 ind2 is not 0 <nonSort> around characters excluded from sort as indicated in indicator value
[If $f$g$k follow $b they go with <subTitle>. If they follow $a they go with <title>.]

Thanks
Josh

I just want to chime in to reinforce what Mary Llewellyn (mllewell) said above: often the statement of responsibility (i.e the 245c) contains information that appears nowhere else on the record. In the case of foreign names it is often the only place where the name appears in a form that patrons will recognize.

Also, I really don't understand why whether there is a search query string or not should ever affect which fields should be displayed. This kind of inconsistency is confusing.

I agree with Mary and Benjamin that the statement of responsibility is often the only place where the author's name appears in the format that's on the book -- with names transliterated from non-Roman alphabets this is a major problem for readers. See the attached screenshot as an example. But even without language issues, the statement of responsibility often includes a version of that differs from the name authority used in the author field.

And it's true that a large percentage of books just have "by John Smith" in the statement of responsibility and that doesn't add much value, but there are also titles with statements of responsibility that add information and context: "by Lois Little, written in cooperation with the Madison Museum of Music, with an introduction by Harry Smithers, Director of the Museum, an afterword by Henrietta Lute, Curator of Stringed Instruments, and photographs by Jane Camerata."