Setting the item type via the “cheater syntax”

[njbart]

citeproc-js accepts setting the item type via the Extra field “cheater syntax” (see https://citeproc-js.readthedocs.io/en/latest/csl-json/markup.html#value-formats), e.g., type: dataset or {:type:dataset}.

BBT, it seems, does not parse this correctly.

Actual biblatex output from an entry containing {:type:dataset} in the Extra field:

@article{doe_title_2016,
  title = {Title},
  author = {Doe, John},
  date = {2016},
  note = {\{:type:dataset\}}
}

Expected output:

@data{doe_title_2016,
  title = {Title},
  author = {Doe, John},
  date = {2016}
}

Actual biblatex output from an entry containing {:type:review} in the Extra field:

@article{doe_title_2016,
  title = {Title},
  author = {Doe, John},
  date = {2016},
  note = {\{:type:review\}}
}

Expected output:

@review{doe_title_2016,
  title = {Title},
  author = {Doe, John},
  date = {2016}
}

Actual CSL YAML output from an entry containing {:type:review-book} in the Extra field:

---
references:
- id: doe_title_2016
  type: article-journal
  title: Title
  note: '{:type:review-book}'
  author:
    - family: Doe
      given: John
  issued:
    date-parts:
      - - 2016
...

Expected output:

---
references:
- id: doe_title_2016
  type: review-book
  title: Title
  author:
    - family: Doe
      given: John
  issued:
    date-parts:
      - - 2016
...

BBT should try to parse all types listed in http://docs.citationstyles.org/en/stable/specification.html#appendix-iii-types – though in practice I’d expect mostly those types that cannot be accessed from the Zotero GUI, e.g., dataset (→ @data), review (→ @review), review-book (→ @review), and maybe pamphlet (→ @booklet). Unrecognized types should be mapped to CSL no-type or bib(la)tex @misc.

[retorquere]

Can you map those CSL itemtypes to Bib(La)TeX for me?

[njbart]

CSL	biblatex	bibtex
article	article	article
article-magazine	article/magazine (1)	article
article-newspaper	article/newspaper	article
article-journal	article	article
bill	legislation	misc
book	book (2)	book
broadcast	misc/broadcast (7)	misc
chapter	incollection (3)	incollection
dataset	data (4)	misc
entry	inreference	incollection
entry-dictionary	inreference	incollection
entry-encyclopedia	inreference	incollection
figure	image	misc
graphic	image	misc
interview	misc/interview (5)	misc
legislation	legislation	misc
legal_case	jurisdiction	misc
manuscript	unpublished	unpublished
map	misc/map (6)	misc
motion_picture	movie	misc
musical_score	audio (5)	misc
pamphlet	booklet	booklet
paper-conference	inproceedings	inproceedings
patent	patent	misc
post	online	misc
post-weblog	online	misc
personal_communication	letter	misc
report	report	techreport
review	review	article
review-book	review	article
song	music	misc
speech	misc/speech (5)	misc
thesis	thesis	phdthesis (8)
treaty	legal	misc
webpage	online	misc

Shorthands: b: (vanilla) biblatex, ba: biblatex-apa, bc: biblatex-chicago

Note that in biblatex users can map any unambiguous type or type/entrysubtype combination, on the fly, to any other type or type/entrysubtype combination – that’s how I would recommend to deal with any remaining mismatches between b, ba, bc, and others.

(1) biblatex only: the part after the slash specifies the entrysubtype

(2) collection if the work has no author but editor(s)

(3) inbook if the work has a bookauthor

(4) ba only (or use misc/data if you prefer not to use types not in the official b repertoire)

(5) as used by bc

(6) my invention (maps never mentioned in b, ba, bc)

(7) my invention (bc uses article/magazine)

(8) could also be a mastersthesis (but you’d have to parse the type field to catch this, not sure whether it’s worth the effort)

[retorquere]

How would I distinguish whether the intent is to export for b/ba/bc?

[njbart]

I would prefer a one-size-fits-all approach for biblatex, i.e., I would not distinguish between exports for b/ba/bc at all.

I feel BBT cannot be expected to deal with all mismatches between b/ba/bc and others, and it’s actually not too difficult for users to fix such issues themselves. For example, if BBT exports misc/broadcast, but a bc users wants article/magazine for this entry type, they can use the DeclareSourcemap functionality (in a latex document preamble) to achieve this on the fly.

[retorquere]

Wait; something like article/magazine isn't a way to describe alternates, but you actually mean it should generate

@article/magazine{...
}

? Will every biblatex-compatible processor understand this?

[njbart]

“article/magazine” is my shorthand for “type=article with entrysubtype=magazine”, like

@article{blah,
  title = {Blah},
  entrysubtype = {magazine}
}

I just noticed that the regular BBT biblatex export (i.e., not using the “cheater syntax”) does not set an entrysubtype for Zotero Magazine and Newspaper items yet either – but it’d be great if it could. Required by biblatex-chicago.

[retorquere]

I think I have it. Do you have some testcases for me?

[retorquere]

Would you prefer no-type over the type inferred from the Zotero type if a type: idunno is present rather than just ignoring it?

[njbart]

Would you prefer no-type over the type inferred from the Zotero type if a type: idunno is present rather than just ignoring it?

Yes, following what the citeproc-js docs say: “Note, however, that when a type not recognized by the target style is set in this way, the item will be processed as an untyped item (sometimes described as a generic type such as “Document” in calling applications).” (https://citeproc-js.readthedocs.io/en/latest/csl-json/markup.html#cheater-syntax-for-odd-fields)

[retorquere]

OK, that's what it does now. If you have some testcases (via error report preferably) I can add them to the test set and merge.

[njbart]

Would you prefer no-type over the type inferred from the Zotero type if a type: idunno is present rather than just ignoring it?

Yes, following what the citeproc-js docs say: “Note, however, that when a type not recognized by the target style is set in this way, the item will be processed as an untyped item (sometimes described as a generic type such as “Document” in calling applications).” (https://citeproc-js.readthedocs.io/en/latest/csl-json/markup.html#cheater-syntax-for-odd-fields)

Sorry, I think I completely misunderstood this passage on first reading. What it actually seems to say is that if a CSL style does not contain any specific instructions for “odd” fields, users should expect those fields to be formatted in a generic and not necessarily correct way.

So now I’d say ignoring types not listed in http://docs.citationstyles.org/en/stable/specification.html#appendix-iii-types is fine.

A few examples: Report ID Z58T9QFH

[retorquere]

Test files:

• BibLaTeX
• BibTeX
• CSL JSON

[retorquere]

If those outputs look good to you, I can merge them into master.

[retorquere]

I'm prepping a release, I'd like to include this if the output above is OK.

[njbart]

\@booklet/Clark and @audio/Mozart look good, and parsing of type: blah seems to work in general. But please remove the other three examples for the time being, these will need more work for other reasons.

[retorquere]

You mean reasons unrelated to this issue? Or refinements to this issue? If they're unrelated reasons I could just merge and change the test cases later. If there's still refinement that needs to be done for this issue I'll just keep this issue open and release .79 without it for now.

There's bound to be loads of edge cases for this at this stage. I check itemType here and there and that hasn't been brought up to speed with checking for this type override.

[njbart]

It's reasons unrelated to the “item type” issue: BBT output for reviews needs work, and I need to figure out what fields could be used to make @data work with both ba and bc.

[retorquere]

OK, I'll leave it to your judgement then whether this should be merged. I think I have every case of checking for itemType changed to incorporate the override, tests are running.

[njbart]

Yeah, please do merge.

[retorquere]

merged

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.