Examples of Zotero Group Libraries Published on Websites
I'm interested in finding a variety of examples of how Zotero group libraries have served as the basis of online bibliographies – I am part of a research group that is developing such a project: we plan to include a bibliography of about 4000 items on a website devoted to Canadian Photography History and we want to do everything possible to get it right.
@adamsmith just recently drew attention to this this example in a recent post:
Reproductive Justice Virtual Library:
http://www.law.berkeley.edu/php-programs/centers/crrj/zotero/library_research.php
and on the Omeka Showcase page I have found this:
Franco American Library, Franco-American Centre, University of Maine:
http://www.francolib.francoamerican.org/items
However, most of the sites featured on Omeka's Showcase and Blog only feature a small number of publications for the purpose of a more focused exhibition, rather than large bibliographies.
Can people suggest other examples of large group libraries turned into online bibliographies, with or without search features and annotations?
I would also be interested in accounts of the process and difficulties in executing such online publications – via Drupal, Omeka, WordPress and other plugins.
Examples of difficulties: on Omeka sites, such as the one listed above, a COinS plug-in seems to have been used, but the different document types all show up and import only as "Documents"! I'm wondering if this is a limitation of Omeka or due to faulty development?
Thanks!
@adamsmith just recently drew attention to this this example in a recent post:
Reproductive Justice Virtual Library:
http://www.law.berkeley.edu/php-programs/centers/crrj/zotero/library_research.php
and on the Omeka Showcase page I have found this:
Franco American Library, Franco-American Centre, University of Maine:
http://www.francolib.francoamerican.org/items
However, most of the sites featured on Omeka's Showcase and Blog only feature a small number of publications for the purpose of a more focused exhibition, rather than large bibliographies.
Can people suggest other examples of large group libraries turned into online bibliographies, with or without search features and annotations?
I would also be interested in accounts of the process and difficulties in executing such online publications – via Drupal, Omeka, WordPress and other plugins.
Examples of difficulties: on Omeka sites, such as the one listed above, a COinS plug-in seems to have been used, but the different document types all show up and import only as "Documents"! I'm wondering if this is a limitation of Omeka or due to faulty development?
Thanks!
https://www.utsc.utoronto.ca/digitalscholarship/content/blogs/consuming-zotero-libraries-drupal-feedsxpath-parser
edit: webpage - still small - via twitter is at least currently here:
https://www.utsc.utoronto.ca/digitalscholarship/berks2014
Some people have posted their (usually smaller) webpages using ZotPress:
http://wordpress.org/support/topic/are-you-using-zotpress-post-your-url-here
editorsnotes.org/ has various collections based on Zotero items.
We also run a Facebook page and the twitter account @FWWbib from the group rss feed. All in all it has proved a very suitable set-up for our needs.
In fact, I have yet to find an Omeka site where the library items work properly, or even where adequate references for pages or articles making up the site can be properly captured. Any idea if this due to limitations of Omeka itself?
ePorte: collaborative scholarship on the Mediterranean from Late Antiquity to the Early Modern period, Univ. of Toronto:
http://humrp1.utsc.utoronto.ca/ePorte/bibliography?page=1&s=author&o=asc
MOISA: International Society for the Study of Greek and Roman Musical History (soon to be hosted by the U of T library):
http://moisasociety.org/de-musicis/year/2012?sort=author&order=asc
These are quite nice – but, unfortunately, both have an odd glitch when using Zotero to ingest the references: while journal articles import without difficulty, with books and book chapters the author names are not importing, despite the fact that the info is there in the author field. See for example:
http://humrp1.utsc.utoronto.ca/ePorte/biblio/brokering-empire-trans-imperial-subjects-between-venice-and
Brokering Empire: Trans-Imperial Subjects between Venice and Istanbul. Ithaca: Cornell University Press, 2011.
and, in this case on MOISA, it is also leaving out the title of the chapter in the book:
http://moisasociety.org/de-musicis/ancient-myths-and-modern-moves-greek-inspired-dance-theatre-martha-graham
The Ancient Dancer in the Modern World: Responses to Greek and Roman Dance. Oxford: Oxford University Press, 2010.
"In fact, since we would consider all the content on our site to be electronic scholarly publications – theme introductions, annotations, and virtual exhibitions will all be distinct, peer-reviewed, signed articles – we would need every page to be able to display a Zotero translator icon that would generate complete and accurate citation imports into Zotero and other reference management systems."
Will report here when I have a response.
The Ecomusicology Bibliography
http://www.ecomusicology.info/resources/bibliography/
- this group opts for offering a PDF download, a link to view the Zotero website version of the group library, and possibility of joining the group
International Society for First World War Studies (ISFWWS) Bibliography
http://firstworldwarstudies.org/bibliography.php
- as noted above by clio_13, this group displays (nicely!) the current state of the bibliography as a live feed from the database, divided into collections, with an invitation to join the Zotero group library
And, finally, one that works pretty much correctly:
Crime, Law and Order, c.1500-1800
http://earlymodernweb.org/crimebib/index.php
- thorough (if not very elegant) search and browsing functionality, nice lists with contrasting bands, and this bibliography actually provides references that import correctly into Zotero – although, oddly, none of the 600 entries include page spans! Did the compiler not include them in the Zotero items or did this field not get picked up in the import?
When Zotero reads in COinS, it largely tries to guess the type from the metadata format used: this works for journal, book (several Zotero types based on other keys that are included), dissertation (thesis), and patent. Unfortunately, for anything using the Dublin Core format, that initial guess is always "webpage." If there's anything set for the DC rft.type and it's the same as a type Zotero knows about, it chooses that instead.
So, to allow for some kind of interoperability with Zotero for types, Omeka drops any values for Dublin Core Type (which would normally be free user input) for an item, and just consults a lookup table between Omeka's built in item types and Zotero's. The overlaps are: interview, audioRecording, videoRecording, email, webpage, and document. Items with the corresponding Omeka item types get COinS output declaring those Zotero types. Omeka items aren't required to have an item type,
so those without one end up as "document."(Edit: actually, when there's no Omeka type set, the COinS output for type will be whatever's in the DC Type field.)In combination with the Zotero Import plugin, Omeka's COinS output could have a one-to-one mapping to Zotero types for imported items, but then would run into issues with actually representing the metadata, which is difficult or impossible to hammer into the formats OpenURL provides.
Maybe "difficult" wasn't the most precise choice of words. With an eye toward what Zotero itself does, output through COinS of things imported by Zotero Import would look something like:
For the specific Zotero types journalArticle, book, bookSection, conferencePaper, report, thesis, and patent, map several imported fields to specific fields in the various type-specific OpenURL formats that those types are each associated with. For those types, none of the Dublin Core data, which Omeka generally attempts to foreground, would be included at all, since you have to pick one metadata format and stick with it for COinS.
For any other type, we'd still be using the Dublin Core format, and then would have to make a choice between whether to use Omeka's native Dublin Core data (thus excluding the data imported from Zotero), the few fields Zotero itself maps to Dublin Core (title, publication, rights, publisher, abstract, and DOI/URL, but this choice again excludes all the Dublin Core data from Omeka), or combining the two somehow. If combining, keep in mind that while the OpenURL Dublin Core metadata format allows multiple values for each field, Zotero won't read more than one (or rather, will allow later values to clobber the earlier ones).
Then all of that would still only work for people who have both the Coins plugin, the Zotero Import plugin, and even then only for those items that were actually imported from Zotero, or the extremely rare case where the user manually filled in values for the Zotero element set in Omeka. From my standpoint that's an awfully small set of things that work would be useful for, especially when under the best case it still wouldn't be able to represent the full spectrum of the imported metadata.
I don't see that as terribly surprising. Omeka's focus is far different from Zotero's, and the different sets of default types reflect that. On top of that, Omeka's set of types is not fixed; individual sites are free to create and add their own.
A final note: the site you're discussing here is running Omeka 1.3, a fairly old version. On a more recent version, the same data would probably import into Zotero with the right type of "book", since they're setting Book as the Dublin Core Type value. That fallback to free-text types has existed since Omeka 2.0.
I suppose that, given its raison d'être (standard description of the widest possible range of web resources), Dublin Core aims at establishing broad, more universal and stable categories. Zotero, on the other hand, aims at more fine-grained distinctions within the narrower realm of bibliographic metadata.
However, what I gather from your explanations is that no platform based on the Dublin Core standard (such as Omeka) will be able to correctly represent the range of bibliographic item types of Zotero. Is this correct?
If so, is this not a fundamental obstacle to interoperability?
Also, would sites that import Zotero libraries built using platforms such as Drupal and Joomla be subject to the same limitations?
Obviously Dublin Core's 15 fields (in the original unqualified variant) aren't going to be able to represent the whole range of Zotero metadata with complete fidelity. When going from Zotero to Dublin Core, crosswalking would probably work reasonably well for most fields, since you'd be going from the specific to the general. But, that data wouldn't round-trip back to Zotero very well. Zotero can and does use heuristics to try and pull a more-specific field like DOI or URL out from a generic Dublin Core field like Identifier, but that's not going to work in all cases.
That loss of specificity is why Omeka doesn't actually crosswalk over into Dublin Core when it imports Zotero items with the Zotero Import plugin. Instead, the plugin adds a new set of metadata fields so the Zotero fields each have a specific counterpart. That data could be round-tripped into a site visitor's own Zotero library losslessly, or at least pretty darn close.
The sticking point here is that the Zotero Import plugin for Omeka doesn't currently produce anything that Zotero knows how to read that would include all that data. That's far from an insurmountable problem. An RDF output of the Zotero data (and the Dublin Core data too, why not) would be pretty simple to create, and Omeka already includes built-in support for different output formats for items. However, I think a simple
link rel="alternate"
tag pointing to that RDF would only allow Zotero to "see" single items when on their specific pages, not all the items on a browse/search page.As far I'm aware, unAPI would be the only discovery method that would also handle the browses. While not complicated, using unAPI for discovery like this entails doing some specific matching to the software you want to read it (here, Zotero, which may well be the only unAPI client floating around anyway). The spec requires little, but detection in practice depends on picking the right combination of format name, mime type, and even sometimes the optional link to documentation.