Distributing Custom Abbreviations File

I have been working with the journal Hesperia (https://www.ascsa.edu.gr/uploads/media/Guidelines10-29-18.pdf) to create a style sheet that would allow output into their format. Many of the journals in classics and archaeology (not anthropology) have adopted a specific abbreviation format as defined by the American Journal of Archaeology (https://www.ajaonline.org/submissions/journals-series). Hesperia uses those abbreviations as well. I have created an abbreviations.json file of the AJA abbreviations.

I have uploaded the Style sheet to the repository and it shows up in Zotero as American School of Classical Studies at Athens, but is there a way to distribute the abbreviations.json file to users?
  • edited 20 days ago
    This continues the discussion that started at https://github.com/citation-style-language/styles/pull/3890.

    Ultimately custom abbreviation lists should probably be distributed as part of the CSL infrastructure, but CSL styles currently can't define which abbreviations to use, and I'm not aware of documentation of the abbreviation list JSON format. So maybe a different temporary home makes more sense while we address those issues?
  • I think we can collect them here: https://github.com/citation-style-language/abbreviations even though we don't exactly know how to distribute them or what their format is.

    (agree on the ultimate goal for CSL, but to be realistic, that's not going to happen in the near future)
  • So the practical goal here would be to be able to associate a given abbreviation list with one or more styles?

    We could implement this in Zotero for the time-being — we can adjust abbreviations.json to include additional lists and map them to style ids. For now, we'd only update these on Zotero updates, not via the repo. And I guess we'd have to change the option in the plugin doc prefs to say just "Use journal abbreviations" instead of "Use MEDLINE journal abbreviations".
  • So either Zotero could have a drop down to select a list, or eventually styles could specify a list ID?
  • edited 19 days ago
    @adamsmith, ah, I forgot we even had that repo. Yes, let's use that for now, then.

    @dstillman, yes. It's my understanding from https://forums.zotero.org/discussion/comment/275237/#Comment_275237 that users can currently put a modified abbreviations JSON file in the Zotero data directory, but that would presumably affect all installed styles, right? So yes, it would be good to have some mechanism to limit an abbreviation list to a subset of styles. Eventually we should do this the other way around (specify the abbreviation list to use in the CSL style), but that would require a new CSL release which is still a ways off.
  • We could implement this in Zotero for the time-being — we can adjust abbreviations.json to include additional lists and map them to style ids. For now, we'd only update these on Zotero updates, not via the repo. And I guess we'd have to change the option in the plugin doc prefs to say just "Use journal abbreviations" instead of "Use MEDLINE journal abbreviations".
    That would be outstanding and also great prep for eventually including this in CSL.
  • @dstillman, there is now an abbreviations.json file at https://github.com/citation-style-language/abbreviations/blob/master/american-journal-of-archaeology/abbreviations.json. It's for american-school-of-classical-studies-at-athens.csl and its dependent hesperia.csl. Let me know if you need anything else.
  • @dstillman, as another update, @emilianoeheyns is working to put together an npm package at https://github.com/citation-style-language/abbreviations/pull/6. The current idea is to have different "abbreviations.json" files in subdirectories:

    "american-journal-of-archaeology/abbreviations.json"
    "ncbi/abbreviations.json"
    "medline/abbreviations.json"

    Let us know if you'd like this to be organized any differently.
  • edited 17 days ago
    Is there a specific need for these files to be named "abbreviations.json" though? I have other code that imports the jabref abbrev lists into this JSON format and it would just yield a lot of directories having just a single file, just so it can be named abbreviations.json rather than abbrv.jabref.org/journals/ams.json, abbrv.jabref.org/journals/acs.json, etc. Since the package would only export the abbrev lists (the way I look at it now), the "files" section of the package.json would make it clear which files are conceptually "abbreviations.json" lists.
  • edited 17 days ago
    Is there a specific need for these files to be named "abbreviations.json" though?
    I think the only benefit is that it makes it easier for Zotero users to download the individual files and store them in their Zotero data directory without having to rename them. That argument would go away if Zotero start to automatically incorporate the lists from the repo, though.
  • Let us know if you'd like this to be organized any differently.
    Doesn't really matter as long as we can easily extract all the files, but I don't think we should privilege NPM here, so if this is going to depend on an index file, I think we should keep that separate and the NPM build script could process that the same way as other consumers.

    Thinking a bit more about this, it probably makes sense for us to just bundle all the abbreviations files separately, with the format unchanged, and then include a separate mapping file that maps style ids to abbreviations files. (It seems like there's some inconsistency between the URIs in some of the files vs. the documentation links in others. I'd be happy with just having an id in the info block to avoid that whole mess and let those be documentation links. We can also update Zotero to work with any structure, so there's no need to keep the original file structure on our account if we want to adjust it before these become more widely used.)
  • I don't mind any which way. NPM is just one way people could import these, and it should be possible to simultaneously package for other distribution platforms (like pypi), I'm just not familiar with their process. I'd be happy to include more data in the JSON files.

    I think having the sources in there is a good idea, but I also think we shouldn't let the perfect be the enemy of the good -- let's not try to solve every current and future problem right now.
Sign In or Register to comment.