Citing a dataset

I'm trying to cite a dataset using APA 6. I've stored the item in Zotero with {:itemType: dataset} in the Extra field (per This should change the item type so that it formats correctly, but this doesn't appear to be the case.

I'm getting:
Dries, N. (2015). Correlations of new career orientations with career outcomes.

I expect:
Dries, N. (2015). Correlations of new career orientations with career outcomes [Data set].

Storing other variables in Extra (e.g., {:medium: } )formats them correctly. This problem occurs both with and without the Propachi plugin enabled. Does citeproc-js not override an item's type with "dataset" if this is specified?
  • the style is correct, you've checked that?
  • Yeah. The style has several different formatting bits in the code, and it looks like it should come out right. None of the conditionals testing for dataset work (they always get treated as the original item type). Is the Extra itemType hack working on your end?
  • Oh, I found where this was discussed. It is a change in how citeproc-js parses variables from extra.
  • Is it working now?
  • edited December 18, 2015
    There hasn't actually been a change in the way citeproc-js parses the Extra variables; in that thread, I just described the existing behaviour.

    My initial thought was that the itemType should be an exception to the no-overwrite-of-existing-data rule, but on reflection I think that may not be a good idea.

    When Zotero fields and item types are extended, it would be best to map existing entries in the Extra field to proper Zotero database fields. For ordinary fields, dates, and names, that can be done losslessly - if a valid target field exists, the data can be moved there; otherwise the entry can be left in the Extra field, and citeproc-js can continue to pick it up from there.

    If any item type can be overwritten with an arbitrary replacement type, the fields contained in the target type (say "dataset") would be indeterminate. If the item type later becomes available in Zotero, data might be lost (or database breakage might occur) when the entry is forced to the new type.

    I think item type changes might be a bridge too far for field-level hackery. If that is enabled, it should be done in a way that guarantees a smooth migration when the target type is permitted by later schema upgrades.
Sign In or Register to comment.