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.

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?

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.

again, the author isn't in the COinS at all. That should be easy to fix on their side if they wanted to.

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?

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.

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.

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.

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.