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!
  • edited April 28, 2014
    There is this, though I can't find the webpage (yet):
    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.
  • re: Omeka - their COinS has all items as rft.type=document, so that's a problem with what they produce. It'd be good to report that to them, this shouldn't be hard to fix.
  • I look after this group bibliography on the First World War with a couple of other volunteers https://www.zotero.org/groups/first_world_war_studies_bibliography/items We originally piped it through to the society website using Zotpress and that worked very well. The website has since been redesigned using perch and now displays the bibliography here http://firstworldwarstudies.org/bibliography.php
    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.
  • My research group is interested in implementing something like these libraries, but a requirement is that we be able to monitor how frequently each attachment is downloaded and individuals would need to supply a name and email address so that we can follow up as updated versions are posted. Does anyone have any thoughts on how/what platform could incorporate these features with data sourced from Zotero?
  • adamsmith, re the Franco American Library Omeka site: is that an issue with the Omeka platform, or just how these people have configured it for their site?

    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?
  • My guess would be that it's a problem with Omeka's COinS implementation, but I don't know enough about Omeka to say for sure. I'd ask them.
  • Here are two online bibliographies produced (by the same people, it looks like) using the Drupal plugin:

    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.
  • again, the author isn't in the COinS at all. That should be easy to fix on their side if they wanted to.
  • edited April 29, 2014
    I've queried the Omeka people on both the Zotero import issue and also expanded it, thus:

    "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.
  • edited April 29, 2014
    Here are two examples of online bibliographies on the static end of the spectrum:

    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?
  • edited April 30, 2014
    And here is the reply from Omeka regarding all the bibliography items appearing as "Documents" instead of their respective types:
    When importing bibliographic data into Omeka using the Zotero Import plugin, the bibliographic item type is represented in a metadata element set that is added to your Omeka installation. All of your bibliographic data is imported and available on the item's page.

    The challenge is when the data is already in Omeka, and a user wants to grab the item save it into their own Zotero library by clicking on the link in the locator bar, the item type choices are more limited. But, once that data is in Zotero, the type of resource can be changed.

    Omeka is used by many communities for web publishing different types of collections. There aren't many Omeka sites that we know of that feature large bibliographies.

    Thank you for your interest in Omeka.
    The Omeka Team
    Well, they've correctly redescribed the problem back to us – but there is no explanation as to why the "item type choices are more limited" once they are on the Omeka page. And, final answer amounts to "just edit each imported item once it is in Zotero to correct it"!!
  • edited April 30, 2014
    Maybe Sean Takats can sway them the other way. Considering that Zotero and Omeka are developed at CHNM, the lack of interoperability is ridiculous. (edit: I'm also referring to how long it took Omeka to update their Zotero plugin) It's really in Omeka's interest to expose proper metadata. COinS isn't the richest of standards, but it can certainly do better than "Document" for all metadata.
  • edited April 30, 2014
    Omeka's COinS plugin, like Omeka itself, is focused on Dublin Core for metadata input and output. COinS has a format for representing metadata as Dublin Core, which Omeka's plugin uses. The majority of the DC fields are included as-is, with the major exception of Type.

    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.
  • 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.
    Do you have a more concrete example of what would be difficult? There are only a few fields that get itemType-dependent treatment. Not sure if those are the ones that you would find problematic.
  • I guess I'm also confused why Omeka doesn't have a book or article item type - or am I misunderstanding something?
  • edited April 30, 2014
    Do you have a more concrete example of what would be difficult?

    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 guess I'm also confused why Omeka doesn't have a book or article item type...

    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.

  • edited May 14, 2014
    jflatnes, thanks for all of this technical insight, which is important to have laid out. I don't think I quite follow all of the implications, due to my own technical limitations. So I would greatly appreciate a few clarifications re the upshots.

    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?
  • I wouldn't call it a fundamental obstacle. Dublin Core is really more of a problem when it comes to getting Zotero to ingest items that are native to Omeka than those that were imported from Zotero.

    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.
Sign In or Register to comment.