Convention on casing of category names

[giorgiosironi]

Implies to verify the behavior of filtering APIs on scholarly-content-detail.

Scenarios

• [ ] Biochemistry and Chemical Biology is in the scholarly-content-detail service, Biochemistry and chemical biology is in the XML, what should happen? It should found with case-insensitive matching, and normalized to what is already in the service (Biochemistry and Chemical Biology),
• [ ] what value should show up in the frontend? The value that is in the service
• [ ] should these conventions be extended to e.g. article types? Not for now, we will deal with that in a separate milestone as they may have more stringent rules deriving from values that are made standard at the JATS level.
• [ ] the service should never apply transformations to values such as lowercasing or uppercasing letters, as there are too many variations such as title casing to take into account.

See also https://github.com/microsimulation/ijm-xml/issues/151 where we try to avoid most of the inconsistency by making the typesetter fixing the XML before we use it. Can't guarantee we will always be able to do this.

/cc @FAtherden-eLife

[fred-atherden]

Biochemistry and Chemical Biology is in the service, Biochemistry and chemical biology is in the XML, what should happen? Accepted and normalized, or error?

I would expect a slugified version of the subject element value to determine what is distinct or not - in other words Biochemistry and Chemical Biology and BIOCHEMISTRY AND CHEMICAL BIOLOGY would be identical.

what value should show up in the frontend?

I see there being three options:

1. Display the value in either all upper or lowercase so as to ensure there are no differences caused by this (what eLife currently do)
2. Allow the Publisher/Journal to set how they want subjects to display (based on their slugified id - i.e. subject supplied as BIOCHEMISTRY AND CHEMICAL BIOLOGY, slugified to biochemistry-and-chemical-biology, and any ids with that value displayed as Biochemistry and Chemical Biology)
3. Default option 1 but also allow option 2 in the configuration

should these conventions be extended to e.g. article types?

It would make sense to use similar logic, I think, given that the data (XML) will be provided in the same format, and will bring the same challenges.

CC @Melissa37

[Melissa37]

I agree with what @FAtherden-eLife has suggested.

• Normalise capitalisation of content from the XML - based on publisher requirement (needs to be configurable whether displays all caps, sentence case or camel case)
• Actual spelling errors cannot be caught by hosting system - journal production should be responsible for that, but if a spelling error generates a new category and resupply should remove the incorrect one

[giorgiosironi]

all caps, sentence case or camel case

Do you mean Biochemistry and Chemical Biology as sentence case? There is no generic algorithm that I know of to reliably generate this from a lowercase version.

[Melissa37]

Do you mean Biochemistry and Chemical Biology as sentence case? There is no generic algorithm that I know of to reliably generate this from a lowercase version.

No, that's camel case (ie a camels hump goes up and down :-))

Sure, makes sense that it's input in defines that

[giorgiosironi]

Updated description with results from call today.