User defined authors' attribute field

In bibtex there is the `authortype` field which allows users to define their own authors' attribute, which can be incorporated into the csl style as part of the citation data.

This makes it convenient to cite Chinese books and articles, in which there are many different types of authoring, such as being a 'commentator' (注), 'exegete' (疏), `copy-editor who punctuates ancient text` (校點) etc.

Currently, Zotero uses a limited drop-down list to define different forms of authoring, one of which is a generalized `contributor` field tag, which is converted to bibtex as:

```
editora = {{Name-of-editor}},
editoratype = {collaborator}
```

This is the only entry that makes use of the authors' attribute field available in bibtex, but the attribute 'contributor' is too general to be of use when it comes to actual citations.

Is it possible to incorporate a user-defined authors' attribute field in Zotero so that the myriad roles of the author can be recorded and cited easily?

My current work around is to add the attribute directly behind the author's name, sometimes separating the two by using the `last name` field for the author's full-name and the `first name` field for the attribute, which is very bad practice, from a data perspective.

Really hope that this new feature can be considered for future Zotero updates.

Thank you!
  • I am transferring this discussion over to the Zotero types whiteboard.
  • Discussion here makes more sense.

    @emilianoeheyns Is there a way to access the authortype field through BBT?
  • It's possible to generate an authortype field using BBT (either by using the custom fields syntax or a postscript), but the source data doesn't have enough information to generate it. It's easy enough to change the editoratype in a postscript, but unless we think of a way to add author metadata like exegete to the extra field, I wouldn't know how to make this decision in code.

    Adding the metadata in the extra field does not seem easy though. By author name (sth like authortype[Heyns, Emiliano=exegete]) means double entry and pretty fragile (bad), by position (sth like authortype[3=exegete]) is very fragile (also very bad), storing the metadata in the author name could work but would then only work in BBT because I'd parse it out, and it would also be moderately fragile (bad).
  • edited June 26, 2018
    My own thinking of the issue is elaborated over here:

    https://github.com/citation-style-language/zotero-bits/issues/82#issuecomment-400202631

    Having an empty `attribute` or `metadata` field that goes with each author/contributor entry, to be included as part of the CSL `author` variable should solve my problem.

    I agree with @emilianoeheyns that adding author metadata to the extra field is a bad idea.
  • I'm OK with a method like that, but I'd much prefer something that makes it explicit what metadata is being hidden there, something like "[authortype=疏]" in the firstname field, which would then (I assume) mean "treat lastname as single-part name, user metadata from firstname". Or something like '<script type="metadata">{"authortype": "疏"}</script>. (how do I do inline <pre> on this forum again?)

    Both pretty ugly though, and if citeproc isn't on board, it would make Zotero bibliography a real mess. And if citeproc is on board, Zotero likely will just pick that up in the UI rather than having to use these kludges.
  • edited June 26, 2018
    Does this mean we'll need to get citeproc on board to make this happen? Would it be easier to get CSL to add an 'authortype' variable to each pre-defined role?

    Any hopes of getting this feature added in the upcoming massive upheaval (update?) of Zotero fields and item types?
  • It's not strictly required, but if citeproc is on board Zotero is likely to be on board and I have a standard behavior I could follow. Zotero could get on board without citeproc, but the possibilities would be limited, and in my experience Zotero eschews these kinds of kludges (for good reason).

    It would still be possible to do it just in BBT, but I'd like to know what the Zotero devs think of this regardless. I have a strong preference to do things in such ways that they fall in line with planned or existing behavior of Zotero.
  • edited June 26, 2018
    Yes - I support your preference as well. Let's just wait and see what the Zotero devs have to say about this. And whether the is any chance to get CSL on board. I suspect the advantages would not be limited to Chinese citations - but we'll have to leave this for other users to comment.
  • Custom Fields are planned in the mendium term (I believe around 5.2 or 5.3). Custom creator types might be possible then, but how it interacts with citations is a complex problem.

    Supporting this in CSL requires some major changes and a big departure from existing language philosophy. I don’t think it’s likely for citrproc to try to address this because it is way outside the existing scope of the CSL spec of even the CSL-m extension.
  • edited June 26, 2018
    @bwiernik, does this mean that meanwhile, all we can do is to possibly work with 'something like "[authortype=疏]" in the firstname field', as proposed by @emilianoeheyns in his earlier comment? It certainly looks better than my present workaround. (At least I can then separate author's name from its metadata and get that parsed into the corresponding fields in Bibtex.)
  • No, that doesn't currently work. It would have to be implemented in BBT. It's not a trivial change either, so I'd really want to know how Zotero intends to approach this first.

    Of course just about anything can be done in a postscript, even the bracket-hack.
  • I would honestly recommend doing any of this in the meantime through Extra, rather than trying to cram things into existing author fields, as the latter will break with anything but BBT output (even if BBT supports it).

    Zotero and citeproc-js support creators in Extra like follows:
    Editor: Last || First A.

    Adapting the citeproc behavior to accommodate BBT-specific authortype information would be fairly straightforward I believe (e.g., putting it in {} after the name, which currently breaks citeproc recognition of CSL variables, but that could be adjusted).

    @fbennett Any thoughts? What was the reason for requiring all CSL fields to be at the top of Extra and contiguous, rather than extracting from any line?
  • That format is much better, and easier to parse too. Main issue right now is that it'd need a marker that it is a author-type line. "Editor" has a fixed meaning, but "疏: Last || First A." does not.
  • BBT also supports the "Editor: Last || First A." format BTW. Adding more flexible author fields will be a bit of work though.
  • A fairly simple approach would be a format like:
    Creator: Last || First A. || Type

    If these are placed after after any proper CSL variables, citeproc-js will still be able to pick up the other CSL variables stored in Extra, then ignore the BBT-specific fields.
  • If someone wants to open an issue at https://github.com/retorquere/zotero-better-bibtex/issues I'm willing to give that a crack
  • edited June 26, 2018
    @Rainshoots Can you open an issue? This isn't personally a concern for me, so you would be better able to comment and test.
  • @bwiernik and @emilianoeheyns, Thanks for the suggestions! I'll give it a shot.
  • edited June 26, 2018
    Would the Extra field be able to hold multiple custom fields, by the way? I am currently using some of my Extras for the original-date field.

    Also, I would probably be entering multiple Creator: Last || First A. || Type strings that overlap with the original Creator data. Would this pose a problem?

    It would be pretty weird to leave the original Author field blank and keep all the Creator data stored in Extra.
  • Extra can hold as many fields as you want so long as each is on its own line and all of the CSL variables are at the top of the field (with at most one non-CSL variable before and none intervening between CSL variables).

    Presumably, you would store any possible variables in the actual Zotero fields (e.g., author, editor, translator), and only use Extra for variables that don’t have an appropriate Zotero field.

    If all of the creators for an item would be stored in Extra, you could doubly enter them as Contributor in Zotero (these don’t get passed to citeproc-js; not sure how BBT handles them).
  • I have found a working solution to my own problem based on @bwiernik 's last comment.

    https://github.com/retorquere/zotero-better-bibtex/issues/1002#issuecomment-400480797
Sign In or Register to comment.