it still works very well with Zotero and is still the best way to serve complex metadata to Zotero absent a dedicated translator, yes. It's also actually used in a fair number of high-profile sites such as the UM Ann Arbor library catalog and the INSPIRE particle physics network.

It also hasn't changed at all, so anything in the archived version is still correct.

The people who created it, unfortunately, don't appear to be at it anymore, which does explain for the lack of proper webpage and also, to some degree, lack of publicity--really too bad, given how bad most alternatives are.

Thanks for the info. I'm trying to chose between unAPI and highwire the the moment and a nine year old spec was slightly concerning.

The whole bibliographic standards landscape is vastly incomplete. It always has been from the best I can tell after conversations with retired librarians. In fact we have a whole room full of punch cards from a system back dating back 35+ years ago from a propriety system we once ran.

Currently our primary format is MODs. I am happy with our RIS files (what we are feeding refworks) and was hoping to go with dublin core in our meta tags. but calling all our item types Text is way too limiting. I could go on, but I won't.

You'll get great results feeding Zotero MODS (and if you do find any problems we'll be happy to fix them) . I'd personally go with that, though highwire--especially given the added benefit of google scholar--is not a bad idea, either.

The biggest issue with unAPI/MODS is that I don't think it's much used beyond Zotero. So for Mendeley, e.g., google highwire will work, but unAPI won't.

The landscape is littered with incomplete solutions. In my view, a complete solution should represent the bibliographical data accurately, and in a way that favors interoperability which means that there's a critical mass of tools that can read the data and read it in a way that preserves semantics.

I ran into this thread while trying to figure out how to make an online scholarly encyclopedia work nicely for people who'd like to import the bibliographical information of any article they read on our site into Zotero. (Other tools too but Zotero is the primary target.) Here's what I found:

1. Dublin Core has no provisions for recording "encyclopedia article". Oh, it can be done: you can create an encyclopedia article in Zotero and export it as Dublin Core, but it is doubtful that the resulting data will be swallowed seamlessly by anything else than Zotero. Zotero sets the DC Type to "encyclopediaArticle", which is the only sensible move given that DC has no equivalent notion. But "encyclopediaArticle" is not part of DC and so who knows how it will be handled by something else than Zotero. Let me be clear: I'm not blaming Zotero. I'm blaming Dublin Core.

Dublin Core also has no notion of a "place of publication". It may be a quaint notion in this day and age but scholars still care about it. Zotero simply does not include the information in the exported data.

(One might argue that I'm blaming Dublin Core for not being something it was never *meant* to be. Like blaming a tricycle for not being a car. Well, it was clear as day that a car was needed for the task. So why did we get a tricycle instead?)

2. Ok, so COinS then? Same problem as Dublin Core. There seem to be no notion of "encyclopedia article" in COinS. When I ask Zotero to export in the COinS format, I get a Dublin Core record embedded in an OpenURL. Again, Zotero is doing the best it can with a standard that is lacking.

3. When I ask Zotero to export to MODS, I get a complete record, which correctly reflects the fact that it is an encyclopedia article. MODS is the only sensible format I've found for my purpose. But I can deliver it only with unAPI, which as adamsmith noted earlier is not used much by tools other than Zotero for importing bibliographical data.

yup, what lddubeau writes would be exactly my complaint about the current state of things. There are good bibliographic data formats (like MODS and some others), but there's no decent format for presenting bibliographic data embedded in webpages.

We should probably revisit RDFa again and see what the status of that is and if Zotero can help pushing that more (starting by reading it). That seems like the most hopeful future standard.

At the moment I'd put my money on JSON-LD. Generally equivalent to RDF, but somewhat easier to work with and it seems like more people are getting on this bandwagon (including ones that can push adoption like DPLA, Europeana, and search engines to a degree).

I've recently been trying to do likewise for a small archive site. I went with using DC metatags and COinS (with the DC fields) in the end.

Since the archive is a mix of pamphlets, documents, and a lot of full issues of old papers and magazines, finding a good type match for Zotero was difficult anyway, so since I had to use the generic 'Document' type, these formats were sufficient, and seem to work ok with both Zotero and Mendeley. I can see the problem with more complex bibliographic data though.

lddubeau mentioned the lack of types in DC, but it's worth noting that the set of fields is separate from the controlled vocabulary. As it stands, the only controlled vocabulary out there seems to be DCMI Types (which only really offers 'text' for this purpose), but using the Zotero types is still perfectly valid in DC.

Our site has some RDFa too, and support for that would be great. It has a big advantage in that there are well defined schemas for the format (unlike DC). Alhough, Schema.org seems to have a type for PublicationIssue but not for Publication, so there may still be gaps.