So we installed the COinS plug-in, but it doesn’t seem to be working properly and I’m not sure why.
The item pages can only be saved as screenshots, it seems that no metadata is being picked up.
From the browse page I can save items, but the item number is missing from the data saved. The source information is also missing.
While we have heavily modified the show page, we have not modified the browse page significantly and I’m not sure what’s going on. What do I need to check?
EDIT: It appears that the span tags are showing up for browsing items and not the show page. OK I fixed the issue, it was related to code that had been removed in our current version of the seasons theme (the plugin hook of all things!). Not sure why source info still isn’t showing up either for the item show or browse pages though.
Am I correct in thinking that there is no field in Zotero for the ‘source’ field from Omeka? Our items are mostly documents that come from other sources. The only info I see saved is Title of the document and author and publisher, but the source info is crucial for documents that come from edited volumes and point to specific page numbers.
You’re basically on track. CoinS outputs the metadata more or less as-is, but Zotero can only deal with Dublin Core data in a pretty limited fashion because it doesn’t perfectly map to Zotero’s item types.
Source should be mapping to Publication in Zotero through Coins though. If you’re not seeing that, the problem is probably that your items are getting imported as a type that doesn’t have Publication as a field (like Web Page, for example). When CoinS metadata contains Dublin Core (as it does for Omeka), Zotero will default to a Web Page type, but you can control it to some extent with the contents of the Type field in your Omeka item, if you pick a type that exists in Zotero.
So we actually don’t have anything in the “Type” field. It does seem, however, that Zotero chooses “Document” on occasion for this - Zotero likewise shows no source (publication) info for document, if that makes sense. (We do use Item Type Metadata - Text for the vast majority of our items. I don’t know if that affects it at all.) So if I understand you correctly, all I have to do is run a script on the backend for existing items that assigns that a “Type” in Zotero - one that includes publication info? Is there anywhere that explains what fields map to what?
EDIT: I am trying to use “Document” and “Book section” on a few items but this doesn’t seem to make a difference. I DO see the publisher info (if that wasn’t clear before). However, what we have are documents that come from specific book volumes. In other words, as example, I have Document 1 from a particular book, and I need to cite the book and page numbers for which that document can be found. In our database, the source field contains this information: the book title and page numbers. (I realize the page numbers here might be problematic.) The publisher field contains the city, publishing house, and year. Unfortunately it seems like the crucial “source” info - namely the book title/volume from which said document comes - is lost altogether when coins CoinS saves it. Oddly, the Title of the document is saved instead as the Book title (this is incorrect). I am attaching a screenshot:
So what is currently in the “Book Title” field should instead be in the “Title” field while the “source” from which that document/book section comes from should be in the “Book Title” field.
I’m not super familiar with Zotero item types, but you’d need one that has the “Publication” field (not Publisher). I imagine it would be more skewing to types dealing with articles and the like. I don’t believe “Book Section” has that field (as shown in your screenshot), nor does Document. Obviously the Book Section type has several more specific fields that serve the appropriate purpose like Book Title and Volume, but Zotero doesn’t know and probably can’t assume that Dublin Core Source should map into those fields.
Title mapping into Book Title feels like a bug, but it may be attempting to account for some case I can’t think of, possibly historical usage. For whatever reason, for a bookSection type item, Zotero maps both title and btitle (a “book title” metadata element from OpenURL) to “Book Title.”
The general problem is that CoinS and OpenURL in general are really geared toward using a handful of specific library-oriented formats. The Dublin Core support Omeka uses for CoinS exists but really isn’t well supported in a variety of ways, unfortunately. Zotero also has a fairly different default philosophy about metadata than Omeka does: it’s quite strict about the item type determining what fields are available, whereas Omeka is heavily based around Dublin Core being available to all items.
A CoinS-based output (or some other format) that gives better results in Zotero is possible, but would require more tuning to a specific site’s needs (and would probably use the “normal” OpenURL metadata formats rather than Dublin Core, which are much more likely to map to more appropriate places on the Zotero end).
