Using the COinS plugin to map Omeka’s Dublin Core metadata to Zotero doesn’t deliver the results I’m expecting.
I can provide details if there’s interest, but the TL;DR version is that I think it’ll be necessary to tweak the existing codebase of the COinS plugin to achieve a more granular level of mapping. Especially mapping journal article metadata.
Apparently, looking at GitHub, COinS hasn’t been significantly updated since 2013. What’s the community protocol when editing plugins - would it be better to fork COinS, or contribute to the existing codebase?
The usual way to make an edit on Github involves making a fork anyway, so if you’re interested in making a change you can pretty costlessly do both your approaches: make a fork and make your change(s) there and then submit a pull request if you’d like to.
The mapping does have some issues: the plugin mostly just outputs Dublin Core directly, and Zotero for various reasons often can’t map that to the fields users want or expect… the same type of issue can happen for item types. By outputting the more “expected” Coins formats for books and journal articles and so on, Zotero should be able to map more of the metadata.
The issue is usually that there’s not necessarily one kind of mapping we can do for everybody that will work well… Obviously as a fork you’re free to just hardcode your desired mapping, or go further and make it configurable in some way.
Eish. Not certain how far I want to go with hardcoding. By looking at the existing code, here’s what I’ve discovered so far about the COinS plugin, which might be helpful for others…
DC metadata elements that are recognized by the COinS plugin: Title, Creator, Description, Source, Date, Language, Publisher, Rights, Contributor, Subject, Format, Relation, and Coverage. Not recognized: Identifier, Type, nor any of the extended DC metadata elements.
Item Types that are recognized: Oral History, Moving Image, Sound, Email, Website, Text, and Document. (I don’t see the Document item type as an option when classifying items, maybe it’s the default fall-back for Zotero captures.)
Using the admin backend, I added Journal Article as an Item Type. If I get ambitious, perhaps I’ll add and test some other Item Types that are recognized by Zotero, namely: Book. Book Section, Thesis, Report, Manuscript, Magazine Article, and Map.
I then edited Coins.php and inserted the following code snippet after switch…
switch ($itemTypeName) {
case 'Journal Article':
$type = 'journalArticle';
break;
With that simple modification, any item that is classified as a Journal Article is now captured by Zotero as a Journal Article (before, it was Document). And the DC metadata elements are mapped as follows…
DC element => Zotero element
Title => Title
Creator => Author
Description => Abstract
Source => Publication
Date => Date
Language => Language
Publisher => Publisher
Rights => Rights
None of the other DC elements are mapped to Zotero, for the Journal Article item type. Not ideal, but acceptable. One quibble is that multiple authors are not parsed into Zotero; only the first author.
That’s a pretty reasonable approach… the types are very important on the Zotero side, much more core to the metadata system than they are in Omeka, so having a proper type Zotero knows and expects is important.
“Out of the box” Coins doesn’t do this since, as you say, those item types don’t exist by default, you had to create it.
I suppose it could still treat those “exact match” type names specially, so that if they were created (or the type name was used in the Type metadata field, I’d have to refresh my memory on if that’s relevant) they’d be mapped over… I’m not sure about that approach but it might work fine.