I'm in support of being able to specify in the style which abbreviation list should be used. I think that implies that abbreviation is closely connected to CSL, but I don't see any reason why the lists couldn't be stored in JSON or another compact format.
If we consider abbreviation part of CSL (and I'm not convinced we do) ...
I'm a little unsure of the exact meaning of "part of CSL". There are two layers: (a) the inclusion of an option in CSL markup to specify an abbreviation list by URI; and (b) the performance of substitutions by the CSL processor. It seems hard to avoid adopting (a), since abbreviation conventions are dictated in the original citation styles meant to be coded in CSL. If (a) is accepted, I think (b) comes with it, no?
I'm in support of being able to specify in the style which abbreviation list should be used. I think that implies that abbreviation is closely connected to CSL,
Not necessarily.
... but I don't see any reason why the lists couldn't be stored in JSON.
As I suggested, it really depends on what the processing expectations are. If the CSL processor expects to get data already abbreviated, then the format doesn't matter. If the CSL processor has to do the abbreviation, JSON is convenient and fast for most languages (Python, Javascript, etc.), but is unintelligible in XSLT.
I'm a little unsure of the exact meaning of "part of CSL".
The question is, which software agent is responsible for abbreviation. It's feasible that the CSL processor passes the client app the abbreviation URI, and that app ships pre-abbreviated data.
The question is, which software agent is responsible for abbreviation. It's feasible that the CSL processor passes the client app the abbreviation URI, and that app ships pre-abbreviated data.
Okay, I follow. If abbreviation lists are to be bundled and distributed with CSL or with CSL styles (which seems to make sense, for consistency and clarity), it probably does make sense to code them as XML. An application can choose to convert and store them in some other form (like JSON) upon installation for ease of processing, so there's no real conflict there.
That leaves the question of whether to provide a global option to identify an abbreviation list by URI.
I couldn't really follow the technicalities in the thread - but I think the following possibility was not discussed:
"Cascading" (like in the CSS) abbreviation lists. Say, the ApJ http://forums.zotero.org/discussion/8278/text-substitution/ abbr.list may contain one or two special items (Astrophysical Journal = ApJ), and otherwise refer to some general IOP abbr. list.
Here's a proposal for both a short term and a long term solution.
The starting point would be to give the processor a list name, rather than the list itself, which by default would be (say) "default". The preferred list to use would be configurable through the Zotero preferences screen, and a specific list name could be associated with a style through the style selection widget in the plugins.
The processor can snoop the content of variables in the context of cite rendering. When the short form of an institution name, periodical title or series name is requested, the processor can issue a call that Zotero translates into an sqlite query against a table of abbreviations, which would be empty on a freshly installed system. (Sorry for all the implementation talk, it helps me to keep things straight.)
When the query fails, Zotero can open an entry in the table, using the list name, the category of name, and the long form of the name as keys. A popup, callable from the word processor plugins, would present a classified list of all entries in a given named list, with the full name to the left, and an editable field (initially empty) to the right. User enters the desired abbreviation for each item, and the next time the document is run, the short forms are used where they are required.
This would give users an immediate solution that would save time. It could be purely local at the outset, but if the associations between lists and styles were also saved, you could later use zotero.org as a platform for sharing and consolidating "master" lists for each style. In the end, this could get you a nice triple-store (if that's the word) of names and abbreviations, unencumbered by restrictive copyright terms, and without any one individual or institution having to take on the thankless task of sorting through many thousands of abbreviations and assigning them to this or that style.
I realize that this would require a lot of burdensome infrastructure work in Zotero; but I think that users (including me!) would be really delighted to have an immediate solution to the abbreviations problem that they can control locally. (Plus, it's probably needed anyway; without an autonomous solution in the client, it seems unlikely that we're going to see comprehensive master abbreviation lists for all names used in all journals of all fields in all languages in all countries anytime soon.)
This same approach could be used to provide "hereinafter" forms for subsequent references to selected resources. The shortTitle field is not really appropriate for this purpose, because the chosen form can be very document-specific. If the same abbreviations screen were to present a list of titles, user could enter back-reference forms, and Zotero could make them available to the processor on the next run, via a (yet to be discussed) hereinafter variable dedicated to that purpose.
Both abbreviation lists and hereinafter forms associated directly with a particular document would be good candidates for embedding, when and if it becomes possible to embed metadata in the target document.
How about a much simpler approach: most scholars work with with only 20-30 journals.
So build a module to create a list (20-30 items) of all the *unique* full journal names (Publications) *in their database*, and their corresponding short forms. Display that to the user.
If there is no short form, allow the user to enter it.
Then have an "Apply" button/method that puts the appropriate short form into Journal Abbr. field of every record.
The processor-side infrastructure for the solution I described above is implemented and ready to go. [1][2]
It wouldn't take significantly more work (possibly less) to tie into this infrastructure, and it would be less risky (because it would not touch user data). In either case, you need a popup, it needs to provide for the editing of entries, and the content needs to be reflected in the database somewhere.
A working solution can be provided by a completely separate Firefox plugin that slightly extends the Zotero document preferences popup (with a tab or button that calls up a list management interface), and provides a little glue code that interacts with the citeproc-js processor. I need this personally, so when I get to it, I'll build the thing and post back here.
As far as I can tell, a separate-plugin approach will not conflict with the other suggestions posted to this thread (shipping lists with Zotero proper, supporting abbreviation list URIs in the CSL schema, implementing a cascading fallback mechanism, coding lists in JSON, or in XML, or whatever). When other tools take over the task, the (also yet-to-be-written) abbreviation plugin can be decommissioned.
A working solution can be provided by a completely separate Firefox plugin that slightly extends the Zotero document preferences popup (with a tab or button that calls up a list management interface), and provides a little glue code that interacts with the citeproc-js processor. I need this personally, so when I get to it, I'll build the thing and post back here.
The thing is now built and ready for trial download. The gadget is a companion plugin to Zotero, that introduces an extension to the "Classic View" of the citation add/edit plugin (the interface isn't ideal, but good enough for testing).
The tool adopts the approach I described above, presenting an editable list of field strings that can be abbreviated in the current document, which is stored in a persistent database and associated with the target style. Lists are not distributed with the plugin (in part for legal reasons), and there is no provision for fetching lists from a central source, but a user's personal lists can be exported and imported in JSON format.
This is a new direction for the processor, and there will no doubt be things to iron out. Let me know if you give the plugin a try and find things that might want fixing.
I need to use journal abbreviations matching CASSI or Biosis, so your Word plug in looks really useful. Thanks for your work on it.
I downloaded the plug in and restarted Word and firefox. I couldn't find any alterations to the Word citation dialogue boxes so I can't use it. This is sad.
Do you know what I might be doing wrong? What is the most up to date version of the citation abbreviation software?
Thanks,
Charlie
I am using Windows 7, Word Professional 2010 version 14.0.6112.5000 (32 bit), Zotero 3.0.3 and Firefox 10.0.2. Cripes, that is a lot of different packages!
If the plug-in to automatically do the journal abbreviations is not working for me, what would you suggest is the best way of doing this for me at the moment?
I suppose I should enter the Journal Abbr field for each of the papers according to the advice from the journal I am submitting to.
Friends I know who use Bibtex in Latex documents tell me they are able to do these abbreviation automatically. I don't suppose it is straightforward to use this with a word document.
Right now the best option is probably to work with the Journal abbr. field. The purpose of Frank's plugin is to make that obsolete, but it's still in it's early stages, I don't think we have abbreviation lists etc.
But Frank, if you could run us through how to actually use the plugin at least for testing that'd be helpful. E.g. I have no idea where to put the abbreviation lists.
Very glad to see interest in the plugin -- and thanks for pointing out the breakage. The plugin was using a shotgun method for detecting the Firefox version, that broke somewhere around FF10. It's fixed now, and things should work (with either MLZ or official Zotero) if you reinstall.
The existing documentation is available in the draft text of a book I'm working on (at page 93 of the current draft) that covers legal and multilingual functionality in MLZ. The UI of the plugin is a little quirky, but it seems to work.
The book chapter talks about distributed abbreviation lists. Some are available, but they're still in flux, and the lists I've cooked up so far are specific to a couple of legal styles. You'll need to build your own through the UI (or by brewing up JSON files), but import and export work as documented, so you can exchange lists between systems. The lists are style-specific and held in a separate SQLite database controlled by the plugin, so you should be able to register many thousands of abbreviations without a significant impact on performance.
Then, as far as I understand, it is not possible to import lists such as
http://images.isiknowledge.com/WOK45/help/WOS/A_abrvjt.html http://www.cas.org/expertise/cascontent/caplus/corejournals.html
http://www.bioscience.org/atlases/jourabbr/r.htm
http://www.efm.leeds.ac.uk/~mark/ISIabbr
Also, it's confusing having a Cancel button only. I write the abbreviations in the right panels, but what should I click next?
By now I just hit return, but the journal names do not get abbreviated in the reference list.
Using 3.03.r10880
firefox 9.0.1, ubuntu 10.04, LibreOffice 3.5.0
Build ID: 350m1(Build:13)
(Dan: I think this was because of
http://forums.zotero.org/discussion/21879/libreoffice-plugin-throws-an-error-after-clicking-the-ok-button-in-classic-add-citation-dialog/#Item_19
How should I revert? Uninstall and install again through firefox? Am I putting at risk my database or my references in the article?)
As for the plugin, yes, it does need an OK button. The popup also should not close when Enter is pressed in a field.
Data can be imported if it is refactored as an appropriate JSON structure, which shouldn't be terribly difficult.
I'm able to reproduce the fault with abbreviations not being reflected in citations (which sort of defeats the purpose of the thing, doesn't it). The cause apparently lies in an excessivly complicated approach that I adopted for controlling output transformations. It can be simplified, and I've now started on the work. Should have it done tomorrow. A release will follow, and the plugin should start working with the next Zotero minor release. Thanks for testing!
Thank you for making it!
Anyway, is this plugin going to work for an existing bibliography or
is the user supposed to have the abbreviation made when the reference is inserted?
Perhaps, if the way zotero works is by relying on the Abbreviation field of the library, it would be easier designing a tool that would fill those fields automatically by reading the dictionary.
Also, I can try to make the JSON structures for the tables that I mentioned, where is it explained?
Agus
Anyway, is this plugin going to work for an existing bibliography or is the user supposed to have the abbreviation made when the reference is inserted?
The plugin works for an existing bibliography (made with zotero).
Perhaps, if the way zotero works is by relying on the Abbreviation field of the library, it would be easier designing a tool that would fill those fields automatically by reading the dictionary.
Different journals ask for different abbreviations. Fbennett's plugin is flexible because it does not rely on zotero metadata (abbr. field).
@alobo: Gracile is right, the plugin works normally with Zotero 3.0; we were being deceived by a "feature" that I have now removed from the processor (at version 1.0.298, which will find its way into Zotero in due course).
The output transformation code that I mentioned earlier did need to be simplified, and that's also included in the 1.0.298 release. It doesn't change the behavior of the processor, though.
What was happening is that all available item fields were being registered for use by the plugin. This caused them to appear in the plugin listing, even if the style did not apply form="short" to them in rendered output. Abbreviation is not performed on fields without form="short", though, so setting an abbreviation on some items visible in the listings would have no effect.
The JSON format isn't documented yet, but you can follow the pattern of this file, putting journal abbreviations in the container-title segment.
As Gracile has noted, this is still in development. If you run into any further snags, feel free to give a shout.
I played around with the plugin. After installing the oscola style and importing the abbreviation list it works and it is nice. But than I tried to import a new list it was not possible. Not overwriting not filling gaps not replacing. adding new abbrev. to the list works only by via the panel. And deleting or changing the abbrev is also only working via the panel. I tried it with 3.0.3.
Upgrade Storage
http://stackoverflow.com/questions/559296/java-implementation-of-json-to-xml-conversion
That leaves the question of whether to provide a global option to identify an abbreviation list by URI.
"Cascading" (like in the CSS) abbreviation lists. Say, the ApJ http://forums.zotero.org/discussion/8278/text-substitution/ abbr.list may contain one or two special items (Astrophysical Journal = ApJ), and otherwise refer to some general IOP abbr. list.
The starting point would be to give the processor a list name, rather than the list itself, which by default would be (say) "default". The preferred list to use would be configurable through the Zotero preferences screen, and a specific list name could be associated with a style through the style selection widget in the plugins.
The processor can snoop the content of variables in the context of cite rendering. When the short form of an institution name, periodical title or series name is requested, the processor can issue a call that Zotero translates into an sqlite query against a table of abbreviations, which would be empty on a freshly installed system. (Sorry for all the implementation talk, it helps me to keep things straight.)
When the query fails, Zotero can open an entry in the table, using the list name, the category of name, and the long form of the name as keys. A popup, callable from the word processor plugins, would present a classified list of all entries in a given named list, with the full name to the left, and an editable field (initially empty) to the right. User enters the desired abbreviation for each item, and the next time the document is run, the short forms are used where they are required.
This would give users an immediate solution that would save time. It could be purely local at the outset, but if the associations between lists and styles were also saved, you could later use zotero.org as a platform for sharing and consolidating "master" lists for each style. In the end, this could get you a nice triple-store (if that's the word) of names and abbreviations, unencumbered by restrictive copyright terms, and without any one individual or institution having to take on the thankless task of sorting through many thousands of abbreviations and assigning them to this or that style.
I realize that this would require a lot of burdensome infrastructure work in Zotero; but I think that users (including me!) would be really delighted to have an immediate solution to the abbreviations problem that they can control locally. (Plus, it's probably needed anyway; without an autonomous solution in the client, it seems unlikely that we're going to see comprehensive master abbreviation lists for all names used in all journals of all fields in all languages in all countries anytime soon.)
Both abbreviation lists and hereinafter forms associated directly with a particular document would be good candidates for embedding, when and if it becomes possible to embed metadata in the target document.
So build a module to create a list (20-30 items) of all the *unique* full journal names (Publications) *in their database*, and their corresponding short forms. Display that to the user.
If there is no short form, allow the user to enter it.
Then have an "Apply" button/method that puts the appropriate short form into Journal Abbr. field of every record.
Not perfect, but much less work than at present.
It wouldn't take significantly more work (possibly less) to tie into this infrastructure, and it would be less risky (because it would not touch user data). In either case, you need a popup, it needs to provide for the editing of entries, and the content needs to be reflected in the database somewhere.
A working solution can be provided by a completely separate Firefox plugin that slightly extends the Zotero document preferences popup (with a tab or button that calls up a list management interface), and provides a little glue code that interacts with the citeproc-js processor. I need this personally, so when I get to it, I'll build the thing and post back here.
As far as I can tell, a separate-plugin approach will not conflict with the other suggestions posted to this thread (shipping lists with Zotero proper, supporting abbreviation list URIs in the CSL schema, implementing a cascading fallback mechanism, coding lists in JSON, or in XML, or whatever). When other tools take over the task, the (also yet-to-be-written) abbreviation plugin can be decommissioned.
More news later ...
The tool adopts the approach I described above, presenting an editable list of field strings that can be abbreviated in the current document, which is stored in a persistent database and associated with the target style. Lists are not distributed with the plugin (in part for legal reasons), and there is no provision for fetching lists from a central source, but a user's personal lists can be exported and imported in JSON format.
This is a new direction for the processor, and there will no doubt be things to iron out. Let me know if you give the plugin a try and find things that might want fixing.
I need to use journal abbreviations matching CASSI or Biosis, so your Word plug in looks really useful. Thanks for your work on it.
I downloaded the plug in and restarted Word and firefox. I couldn't find any alterations to the Word citation dialogue boxes so I can't use it. This is sad.
Do you know what I might be doing wrong? What is the most up to date version of the citation abbreviation software?
Thanks,
Charlie
I am using Windows 7, Word Professional 2010 version 14.0.6112.5000 (32 bit), Zotero 3.0.3 and Firefox 10.0.2. Cripes, that is a lot of different packages!
If the plug-in to automatically do the journal abbreviations is not working for me, what would you suggest is the best way of doing this for me at the moment?
I suppose I should enter the Journal Abbr field for each of the papers according to the advice from the journal I am submitting to.
Friends I know who use Bibtex in Latex documents tell me they are able to do these abbreviation automatically. I don't suppose it is straightforward to use this with a word document.
I am new to this, so thank you for your help.
But Frank, if you could run us through how to actually use the plugin at least for testing that'd be helpful. E.g. I have no idea where to put the abbreviation lists.
The existing documentation is available in the draft text of a book I'm working on (at page 93 of the current draft) that covers legal and multilingual functionality in MLZ. The UI of the plugin is a little quirky, but it seems to work.
The book chapter talks about distributed abbreviation lists. Some are available, but they're still in flux, and the lists I've cooked up so far are specific to a couple of legal styles. You'll need to build your own through the UI (or by brewing up JSON files), but import and export work as documented, so you can exchange lists between systems. The lists are style-specific and held in a separate SQLite database controlled by the plugin, so you should be able to register many thousands of abbreviations without a significant impact on performance.
http://images.isiknowledge.com/WOK45/help/WOS/A_abrvjt.html http://www.cas.org/expertise/cascontent/caplus/corejournals.html
http://www.bioscience.org/atlases/jourabbr/r.htm
http://www.efm.leeds.ac.uk/~mark/ISIabbr
Also, it's confusing having a Cancel button only. I write the abbreviations in the right panels, but what should I click next?
By now I just hit return, but the journal names do not get abbreviated in the reference list.
Using 3.03.r10880
firefox 9.0.1, ubuntu 10.04, LibreOffice 3.5.0
Build ID: 350m1(Build:13)
Agus
http://forums.zotero.org/discussion/21879/libreoffice-plugin-throws-an-error-after-clicking-the-ok-button-in-classic-add-citation-dialog/#Item_19
How should I revert? Uninstall and install again through firefox? Am I putting at risk my database or my references in the article?)
Data can be imported if it is refactored as an appropriate JSON structure, which shouldn't be terribly difficult.
I'm able to reproduce the fault with abbreviations not being reflected in citations (which sort of defeats the purpose of the thing, doesn't it). The cause apparently lies in an excessivly complicated approach that I adopted for controlling output transformations. It can be simplified, and I've now started on the work. Should have it done tomorrow. A release will follow, and the plugin should start working with the next Zotero minor release. Thanks for testing!
Anyway, is this plugin going to work for an existing bibliography or
is the user supposed to have the abbreviation made when the reference is inserted?
Perhaps, if the way zotero works is by relying on the Abbreviation field of the library, it would be easier designing a tool that would fill those fields automatically by reading the dictionary.
Also, I can try to make the JSON structures for the tables that I mentioned, where is it explained?
Agus
The output transformation code that I mentioned earlier did need to be simplified, and that's also included in the 1.0.298 release. It doesn't change the behavior of the processor, though.
What was happening is that all available item fields were being registered for use by the plugin. This caused them to appear in the plugin listing, even if the style did not apply form="short" to them in rendered output. Abbreviation is not performed on fields without form="short", though, so setting an abbreviation on some items visible in the listings would have no effect.
The JSON format isn't documented yet, but you can follow the pattern of this file, putting journal abbreviations in the container-title segment.
As Gracile has noted, this is still in development. If you run into any further snags, feel free to give a shout.