multi-section bibliographies

[bdarcus]

This has come up a number of times, with this being the latest:

http://forums.zotero.org/discussion/16531/sort-bibliography-by-reference-type/

My thought is that this is out of scope for CSL per se, and that it should be implemented at the interface between the processor and the editing environment, using named reference groups.

In short, the feature can be supported now, without any CSL changes.

But it's worth discussing.

[manuelmeister]

I think this would be really great addition.

F. e. to differentiate between primary and secondary sources or literature and internet sources.

[bdarcus]

The discussions about this are spread across different places, but the consensus has been that while it's an important feature, it is indeed out of scope for CSL.

Put differently, the right place for the feature to be implemented is in the citation processing tool (Zotero, pandoc-citeproc, Mendeley, etc.).

For future reference, it seems like that biblatex is a good model to follow. You'd basically want to allow users to associate particular references with specific sections manually (tag a reference with an optional section, say) or to do it based on type.

[denismaier]

Well, now that we are discussing a CSL API we could perhaps consider the feature request in that context. Like, calling applications should be able to request multiple bibliographies with different selection criteria.

[bdarcus]

That's a good point.

Maybe we can add an issue on the documentation repo tracker for this?

[bdarcus]

Moving to documentation, for possible incorporation into a new API appendix of the specification.

[adam3smith]

I like the idea of recommending an API that allows implementation of this client side. So is this consensus? No for direct CSL implementation, yes for recommending in API?

[bdarcus]

I think it makes sense. We could approve an issue for that, and link to this.

[bwiernik]

How about this for an API:

1. Items in a citation can have a section attribute sibling to id.
2. Calls to render a bibliography can be instructed to limit citations to a specific section.

Implementing clients could then create interfaces to (1) add section tags manually to items or automatically based on criteria like type or presence of `archive-place, (2) select a specific bibliography section to render. Users would then enter any headings, etc. manually.

[bdarcus]

As you can see, I created a new issue and linked to this.

[denismaier]

Coming back to an earlier issue concerning this topic, and re-reading @fbennett's response, I realize that citeproc-js is apparently already able to do this (citeproc-js manual). (Frank has also described that approach already on the discourse forum.) Essentially, you could create one bibliography with e.g. only webpages, and a second bibliography that excludes webpages.

In the case of Zotero, this probably only means two steps to get there:

1. Allow multiple independent bibliographies.
2. Allow filters for each bibliography. A GUI would be nice, but something simple like the javascript runner should be enough for the beginning.

(Right now, you can have multiple bibliographies, but they are not independent. If you add one entry in one bibliography via uncited, it will affect all bibliographies.)

Any drawbacks? Things I don't consider?

@dstillman What do you think about it?

[dstillman]

This sounds like something we could do fairly easily on a technical level (though @adomasven would know better), but it would need a GUI. (I'm not sure what you mean by "something simple like the javascript runner should be enough for the beginning" — the JavaScript runner in Zotero wouldn't help with word processor integration.)

I could see having a way to add filters in the Edit Bibliography window — basically a (greatly) simplified version of the Advanced Search window, with a handful of search conditions (e.g., "Item Type").

[fbennett]

Back when I was working on this, I remember thinking that whitelisting/blacklisting with tags might be a conceptually simple way to give users a high degree of flexibility. I think the processor UI would support that, if item tags were passed to the processor.

On Mon, May 4, 2020 at 1:48 PM Dan Stillman notifications@github.com wrote:

This sounds like something we could do fairly easily on a technical level (though @adomasven https://github.com/adomasven would know better), but it would need a GUI. (I'm not sure what you mean by "something simple like the javascript runner should be enough for the beginning" — the JavaScript runner in Zotero wouldn't help with word processor integration.)

I could see having a way to add filters in the Edit Bibliography window — basically a (greatly) simplified version of the Advanced Search window, with a handful of search conditions (e.g., "Item Type").

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/citation-style-language/documentation/issues/71#issuecomment-623255118, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASMSW2JEEJATCOPCABGS3RPZCILANCNFSM4MMO7S5A .

[dstillman]

Does this actually make sense in the citation processor, though? Couldn't the calling application just create a separate bibliography session for each bibliography and add the citations from the document that match the specified filters to each session?

Among other things, since the filters would be in the calling application, the search conditions would be for application metadata, not CSL-JSON, so something like "Item Type" would need to be converted into the CSL equivalent. Same for any other field. The calling application can make those conversions, of course, but what's the advantage to doing this on the processor side at all?

[fbennett]

The original reason for implementing filtering in the processor was to screen out items that should not appear in the bibliography, following settings in the style. CSL does not provide for those settings, it's a feature of CSL-M, but that's the original reason for it being in there. You could do the filtering on client-side, if done by post-processing the full array of bibliography entries returned by the processor. If the partial bibliographies were generated in separate processor instances, disambiguation operations would differ from those applied against the full set of references, and things like year-suffix (and maybe some other things) would not line up between document and bibliography.

On Mon, May 4, 2020 at 2:02 PM Dan Stillman notifications@github.com wrote:

Does this actually make sense in the citation processor, though? Couldn't the calling application just create a separate bibliography session for each bibliography and add the citations from the document that match the specified filters to each session?

Among other things, since the filters would be in the calling application, the search conditions would be for application metadata, not CSL-JSON, so something like "Item Type" would need to be converted into the CSL equivalent. Same for any other field. The calling application can make those conversions, of course, but what's the advantage to doing this on the processor side at all?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/citation-style-language/documentation/issues/71#issuecomment-623258294, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASMSW3GQCGTRUYU43KQCTRPZD7BANCNFSM4MMO7S5A .

[adomasven]

You could do the filtering on client-side, if done by post-processing the full array of bibliography entries returned by the processor.

This is not reasonably possible since the processor does not return information about which entry corresponds to which item in the bibliography.

If the partial bibliographies were generated in separate processor instances, disambiguation operations would differ from those applied against the full set of references, and things like year-suffix (and maybe some other things) would not line up between document and bibliography.

I was thinking that the easiest way to generate multiple bibliographies from a single processor instance with the current API would be to update uncited items list and make the bibliography for each section separately. We could probably also use the filtering functionality on makeBibliography() if it supports filtering by item ids.

[fbennett]

On Mon, May 4, 2020 at 3:34 PM Adomas Ven notifications@github.com wrote:

You could do the filtering on client-side, if done by post-processing the full array of bibliography entries returned by the processor.

This is not reasonably possible since the processor does not return information about which entry corresponds to which item in the bibliography.

The ordered set of IDs is should be available in the first element of the array returned by makeBibliography().

https://citeproc-js.readthedocs.io/en/latest/running.html#makebibliography

If the partial bibliographies were generated in separate processor instances, disambiguation operations would differ from those applied against the full set of references, and things like year-suffix (and maybe some other things) would not line up between document and bibliography.

I was thinking that the easiest way to generate multiple bibliographies from a single processor instance with the current API would be to update uncited items list and make the bibliography for each section separately. We could probably also use the filtering functionality on makeBibliography() if it supports filtering by item ids.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/citation-style-language/documentation/issues/71#issuecomment-623283932, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASMSUQNPTZTGWC2FCQQX3RPZOWHANCNFSM4MMO7S5A .

[adomasven]

The ordered set of IDs is should be available in the first element of the array returned by makeBibliography().

Oh sorry, yeah, that was my mistake.