exhibits
exhibits copied to clipboard
sul-dlss
Display repeated instances of the same field on separate lines
Story: Using multiple instances of the same element to structure information indicates that each instance is a distinct unit. Concatenating these units into a single sentence regardless of their individual content or internal punctuation blurs these distinctions, and is more difficult for the user to parse. Exhibit creators would like to display each instance on a separate line for greater clarity.
Acceptance criteria: Each metadata value indexed individually to a field should appear on a separate line in the item display.
How can we delineate when something should delimited by a comma vs a separate line? This has potential implications on how the page displays and could have unwanted side effects. For example, if an item has many subjects, should these all be separate lines?
Do we have some concrete examples of metadata where/why this is needed?
I think there are a lot of design implications here and would defer to @ggeisler on how to handle this.
This issue has been resolved for the case of repeated notes (#715).
To deal with other fields, do we know which other fields are candidates for repeated instances? We have a couple of potential patterns in use that could be applied for repeated instances of the same field:
-
The pattern used for notes, where there is one field label (e.g., "Notes") and the repeated values displayed in a
ul. In this case, all values are displayed. -
The pattern used (in progress, I think) for the text title field (table of contents) where it is a single field but has many values, separated by a
-(I think). In this case the plan is to put all the values in a expand/collapse structure, so that there is a single field label and the initial field value is "Show". When clicked, all values are displayed, each on its own line. The list can be long, but initially it isn't shown, and when shown it can be collapsed back to the "show" link.
I'm hoping we can stick to using one or the other of these patterns for other cases but I think we might need to be specific about the potential cases so we can decide which pattern might be most appropriate for each.
An overview of fields in MODS that may have multiple values.
More common:
- Alternative title (cf. Parker)
- Name/role - names per record, names per role, and roles per name
- Genre
- Date - different date types within a single originInfo element, and multiple originInfo elements with non-contiguous dates or different event types
- Place of origin - multiple within a single originInfo element and multiple originInfo elements with different event types
- Language
- Physical description note
- Note
- Subject
- Identifier
- Related item
Less common but possible: translated title, type of resource, publisher, and form.
@ggeisler For context, the two display patterns you mention are based on two different underlying data models -- for the notes, each appears in a separate <note> element in the MODS XML, where as the items in the contents list are all contained within a single <tableOfContents> element, hence the need for an internal separator. That second data model is unique to the <tableOfContents> element.
I think the only elements in the list above that would approach the Parker tables of contents in terms of length are name, note, and subject (and related item, but that's being addressed separately). Ideally names would be separated out by role (see #546), which would break them out somewhat.
Very helpful @arcadiafalcone, thanks. I'll work on recommendations for displaying these fields at some point soon, unless @jvine thinks this fits into the work I discussed with her today about enhancing the MODS Display gem to show additional fields (#799).
(Although some of the fields @arcadiafalcone lists are indexed fields in Exhibits so we will need to think about how to display repeated values of those independent of what we do in #799, which is focused on the MODS display. Though the solution could very be identical in both contexts.)
Please use the MODS display rules at https://consul.stanford.edu/display/chimera/MODS+display+rules as a guide as it states current requirements. For the issue with https://purl.stanford.edu/jj501yz7689, where we see
FORM
sound recordingsound recordingsound disc
instead of
FORM
sound recording, sound disc
or
FORM
sound recording
sound disc
this is already a bug per the spec, which says "Show unique values (cast out duplicates) together on one line separated by comma-space". (https://github.com/sul-dlss/mods_display/issues/33)
On a related note, I observe that while Searchworks shows
