Potential simplification of additional titles/descriptions

[fenekku]

We could potentially collapse additional_descriptions and additional_titles fields into a descriptions and titles fields resp. if we build an indexing hook (or other means) to allow description=mySearchTerm and title=mySearchTerm to still be valid search box searches.

[tmorrell]

Sounds like a good plan for a future improvement. It would make the metadata easier to understand and make the deposit form simpler.

[ppanero]

The main issue behind the two fields is developer/UI experience. If you have 10 titles? How do you know which one to display? we would also need to perform many many extra loops... IMHO this simplifies things a lot. What do you think?

[fenekku]

The first description and title in the array should be the main one (with the caveat of the type). Others would be placed according to types. This will take additional logic for sure.

[tmorrell]

We might want to tread title and description differently. I agree that the UI for multiple titles is tricky, and we don't use them. We use multiple descriptions for a lot of our records. They just get listed in the order they are in the metadata, similar to how authors are treated.

[saragon02]

Alternative titles I believe are not as common as multiple descriptions of various types. I like the idea of the first title in an array serving as the main title, with the others serving as alternative titles. The type can be "alternative" unless more specific type designations are warranted.

[lnielsen]

A couple of points:

• This schema is the internal JSON storage format - it is not the JSON structure exposed on the REST API, and it doesn't impact how the deposit forms will show.
• The code becomes dirty with lots of for-loops and all code has to deal with the possibility of a zero-sized list, and/or all access to e.g. the title becomes record.title[0] (thus we're encoding semantics into that the first title means the primary title.
• Developers will inconsistently choose which title/description to use in the code.

Above is based on experience with MARC21 in Invenio v1, and putting it all together has a huge impact on the code architecture, so I'd like to say with the current design of a primary title and primary description (and a list of additional).

Again, this is the internal storage formats and it doesn't change what RDM will expose via APIs or what RDM is capable of storing.

[fenekku]

I defer to that experience. I am fine with staying with the split between title and additional_titles. Let's close this by end of day if no one else feels strongly about keeping it.

[fenekku]

We will keep as is because it turns out to be fine. Closing!