Collaboration with NISO?

CSL Evolution
1

First, just to be clear, I don’t work for NISO, so I’m not offering to collaborate.

But I am curious if this group has ever considered working with NISO/ANSI to develop CSL into an official standard? While I almost certainly lack important context, it seems like this would be a good idea / fit.

Additionally, I can see that NISO/ANSI has bibliographic reference standard. But it’s 15 years old and presumably inferior to CSL.

Mostly I’m just curious as someone who is involved in some NISO committees and works extensively with CSL.

Thanks for creating / maintaining the CSL spec. It’s very well done!

2

Hi @coryschires - sorry for the delay.

I think these days our biggest constraint is time.

I do have some experience in standards development, and my experience is it’s pretty time-consuming, with unclear benefits in this case.

Looking through that bib standard doc, for example, shows it was developed by a large team of people who were basically paid to develop it. Most of us who do most of the work these days on CSL do it pro bono.

So you can see the basic constraints that make this extremely unlikely given the current situation.

3

Hi @ Bruce_D_Arcus1

I totally understand the constraints and appreciate all the work y’all have done.

I also agree that the practical benefits to CSL itself would be fairly minor. Clearly, y’all have a figured out how develop and maintain an impressively comprehensive spec and don’t need help from a government agency, bureaucrats, etc.

So perhaps some additional context may help clarify why I think a collaboration would be helpful…

First, a quick clarification, while many members are bureaucrats / professionals (e.g. working at NLM or ANSI), as far as I know, no one is directly paid for this work. It’s all done for professional development, geekiness, etc.

I myself have recently begun working with NISO committees to help with various publishing standards / recommendations. As a long time user and fan of CSL, I was surprised to discover some (perhaps even many) of these folks were not aware of the CSL spec.

In a recent call, for example, someone mentioned potentially developing a new version of ANSI/NISO Z39.29-2005. Given the successful and positive experience I have had using CSL, this suggestion surprised me. “Why would they bother developing a new spec when CSL has all this stuff figured out,” I thought. So part of the benefit would be, simply, to prevent wasted effort and confusingly redundant specifications.

Secondly (and perhaps a little selfishly), I would like to see greater consistency between CSL and NISO standards – especially JATS. For example, the JATS4R folks are currently discussing which values should be allowed for the publication-type attribute on <element-citation> elements. Rather than hash this out, I think they ought to use the CSL types. This would significantly improve interoperability between JATS and Citeproc / CSL. Also, it just seems better: again, why define a new list when y’all have already done this work.

But, overall, I think you can close this issue. On my end, I will continue to work with NISO and, to the extent it makes sense, encourage folks to use / learn about the quality work y’all have done. Hopefully, they will be open to my suggestions.

Finally, if they do decide to revamp ANSI/NISO Z39.29-2005, I will vigorously advocate that they consider recommending the CSL spec rather than reinventing the wheel.

4

Are you thinking about this from the data input angle (fairly simple comparatively), the citation styling angle (MUCH more complex), or both?

Norm Walsh last year was complaining our style spec wasn’t really a spec, and our response was we didn’t really have the time (or really the experience) to create what he was looking for.

You can always update this issue in the future if something comes up.

I’ll also tag @bwiernik @Denis_Maier @Rintze_Zelle @Sebastian_Karcher to make sure they see this.

5

Thanks @Bruce_D_Arcus1

Are you thinking about this from the data input angle…

Yes, if I’m understanding the distinction correctly. I am interested in encouraging greater alignment between the work y’all have done and whatever NISO (and by extension JATS) is considering. Some specific examples may help illustrate my thinking:

  1. Beyond allowing <mixed-citation> and <element-citation> tags, JATS does not offer much instructions / best practices for structuring citation data. The guidelines that do exist are unfortunately flexible, leading to variation and thus interoperability difficulties. In my experience, CSL-JSON is both tighter and more comprehensively considered. In my perfect world, JATS would adopt (or perhaps merely allow) child tags which matched the CSL-JSON keys. While this would almost certainly cause growing pains for legacy publishers, it would be a huge boon to anyone whose citation tooling is built on CSL / Citeproc (which, it seems to me, is the strongest solution).
  2. In-text cites are another sticky issue for JATS where the lessons from CSL could be very helpful. JATS provides the <xref> element for in-text cites (among other uses). But problems arise because folks structure <xref> elements in slightly different – but all equally valid – ways:
    • (<xref ref-type="bibr" rid="cite1">Doe 2012</xref>)
    • <xref ref-type="bibr" rid="cite1">(Doe 2012)</xref>
    • <xref ref-type="bibr" rid="cite1-cite4"><sup>1-4</sup></xref>
    • <xref ref-type="bibr" rid="cite1, cite2, cite3, cite4"><sup>1-4</sup></xref>
    • <sup><xref ref-type="bibr" rid="cite1-cite4">1-4</xref></sup>

Needless to say, this variation (and I could add more) is difficult to wrangle. By all accounts, JATS really needs a stricter format. And, from my own perspective, that format ought to closely mirror the expectations / behavior of CSL (e.g. cite formatting should be included in the <xref> rather than wrapping around it).

Norm Walsh last year was complaining our style spec wasn’t really a spec

I don’t understand what is not “really a spec” about it. But I am very much approaching things from an applied-developer standpoint rather than an expert-at-defining-specs standpoint. So it’s very possible I have large gaps in my understanding.

6

I certainly would like to see wider adoption of CSL-formatted bibliographic data. I don’t have a lot of spare time, though, as Bruce mentions. Do we have any indication as to how receptive NISO/ANSI would be to such an activity?

7

@bwiernik I don’t have much indication just yet. My company only recently became a member of NISO, and I am still working to join the relevant committees (e.g. some committees don’t allow new members when they’re in the thick of an ongoing initiative, which is sensible).

We work with over 1000+ journals across nearly every discipline and, from what I understand, they are generally eager to receive feedback from developers. So I’m hoping they will be receptive to my suggestions.

Either way, I’ll let y’all know if I make any headway.