I’m currently using Piwigo for a photo gallery of historic photos from science fiction fandom, with a few thousand images in it (and more on our fileserver not yet organized and published to the web gallery). I just discovered Omeka, which in some ways (oriented towards archival collections, and built around standard metadata including Dublin Core), and am trying to quickly understand Omeka enough to know if I should actually consider switching (always work; could be working on importing new images instead).
So one big question in my mind is “what is the smart way to use Omeka on a photo collection”. Should I be creating a separate item for each of thousands of photos? (not by hand for sure!!!). Or should I be creating an item for (say) all photos from one meeting or one panel at an SF convention, with all the photos from one photographer at that meeting as files on that item? Or some other way? Or it depends on things I haven’t told you?
Secondly, these photos are all labeled with date, location, tags/keywords, and such in metadata fields. In my test so far, I do see that information in the file page for an image I imported into Omeka. However, several other messages in this forum, and my tests, tell me that that information is not searchable, which kind of spoils the good impression! Has anybody found a way to fix this?
Finally, if I need to update the copy of an image file that I have published to Omeka, how can I do that? In Piwigo I just run an rsync from my local virtual gallery directory over to the Piwigo server, and everything I’ve updated since the last time gets found and swept over (then I do have to do synchronization on the web end to get that data into the database). Those updates could involve the image itself, or metadata, or both. How would I update photos here?
There is a lot going on in this question, so I’ll see if I can address some of it. Others will have more informed thoughts on the remaining elements.
With respect to creating items and organizing collections, since Omeka Classic has the DCMI schema baked in the core description is teamed with item types. As a result, generally we would recommend a single item with a single photo because the item being described is the still image rather than multiple depictions of a subject or an event. Those items could then be organized into collections. Each item may only reside in a single collection.
Given the size of the number of items you would be generating, we would suggest using the CSVImport plugin to do you item creation. If you could use Adobe Bridge or some such tool to extract the descriptive data from your images into a CSV, that could then be mapped to the Dublin Core properties. If the files are available live on the web, they can be automatically attached to the items upon import. You may also be interested in deploying Search by Metadata and Simple Vocab to standardize your descriptive content and to allow for lateral movement across the collection via the description.
There are not currently sync update options for Omeka Classic, however it would be possible to build a plugin that uses the API to create something similar to your current update workflow I would think.
Thanks, LOTS of useful information there, and I’m still working through things.
The limitation of one collection per item makes me wonder what kind of group a collection is supposed to represent. About the only thing where an item could only belong to one is a particular donation; is that the origin? Or maybe my subject space is just unusually highly interconnected (science fiction fandom, where fans and pros and conventions and cities and regions and awards and publishers and overlap and intermesh). There’s some kind of grouping that can be hierarchical and multiple, right?
The Simple Vocab plugin seems to be very nice; wouldn’t have expected that capability to be able to be provided through a plugin.
Haven’t gotten Search by Metadata to find anything yet; need to look more closely before I start asking for more help though, haven’t tackled the problem systematically yet.
When reminds me – haven’t looked at the code, but both the on-screen appearance and the function of this package seem to be very clean and even elegant. (50 years as a professional software engineer, including doing web stuff professionally from 1996 for a while; now working on preserving historic photos from science fiction fandom in my retirement.)
My test sandbox is running fine on Dreamhost for the moment, so I feel like I can run it on any mainstream hosting platform; which makes me feel not trapped :-). Obviously a big photo collection takes a lot of space (I’ve already got 2GB there and that’s only 7k photos), and if it becomes popular (not a problem I have so far) it would also take a lot of CPU and net bandwidth, so flexibility can be important. I’ve heard good reports on AWS instances for omeka, and your own hosting is not unreasonably priced either.
I think I understand your issue with collections, as you probably have the same item that would be part of different convention displays and so on… I guess the Collection feature of Omeka would not really help you there, because - as Sharon already pointed out - each Item can belong only to a single collection (there’s a pluging out there that mimic the one-item-to-multiple-collections feature, but I’ve never tried it so don’t know whether that would work for you).
You might consider using Exhibits, since then you could put the same item in many exhibits, though. Or heavily rely on metadata (and then use the SearchByMetadata plugin - btw: I’ve forked and improved the original version, you can find my fork at SearchByMetadata).
Also SimpleVocab has got some improved forks (again, you could check whether they work for you too, SimpleVocabPlus being my version).
Last but not least: for the kind of data you have, you might want to check also Related Content plugin, that could probably turn out useful.
The model for the Collections restriction is actual physical collections in an archives or museum repository. In those cases, entities can only belong to a single collection.
One possible solution here might be judicious use of the Collection Tree plugin to provide some hierarchical order to the collections.
But, as Daniele suggests, Search by Metadata really is the way to go. The plugin creates a linked browse result of any item matching the exact literal input for the metadata property to which it is assigned. That was you can gather together all the items that have the same creator or subject term or coverage (place or time period). It will allow for lateral movement across the items, but also you can use those search strings to build navigation. Simple Vocab really is the easiest way to keep those inputs consistent via the drop down menus.