I'm still trying to find a good way to manage photographic metadata.
Several months ago, when I upgraded to Feisty, my nascent photographic metadata web application stopped working. Although I'd abandonned all realistic hope of turning it into an application that others would use, it was working pretty well for me. Pretty well until it stopped completely:
/usr/lib/ruby/1.8/rdf/redland/resource.rb:5:in `append_features': cyclic include detected (ArgumentError)
from /usr/lib/ruby/1.8/rdf/redland/resource.rb:5:in `include'
from /usr/lib/ruby/1.8/rdf/redland/resource.rb:5
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
…
Web searching revealed that I wasn't alone, but didn't reveal any obvious messages of the form “do this to fix the bug” short of upgrading the whole ruby/redland infrastructure. I sent off some mail, reported the bug, and waited. I poked at doing my own upgrade of the ruby/redland infrastructure but gave up when the obvious five-step: download, unpack, configure, make, install didn't fix the problem.
I was confident that one of my routine “apt-get upgrade”s over the next few days or weeks would make the problem go away. No such luck. So when I stumbled, by random chance, over Mark’s Essentials list and saw his description of digiKam:
It’s just like iPhoto except it calls albums “tags”, exports to Flickr for free, exports to HTML that validates, stores my important metadata in a SQLite database, can be operated entirely with a keyboard, and doesn’t suck.
I thought I'd give it a try. Converting my several tens of megabytes of RDF/XML metadata into several tens of megabytes of SQL so that I could manufacture an SQLite database that digiKam would swallow took a few hours, but I managed.
![[Photo]](http://farm2.static.flickr.com/1289/535305945_615e08cb93.jpg)
![[Flickr]](/graphics/flickrt.png)
digiKam editing The TAG at Google
After tagging a few dozen photographs, I have to say, I think it's probably good enough. I have some gripes, but they're perhaps the result of design decisions more than bugs, so I'm unlikely to pursue any remedy for them. In case you're interested:
-
As far as I can tell, digiKam expects you to store all of your photographs in one location, system wide. If you attempt to import new photographs, it begins by copying them into that location. This is contrary to how I work, and seems unlikely to work for anyone with a really large collection of images. I want to point digiKam at a location and say “let's tag some of these”, then later, point it at another location and do the same. Ideally, it would let me move images between locations, preserving the database-backed metadata as I did so.
Speaking of metadata, if you start digiKam and it can't find some of the images that it tagged before, perhaps because some disk isn't mounted, it insists on deleting all the metadata associated with those images. I appreciate the option of deleting the metadata, but I resent being forced to. I wish it had an option to just ignore (but preserve) metadata for the missing images. Always having all the relevant disks mounted is going to become inconvenient.
-
The digiKam database contains a comment associated with each image and a set of tags. I wish it allowed me to associate arbitrary key/value pairs with each image, but I can see how that would complicate the database design. Lucikly, the tags digiKam supports are hierarchical, so I can do just enough mapping. I associate the top-level “People” tag with with the foaf:depicts property, “What” with dc:subject, and “Where” with dc:coverage, for example. It's not perfect and it doesn't really work for titles, credits, copyrights, descriptions, comments, or geographic metadata. I work around those with the same “structured comments” hack that I use in my PDA.
The way digiKam expect you to deal with all this other metadata is by storing it directly in the image using the EXIF and IPTC standards. On the one hand, that's exactly the right answer. I wrote JpegRDF years ago so I could do exactly that. On the other hand, the plugins that support editing that data don't seem to support the RAW format from my camera. And also, photographs are one of a very small number of truly irreplacable digital artifacts in my life. I'm very, very conservative about letting applications edit them.
Finally it doesn't seem to be possible to make changes to the EXIF and IPTC data on a group of files at once.
So I make do with structured comments. I expect to pull all the data out of SQL and turn it back into RDF eventually anyway.
I haven't figured out how I'm going to update the database automatically with new images (preserving, for example, GPS and other metadata from my RDF sources). But I suppose it's just SMOP.
