Add label attribute to names schema

[bwiernik]

Used to override the default label rendered for a role.

Following the discussion at #293 and https://forums.zotero.org/discussion/84042/tromso-recommendations-for-citation-of-research-data-in-linguistics this lets a user enter a more specific role label without requiring such things to have their own variable types. For example, a linguist might cite the person whose speech they are studying as an author with label: "speaker".

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

[denismaier]

That looks really useful, and I'm absolutely in favor of adding this.

How will that look like in practice? Will you be able to enter "verb" forms of a label?

[bwiernik]

How will that look like in practice? Will you be able to enter "verb" forms of a label?

That is a good point.

[denismaier]

This here could work:

            "label": {
              "title": "Non-default label to use when rendering name",
              "description": "Overrides the default label for the role. e.g. to indicate a subtype of a role or specific MARC or CRediT roles."
              "verb": {
                "type": "boolean"
              },
},

But, of course, this will only allow one or the other. Don't know if both are needed...

[denismaier]

Also, don't we need a "type": "string" here?

[bdarcus]

Also, not sure how this happened (seemed to happen with the last merge I did), but there are multiples places where the $ref syntax got screwed up. We need to add to the python test code to catch these problems in the future.

You can fix by find-replace #definition -> #/definition.

[bdarcus]

Yes this being locale-specific may be an issue. But I assume @bwiernik has already an idea how this could play nicely with #240

He mentions this in this comment, which I missed earlier.

How does this PR relate to the idea in that comment @bwiernik?

Is this really an uncontrolled term name?

Notwithstanding the question of whether to add an enum of controlled values, should probably have a regex pattern to constrain it to a token?

Edit - here's the full MARC list as linked RDF data.

http://id.loc.gov/vocabulary/relators.html

Example:

http://id.loc.gov/vocabulary/relators/abr.html

SKOS RDF:

<rdf:RDF xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/1999/02/22-rdf-schema#" xmlns:cs="http://purl.org/vocab/changeset/schema#" xmlns:skosxl="http://www.w3.org/2008/05/skos-xl#">
  <rdf:Description rdf:about="http://id.loc.gov/vocabulary/relators/abr">
    <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
    <skos:prefLabel>Abridger</skos:prefLabel>
    <skos:definition xml:lang="en">A person, family, or organization contributing to a resource by shortening or condensing the original work but leaving the nature and content of the original work substantially unchanged. For substantial modifications that result in the creation of a new work, see author</skos:definition>
    <skos:notation>abr</skos:notation>
    <skos:inScheme rdf:resource="http://id.loc.gov/vocabulary/relators"/>
  </rdf:Description>
</rdf:RDF>

[bdarcus]

Does anyone have any concerns about this being locale-specific? We earlier discussed possiblity of a role or type attribute, with a controlled list, that I imagine would be quite long (say based on the MARC list).

[denismaier]

Yes this being locale-specific may be an issue. But I assume @bwiernik has already an idea how this could play nicely with #240

[bdarcus]

I mean, keep in mind CSL JSON is already being used as an exchange format, which I expect will increase in the future.

[bwiernik]

I think we perhaps defer this to 1.2?

[bdarcus]

Where do we stand on this now? Seems there's some uncertainty.

[denismaier]

Well, we've deferred this to 1.2

[bdarcus]

Well, we've deferred this to 1.2

Seems like maybe we should close this then without merging, given we don't have a target branch, or an idea of what 1.2 would be?

Alternately, we need a target branch, but I worry that gets a little complicated.

[bwiernik]

I'm happy to add it to 1.1 if you think that's reasonable.

[bdarcus]

I'm happy to add it to 1.1 if you think that's reasonable.

Before considering that, can you address this concern I raised?

#337 (comment)

[bwiernik]

I suspect this would be used in 2 ways:

1. With a syntax like term:cartographer indicating that the CSL term for "cartographer" should be inserted and localized. I would like this syntax to exist for other use cases as well (eg, to enable controlled vocabularies for status or allow styles to specify the terminology used for preprint/working paper or distinguish between podcast/tv broadcast/radio broadcast without needing more types). I don't know that there would be that many additional terms beyond the roles we already have. The major citeprocs do support off-schema terms to be specified in a specific style file's locale section for unofficial user usage.

2. Very user-specific labels (eg, we've had requests for CrEdit taxonomy roles and for the ability to describe sources of Indigenous Oral History). I would like to support this as an option, and I am not too concerned about localization here.

[bdarcus]

I suspect this would be used in 2 ways:

1. With a syntax like term:cartographer indicating that the CSL term for "cartographer" should be inserted and localized. I would like this syntax to exist for other use cases as well (eg, to enable controlled vocabularies for status or allow styles to specify the terminology used for preprint/working paper or distinguish between podcast/tv broadcast/radio broadcast without needing more types). I don't know that there would be that many additional terms beyond the roles we already have. The major citeprocs do support off-schema terms to be specified in a specific style file's locale section for unofficial user usage.
2. Very user-specific labels (eg, we've had requests for CrEdit taxonomy roles and for the ability to describe sources of Indigenous Oral History). I would like to support this as an option, and I am not too concerned about localization here.

Right now, the PR only applies to the JSON, with a new property that is just a string, without any examples.

Don't we need a more comprehensive solution before actually merging it?

I support the basic idea, but seems there are details to sort out?

cc @cormacrelf

[bwiernik]

The basic detail is, when a name object contains a label element, that element overrides the label that would be generated based on the role term. That would be described in the specification

[bdarcus]

The basic detail is, when a name object contains a label element, that element overrides the label that would be generated based on the role term. That would be described in the specification.

That's simple and clear enough. But isn't it inconsistent with how we handle this sort of thing everywhere else?

E.g. it's a completely uncontrolled string, that can't be localized.

Or does that not matter in your view?

PS - Except I'm unclear how the "term:x" thing fits. That seems another detail.

[bdarcus]

I do think you should add "examples" here, as you see elsewhere in the schema.

[Quintus]

Just chiming in in order to support this PR. In German law discipline, we often cite established collected works by their founding editor. For this, labelling the editor as “founder” and being able to check for that would be very useful, as in the bibliography one needs to distinguish between current editors (abbreviated as Hrsg.) and founding editors (abbreviated as Begr.).

I was directed here from this forum post.