is unAPI dead--because their website sure seems to be

Well, they may still own it. But has been down all year.
If i wish to expose my data as RIS or MODS is unapi still recommended and is the info found in the web archive[1] still accurate?

I apologize if this has been brought up ad nauseam, but I didn't see anything after a search.

  • 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.
  • edited June 30, 2015
    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.

    Thanks again for the quick response.
  • 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.
  • Maybe another unAPI service helps you with your own work:
    The whole bibliographic standards landscape is vastly incomplete. It always has been from the best I can tell after conversations with retired librarians.
    I am just curious, because this is connected to my work: how exactly do you think that the bibliographic standards landscape is incomplete?
  • 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.
  • Thank you for impression. I agree, that there might be missing an data format between the simple formats (like DublinCore, BibTeX) and the complex (library) formats (like MARC, MODS).

    @adamsmith: Agree. RDFa,, linked data in general etc. would be nice to support in Zotero.

    I found an alternative to unAPI with HTML5 elements:
    <link rel="alternate" title="marcxml"

    found in (blacklight catalogue).
  • 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).

    For embedding multiple items in a page:
  • (JSON-LD looks like a great fit for directly delivering CSL JSON too)
  • edited July 13, 2015
    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.

    (Thanks to adamsmith for the help on this thread, by the way).

    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, seems to have a type for PublicationIssue but not for Publication, so there may still be gaps.
Sign In or Register to comment.