search

zerocrates / OaiPmhRepository

OAI-PMH repository plugin for Omeka
http://omeka.org/codex/Plugins/OaiPmhRepository
GNU General Public License v3.0
3 stars 15 forks source link

Current version no longer exposing thumbnail #26

Open cppdigital opened 8 years ago

cppdigital commented 8 years ago

Hello,

We are in the process of firming up metadata aggregation with or regional DPLA hub. In the process, I updated the OAI-PMH Repository plugin, and upon the next test aggregation the thumbnail was no longer being exposed. In previous versions both the original and thumbnail were exposed using <dc:identifier xsi:type="original"> and <dc:identifier xsi:type="thumbnail">. Now just the original is exposed simply with <dc:identifier>, which is the same tag the item show page and Dublin Core identifier field are exposed with. I'm wondering if there are plans to expose the thumbnail in future versions, or if there is a way to configure the current version to expose it.

Thanks!

Tristan Dahn Digital Projects Librarian Historical Medical Library of The College of Physicians of Philadelphia

zerocrates commented 8 years ago

I don't recall the "original" and "thumbnail" stuff ever being in this plugin. Could it have been a local modification or a fork?

cppdigital commented 8 years ago

That's entirely possible, I inherited a highly customized Omeka instance with basically no documentation, so working through what is native and what has been added has been a constant. I'll do a comparison between the version I have that exposes both and the out of box version of the 2.0 plugin to see. Thanks!

zerocrates commented 8 years ago

It's pretty constrained what you can do with oai_dc and still stay within the spec, which is why the plugin just adds the original file as a plain identifier.

METS gives us an explicit place to put links to files, so we do that there and leave the DC data untouched. The plugin's METS output still just includes the original file, but it's declared in a more structured way that should be easier for a harvester to deal with.

cppdigital commented 8 years ago

Thanks, that makes sense. I believe the version I have that uses the xsi:type to force validation. I'll run this by the people at our local DPLA hub, and will also let them know that this is not the standard functioning of the plugin. It's a relatively new local hub and I'm pretty sure we are the first Omeka instance they are aggregating from, so it would be good for their developers to know the thumbnail is not typically exposed. Thanks for your help! It's made things much clearer.

zerocrates commented 8 years ago

The change to the METS output to add FLocat elements for the thumbnails would be pretty trivial. The MODS output would be similarly easy, I think, though there you have the downside of a crosswalk to MODS for the metadata. I'd be open to making or accepting changes to those outputs to add those extra URLs for the derivatives (possibly also CDWA Lite, but I haven't looked at it in a long time).

oai_dc is usually the toughest place to try to do anything "more" because it's specified pretty rigidly. I don't think I'd want to cram in any more identifiers there, or try to fit in extra information in stuff like xsi: attributes where it doesn't really belong.

Another route open to you with the current versions of the plugin is altering or adding your own format more easily. The oai_pmh_repository_metadata_formats filter allows you to have a separate plugin add, remove, or replace any of the formats with your own, if you've got some specific need not served by the plugin's default outputs. (Though, my preference is for improving the built-in ones wherever feasible).

cppdigital commented 8 years ago

Thanks again! This is all very helpful. I'm going to write the people at Temple University who are in charge of the PA hub and have them help to guide my decision making in these regards.