needed: more fields

There are more fields needed in order to complete a case and make a case law
these are to the very least:
*ECLI-number (an initiative to give all European cases a unified number) eg
ECLI:FR:CESSR:2013:355608.20130325
*short journal reference
*judge
*advocate-general

Further the distinction between author and journalist is to me very confusing. In The Netherlands we have annotators. They are neither authors nor journalists. They (lawyers, professors eg. )comment to the case for journals. There can be more journals per case.

Why journalist? Is this useful for American cases?

In addition I have some urgent suggestions for the Dutch translation. I don' t know if this is the right place for that...
  • "Journalist" may be the result of a mistranslation into Dutch.
    The English field is "reporter" which isn't a person, but the official publication where the case is published, e.g. something like "Wisconsin Reporter Second" for the US or "All England Reports" for the UK.

    I don't think we'll be able to accommodate the complexities of various international law citations in regular Zotero any time soon. Even if Zotero had fields for judge, advocate-general, and ECLI, we'd also have to make them citable - as I say, I wouldn't expect any of this to happen within the next couple of years.
    Get in touch with Frank Bennett at citationstylist.org, who runs a Zotero fork specifically dedicated to legal citations, that'll be a more promising route to go.
  • edited April 19, 2013
    @zaz: if you'd like, I can add you to Dutch translator team of Zotero. You just need to register at http://transifex.com and post your username here. See also http://www.zotero.org/support/dev/localization
  • @zaz: Is Docket Number suitable for the ECLI Number?
  • @fbennett:
    It totaly is

    @Rintze:
    Can I opt in to that too?

    @adamsmith
    "journalist" (reporter) should be translated (in the legal context) with: "Gepubliceerd in" [translated backwards: published in]
    "reporter volume" (volume) should be translated (in the legal context) with: "Uitgave, vindplaats" or "Vindplaats" [translated backwards: Issue, Location]

    The reporter-volume will actualy refer to a review or annotation in a periodical issue of legal magazines. With "Gepubliceerd in" the reference to the right magazine is made (usualy with a short abreviation of the entire name).
  • @Joel,

    It's not relevant to the current official Zotero layout, but in Multilingual Zotero I have tentatively added a "Jurisdiction" field to Journal Article, to cover the annotation practice in Japan. When present, it would indicate that the article is a comment on an official source, typically a legal case.

    I'm doubtful about this solution, however. I have seen French citations that collapse a cite to the case report itself and a series of cites to comments by academics and judges into a single, compact citation with multiple elements. To produce that formatting, we would need the full metadata in each Zotero/MLZ item, so that the processor could treat them as referring to a single case.

    Perhaps a better solution will be to add a "Commentator" or "Annotator" creator on the Case type, which when present would identify the citation as being a published comment on that particular case. What are your thoughts, from the Dutch and European perspective?
  • @Joel, sure. Just follow the instructions above, and I'll add you as a translator.
  • @fbennett

    When one would want to use an automated reference system with a certain citation style in a legal context, three main elements are important besides books/articles and so on:
    (using CSL definitions)
    - bill (create)
    - legislation (put in place)
    - legal_case (use/redefine)

    This does not differ in any legal system, not in the common law tradition nor in the civil law ('droit civil') tradition. A bill or legislation is easy to find. These two will always be on public record, for obivious reasons. What does differ is that legal_case is not always published as open as a bill or legislation. Esspecialy in the civil law tradition.

    For many (European) civil law traditions the following is true:
    Untill a few years ago only important court rulings were printed in (specialized) magazines and sometimes published in newspapers (as a part of the ruling). I think it is even fair to say that up to ten years ago that was the only way to get aware of (important) court rulings.
    Important to note is that the publication of the ruling in the magazine maybe months or even years after the court ruling. So the date of the publication is important too.
    Nowadays courts do publish some their rulings on the website of the court. Note the word 'some'. The farmost is not published in the open (yet). There is still a moderation on what is beeing published or not by the courts. This moderation goes beyond whiping out the names of victims and suspects. Because of this, there are still magazines with case law. Publishers of these magazines use open and not openly published court rulings, usualy combined with the findings of an (judicial) expert. These findings are usualy called an annotation. The name of court ruling, if there is any, is usualy based on the name the annotator would give it.

    In the (European) civil law tradition these annotations are important because they explain the somewhat cryptic/difficult sentences in the court rulings. They also explain why this court rulling (will) create a difference to the way the legislation has to be applied. Most of the time these conclusions are used to support a theory in judicial scientifcal papers (and so on). To note the (readers of the paper) that you are refering to this expert in the reference something in the reference is said like "annotated by: name". As for the opinion of the annotator, the same applies to the conclusion of the Advocate-General: something in the reference says "conclusion by: AG-name".

    To be more complete, some courts (also in Europe) have the possibility of dissenting opinions (of judges). These opinions can be interesting in judicial scientifical research aswell. They should be considered the same as an annotation or a conclusion by a AG. These dissenting opinions are mostly published with the court rulings, but sometimes printed later on in the specialized magazines.

    These days, more and more, all court rulings are published open on the internet, without any annotations. These cases will not have names, only date(s) of ruling and a sort of identifier.

    So there is a transistion between the 'old' and 'new' published court rulings.

    Most reference systems in Europe use the name of the court + date of ruling as base to reference to the right ruling, usualy combined with an identifier (which sometimes again is based on date).

    In 2010 a voluntary guideline to identify case law was set by the EU. This guideline can be found here: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:C:2011:127:0001:01:EN:HTML More and more countries in Europe are starting to adapt to that. What it basicly says is that all rulings should be marked as:
    ECLI:COUNTRY:COURT:YEAR:NUMBER
    ECLI = fixed
    COUNTRY = ISO 3166 alpha-2 (two letter country code)
    COURT = to be assigned by each country
    YEAR = 4 digits (does not have to match ISO 8601...)
    NUMBER = max 25 positions, may only include dots (.) and dashes (-).

    Besides of that there are court rulings by the
    - EU Court of Justice (= EU Institute, highest EU court)
    - EU Court of Human Rights (= NOT an EU Institute !!!)
    They use a system of (special) number/year (2 digits) as unique case idenitfier; the year usual referes to the year of application, not of ruling. This number/year combined with a date will you get the application, the conclusion by the AG, the dissenting opinion or the courts ruling.

    === OVERVIEW ===

    A 'legal_case' must have:
    - a date of ruling
    - a type of court that gave the ruling
    - a unique identifactor (numbers or strings like AE3924 or 23.392.a or C-194/94 or 39630/09)
    A 'legal_case' may have:
    - a reference to a verdict line or paragraph (when this is available in
    the ruling itself)
    - a name
    A 'legal_case' could only have been published in a magazine; then it should have:
    - the name (container_title) of the magazine that published it
    - the year of publication of that magazine
    - the volume/issue (number) of that publication

    [conclusion by AG part] A 'legal_case' may have an (optional) conclusion by the AG:
    - the name (container_title) of the magazine that published it (if not published within the court ruling)
    - the year of publication of that magazine
    - the issue (number) of the publication with the legal_case
    - the name of the AG(s)

    [dissenting opinion part] A 'legal_case' may have an (optional) dissenting opinion:
    - the name (container_title) of the magazine that published it (if not published within the court ruling)
    - the year of publication of that magazine
    - the issue (number) of the publication with the legal_case
    - the name of the dissenting judge(s)

    [annotation part] A 'legal_case' may have an (optional) annation:
    - the name (container_title) of the magazine that published it
    - the year of publication of the magazine
    - the issue (number) of the publication with the legal_case
    (these three above only when not mentioned earlier as publisher)
    - the name of the annotator(s)

    IN 'CSL/Zotero' terms that is:
    a reference of the type 'legal_case' must contain:
    - a full date from: 'issued'/'dateDecided'
    - a court: 'authority'/'court'
    - a unique identifier: 'call-number'/'callNumber' (due to the
    unpredicatable form, 'issue' would be better but 'issue' can only be a number according to the current CSL definitions)

    a reference of the type 'legal_case' may contain:
    - a specific pointer: 'section' (can be others than numbers only, but is
    a 'locator')
    - a name: 'title'/'caseName'

    When published only in a magazine it must contain:
    - the name of magazine that published it: 'container-title'
    - the date that publication: 'issued'
    - the 'volume' and/or 'issue' of that publication
    ...and may have:
    - a locator (page) within that publication

    When used, the conclusion by AG part of the reference must contain:
    - a name: 'author'
    When published this was published only in a magazine it must contain:
    - the name of magazine that published it: 'container-title'
    - the date that publication: 'issued'
    - the 'volume' and/or 'issue' of that publication
    ...and may have:
    - a locator (page) within that publication

    When used, the dissenting opinion of the reference must contain:
    - a name: 'author'
    When published this was published only in a magazine it must contain:
    - the name of magazine that published it: 'container-title'
    - the date that publication: 'issued'
    - the 'volume' and/or 'issue' of that publication
    ...and may have:
    - a locator (page) within that publication

    When used, the annotation of the reference must contain:
    - a name: 'author'
    if not already mentioned as publisher of the legal_case)
    - the name of magazine that published it: 'container-title'
    - the date that publication: 'issued'
    - the 'volume' and/or 'issue' of that publication
    ...and may have:
    - a locator (page) within that publication
  • === CSL IMPROVEMENT ===

    The following VARIABLES should be added:
    NAME VARIABLES
    - annotator (containes: name(s))
    - advocate-general (containes: name(s))
    - court (containes: title)
    - judge (containes: name(s))

    The reason why court should be distinguished from authority is to prevent misunderstanding. A authority (like a city council) can be a party involved in a legal_case. Imagine legal_case about a patent. That could have two 'authorities'.
    The reason why an annotator should be distinguished from reviewed-author is that a reviewed-author describes the quality of the item that he or she is reviewing. An annotator would typicly also explain things or give his/her opinion behind the argumentation that is used in the item (usualy: a court ruling). This is more in-depth or in a different way in-depth than review. Therefor it should be a specialized term.
    All these terms are sometimes used in (legal) reference styles, also in short of abrivition form. By setting these as terms, it becomes possible to the localization can create the correct writing/display form of these terms.

    STANDARD VARIABLES
    - indentifier (containes: all kind of input, including dashes, slahes, dots, letters, numbers)

    (sofar the easy stuff I guess)
  • edited November 5, 2013
    === REQUEST FOR NEW CSL FUNCTION ===

    Then a new sorting function should be added: hierarchy. This is an advanced function that should only be used by advanced reference style makers.

    <biblography>
    <sort>
    <key hierarchy="name_hierarchy_list"/>
    </sort>
    <layout>
    [! -- rendering elements -- ]
    </layout>
    </bibliography>



    The [hierarchy] element is a optional child element of cs:style, but must be set when hierarchy is used as key in the cs:sort within the bibliography element. It most be placed after cs:citation, but before cs:bibliography. It may appear multiple times.
    The [hierarchy] element sets a predefined sorting order for the bibliography. It gives the posibility to split out multiple types or variables, based on their content. This order is always the same, regardless of the statement of the sort-attribute, it ignores the sort-statement.
    <key hierarchy="name_hierarchy_list"/>
    <key hierarchy="name_hierarchy_list" sort="ascending"/>
    <key hierarchy="name_hierarchy_list" sort="descending"/>

    will all result in the same thing.


    A element must have a (unique) name, set by the requiered name attribute on cs:hierarchy. The hierarchy-element contains numbered child elements. There must be a first child element called [1]. The child elements may have a attribute called sortlabel. The value set on sortlabel can be used within the cs:layout to display as sort label. The numbered child elements must contain either a [type] or a [variable] child. The [type] element will return any reference that matches with one of the listed types. The [variable] element must contain the name of the variable to be tested. Each statement that must be tested must be placed within " " and seperated by a space. The [variable] element will return any reference that exactly matches (uppercase/lowercase sensitive) with one of the tested statements.
    A numbered child element that has a higher number than the previous will only test and return references that are not already returned by the previous child element(s). When a test statement does not return a result, the sortlabel is dumped. The hierarchy element must return atleast have 1 rendering element.

    <hierarchy name="first_list>
    <1 sortlabel="Used books">
    <type>book review-book</type>
    </1>
    <2 sortlabel="Important EUROPEAN case Law">
    <variable variable="authority">"ECHR" "ECJ"</variable>
    </2>
    ...
    <999> sortlabel="Garbage">
    <variable variable="keyword">"garbage"</variable>
    </999>
    </hierarchy>


    ATTENTION: References that did not match any of the test statements wihtin cs:hierarchie will not be returned. This can lead to both wanted and unwanted results. Be shure to include all wanted content. For example: I have a data-set of references; that do contain items that are not of the type: book or review-book and do not have a variable called "authority" that contains "ECHR" or "ECJ" than these items would not be in the bibliography. This can be usefull when you want to skip the 'garbage' <999> that you do not want in your bibliography. Only the system works the other way around: you have to define what you DO want in the bibliography.

    Within the cs:layout element inside of the cs:bibliography the child element cs:sortlabel can be placed. It will return the sortlabel, if provided, for each group of tested statements in the hierarchy list. It can be formatted with the regular formatting attributes.
    <biblography>
    <sort>
    <key hierarchy="first_list"/>
    </sort>
    <layout>
    <sortlabel font-weight="italic">
    <group display="block" font-weight="bold">
    <text macro="short-reference"/>
    </group>
    <text macro="long-reference"/>
    </layout>
    </bibliography>


    Will result in:
    Used books
    Short Reference book 1
    Longer reference of book 1 with some more information

    Short Reference book 2
    Longer reference of book 2 with some more information

    Important EUROPEAN case Law
    Costa/ENEL
    The famous Costa/ENEL case by the ECJ


    When all of the above is implemented, there should be no more worries about judicial things and CSL. I know that my requested function 'hierarchy' may breakdown the everlasting fallback structure of CSL where not one reference gets 'lost'; but on the other hand that could be usefull. And some reference systems even require to do so!
  • @Rintze

    My name on Transifex: joelhendriks
  • Joel,

    Thanks for this detailed overview, and for the link to the EU metadata guidance notes.

    Several of the extensions you recommend have been implemented in CSL-m, the extended version of CSL used by Multilingual Zotero (MLZ). A set of use cases is described in a book on the system that I released a few months ago (Citations, Out of the Box, available as a PDF download and in print form).

    If you are interested in style development, it would be great if you could take a look at Multilingual Zotero, and see how close it comes to covering your needs. The schema can be extended if there are specific common requirements (such as the "annotator" issue) that are not currently covered.
  • Perhaps a better solution will be to add a "Commentator" or "Annotator" creator on the Case type, which when present would identify the citation as being a published comment on that particular case. What are your thoughts, from the Dutch and European perspective?
    That could be a good solution indeed.

    @Joel Hendriks: FWIW, https://forums.zotero.org/discussion/9823/french-law-cases-droit-francais-decisions-arrets-jugements/
  • Gracile,

    I did read parts of your converstation. I noted:
    The problem I'd like to tackle is that of comments. It would be great if zotero/csl could know the relationship between a case and a journal article which comments this case
    As I mentioned above, I think this is THE problem with CSL and legal reference systems.

    In legal context it is common to combine two or more sources into one reference. CSL is based on one reference to one source. Within a typical legal reference the first source is the legal case and the magazine in which it was published is the second source (and with paralel references there could be even more sources).

    You can argue on whether that is wrong or right. The question will always remain: to what do you want to refer? Most of the time (in legal context) that will a specific paragraph in a ruling, annotation, conclusion or dissenting opinion. Personaly I think only the reference to that specific instance would do (without mentioning the legal case details). When I want to refer to comment by a annotator in a magazine, then simply refering to the right page of that magazine should do, I think.
    Other people would then argue that you cannot easily tell to what kind of court, court case and historical context (date) this comment has been made.

    Both have sometime pro's and con's. The matter of the fact is that in most (European) (judicial) academic environments you will not be heared on any alternative to the traditional way of doing. Why? Because 'this is the way we do things, always have done, and always remain doing'.
  • Frank,

    It took me some time, but I read your book (quickly). I understand why you have created MLZ, and that there was a need for that. But when I analyse it: MLZ is an adapt version of Zotero; Zotero is based on the citeproc.js; citeproc.js is based on the CSL schema.

    The potential great thing about a CSL-style is that it can be used on many platforms with many systems. I think CSL-m is a great solution for now, but the 'problem' (or: wish) must be found back in the CSL schema. I think it would be better to improve that, rahter then creating alot of sub-schema's.

    I hope this post can be the start of the development CSL 2.0 (to be finished before summer '14) and a shortterm improvement, an update: CSL 1.2. First of all, I am not a computer nerd, so I don't know alot about programming. But I guess some things are 'easy' and some things need 'work'.

    For the update I suggest that the following variables are added:
    - annotator (containes: name(s))
    - advocate-general (containes: name(s))
    - court (containes: title)
    - judge (containes: name(s))
    - indentifier (containes: all kind of input, including dashes, slahes, dots, letters, numbers)

    For CSL 2.0 I suggest three things should be added:

    1. Citation Specific Terms
    One of the problems right now is that citation style creators want to use more terms then there are available right now. A huge example for that are the abbrivations.

    Besides the "Locators", "Months", "Ordinals", "Question marks", "Roles", "Seasons" and "Miscellaneous" (the pre-defined terms) a citation style may set their own terms. These terms can be manipulated with the localization options to display the correct abbrivied (verb-short), shorter (short) or normal (long) text (names...) version.

    2. Citation Specific Mapping
    Right now the citation style handlers (Mendeley, MLZ, Zotero) determ in which way items should be mapped. I guess computers need mapping to display things in the right order. But why should a citation style handler deside which mapping is needed for that specific citation style? In essence this should not be decided by the citation style handler anyway. This should be provided by the citation style. The citation style itself knows best how items should be mapped according to that reference style. In a stylesheet that would look like this:
    ===EXAMPLE===
    <mapping>
    <article>
    <must-have>author title issued</must-have>
    <may-have>publisher publisher-place</may-have>
    </article>
    <book>
    <must-have>author title issued</must-have>
    <may-have>publisher publisher-place</may-have>
    <may-contain>
    <article>
    <must-have>author title</must-have>
    <may-have>publisher issue</may-have>
    </article>
    </may-contain>
    </book>
    <legal_case>
    <must-have>jurisdiction authority issued call-number</must-have>
    <may-have>container-title publisher publisher-place</may-have>
    <may-contain>article</may-contain>
    </legal_case>
    </mapping>

    A citation style handler may have a back-up mapping (for types that do not have a mapping within the used citation style), but should respect the mapping of the citation style at all times.

    With the mapping it should be possible to 'nest' types within types. The nested typed inherents the properties of the original mapped type; but can be overruled by setting new mapping within.

    3. Hierarchy
    See my post above to explain this. Short example of it in a stylesheet:
    ===EXAMPLE===
    <hierarchy name="first_list>
    <1 sortlabel="Used books">
    <type>book review-book</type>
    </1>
    <2 sortlabel="Important EUROPEAN case Law">
    <variable variable="authority">"ECHR" "ECJ"</variable>
    </2>
    ...
    <999> sortlabel="Garbage">
    <variable variable="keyword">"garbage"</variable>
    </999>
    </hierarchy>
  • 1. there is a good chance we'll do and that wouldn't even require CSL 2.0 - that's a pretty trivial change - there are some comments on that and a proposal by aurimas.

    2. I disagree with. It still doesn't solve the issue of mapping - i.e. how fields in different ref managers are mapped to CSL variable and it creates a lot of complications for something that isn't even strictly necessary - if you don't want a variable to appear for an item type, don't call it for that item type.
    The problem here is more a result of the fact that different ref managers do already impose such restrictions via the available fields and that because of that styles don't always travel as well as they should (one example are e.g. publisher and place for journals, which simply don't exist for journal articles in Zotero). I think there is a good case to be made for CSL to presribe to ref managers which fields should be mapped per item type, so that styles produce similar results across implementations, but there is no way to do that without the ref manager side (not to speak of the _huge_ costs of implementing this

    3. I'd like better functionality for sectioned bibliographies, but I'm not sure we should handle that in CSL. The possibilities for how such things are sectioned are almost limitless and we'd have to allow for so much hackish matching on all types of variable - many that don't exist and map awkwardly in different reference managers (think Zotero collections) - there is a good case to be made for having this handled by the implementation and not the style.
  • Oh - and to be realistic - CSL 2.0 is not going to happen in a year. If we're lucky we get 1.2 released by next summer

    But all of this should happen on xbiblio, where more than just zotero people follow along:
    https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
    archive: xbiblio-devel.2463403.n2.nabble.com
  • edited November 6, 2013
    but there is no way to do that without the ref manager side (not to speak of the _huge_ costs of implementing this
    Like I said, I don't know alot about writing applications. But 'ref manager side' must have mapping inside I guess to make it work. And (maybe a dumb as I am) if it is inside, why not outside?

    Anyway, I will register and post it on xbiblio-devel.
  • And (maybe a dumb as I am) if it is inside, why not outside?
    to start with, because not all ref managers have the same names for fields or even item types. But also simply because of programming - these are database fields that need to be written to variables - that needs to happen in the software, some of which (Mendeley, Quiqqa, Papers) is proprietary. We can certainly make suggestions - we do - but this can't be written into a CSL styles while keeping the nice modular way - ref-manager -- citeprocs -- citation styles - this is set up.
  • I think it would be better to improve [CSL], rather then creating alot of sub-schema's.
    There seems to be some misunderstanding. No one said anything about creating a lot of sub-schemas.

    The CSL language is implemented by multiple processors used in many separate projects, and it is relied upon day-to-day by thousands of users. Because small problems can create cascading headaches for lots of people, the CSL schema development process (as adamsmith says) is deliberate and careful, and tends to be incremental.

    From the CSL perspective, legal support is a hard sell because it will require extensive, tightly coordinated (and therefore potentially risky) changes to the language. The aim of MLZ and CSL-m is to put an extended system into the hands of researchers in the field, so that its usability can be verified with a view to eventual adoption by official CSL. CSL-m is not intended as permanent fork of CSL.

    In other words, the idea is to harness the knowledge of users in the field to build out a satisfactory working system, based on experience with specific use cases. That is how official Zotero and official CSL themselves have grown to be such strong tools in other research fields: and it stands in contrast to the "waterfall" approach adopted by a large number of previous legal metadata initiatives, which have shown a remarkable tendency to stumble before actual implementation -- and to be limited to a single jurisdiction or a single vendor's product when they don't.

    So bear with us: CSL-m is actually a part of the process that you are wanting to push forward.

    In any case, adamsmith is right that the place for these develpment discussions is the xbiblio-devel list.
  • zaz
    edited January 7, 2014
    I promiss to look here more often, thanks everyone and I registered hmyself as a translator,

    Docket number and ECLI are NOT thesame.
    Great news, it is some sort of working for all dutch cases, viz www.rechtspraak.nl since very recently
    http://uitspraken.rechtspraak.nl/inziendocument?id=ECLI:NL:GHARL:2013:6675
    There you can also see the difference between ecli and the court case number. may be in future ecli and the zaaknummer/court case number/docketnumber will be thesame but as of today every court has its own registry number alongside the ECLI number. I think this is true almost everywhere in Europe.
    I see there is a lot of work to be done, but I think If it works in some European countries, others soon follow.
Sign In or Register to comment.