[Feedback CSL 1.0.2] Media roles

There are several new “media roles” introduced in CSL 1.0.2. For example the very generic “creator” or “writer” besides the already existing “author” role. Moreover, “host” and “guest” are very generic as well. AFAIK all variables including the name roles can be used´in CSL-JSON for any publication type, i.e. there is no mechanism which will restrict these new roles to media types only. In the final schema there also no hints about how to use these variables.

I would envision that a new software engineer which wants to implement CSL in their software has it a lot harder if s/he just sees all these possibilities for creator/contributor types. For example if I want to model data for a book according to the CSL schema, then I can take “author” or “creator” or “writer” which IMO would all look fine for a book. (Moreover, there will also be slight semantic changes when these terms have to be translated.)

One possibility for “writer” is to use the more specific term “screen-writer” or “script-writer” (=Drehbuchautor) instead. In German there is also “Studiogast” which is more specific as only “Gast” (=guest) but I don’t know if you have something similar in English as well.

1 Like

These will all be described in the spec; there isn’t much documentation of anything in the schema itself, so unless that structure is changed, a developer will likely need to consult both the schema and spec.

Clearer names is a good idea. script-writer is good. Perhaps series-creator, series-host, series-guest? Creator is generally going to refer to creators of TV or radio serials, so that’s a good fit. Host and guest might conceivably be used in, for example, a standalone documentary film, but I think series-host/series-guest is probably still fine there.

1 Like
  • script-writer: :white_check_mark:
  • series-creator: Okay, would work for me. :heavy_check_mark:
  • host or series-host: The series-host looks strange for me and I might want to prefer host here. I only mentioned here that host is generic, but it could be even okay as it is. Host and organizer as well as chair is very similar in their meaning. Do we need all of them?
  • guest or series-guest: It looks like I haven’t understood you correctly here, at least series-guest sounds different to a talk show guest which I had in mind. Did you have something else in mind?

I think a talk show guest, a guest expert on a podcast, and similar would all fit under guest.

Host is host of a series, like a podcast or radio show. Not related to organizer or chair at all.

But the host of a conference does also work, right?

I am intending to add annotations, including hopefully examples, for all variables to the json/yaml schema.

1 Like

@Phillipp_Zumstein Yeah, I think that would be fine if they were both labeled as “Host”. For creators, I think the major question comes down to what label is used. When two types of creators call for distinct labels, they should probably be a distinct variable. “Organizer” and “Chair” are both potentially conceptually distinct (e.g., a “chair” of small symposium session within a conference is not necessarily the organizer; an organizer might not be a “chair”) and they have different label needs.

I feel that in some ways CSL is reinventing the wheel when it comes to roles. I would like to see MARC Relator roles added to (or aligned to) in CSL: https://www.loc.gov/marc/relators/relaterm.html I know that in linguistics there are two influential efforts to make these roles more accessible in citations.

MARC roles for instance have codes (great for localization), and as far as I know are used in the various library systems in national libraries (archives) and have been translated in to 20+ languages https://www.loc.gov/marc/translations.htm (link to translation of the whole MARC standard not just the roles).

To the point of the issue with host and it’s semantics, both the host of a show and the host of a conference (in the sense of an organization) are in MARC relators. @Philipp_Zumstein @Bruce_D_Arcus1

“Reinventing the wheel” is a bit of a loaded term that suggests (to me at least) that we’re ignorant of the existence of MARC, which is not the case.

The first implementation of CSL, in fact, used MODS as the input format, which was effectively an XML version of MARC.

But in citation oriented formats, contributors roles are top-level relations, while in MARC and MODS, they’re a property of names IIRC.

We have discussed the possibility of subtyping some of the core relations, though, and presumably that might work here too:

author:
  -
    role: primary
    name: Jane Doe

Is that what you had in mind @HughP?

Bruce, I didn’t mean to insinuate that anyone was ignorant. I’m sorry my message came across that way. Let me try and make my comment a different way. I was reading though this thread, with a eye on the following part of the conversation:

Can someone help me understand why the engineers here would choose additional labels for roles, instead of using the labels in a standard like MODS/MARC – specifically the relator roles? My understanding is that in many cases (if not all) the semantics of what the labels represent in CSL and MARC is the same. What I am perceiving here is that MARC relators have one string, while CSL will use a different string to both refer to the same semantic content. Why not keep the strings the same, or use the MARC code?

FYI: sub-typing of roles is tangential to my comment. Personally, I’m not a big fan of gradient roles. But I do foresee the need to use MARC relater roles like ‘speaker’ on an item which is textual (paper).

No problem; no offense taken.

I guess I don’t see why we would use the MARC terms or codes. MARC is for library cataloging, while CSL is for citation formatting. Clearly they’re related, but they do have different purposes and priorities.

And the data applications in this space are typically using is not coming from MARC, but from citation-oriented formats like BibTeX and RIS.

So practically speaking, we started (~15 years ago) with the roles in those formats, and added new ones as users requested them, only adding if there’s a demonstrated need for purposes of citation formatting.

CSL was also developed alongside Zotero, and adding a long list of library-oriented roles to its GUI would have been a non-starter.

In retrospect, 15 years later, one might ask the question, but I’d turn it around: why should it matter whether we have the same, or a different, list of contributor relations?

And what, practically, should we do about it now, when we have a large legacy of styles, libraries and applications?

Are you suggesting we change all our existing terms, for example, and add the rest?

Or are you really just saying, when naming new contributors, we should consult the MARC list?

Just trying to understand.

Thanks for taking the time.

I am minimally saying that “when naming new contributors, CSL should consult the MARC list and pull from that when possible.”

Renaming legacy code can be a challenge. I’m not sure how much “cost” there on the whole ecosystem of tools which use CSL with respect to renaming, simply for continuity. So I don’t have a clear picture on what to do about legacy.

About adding all of the relators in MARC, I know that Zotero and CSL have an intertwined, but independent development paths.

I do know that recommended citations formats coming from the academic fields of language documentation, linguistics, and language archiving, are pushing for richer role declaration in the citation of materials – especially raw data formats (audio, video, photographs, data sets, annotations, etc). The recommendations from these communities is to just use MARC relator terms like one would for ‘editor’.

Something like this:

Zavala Maldonado, Roberto (Researcher), Juan Gervasio (Speaker). (1986). “Juan Gervasio”. MesoAmerican Languages. The Archive of the Indigenous Languages of Latin America: www.ailla.utexas.org. Media: audio. Access: restricted. Resource: COK002R003.

How these pan out inside of the Zotero UI, is really a Zotero issue. However, if Zotero is hamstrung because CSL doesn’t have the ability to reference a certain MARC relator, then that is really a CSL dev issue. — So, my request is both, pick when possible new role titles from MARC relator roles, and build the capacity to have any MARC role in CSL.

This is where I thought that maybe using the three letter relator role code might be advantageous, because of its ability to allow for localization. But using codes like that may be against the design philosophy of the CSL project.

1 Like

CSL is localized. The english tokens are, from a processing perspective, equivalent to a code, but human readable.

If you have suggestions for specific missing contributor roles, let us know.