RSS for Photos | Syndicating your photos, and making them more searchable

Mar/12

5

Theoreticians vs Implementors

I subscribe to the geowanking list, run by the guy who started geourl (currently down for repairs), and del.icio.us. (If nothing else he’s got a penchant for puns – check out the geowanking list server domain.)

There’s been a discussion about the “next gen geourl” on geowanking which has caused tempers to flare a bit, and the list mom to send out a virtual spanking or two.

My take on it is that there are two types of people on the list – theoreticians, and implementors – and they really don’t understand each other.

The theoreticians throw around RDF notation like it’s fairy dust, certain to charm everyone if they just sprinkle enough of it. And the implementors roll their eyes and say things like “oh come on, let’s just do something”. Combine the two and you’ve got a recipe for nothing actually getting done on the list. Not that big a deal for me, as I subscribe for the occasional postings that keep me in touch with what’s happening in the geo-world, but it can make for people talking past each other at times.

I’ve had a number of interesting off-the-list conversations recently, two in particular, one with a theoretician and one with an implementor.

The one with the theoretician started with him sending out this message:

Why an “elegant” notation?

Because a healthy and sustainable approach would be to publish (or adopt) a resilient place-time grammar, and then derive simpler notations from it for specialized applications, of which “putting tags on web pages” is one.

Those who want to work on this, please contact me directly via e-mail and we will proceed.

Ok, I thought, I can get behind that last part. So I wrote back and said:

When you get to the “putting tags on web pages”, let me know, and I’ll update my app accordingly.

And oh by the way, here’s how I’d do it (I know, had to shoot my mouth off)…followed by the more seat of the pants get it done approach I would take if I were still at Wired Digital (i.e. Terra/Lycos).

We had another back and forth, and then left it at that.

Tonight I got a chance to plug my new photo application, Web Photos Pro, on the list, in response to a question about “tools for managing photo metadata (geo included)”. And in response to my posting I got an email from Sam at A2B (another punster it looks like), who wanted to know if there was a way we might work together. Aha!, a fellow implementor.

We had a couple of back and forths, and in one of them he asked me how I thought the RSS and PhotosRSS feeds that Web Photos Pro produces could make photos more searchable. And in responding to him I realized it might be useful to record the response here, in case others had the same question, but also because it lies at the heart of what I’m trying to do on this site (www.photorss.org).

Here was my response:

Sam’s Q: Okay, I think I get it – so the idea is that people can search for photos, using RSS and PhotoRSS, which are close to their other photos or [in] a location they specify? What I don’t understand enough about is the way searchable RSS works – how do you search back through many, many RSSed photos from the past when they’ve come from so many different RSS feeds?

Frank’s A: Almost, but not quite – here’s the idea in more detail:

  1. Web Photos Pro generated “RSS” feed: this is just like any old RSS feed. Do you use an RSS reader? If so, add this RSS feed – http://www.webphotospro.com/MyFirstPhotoGallery/My%20First%20Album/rss.xml – and you’ll see the photos in the album as individual entries in your RSS reader. Pretty cool. This means people can subscribe to these photo albums and photo galleries just as they do any other RSS feed.Where this becomes much more useful is when Web Photos Pro Server Edition is installed on a web server. Web Photos Pro Server Edition will produce a “Latest Photos And Albums” RSS feed, which means that people will only have to subscribe to a single RSS feed to get all of your latest photos and albums.
  2. Web Photos Pro generated “PhotoRSS” feed: This is similar to an RSS feed (in that it’s XML-based, and uses some of the same terminology), but it’s photo specific. I think there will be a need for a photo specific feed in order to do more advanced things (a little hazy here…), and to allow for better extensibility. Yes, RSS is extensible, but do you really want to be extending the extensions in order to add EXIF data to the RSS feed? Maybe, or maybe not. We’ll have to see.(I guess I’m covering my bases by generating both RSS and PhotoRSS.)
  3. Making Photos More Searchable: This has two components, the RSS and PhotoRSS feeds, and an enhanced <img> tag.
    1. RSS and PhotoRSS feeds: I don’t know if you’re familiar with Technorati, but it’s just one of several RSS-specific search engines. I want Technorati to start searching my photo RSS feeds as well as my blog feeds so that people can find my photos more easily.I guess what I’m hoping is that someone will start Photorati, and they’ll index my PhotoRSS feed in the same way that Technorati indexes my RSS.
    2. Enhance the <img> tag: I want Google (and other search engines) to start indexing my photos too, but I want them to know what each photo is about, not just guesswhat they’re about from the html that’s near the photo (basically how they do it now).They could, I suppose, start looking for an RSS or PhotoRSS feed and index that, but I think it’s unlikely they’ll do that.What I think they’re more likely to do, is to starting looking for an image-specific tag, once one is defined and in wide-spread use.

      There are at least three forms that this tag could take. The options seems to be:

      • Option 1: Add new attributes to the <img> tag:Example:
        <img
        src=”/foo.jpg”
        photo.geoURL=”45.4569,-122.1432″
        photo.title=”Mustard Fields”
        photo.description=”…”
        >
      • Option 2: Add data by matching id’s:<photo id=”1″>
        <geoURL>45.4569,-122.1432</geoURL>
        <title>Mustard Fields</title>
        <description>…</description>
        </photo>and somewhere on the page (possibly right next to it, but not necessarily), is an image with id=”1″, e.g.
        <img src=”/foo.jpg” id=”1″>

        Google would see that the id’s matched, and index the photo based on the data in the <photo> tag.

      • Option 3: Similar to 2, but the <photo> tag would surround the <img> tag, like this:<photo id=”1″>
        <geoURL>45.4569,-122.1432</geoURL>
        <title>Mustard Fields</title>
        <description>…</description>
        <img src=”/foo.jpg”>
        </photo>

Anyway, you probably get the idea by now. I know something needs to be done, the question is what. And then how to make it happen.

Personally I think it requires an implementation to make it happen. Look what geourl did – who knew there were so many people willing to add a latitude and longitude to their web pages? And now del.icio.us and Flickr.

RSS Feed

<<

>>

Find it!

Theme Design by devolux.org

Tag Cloud

Archives

To top