Display each instance of abstract element on new line instead of concatenating

[arcadiafalcone]

Abstracts are often a prose paragraph of complete sentences ending with a period, so concatenation is not appropriate. Per LC MODS guidelines, this field is repeatable, and in particular MODS records converted from MARC may have multiple instances of the abstract field.

Purl concatenates with no delimiter: https://purl.stanford.edu/fr878dp2426 Spotlight metadata modal concatenates with comma space: https://exhibits.stanford.edu/time-travel-japan/catalog/fr878dp2426

Overall, the goal is to get consistent display across applications (e.g. Purl, Spotlight, and SearchWorks).

[caaster]

The gryphon search team approves moving forward with the abstract and note fixes. Here's what Arcadia presented to them:

1. Allow users to specify line breaks within abstract and note values, and respect those wherever MODS is displayed in our systems (sample use cases: entering multiparagraph text, quoting multiple lines of verse, providing lists such as exhibition history that are much more readable on separate lines). (This is #78)
2. Consistently concatenate multiple instances of the abstract field with a blank line between them for display, as multiple instances of note currently are (sample use cases: multilingual abstracts, abstracts from multiple sources). (This is this issue)

This is one example, that has line breaks in the original abstract that are not displayed on the PURL: https://purl.stanford.edu/xh643gr2981

[anarchivist]

@cbeer mentioned that this specific case 1) has been documented in our existing MODS validation and normalisation rules, which suggests a particular solution (encoded in hex character references as 
 or 
. This seems like it was implemented in Exhibits already as sul-dlss/exhibits#2032.

Is the assumption that this should be consistent across all our discovery/display applications?

[caaster]

For the question above from @anarchivist -- I think the answer is yes. @arcadiafalcone -- could you please verify? Thank you.

[anarchivist]

Thanks @caaster - I'll also note that the object referenced above does not contain linebreaks in the form described in the rules I linked.

[arcadiafalcone]

@anarchivist @caaster For this specific ticket, it's not about line breaks entered by the user - it's about how the code concatenates multiple instances of the <abstract> field. But yes, consistent display is the goal.

[anarchivist]

@arcadiafalcone Got it, thanks. The additional context led me to be a little confused about this. Do we need a separate ticket about the user-entered linebreaks?

[arcadiafalcone]

@anarchivist There is a bare-bones ticket for the internal line break issue: https://github.com/sul-dlss/mods_display/issues/78

[caaster]

This is where I start to get lost and need some assistance. I am uncertain what else I should be doing to facilitate: specifically, is there additional information I should be gathering? @anarchivist @arcadiafalcone

[anarchivist]

@caaster Nothing is needed on this ticket. #78 needs more detail, but that can be done separately.

[thatbudakguy]

@arcadiafalcone just to make sure I understand — is the current behavior in the exhibits modal wrong? I see the abstract for https://exhibits.stanford.edu/time-travel-japan/catalog/fr878dp2426 as two paragraphs:

which matches SearchWorks.

[arcadiafalcone]

It's still concatenating on purl (see https://purl.stanford.edu/fr878dp2426), but that may be the only place.

[thatbudakguy]

looks like this is fixed in purl UAT: https://sul-purl-uat.stanford.edu/fr878dp2426. if someone knows an item with multiple contents values we could test that too, otherwise I think this can be closed and i'll deploy to production.

[thatbudakguy]

fix is in prod.