Closed georgd closed 4 years ago
@fbennett what do you think?
Adding a document type for legal commentaries would have the advantage of being able to create specific field names for display in Juris-M.
Adding only a commentator
to chapter
is probably done with only little code change.
Would the locator-extra
and locator-date
attributes work here? In that case there would be just the one item for the overall commentary in the DB, and authors would note the pinpoint, author, and optionally the date details in individual citations. (This was originally added to support looseleaf services, which sounds like a similar use case.)
https://citeproc-js.readthedocs.io/en/latest/csl-m/index.html#locator-date-and-locator-extra-extension
IIRC, we discussed this option a year ago and came to the conclusion that it wouldn’t work when the subsequent citation is formatted differently from the first, like in the test. This one is for the sibling style https://github.com/georgd/jm-styles/blob/master/jm-leg-cit-ohne-verzeichnisse.csl which shouldn’t create a bibliography. Here, the subsequent citation leaves away the editor
label and replaces title
by title-short
. If the author only went into locator-extra
, any subsequent reference to a commentary in the same volume would be seen as subsequent, even if it’s not the same.
>>===== MODE =====>>
all
<<===== MODE =====<<
>>===== KEYS =====>>
[
"P3FMMUBT",
"7RPL6N47"
]
<<===== KEYS =====<<
>>===== DESCRIPTION =====>>
Legal commentary
<<===== DESCRIPTION =====<<
>>===== RESULT =====>>
FIRST
<i>Oberhammer</i> in Schwimann/Kodek (Hg), ABGB II<sup>4</sup> (2012) §364a ABGB; <i>Hippold</i> in Schwimann/Kodek (Hg), ABGB II<sup>4</sup> (2012) § 1313a ABGB.
FIRST w/LOCATOR
<i>Oberhammer</i> in Schwimann/Kodek (Hg), ABGB II<sup>4</sup> (2012) §364a ABGB 123; <i>Hippold</i> in Schwimann/Kodek (Hg), ABGB II<sup>4</sup> (2012) § 1313a ABGB.
FIRST w/LABEL
<i>Oberhammer</i> in Schwimann/Kodek (Hg), ABGB II<sup>4</sup> (2012) §364a ABGB Abs 123; <i>Hippold</i> in Schwimann/Kodek (Hg), ABGB II<sup>4</sup> (2012) § 1313a ABGB.
SUBSEQUENT
<i>Oberhammer</i> in Schwimann/Kodek, ABGB II<sup>4</sup> §364a; <i>Hippold</i> in Schwimann/Kodek, ABGB II<sup>4</sup> § 1313a.
SUBSEQUENT w/LOCATOR
<i>Oberhammer</i> in Schwimann/Kodek, ABGB II<sup>4</sup> §364a 123; <i>Hippold</i> in Schwimann/Kodek, ABGB II<sup>4</sup> § 1313a.
BIBLIOGRAPHY
<div class="csl-bib-body">
</div>
<<===== RESULT =====<<
>>===== INPUT =====>>
[
{
"id": "P3FMMUBT",
"type": "chapter",
"title": "§364a ABGB",
"author": [
{
"family": "Oberhammer"
}
],
"editor": [
{
"family": "Schwimann"
},
{
"family": "Kodek"
}
],
"container-title": "ABGB",
"volume": "II",
"edition": "4",
"issued": {
"raw": "2012"
},
"shortTitle": "§364a",
"multi": {
"main": {},
"_keys": {}
}
},
{
"id": "7RPL6N47",
"type": "chapter",
"title": "§ 1313a ABGB",
"author": [
{
"family": "Hippold"
}
],
"editor": [
{
"family": "Schwimann"
},
{
"family": "Kodek"
}
],
"container-title": "ABGB",
"volume": "II",
"edition": "4",
"issued": {
"raw": "2012"
},
"shortTitle": "§ 1313a",
"multi": {
"main": {},
"_keys": {}
}
}
]
<<===== INPUT =====<<
In the test just posted, there is no difference in format between first and subsequent references. When do subsequent references format differently?
It’s not easy to detect. It’s the (Hg)
(=ed.) omitted and §364a
(title-short
) instead of §364a ABGB
(title
):
<i>Oberhammer</i> in Schwimann/Kodek (Hg), ABGB II<sup>4</sup> (2012) §364a ABGB.
<i>Oberhammer</i> in Schwimann/Kodek, ABGB II<sup>4</sup> §364a.
^^^ ^^^^^
Is ABGB meant to be omitted when the reference was first used somewhere else in the document, or when it was referenced in the immediately preceding cite? (I assume the former, but just to confirm.)
In the SUBSEQUENT result, the first cite omits (Hg), but the second cite includes it, although it also drops the ABGB portion following the section number. If that is intentional, what is the rule behind it?
In the SUBSEQUENT result, the first cite omits (Hg), but the second cite includes it, although it also drops the ABGB portion following the section number. If that is intentional, what is the rule behind it?
Oh, that’s an oversight by me, cleaning up the artefacts of the initial testing. The test-runner doesn’t apply subsequentness to both cites and I haven’t removed the (Hg) in the second one while I did remove the ABGB portion there.
Edit: I updated the test above.
With the kit that we have at the moment, it looks like the least-painful way to address this would be to add a commenter
creator to type chapter
, set exclude-with-fields="commenter"
as a style option, and remove the deprecation note from exclude-with-fields in the citeproc-js docs. Would that work?
With the kit that we have at the moment, it looks like the least-painful way to address this would be to add a
commenter
creator to typechapter
, setexclude-with-fields="commenter"
as a style option, and remove the deprecation note from exclude-with-fields in the citeproc-js docs. Would that work?
But then, the commentary would never end up in the bibliography while the whole work should. And there are other styles around which require the same handling for chapters in edited books in general. So a more generic solution would be nice.
Is ABGB meant to be omitted when the reference was first used somewhere else in the document, or when it was referenced in the immediately preceding cite? (I assume the former, but just to confirm.)
Exactly, the former. Use the short title if the reference was used anywhere in the document before.
With the kit that we have at the moment, it looks like the least-painful way to address this would be to add a
commenter
creator to typechapter
, setexclude-with-fields="commenter"
as a style option, and remove the deprecation note from exclude-with-fields in the citeproc-js docs. Would that work?But then, the commentary would never end up in the bibliography while the whole work should. And there are other styles around which require the same handling for chapters in edited books in general. So a more generic solution would be nice.
It will not be possible to analyze a set of chapter references to derive a single reference representing all of them, minus some details, for insertion into the bibliography. The processor must be supplied with a single unambiguous item that is to be inserted into the bibliography, whether it is an item cited in the document notes, or inserted into the bibliography as an uncited item. A fully automatic solution is not within reach.
(Since this also affects ordinary book chapters as you say, perhaps it would make sense to leave this issue for now, pending whatever syntax comes out of CSL discussions, and implement that once.)
Actually, something similar to this does exist for statutes. When multiple items reference the same statute with different section numbers, it's set up to cite the statute just once in the bibliography. Since that's already in there, it might be possible to extend it to cover chapters. It would cover this case, but not cases in which the book is meant to be cited with the cited chapters listed below it (Chicago wants something like that IIRC), so the pressure for further changes would not go away. What is the status of mock-hierarchical items in CSL discussions currently?
I think
With the kit that we have at the moment, it looks like the least-painful way to address this would be to add a
commenter
creator to typechapter
, setexclude-with-fields="commenter"
as a style option, and remove the deprecation note from exclude-with-fields in the citeproc-js docs. Would that work?But then, the commentary would never end up in the bibliography while the whole work should. And there are other styles around which require the same handling for chapters in edited books in general. So a more generic solution would be nice.
It will not be possible to analyze a set of chapter references to derive a single reference representing all of them, minus some details, for insertion into the bibliography. The processor must be supplied with a single unambiguous item that is to be inserted into the bibliography, whether it is an item cited in the document notes, or inserted into the bibliography as an uncited item. A fully automatic solution is not within reach.
(Since this also affects ordinary book chapters as you say, perhaps it would make sense to leave this issue for now, pending whatever syntax comes out of CSL discussions, and implement that once.)
Your idea last year was to "clean up" the bibliography, removing identical items.
A further question. If only one commentary is cited, or only one chapter of a book, is the requirement going to be to cite the specific chapter, but cite the larger work if multiple commentaries/chapters are cited in the doc? That would complicate things considerably.
Actually, something similar to this does exist for statutes. When multiple items reference the same statute with different section numbers, it's set up to cite the statute just once in the bibliography.
Interesting – I haven’t noticed that yet (I think, I’m still scratching only at the surface of citeproc’s powers).
Since that's already in there, it might be possible to extend it to cover chapters. It would cover this case, but not cases in which the book is meant to be cited with the cited chapters listed below it (Chicago wants something like that IIRC), so the pressure for further changes would not go away.
Yes, that’s true.
What is the status of mock-hierarchical items in CSL discussions currently?
Not really in sight with 1.1 AFAIR. The relations that are enabled with 1.1 are reviewed
and original
.
A further question. If only one commentary is cited, or only one chapter of a book, is the requirement going to be to cite the specific chapter, but cite the larger work if multiple commentaries/chapters are cited in the doc? That would complicate things considerably.
No, in these styles, the specific chapter would never appear in the bibliography.
I'll take a look at giving chapter
treatment similar to legislation
. Here's hoping for a smooth path on the issue!
You're great!
A further question. If only one commentary is cited, or only one chapter of a book, is the requirement going to be to cite the specific chapter, but cite the larger work if multiple commentaries/chapters are cited in the doc? That would complicate things considerably.
No, in these styles, the specific chapter would never appear in the bibliography.
Actually, I've heard exactly that from students here in Switzerland. Might not be a deal breaker, but it seems to be fairly common here.
Not really in sight with 1.1 AFAIR. The relations that are enabled with 1.1 are reviewed and original.
Yeah, there were enough things coming in CSL 1.1, that we decided to hold off on further major features until 1.2.
Handling containers hierarchically with the CSL 1.1 related item structure is thorny because it is such a major change from the existing style and data structure in order to meet a fairly rare formatting need.
@fbennett If you can handle this structure using field matching like with statutes, that would be really cool and helpful to inform if/how this might otherwise need to be developed in CSL (e.g., if hierarchical item data are even necessary).
If only one commentary is cited, or only one chapter of a book, is the requirement going to be to cite the specific chapter, but cite the larger work if multiple commentaries/chapters are cited in the doc? That would complicate things considerably.
This is the requirement for things like Chicago and Annual Reviews styles. For example, Annual Reviews would want this for a single chapter from a book cited:
Author, A. A. (2010). Title of the chapter. In Editor, E. E. (Ed.), Title of the book.
But this for two or more chapters from a book cited:
Author, A. A. (2010). Title of the first chapter. See Editor (2010). Author, B. B. (2010). Title of the second chapter. See Editor (2010). Editor, E. E. (Ed.), (201). Title of the book.
A further question. If only one commentary is cited, or only one chapter of a book, is the requirement going to be to cite the specific chapter, but cite the larger work if multiple commentaries/chapters are cited in the doc? That would complicate things considerably.
No, in these styles, the specific chapter would never appear in the bibliography.
Actually, I've heard exactly that from students here in Switzerland. Might not be a deal breaker, but it seems to be fairly common here.
I'll keep this in mind. It might be possible to handle it.
Okay, it looks like this can be implemented without much trouble in citeproc-js
, but there may be an additional wrinkle. In a footnote style, does a requirement like this occur at all?
[1] Author One. Title of Chapter One in Title of Book (2011). [2] Author Two. Title of Chapter Two in Title of Book. [3] Author One. Title of Chapter One.
That is to say, are there two discrete subsequent citation forms: one for a newly cited chapter to a previously cited book, and another for a repeat citation to a previously cited chapter. (If that is going to be a requirement, we're in deep water.)
But this for two or more chapters from a book cited:
Author, A. A. (2010). Title of the first chapter. See Editor (2010). Author, B. B. (2010). Title of the second chapter. See Editor (2010). Editor, E. E. (Ed.), (201). Title of the book.
First thought: Fugedaboutdit. :-)
Second thought: Maybe we can do this, or part of it. In the current code, items are sent to the bibliography function with a shared legislation_id
value, and for chapters we would set a similar chapters_id
value. We can either filter the items to render just one of them, or count the number of items for each ID, and adjust the formatting accordingly. It would need a fresh conditional valid only in cs:bibliography
. Something like chapter-count="1"
maybe. That could be used to render the two possible forms. The entry for the book as a whole would need to be inserted as an uncited item if it is not present in the bibliography, but the rest would be pretty well automated. He said.
But this for two or more chapters from a book cited:
Author, A. A. (2010). Title of the first chapter. See Editor (2010).
Author, B. B. (2010). Title of the second chapter. See Editor (2010).
Editor, E. E. (Ed.), (201). Title of the book.
First thought: Fugedaboutdit. :-)
Second thought: Maybe we can do this, or part of it. In the current code, items are sent to the bibliography function with a shared
legislation_id
value, and for chapters we would set a similarchapters_id
value. We can either filter the items to render just one of them, or count the number of items for each ID, and adjust the formatting accordingly. It would need a fresh conditional valid only incs:bibliography
. Something likechapter-count="1"
maybe. That could be used to render the two possible forms. The entry for the book as a whole would need to be inserted as an uncited item if it is not present in the bibliography, but the rest would be pretty well automated. He said.
Could we chat a bit about various data and style structures that might make this more or less feasible?
I think we could make this work pretty straightforward based on your last comment.
Basically, we have a container-id for various collapsed items. With potentially a style format for the collapsed chapters and the common book.
So, we detect the presence of a container-id, maybe through explicit data or implicit detection, then we have a format based on the existence of the common container-id. I think the specific formatting could be managed by the style.
Yes, I think the bibliography end would be pretty straightforward with implicit matching of a few field values. Supporting two subsequent forms would be harder, but maybe not impossible. Would that be needed?
I'm not sure citation forms are needed. Just the bibliography form
I've opened a new issue for discussion of the solutions floated here, at https://github.com/Juris-M/zotero/issues/81.
Okay, it looks like this can be implemented without much trouble in
citeproc-js
, but there may be an additional wrinkle. In a footnote style, does a requirement like this occur at all?[1] Author One. Title of Chapter One in Title of Book (2011). [2] Author Two. Title of Chapter Two in Title of Book. [3] Author One. Title of Chapter One.
That is to say, are there two discrete subsequent citation forms: one for a newly cited chapter to a previously cited book, and another for a repeat citation to a previously cited chapter. (If that is going to be a requirement, we're in deep water.)
I really don’t like the role apparently bestowed upon me to pronounce the uncomfortable. At least in the case of legal commentaries, the second subsequent citation form does occur (I have to check again for styles where chapters in general are treated this way). In the test above, in reality, FIRST
should look like this:
FIRST
<i>Oberhammer</i> in Schwimann/Kodek (Hg), ABGB II<sup>4</sup> (2012) §364a ABGB; <i>Hippold</i> in Schwimann/Kodek, ABGB II<sup>4</sup> § 1313a ABGB.
Where the second citation lists the commentary’s title in its full form § 1313a ABGB
(contrary to its short form § 1313a
but the book data is formatted like in context="subsequent"
: dropping the editor
label ((Hg)
) and the publication date ((2012)
).
BTW, this form is also required in styles that don’t print a bibliography and there, definitely also for normal chapters, not only commentaries. [ceterum censeo hierarchical structuring would be great]
Okay, we'll see what we can do. If it turns out to be possible, it will require a fifth position condition, I think, or (more likely) a condition to nest within a position="subsequent"
block.
Be careful what you wish for: hierarchical structuring would open up a bunch of fresh bug vectors, and require a years-long project to produce an implementation. :-)
A couple of lurking questions not relevant to the styles that @georgd is working on.
subsequent
, it will be correct to trigger ibid only when the exact same item is re-cited? There won't be styles that want "Chapter One in ibid." ... yes?first-reference-note-number
point to the first reference to the book, or the first reference to the specific chapter?I'm reeling a bit from how smoothly this came together, but here is a test of two-stage subsequent rendering. All other tests in the suite also pass. Will bundle this into a processor release soon.
Great! Thanks, it looks fine for commentaries now – suddenly, so many tests don’t fail anymore :)
Now, how could I tell the processor to apply the consolidation only to chapters that are commentaries, not to all the others. I couldn’t read that out of the tests in the citeproc-js
repo. Consider this test, which fails while the test in the original report passes:
>>===== MODE =====>>
all
<<===== MODE =====<<
>>===== KEYS =====>>
[
"7DMKIKMQ",
"DBMR4UZM"
]
<<===== KEYS =====<<
>>===== DESCRIPTION =====>>
Two chapters from same book
<<===== DESCRIPTION =====<<
>>===== RESULT =====>>
FIRST
<i>Eberle</i> in GedS Martens; <i>Karpen</i> in GedS Martens.
FIRST w/LOCATOR
<i>Eberle</i> in GedS Martens 123; <i>Karpen</i> in GedS Martens.
FIRST w/LABEL
<i>Eberle</i> in GedS Martens Abs 123; <i>Karpen</i> in GedS Martens.
SUBSEQUENT
<i>Eberle</i> in GedS Martens; <i>Karpen</i> in GedS Martens.
SUBSEQUENT w/LOCATOR
<i>Eberle</i> in GedS Martens 123; <i>Karpen</i> in GedS Martens.
BIBLIOGRAPHY
<div class="csl-bib-body">
<div class="csl-entry"><i>Eberle</i>, Zum Verwertungsverbot für rechtswidrig erlangte Informationen im Verwaltungsverfahren, in Selmer/Münch (Hg), Gedächtnisschrift für Wolfgang Martens (1987) 351.</div>
<div class="csl-entry"><i>Karpen</i>, Verfassungsgeschichtliche Entwicklung des Gesetzesbegriffs in Deutschland, in Selmer/Münch (Hg), Gedächtnisschrift für Wolfgang Martens (1987) 137.</div>
</div>
<<===== RESULT =====<<
>>===== INPUT =====>>
[
{
"id": "7DMKIKMQ",
"type": "chapter",
"title": "Verfassungsgeschichtliche Entwicklung des Gesetzesbegriffs in Deutschland",
"author": [
{
"given": "Ulrich",
"family": "Karpen"
}
],
"editor": [
{
"given": "Peter",
"family": "Selmer"
},
{
"given": "Ingo von",
"family": "Münch"
}
],
"container-title": "Gedächtnisschrift für Wolfgang Martens",
"issued": {
"raw": "1987"
},
"page": "137",
"language": "de",
"shortTitle": "Verwertungsverbot",
"note": "container-title-short: GedS Martens",
"multi": {
"main": {},
"_keys": {}
}
},
{
"id": "DBMR4UZM",
"type": "chapter",
"title": "Zum Verwertungsverbot für rechtswidrig erlangte Informationen im Verwaltungsverfahren",
"author": [
{
"given": "Carl-Eugen",
"family": "Eberle"
}
],
"editor": [
{
"given": "Peter",
"family": "Selmer"
},
{
"given": "Ingo von",
"family": "Münch"
}
],
"container-title": "Gedächtnisschrift für Wolfgang Martens",
"issued": {
"raw": "1987"
},
"page": "351",
"shortTitle": "Verwertungsverbot",
"note": "container-title-short: GedS Martens",
"multi": {
"main": {},
"_keys": {}
}
}
]
<<===== INPUT =====<<
Currently, commentaries are chapters missing an entry page
. (On a side note, I’d prefer to make the differentiation by the presence of a commenter
but that’s not a way to go if it is not visible in the UI – It’s not a new variable as it exists already for legal_case
).
Which style does this use? I've pulled your fork of jm-style-tests
, but all of the style subdirs are empty.
I like your suggestion of adding commenter
as a creator on the chapter
type. It will save a little time if it's possible to access your test suite(s) directly.
Which style does this use?
The jm-leg-cit-rechtsquellenverzeichnis-literaturverzeichnis.csl.
I've pulled your fork of
jm-style-tests
, but all of the style subdirs are empty.
Thanks for reminding me. I put them in a separate branch jm-legcit
because I planned to re-open a PR which I find much easier from a local branch but then I lost that out of focus, I’m sorry. I now opened the PR.
No worries, thanks for the tests. I went ahead and added commenter to the chapter type, and released a beta with the change, and with the latest processor. In should be installable from the link below:
https://our.law.nagoya-u.ac.jp/jurism/dl?channel=release&platform=mac
@fbennett Is there a style switch that you've added to indicate that chapters with the same containers should be collapsed?
@fbennett Is there a style switch that you've added to indicate that chapters with the same containers should be collapsed?
It's @consolidate-chapter-items="true"
on cs:bibliography
.
And how is consolidating only commentaries versus all chapters controlled?
@fbennett Thinking about how this might be implemented into vanilla CSL, I wonder if we might anticipate consolidation across more types (e.g., multiple chapters in a multi-chapter report
or multiple books in a compilation (book
item with container-title
). Instead of a Boolean, could we do @consolidate-container="chapter report"
, with the list of type of item types that have containers consolidated?
And how is consolidating only commentaries versus all chapters controlled?
It's ... not. Not sure what I was thinking, but chapters are still all or nothing. Conditioning consolidation on the presence/absence of a field value would get messy for simple style attributes. I think we land on @georgd's original suggestion of casting a specific item type for legal commentaries. I've resisted that, but the case is pretty clear now. It's a big step, but not hard to do in the Jurism schema patch framework. Shall I set that up?
We could then drop commenter
from chapter (and its clone), since the commenter on a legal-commentary
type would just be the author. Safe enough to do at this stage, since commenter
has only been live in the beta for a few hours, and is known only to devs following this.
@fbennett Thinking about how this might be implemented into vanilla CSL, I wonder if we might anticipate consolidation across more types (e.g., multiple chapters in a multi-chapter
report
or multiple books in a compilation (book
item withcontainer-title
). Instead of a Boolean, could we do@consolidate-container="chapter report"
, with the list of type of item types that have containers consolidated?
That's a capital idea, and would fit very nicely with a legal-commentary
type.
And how is consolidating only commentaries versus all chapters controlled?
It's ... not. Not sure what I was thinking, but chapters are still all or nothing. Conditioning consolidation on the presence/absence of a field value would get messy for simple style attributes. I think we land on @georgd's original suggestion of casting a specific item type for legal commentaries. I've resisted that, but the case is pretty clear now. It's a big step, but not hard to do in the Jurism schema patch framework. Shall I set that up?
You know, I could live with the chapter solution but of course the new type is much cleaner and it looks like we get into much less trouble with it so, I’m all for it :)
We could then drop
commenter
from chapter (and its clone), since the commenter on alegal-commentary
type would just be the author. Safe enough to do at this stage, sincecommenter
has only been live in the beta for a few hours, and is known only to devs following this.
Agreed.
@fbennett Thinking about how this might be implemented into vanilla CSL, I wonder if we might anticipate consolidation across more types (e.g., multiple chapters in a multi-chapter
report
or multiple books in a compilation (book
item withcontainer-title
). Instead of a Boolean, could we do@consolidate-container="chapter report"
, with the list of type of item types that have containers consolidated?That's a capital idea, and would fit very nicely with a
legal-commentary
type.
I like this idea!
Yeah, I think legal-commentary makes sense as its own type. Though following the CSL naming convention, it should be legal_commentary
(cf. legal_case
).
Closing this in favor of https://github.com/Juris-M/zotero/issues/81
What is a legal commentary?
The legal commentary of a statutary law is usually very similar to an edited book, compiled by a team of editors or by a single editor which collects commentaries to the single subdivisions of the law, often authored by different experts. As laws are amended over time and legal practice might find new interpretations over time, the commentaries are reedited quite often, in some cases in the form of loose leaf editions.
What’s special in citing a commentary?
Styles that require a bibliography list the concrete subdivision commentaries only in the note citation in the text. Only the data for the entire commentary work goes into the bibliography, how many ever subdivisions are cited in the text. [I’ve seen this requirement in an Italian style as well].
What’s needed?
commentary
. But it probably suffices to addcommenter
to the list of name variables for typechapter
in the Jurism interface.A test case
(currently, the bibliography line is duplicated)