schema
schema copied to clipboard
citation-style-language
Identifiers
Identifiers are awkward to format currently, for want of variables and locators to house and describe them. A proposal for a flexible set of descriptive locale terms and specific variables for common identifiers is here: http://groups.google.com/group/zotero-legal/web/proposal-identifiers
- Bitbucket: https://bitbucket.org/bdarcus/csl-schema/issue/17
- Originally Reported By: Frank Bennett
- Originally Created At: 2009-12-29 02:42:54
Why not just let the value of a document identifier be "U.N. Sales No. S.02.II.G.47"? It may not ideal, but it seems more practical than adding tons of these on an ad-hoc basis.
Original Comment By: Bruce D'Arcus
Note that the example citation uses two document identifiers ("U.N. Doc. LC/G.2178-P, U.N. Sales No. S.02.II.G.47"). If you add the label to the identifier field, you can either use a single variable ("U.N. Doc. LC/G.2178-P, U.N. Sales No. S.02.II.G.47"), or two ("U.N. Doc. LC/G.2178-P" and "U.N. Sales No. S.02.II.G.47"). In both cases you lose localization of the label, and (re-)ordering of the two identifiers becomes non-trivial.
What would be the downsides of having a few tens of identifiers? The added burden on the BabelZilla translators? Or the moderation which identifiers get added, and which don't?
Original Comment By: Rintze Zelle
In both cases you lose localization of the label, and (re-)ordering of the two identifiers becomes non-trivial.
In addition, you of course lose the semantic annotation, which might be the biggest loss.
Original Comment By: Rintze Zelle
OK, but realistically, how are we supposed to manage adding all the possible identifiers across UIs, databases, BIBO, CSL schema and styles?
Original Comment By: Bruce D'Arcus
UIs: for Zotero, a dropdown menu has been suggested (http://forums.zotero.org/discussion/5404/pubmed- id/?Focus=26427#Comment_26427). If things get really crowded, you always could go multiple levels [Life Sciences (pmid, pmcid), Math (mathreviews, zentralblatt), UN (un-sales-number, un-document-number)]
databases: as long as we don't weekly release a new version of CSL with new identifiers, I don't know why this shouldn't be manageable.
styles: I don't think there is a good way to use these identifiers now, so people probably won't complain when styles have to be modified to take advantage of the new identifiers.
id/?Focus=26427#Comment_26427
Original Comment By: Rintze Zelle
I have less issue with things like pubmed id numbers than I do with the UN stuff. Notwithstanding CSL, there seems something fundamentally wrong about calling an id for a document that just happens to be published by the UN be called a "un-document-number". ATM, I see two alternatives:
- simply not supporting this
- adding the ability to test for variable content (if publisher = "UN" ...)
Am not really anxious to do the latter.
Original Comment By: Bruce D'Arcus
- Use more generic variables (e.g. sales-number or order-number instead of un-sales-number)?
The UN document number has its own Wikipedia page though, so it must be important ;) http://en.wikipedia.org/wiki/United_Nations_Document_Codes
Original Comment By: Rintze Zelle
A fourth alternative would be to add a second generic number field, and give us a specific item type for U.N. Sales Documents. At the moment, one U.N. institution is telling people to put the extra number in the Zotero "Extra" field. I'd like to head that one off at the pass, before the data situation starts getting out of hand.
Original Comment By: Frank Bennett
Ah. One point that might simplify the discussion is that the sticking point for cite formatting is the lack of a variable for "U.N. Sales Number". The "U.N. Document Number" is something else, and can be handled as generic "number", with "authority" set to "United Nations", as suggested for generic institutional filing system numbers in the proposal. Documents that have a U.N. Sales Number are things (mostly books, but also videos, audiotapes, etc.) for which the U.N. serves as publisher.
Original Comment By: Frank Bennett
There was finally some discussion of this on the BIBO list, but no obvious resolution ATM.
Original Comment By: Bruce D'Arcus
Slightly getting ahead of things, maybe, but this may be relevant to the discussion: http://forums.zotero.org/discussion/8874/getting-journal- abbreviations-from-a-repository/#Comment_49446
A mechanism that allows users to specify abbreviations could be used to furnish user-defined label texts to go with user-defined identifiers. As described in the note linked above, identifiers in use could be marshalled, and either added to the "officially recognized" list, or published in a set of "recommended" identifiers. The workflow described would require infrastructure (the note floats a suggestion for doing this through Zotero), but it would avoid the awkwardness and inflexibility of relying of hardwired variables and locale terms for identifier support.
(As a note to file, if in the end number is converted to a graphed variable similar to creators, I would ask that there be two such fields, since U.N. materials (and probably other resources out there) require to identifying numbers in the citation.)
abbreviations-from-a-repository/#Comment_49446
Original Comment By: Frank Bennett
With discussion unfolding on bibo, everyone is happy to see the treatment of identifiers postponed to the next cycle. Shifting this ticket to 1.1.
Original Comment By: Frank Bennett
Any news from Bibo? Would be nice to have a little flexibility over the handling identifiers, so that we can format citations to U.N. documents. It's a big organization, they publish a lot of stuff.
Original Comment By: Frank Bennett
I still remain uncomfortable with the options here. We need to make a final decision sometime before 1.1, but am still not sure what the best approach is.
Original Comment By: Bruce D'Arcus
There may be some hope with this:
http://tools.ietf.org/html/draft-spinosa-urn-lex-03
My worry would be that it may be many years before the proposal bears fruit.
This issues discussed here would be incidentally addressed by the patch under this ticket, available for preview here (see the note at the bottom, after the patch).
(Edit: link to patch dropped. The relevant branch has been deleted, although github apparently retained the patch object.)