International Treaties and UN Documents

Hello all,
Does anybody know what is the best way to get international treaties, and UN documents into Zotero?
Thanks,
Pini
  • These will require additional fields, I think, and they are important categories that need to be covered. Starting from an analogous entry type (Statute?), could you provide a list of the fields that you think would be required for each? Pinning this down will be an important first step toward providing this support, both for storage and for formatting.
  • Hi,

    Thanks for your interest on this. Here is a few information :

    - Title (already exist)
    - Members/Authors (Similar to author, but those are countries)
    - Members (Countries who accessed after it officially took place)
    - Signature date (text approval and open for ratification)
    - Ratfication date (entered into force...)
    - Code for reference...
    - Institution (Sometime applies : WTO, UN, etc.)
    - website (okay)
    - Database name

    I'll check again later tonight, but that should be enough.
    Sometime, all these info are not required and members who are authors and members who join the treaty afterward are list together. Sometime, it is needed to seperate them. Sometime we don't even use that info.

    Thanks!
  • As an example,

    - Title : Treaty relating to Boundary Waters and Questions Araising with Canada,
    - Parties (if applicable) : United-States and United Kingdom
    - Date of signature : 11 January 1909
    - Treaty series reference : 36 U.S. Stat. 2448
    - Parallel citation : U.K.T.S. 1910 No. 23.

    That's for a bilateral treaty, otherwise you won't put all parties (especially not 150 countries...!), but you'll need :
    - Institution : ECHR (European Court of Human Right)
    - The date of entry into force
    - The number of ratification

    And well, sometime you need to add the statut of a particular country, but that could go into "extra" or be entered manually as it might be very specific to that footnote or refence - specifically linked with your text. For exemple, I often cite the Vienna Convention on Treaties, so... signature was done in 1969, it entered into force in 1980 (a treaty sometime has a minimal amount of signature/ratification before it enters into force), but the specific country I talked about only ratified the treaty in 1998.


    UN meetings would need those information :
    - UN body's accronym : UNCTAD
    - session number or the number of year since the body inscription: 23d Sess.
    - meeting : 565th Mtg.
    - UN doc no. (and sale no. if applicable) : UN Doc. TB/B/SR.565
    - Year of document
    - Pinpoint
    ...and I sometime add special mention when it is provisionnal.

    Furthermore, UN Resolutions, decisions and reports appear as supplements to documents published in the Official Records.
    So you need these informations :
    - Author : Commission on crime...tada...tada...
    - Title : Report on the Ninth session (the session is sometime part of the title, so then insead of session number later on you put calendar year)**
    - UN body resolution/decision number :
    - UN body's accronym :
    - Session number or calendar year**
    - Supplement number
    - UN doc. number
    - Calendar year
    - First page and pinpoint

    For annexes, it usually replaces the supplement number by the mention "annex, agenda Item 6", etc.

    So... I guess you got it all...

    Right now... we usually have enough fields already to do it... but you have to twist your mind a little bit to make it work... actually it's not really pleasant because you have to remember (or have it note somewhere) that this field replaces this one... that other one replaces that, and this to that and etc, which ends up being a mess... especially if that's me doing it. ;)

    What do you say? Do you have all you need?
    Statute (legal act = acte juridique) has already a bunch of fields and is a good starting point but you might prefer "report" which is the one I use for those annoying UN docs.

    You can ask for my e-mail address if you need.

    Thanks!
  • Has this been followed up?
  • edited August 18, 2011
    It is being followed, but pings are always welcome (I hadn't bookmarked this thread, but I have now).

    Some of this can't be handled by CSL 1.0. In particular:
    UN document numbers
    These, and document numbers of other international organizations such as the WTO, require labels in the cite that are specific to the organization, such as "UN doc. no. XXX".
    Acronyms of institutional names
    Institution names are treated as a single "family" name; it is not possible to place both the long form of the name and an acronym in the same citation.
    Jurisdiction-specific formatting
    A general issue with cites to primary legal materials is the need to vary the form of citation according to the issuing jurisdiction. Zotero now passes the "jurisdiction" variable to citeproc-js, but in CSL 1.0 there is no means of handling it.
    To address these issues, several things are needed:
    • Fields and mappings in Zotero that provide sufficient information to cite these categories of material correctly (there is a thread for this, but the fields that need to be requested depend on solutions to the remaining items in this list, hence this has come last in time.
    • Ways of expressing the necessary cite forms in CSL need to be settled, and cast into the CSL schema, so that styles with the extended syntax can be validated. An extended version of the CSL schema is now available for this purpose (click on the "Switch branches" link to see a list of the various changes to the official schema).
    • The schema extensions need to be documented, so that designers of legal styles know how to use them. I'm working on this documentation now.
    • The extensions need to be implemented. This is now done for the citeproc-js processor used by Zotero.
    Abbreviations and acronyms can be handled by a third-party plugin that interfaces with the CSL processor. I'll be putting together such a plugin in due course, which will enable the institutional names functionality mentioned above.

    So things are on track, but it will be awhile before everything comes together in a working package.

    To help everyone stay on the same page in legal (and multilingual) development, I'm working on a (simple) site for tying the various bits and pieces described above together in one location. More news on that in a few days.
  • edited August 22, 2011
    The site mentioned above is now ready. It is a read-only site for disseminating information about the state of play in legal and multilingual style development, with information on the tools to be used for collaborative development. The site is a first draft. Please feel free to comment here (in a fresh thread) if it is not clear, or if you spot something that is missing.

    (Edit: name of the site has been changed since the initial post, but browsers should seamlessly redirect to the new address, which is http://citationstylist.org/.)
  • Nice work on all this, people.

    May I just add my international lawyer's two cents on a couple of little things:

    1. For treaties, sure it would be better and more elegant to have a specific item type, but if this is not possible the only thing that makes existing Zotero item types lkike "Statute" difficult to use IMO is the necessity for two dates (adoption and entry into force). Otherwise it's simply a matter of adding the parties names onto the treaty (statute) name for bilateral treaties and not for multilateral treaties and putting the UNTS or other reference in the Code field. The problem is that the second date (which is not the same thing as the "ratification date" (impliedly of a certain State) as suggested above), needs to be a date field for all treaties that have entered into force and simply be cited as (not yet in force) for those which haven't. Is there a way a citation style can interpret a blank date field to add the text "(not yet in force)"?

    2. For decisions of IOs, I would suggest keeping the fields as general as possible and that we just type "UN Doc ***" or "WT/***" ourselves. I think the key fields here would be the date and the name of the specific body which made the decisions. General fields are the way to go here, even if they require a bit more data entry in the first couple of year. I think it would be dangerous to create something specific for the UN, because then it might not work for other international organisations and we'd be stuck creating specific fields for all of the many organisations.

    If I can do anything to help, please let me know on this thread.

    Thanks again.
  • Proofsheets for treaty cites in the six citation styles covered by the MLZ Zotero for Law project are now available. Full document and a fuller set of example cites will be forthcoming later, but the early proofs show the processor working with this category of material. The parallel citation example may be of particular interest.
  • Thanks for this, Frank, your legal version really seems to be coming along -- which is great news.

    I had a little bit of difficulty understanding the proof-sheets, but it seems that you envisage creating a new Item type "Treaty" and then adapting the citation styles around it. Is this correct?

    If this is the case, do you have a list of all of the Zotero fields that would be available for a treaty item (Name/ Abstract / Code / Date adopted / Date entered into force etc) that we could comment on?

    The treaty citations on the proof-sheets seem to be working quite well, other than the strange way they refer to the pinpoint reference. There's a problem with "Article" again. It seems very odd to have an "article" number in a separate field to the pinpoint reference itself as the most specific pinpoint reference will usually be to an article, ie. something like "Vienna Convention on the Law of Treaties (opened for signature 23 May 1969 entered into force 27
    January 1980) 1155 UNTS 331, Art 41" or "General Agreement on Tariffs and Trade (adopted 30 October 1947), 55 UNTS 194; 61 Stat pt 5; TIAS No 1700, Art XXIV(8)(a)(i)".

    Obviously Zotero (or even multilingual Zotero) isn't going to be able to handle multi-levelled pinpoint references, so "Ibid." won't be marked for a next reference referring to "Art XXIV(8)(b)" instead of "Art XXIV(8)(a)(i)", but that's ok. I just don't see why, in the examples in your proof-sheets, "art X" is often followed by a number or a chapter or paragraph reference (this would always be part of the article pinpoint reference).

    I hope I managed to make myself clear, please let me know if it's not!
  • edited May 19, 2012
    a new Item type "Treaty"
    Yes indeed. Treaties have too many special characteristics to be handled through existing types. The weird syntax in the Extra field is currently used to force the item type to "treaty", but the need for that will go away eventually.
    a list of ... Zotero fields ... that we could comment on?
    Once the basic cite examples are done at the end of the month, I'll begin putting together more systematic field lists, but for this type I've extended CSL with one additional date variable, so that for dates we have:

    Date adopted = original-date
    Date opened for signature = available-date
    Signing date = event-date
    Effective date = issued
    There's a problem with "Article" again. ... "Ibid." won't be marked for a next reference referring to "Art XXIV(8)(b)" instead of "Art XXIV(8)(a)(i)
    There is some good news on this front. The processor constructs an internal ID for bill, legislation and statute items, based on item metadata, and uses this instead of the Zotero ID when evaluating back-references for these types only. This gives us the best of two worlds: fine-grained storage of statutory and treaty provisions for research management in Zotero, and correct generation of "ibid" and "supra" references.

    The pinpoint set in the "section" variable provides a starting point for the item. An optional leading label marker is mapped through to the CSL "label" variable (so the style can render the "art." as "Art." or "Article" as required), and the content is mapped to the CSL "locator" variable. It's not shown in these examples, but the user-provided locator string (i.e. the pinpoint entered via the word processor) attaches sensibly to this starting point, so by setting "(1)(a)" in the locator field you would get "art. X(1)(a)". [edit: A little documentation on how pinpoints work is needed, but it's been reasonably well tested, and should be flexible enough to fit requirements.]

    When hooked up to site translators this should work out very nicely. I've prepared a short (12-minute) screencast covering client installation, item acquisition and insertion of a reference into a document. With per-section items in the Zotero database, we can contemplate things like relation graphs to illustrate how treaty articles, statutory provisions, administrative orders and law cases tie together to form the law on a particular topic. Semantic web, here we come.
  • Hi Frank,

    I'm trying to get my head around the ins and outs of your legal version this evening. I had a lot more difficulty understanding the OpenCongress.org screencast than the "Demo of Experimental Law Support in Zotero", probably because I'm not a US lawyer.

    However, it seems to me that the client envisages entering statutory provisions separately, which seems to be able to be done for US legislation through opencongress.org. I see the appeal in such a system and it seems to work well for back references (around 8:00 on the screencast). However, I just hope that this way of citing isn't built into the new client as the only way of citing legislation / legislation style instruments, because it would be a huge hassle to have to make separate Zotero items for different provisions of instruments that can't be captured separately like they can be for many US instruments on opencongress.org.

    Will there a way of back-referencing different sections (or articles) of the same instrument simply by using the same Zotero item but entering a different, potentially multi-levelled pinpoint?

    I hope I haven't completely misunderstood what you were saying. I will probably understand better when I can see it and will be happy to be a guinea pig for you!
  • Julian: thanks for this feedback. That's it, yes. Currently, the client refuses to recognize the user-entered locator unless there is a preloaded value in the Section field. I can see the case against this nannyism, and I'll loosen that up when the next release comes out (probably this weekend).
  • Great work Frank, I look forward to seeing the next release.
Sign In or Register to comment.