Hi Tom,
So, to briefly condense your posts on this topic (for myself and others):
Juris-M (formerly Multilingual Zotero, MLZ) extends the official CSL
specification in a number of ways to improve support for legal citations.
One of these extensions is the support for parallel citations, where a
single document is published redundantly in multiple outlets. Juris-M
assumes that each so-called report is stored as a separate item, and
automatically collapses reports to the same document if they are cited
directly next to each other. See pages 6 and 78 of
http://citationstylist.org/public/mlzbook.pdf for more context and examples.
Your proposal is to store these separate reports as a single item, and to
make it possible in CSL to properly render the information from the various
reporters of each item (each report will have its own values for fields
like "container-title", "volume", "section", etc.).
After reading your proposal, I have a few questions:
* assuming that we store all the publication information from the various
publishers/reporters in a single item, in some form of ordered array, what
are the exact formatting requirements for parallel citations? For example,
for an item with multiple reports, is it ever necessary to be able to:
- cite a subset of the reports?
- control the order of the reports?
* for the old-timers here: does anybody know if there are any good
discussions here or on the Zotero forums about hierarchical item types? Do
we have an overview of the various cases where hierarchical item types
would help? E.g. https://www.zotero.org/support/requested_features only
mentions "chapters as sub-items of an edited volume". I'm wondering if
there is a lot of functional overlap between hierarchical item types and
parallel legal citations.
Rintze
P.S. Tom, it looks like every time you respond you start a new thread in
this mailing list, which makes this discussion harder to follow (this
discussion is a continuation of
http://xbiblio-devel.2463403.n2.nabble.com/Proposed-change-to-CSL-input-XML-specification-tp7579492.html
and
http://xbiblio-devel.2463403.n2.nabble.com/Proposed-change-to-CSL-input-XML-tp7579502.html).
Could you try to reply directly next time? You should be able to do this by
replying to the thread via http://xbiblio-devel.2463403.n2.nabble.com/, or
by subscribing to the mailing list at
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel, after which you
should receive future mailing list emails in your inbox.
On Tue, Jan 3, 2017 at 7:29 PM, Thomas O'Reilly <ia...@hotmail.com> wrote:
> After giving more thought to my proposed CSL element, I would like to
> modify the proposal. I would to rename the proposed element from <serials>
> to <containers>. Other changes will be listed in my answer to the questions
> that Bruce raises.
>
>
> Bruce brings up 2 important concerns with my previous proposal:
>
>
> QUESTIONS
>
> 1) Is the proposal necessary?
>
> 2) Could the solution be solved by extending the features of the <group>
> element?
>
> 3) Could the proposal be generalized beyond its niche applicability?
>
>
> ANSWERS
> (1) The proposal is necessary in my opinion.
>
> Frank Bennett has done a lot of incredible work with citeproc-js and
> Multi-lingual Zotero. In addition to maintaining the processor, he added
> experimental support for parallel citations for legal users. However, the
> lengths that he has had to go to achieve that support demonstrate why the
> <containers> construct should be adopted.
>
> "In CSL-M, parallel citations are produced when the item types of two
> adjacent citations match, the items are of a legal type, and their titles
> and dates also match." (Bennett, F. "Citations out of the Box", p. 78).
>
> This approach introduces several problems. First, storing information
> about the same item in two different citations allows the possibility of
> storing inconsistent information. Second, it relies upon the processor to
> imply a relationship between two citations, instead of relying upon an
> explicit data structure. This means that CSL Processors need to have
> complicated code in order to support parallel citations - which limits
> adoption of the feature. Third - from my understanding - the style creators
> don't have the ability give instructions about how parallel citations
> should be styled.
>
> In contrast, supporting a <containers> element will ensure data integrity,
> it is easier for processors to implement, and it gives style creators the
> flexibility to target users of parallel citations, if they choose.
>
> (2) Extending the <group> element to support the proposed features would
> NOT be an advisable solution.
>
> Just like the proposed <containers> element, the <group> element is
> primarily used for item data that is logically related. However, it's
> primary function is that it "implicitly acts as a conditional." (
> http://docs.citationstyles.org/en/stable/specification.html#group).
> <group> elements are not rendered if it contains a variable, and the
> variables are empty. When a <group> element is rendered, it can apply
> prefix before the content, apply a suffix after the content, and apply
> delimiters in between its variables.
>
> The <group> element has a clearly defined, useful role in styling data.
> However, there are several features that the <group> element lacks compared
> to the proposed <containers> element.
> First, the <group> element does not have a variable name. The <group>
> element acts as a collection of variables, but it is not a variable itself.
> Second, because the <group> element does not correspond to a variable, it
> also does not support iterating through complex data. The <names> element
> and <date> element are examples of elements that supported complex data -
> data that is represented in a nested structure. A <names> element will
> iterate through every name that is associated with that variable. The
> proposed <containers> element is functionally closer to the <names> element
> than to the <group> element. In fact, the <containers> element is fairly
> be described as a more flexible <names> element. Just you would not want to
> extend the <group> element to directly render names, I think that it would
> be just as unwise to use <group> to directly render information that a
> <containers> element should render.
>
> (3) The proposal could be generalized beyond supporting only parallel
> citations for legal users.
>
> I think that the element should be named a <containers> element, instead
> of being named <serials>. The allowed sub-elements of <containers> would be
> <container> elements. This would indicate to style designers that the
> element is to be used as a "container" for any pieces of information that
> are logically related and that are repeatable.
>
> Each <container> element would be composed of <container-part> elements.
> The <container-part> elements are directly analogous to <text> elements of
> a CSL style. <container-part> elements should follow the variable-naming
> conventions for Standard Variables from Appendix IV of the CSL
> specification. (http://docs.citationstyles.org/en/stable/specification.
> html#standard-variables).
>
> EXAMPLE REPRESENTATION
>
> <containers name="variable-name">
>
> <container>
>
> <container-part name="text-variable-name" />
>
> .....
>
> </container>
>
> </containers>
>
>
> ADDITIONAL THOUGHTS
> 1) THE PROPOSAL IS PARTIALLY BACKWARDS COMPATIBLE
>
> If adopted, new CSL styles would be able to process old data. I have
> already written a patch for citeproc-js that would support <containers>
> elements in a CSL style sheet. (81 lines of pretty simple code). My
> implementation first looks for item data under the variable-name of the
> <containers> element. If that variable-name is not found, the processor
> then looks for item data using the variable names of the <container-part>
> elements. This means that styles that use <containers> elements can still
> fully process item data, even if that data was not encoded to explicitly
> support <containers> elements.
>
>
> 2) THE PROPOSAL IS NOT FULLY BACKWARDS COMPATIBLE, AND IS NOT COMPATIBLE
> BETWEEN STYLES. THE POSSIBLE VARIABLE NAMES FOR <CONTAINERS> ELEMENTS
> SHOULD BE SPECIFIED
>
> Old style sheets would not be able to process new data that would target
> the <containers> features of CSL - unless the possible variable names for
> <containers> elements are constrained. Constraining the variable names
> would also required for compatibility between new CSL styles.
>
> It is hard to work out which variable names should be allowed for
> <containers> elements, without anticipating every use case. If I could
> speculate about a possible solution. . . Drawing inspiration from
> Bibframe's model (https://www.loc.gov/bibframe/docs/bibframe2-model.html),
> perhaps the variable name for <containers> elements should be limited to
> names such "Instances", "Events", and "Subjects".
>
>
> - Tom
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
