[BUG] Errors in Chicago 17th Artwork Type

edited February 1, 2024
Related to the need to use the Extra field to customise types such as Artwork.

It seems to me that Artwork renders problematically. I might be missing something

Example 1:

Data fields: https://i.imgur.com/dFAMUZA.png
Rendered result: https://i.imgur.com/8VSSgoJ.png

Why is the year appearing twice in the Individual Citation?

Example 2:

Data fields: https://i.imgur.com/HnnRzHP.png
Rendered result: https://i.imgur.com/pdcanUa.png

Now the event title and year are duplicated and the event place is not rendered.

`annote` and `note` do not get rendered at all.

'event-title' with no other variables in extra also does not render at all.

Can someone please clarify/fix?

For example, what should I enter to achieve these citations as shown in the Chicago manual?


To sum up:

Can we please have 'event-title', 'event-place', 'event-date' work as expected in officially maintained styles for the Artwork type please?
  • Yes, there are bugs in the style for artwork, but the event variables are not what you'd want for an artwork in a museum (I believe archive should work?). Temporary exhibits, perhaps -- and we'd have to figure out how to do this right.

    Also, annote and note will never render in Chicago style -- we generally try to avoid them in general styles since people use those variables in all sorts of different ways.
  • Thanks. I think our situation is pretty common so perhaps warrants a bit of strategic attention. Many universities and major funding bodies now require formal accounting of 'non-traditional research outputs' or 'creative works'.

    Categories for the Non-traditional research outputs (NTROs) include:

    JO Original Creative Works
    JL Live Performance of Creative Works
    JR Recorded/Rendered Creative Works
    JE Public Exhibitions and Events
    JQ Research Reports

    In turn, Original Creative Work can be:

    Visual artwork
    Design/architectural work
    Textual work

    Chicago, etc. will catch up at some point but now one needs to be able to cite.

    Say, it is JO and design work but in other cases too one would want to add at least the place where the work was shown/used first.

    Hence the through to use Artwork for most but the need to add event-related entries.

    We can try with Archive instead, but it would be good to know which fields are included into centrally managed styles and if they are included it would be super if they worked as expected. I understand that 'expected' here is very fuzzy but non-rendering and duplication do look like bugs...

  • OK, trying `Archive` but it renders the year twice in the Individual Citation. Is this a bug?

    Data fields: https://i.imgur.com/LbFM3kY.png
    Rendered result: https://i.imgur.com/BqxGz1g.png
  • @adamsmith or @damnation

    Might it be possible to fix the rendering for the `Archive` entry at least please?
  • OK, if all are busy, I can try. But could you point me to the right place in the code and if there are any complexities to be wary of? I could then have a go and submit a PR?

  • Sorry, finding the right place in the code and figuring out how they interact, i.e. complexities, is 90% of the work here. The actual code change will almost certainly be 4 lines.
  • Hm... By this logic even if I submit a PR the bottleneck will remain because testing if the PR breaks something will also be laborious. How can we have it fixed given this is one of the most common styles and known bugs in it are a problem?
  • I mean -- we'll get it fixed as fast as possible, and in all likelihood it'll be faster with a PR (Plus, once you fixed it, it's fixed for you locally as a bonus...), but I'm not sure what else you expect me to say?
    Yes, it's a common style, I definitely want to see it fixed, but it's also a fairly uncommon item type, so it's not like this is an acute emergency with people posting every day about wrong citations (which does happen otherwise -- see e.g. people being caught off guard by the recent IEEE changes) .
  • Ha. :)

    I can direct my students to complain here, one subject I have this semester is some 600. But do we want this?

    Thanks for your attention.
  • Hello! I am not sdflewrit783's student, but I am a PhD student in art history and use JurisM (for multilingual options), and I can confirm having this fixed would be very helpful. Thank you very, very much for all you do!
  • Had a look at GitHub, there are quite a few maintained Chicago variants. If 'artwork' is fixed, would this have to apply to all of these styles?

  • If you have a fix for one of the fullnote variants, I can port it to the rest
  • edited February 21, 2024
    The artwork is only mentioned once in a comment, along with maps, and does not seem to be differentiated in the code as a type. Any tips on the overall strategy in this case?

  • Thanks. Shall look. This is pretty misleading as 'artworks' can be designs, buildings, performances, etc. and not just graphics.
  • edited February 26, 2024
    OK, so here is the problem code, it applies to 'Artwork' and 'Map'.

    I am not sure what it is supposed to be doing but as it is, if the 'pulisher' or 'publisher-place' is missing it duly replaces with a repeated date.

    This does not make sense but I do not know if we can simply remove this code because it might be fulfilling some other need.

    At the moment, following the advice elsewhere, we put the place into the 'Archive' field. We can move that to 'publisher' and 'archive-place' to publisher-place' as a workaround. These fields sound more natural than the archive fields for the data we have or will there be other issues with those?

    Can those in the know clarify the best path forward?

  • Delete graphic from the first <if> line.

    Then, after the second </if> line, add:

    <else-if type="graphic">
    … code for artwork …
  • I guess the question is why this code is there -- it looks very purposeful and I'd be discinclined to just take it out. It might be that the _other_ place where "issued" is produced (recall, we're trying to fix that it's duplicate) just needs to be fixed to properly exclude it for exactly the cases where it appears here. I'm not surprised that's buggy: writing CSL that excludes based on two conditions (i.e. is grapic or map and does not have publisher or publisher place) is long and error-prone
  • edited March 1, 2024
    OK, now that we do know where the offending action resides but do not know what the desired action is supposed to be, I shall leave this to the experts (does GitHub blame a concrete author for this snippet? They might know what they wanted with this one).

    For us, it is enough that `publisher` and `publisher-place` work as expected, as a workaround for the time being.
Sign In or Register to comment.