Extensions to `name` data: `label` or `alternate-name` + `role`

CSL Evolution
1

tl;dr: I suggest we add alternate-name and role elements to CSL name variables. Alternatively, a generic label element for name could fill both functions and be less disruptive to existing styles and processor behavior.

There are a couple of name formatting requirements for APA style that either (1) aren’t currently supported by CSL, or (2) currently work using off-spec (I think) behavior in citation processors.

  1. Alternative names (e.g., usernames, alternative script names, inferred names): Usernames for online materials should be provided in square brackets:

  • APA Style [@APA_Style]. (n.d.). Tweets [Twitter profile]. Twitter. Retrieved November 1, 2019, from https://twitter.com/APA_Style

    The same formatting is also used for things like names in the original script if the name is translated or transliterated or inferred authors for historical materials.

  1. Role labels: In some places, APA wants more descriptive role labels than I think we would necessarily want to provide terms for (e.g., “Host” for podcasts, “Guest” for broadcasts, “Creator and Director” for some TV broadcasts).

Currently, with citeproc-js (and pandoc-citeproc I believe), alternate names and roles like this can be approximated by adding them in brackets/parentheses following the creator given or family name (depending on the style). The processor applies style’s family name formatting to the first word in the brackets and the given name formatting to subsquent words. This works for adding a role like “Host” and can be made to work with multi-word roles/names using joiner characters. However, it doesn’t really work for corporate/single-field authors, and it interferes with correct formatting of names like Park || HyeSoo (Hailey), which should be rendered as Park, H. (H.) but currently renders with citeproc-js as Park, H. (Hailey).

I suggest that we expand the fields that can be supplied in CSL-JSON names to include alternate-name and role elements. A simpler solution would be to allow a label element to be provided that would override the automatic label rendered for the creator. This option would be less disruptive to existing styles and the only drawback would be requiring users to enter the punctuation manually (perhaps with parentheses being used as a default unless other brackets are provided).

Clients should provide a UI field for name labels. We could also devise a syntax for parsing labels two-field names similarly to how particles and suffixes are handled (e.g., separate given name parts and the label with a semicolon).

Processor behavior for name text entered in brackets/parentheses should follow the formatting rules for the rest of the name (e.g., abbreviated if entered in the given name field).

1 Like
2

That’s a worthwhile suggestion.
I’d prefer the more involved solution with alternate-name and role elements. This is more complex than a simple label element, but in turn also far more flexible. (Different styles can have different requirements regarding roles and alternative names. If you’re only using one particular style, that’s not much of an issue, of course. But changing citation styles might involve changing item metadata, which should be avoided if possible.)

3

It might be best to add alternate-name and label elements. The label would override the automatic label (e.g., “editor”), the alternate-name would need to be called by the style in the name element.

1 Like
4

Ok, great. So, what shall we do about it now? Do you think that this can be targeted for 1.1? Or should that be for later as this has a bit more far reaching consequences?
Looks like we’re again in the same situation here as with other proposals. We need a decision making process.

5

I wrote a proposal here https://github.com/citation-style-language/csl-evolution/issues/29