Address "alternate_title" confusion

[jeremyf]

Based on an initial question:

Question: Why is the alternative title a hidden input field in the works edit form? (see
https://samvera.slack.com/archives/C0X9STKSP/p1589839711011900)

We have a commit that introduces "alt_title". It appears that the purpose of the "alt_title" is to help us treat "title" as a single field, but not lose any excess entries.

Looking at c2bc31326d, we see handling the excess. Later, in 854d66c0de we see that introduced alt_title properties is aligned closer to alternate_title. However, the alternate_title in the form-field does not appear related to alternative_title the metadata field.

This needs detangling. Further confounding the issue, when we look at the tags that contain the original @c2bc31326d commit we have:

v2.5.2
v3.0.0-rc1
v3.0.0.pre.beta3
v3.0.0.pre.rc1

Further digging, highlights that while there is a tag for v2.5.2, there is no minted version in rubygems.org for v2.5.2

What this means is that there are no production releases that include the confusion of the alt_title

[svogtunh]

A couple of other related issues that are still open: #4286, #2354. The issue referenced above related to commit c2bc313 is #3299 and there is no issue related to commit 854d66c.

[jeremyf]

From @jlhardes on Slack

That makes sense to use dct:alternative for these “extra” titles. There is a single primary title and any other titles are considered alternative titles. It’s not a subtitle or anything really additional. The fact that the field is a hidden field might be more to do with trying to transition away from having multiple title fields. As its own field using a separate property it doesn’t really need to be hidden from view - the hiddenness might be more connected to making the change backwards compatible?

[no-reply]

i'm not sure that the addition of dct:alternative frees us from the issue of a multivalued dct:title field in Core Metadata.

fields that are single-valued at the model layer are terminally fragile when implemented over Fedora. since Fedora doesn't have a concept of single-valued fields, any read-write cycle runs the risk of deleting arbitrary data for "single valued" fields. the work @blancoj did originally addressed this issue in order to support "single valued" titles for the form, even though the model still treats titles as multi-valued. i don't think pushing "extra" titles into dct:alternative can address this issue.

from a feature standpoint, Core Metadata with multi-valued titles is relatively easy to extend to handle language tagged titles; e.g.

<> dct:title "Comet in Moominland"@en .
<> dct:title "Mumintrollet på kometjakt"@sv .

making dct:title single valued at the model layer would make supporting this kind of language tagging for titles much harder for applications (and move us further from supporting it in Hyrax by default).

[jlhardes]

Is dct:alternative not actually being used for what was additional dct:title's previously? It sounds like multiple titles that were previously created are being managed in the form through the alternate-title form field but are not being stored as dct:alternative. Is that correct?

[svogtunh]

I think the standard (qualified dublin core?) should be implemented as far as titles and alternate titles goes. We need to be able to specify, store, edit multiple titles and multiple alternate titles. This means having those values in the edit menu so they can be input or modified, the same as the rest of the meta data.

Interpreting what that means, what to do with those fields, viewing them, displaying them is a completely different topic. Offer a basic display, 1 title - the first title input, alternate titles in a field display somewhere at the top of the object display. Whoever is using the application can modify that view to their needs.

My group uses alternate titles so I need to be able to input them and edit them. However, I don't know yet what that means in terms of the final displays.

[no-reply]

Is dct:alternative not actually being used for what was additional dct:title's previously?

that's right. what you see referred to as alternative_title in the form objects and views is a "virtual field" intended to ensure accurate round-tripping of title entries. it doesn't connect with dct:alternative in any way.

It sounds like multiple titles that were previously created are being managed in the form through the alternate-title form field but are not being stored as dct:alternative. Is that correct?

yes; previously created titles and titles created by tools other than the default Hyrax work form (e.g. batch importers, other software interacting with Fedora).

---

(this is where a product owner would be very helpful)

We need to be able to specify, store, edit multiple titles and multiple alternate titles. This means having those values in the edit menu so they can be input or modified, the same as the rest of the meta data.

a decision was made with the most recent round of Hyrax BasicMetadata revisions (cc: @samvera/hyrax-metadataists) to make the default forms treat title as a single-valued field. i'm hesitant to revisit that here.

i think the immediate, release-blocking scope of this ticket is to fix the implementation in Hyrax::Forms::WorkForm and any related view template code to use a name other than alternative_title for its internal hidden field.

does that seem correct?

[jlhardes]

I agree that it makes sense to leave title in the default form as a single-valued field and not make any changes to that field arrangement. Since the hidden field is for those additional titles (and is stored as additional dct:title's?), calling that form field something besides alternative_title (it actually is alternative_title and not alternate_title, right? I can't find alternate_title in any forms right now) also makes sense - maybe call the hidden field additional_title?

And if none of this is using dct:alternative, what is using that metadata property alternative_title that is connected to dct:alternative in https://github.com/samvera/hyrax/blob/master/app/models/concerns/hyrax/basic_metadata.rb?

[elrayle]

Comment by @j-dornbusch in PR #3554

This change breaks our instance because we previously had a multivalued 'title' field (with language support) and another multivalued 'alternative_title' field (with language support) based on dc: alternative. From a documentary point of view, 'title' and 'alternative title' are two separate fields, and each one is likely to receive several values in case of translation of the content. So the mechanism that copies a field into the other will cause problems over time if increased support of the multilingual is introduced.

[elrayle]

This is causing a breakage in our migration to 3.0. We do not include basic metadata in our work and collection models. So attempts set @attributes["alternative_title"] << value raise an exception because @attributes["alternative_title"] is nil.

I was looking at making a PR with a quick check for @attributes["alternative_title"].nil?, but ran into some complications. Observations...

• There are clearly outstanding refactor issues being discussed in this and other issues
• What happens when title has multiple values, but alternative_title is not included in the model? Are all the values except the one that sorts lowest with alpha-sort lost? If not, then sometimes title will be single and sometimes multiple. Not good.
• If this alternative_title is going to be in lock-step with title, then it should be defined in core_metadata along with title.
• Given the approach is to sort all titles and select first as the title, that means that what shows up as the primary title can change between edits if a title is added that is earlier in alphabetical order.

I'm going to monkey patch locally for now pending the results of this discussion.

[elrayle]

@no-reply I marked this issue as a blocker for the release of 3.0. This will cause technical dept that will complicate a potential fix in future releases. It would be best to have a definitive solution in place for this that addresses the concerns of the community prior to the 3.0 release.