By accident, I discovered that I was in violation of Flickr’s Terms of Use today. According to the TOS, Flickr is not a image hosting service. I’m not sure how it differs from an ‘image hosting’ service, other than I needed to include a link back to the photo flickr page for every photo embedded in a page here. Which explains why Flickr photo pages are starting to dominate search engine results, especially if people use meaningful photo titles.
The link back isn’t a problem within my weblog posts, but my the page generated by my photo metadata application, as well as Tinfoil, my photo album, have not been including a link back to the Flickr page. Unfortunately, this means that I’m going to have to change the code of the data collection element of my photo application. Which also means I’m going to have to re-run this for every page where I’ve included photos.
My fault for not checking the TOS more carefully. However, while I’m in the process of making this change, another one I’m making is to define a set for all photos that have been embedded in a weblog post, and add a tag linking the photo with that post. I also created a program that will use the Flickr API and download a local copy of each image. It will then update my post entries to point to the locally named copy, as compared to the one on Flickr. It’s my ‘backdoor’, just in case I decide I want to host my photos locally. No matter how much you like a centralized service–and I like Flickr–you should always have a backdoor.
I’m adding the metadata directly into the image itself, including the new longitude and latitude values, using the geotagging format. This way, this information follows the image no matter where I store it. I also add title, creator, description, keywords, and so on. When I do, Flickr pulls this data out and uses it to create the Flickr title, description, and tags.
(The geotagging format consists of three keywords or tags: “geotagged”, “geo:lon=value”,”geo:lat=value”. This is becoming standard format, and photos tagged with this are automatically pulled into other, external applications, such as my use with GoogleMaps.)
My photo application can pull this data out of the original image (whether stored locally, or found using the Flickr web services), utilizing a handy image metadata library for PHP.
I could keep the metadata stored in the image and just output this when the image metadata page is accessed. However, I store all of the data for each image as RDF, associated with the URL of the page itself, added to any other metadata I have for the page (much of this generated automatically using the same functionality used to drive the syndication feed in use for the site). The data is then available for my use, and accessible by any tool that can consume RDF/XML, such as Piggy-Bank.
I used to store this data in the database, but I’m now looking at trying something new. I figure if I have to re-do all the data, I might as well experiment.