I’ve been working on a new website – PhotoPing.com – and with it comes a revival of the PhotoRSS spec.
Look for it soon…
August 6, 2007
September 24, 2004
Today on the geowanking list Sonny Parafina wrote:
“Raj put forward his planning use case that required lines and polygons. Could someone articulate a use case for “intermediate stages"? I think that would be a useful place start in addition to all the discussion. I’m still not sure we are all talking about the same problem set.” [emphasis mine]
The following was my response.
My wife Rachel was in the ad business for a long time, and has hammered into me the following mantra – start with a goal, then develop strategies to reach that goal, and finally devise some tactics to implement the strategies. She laughs at me (and most of my fellow geeks) because I’m (we’re) always doing things from the bottom up – “hey here’s a cool idea, I wonder if I toss it into the ether it will become a solution to someone’s problem that I’m not sure exists yet?” Take RDF for instance… (just kidding guys, no flames please).
All I can do is try to answer those three questions from my perspective:
My Goal: Make photos more searchable.
My Strategies:
- Make it possible for search engines to know what a photo is about, rather than having to guess what it’s about from the surrounding context.
- Build on existing solutions, rather than starting from scratch.
- Make it dead-easy for everyone to update their web pages.
My Tactics:
- Build a photo app that makes it really easy to get photos up onto the web (i.e. Web Photos Pro).
- Enhance the <img> tag on the web pages produced by my app. Exactly what form that might take is up in the air, but there are at least three possibilities, as discussed 2/3rds of the way down at 3. Making Photos More Searchable, and again at Four XHTML Questions.
- Output RSS from the app so that people can subscribe to my photos with an RSS-reader (if they are so inclined), and the feeds can be indexed by Technorati, etc.
- Build on the success of RSS by suggesting something similar that’s photo-specific. I’ve called that PhotoRSS, and discuss it at PhotoRSS.com. Personally I’m hoping that someday someone will build a “Photorati” search engine that indexes PhotoRSS feeds just like Technorati indexes RSS feeds.
FWIW, I believe there’s one tactic missing, that I just haven’t had time to get started, and that’s to develop a geourl-like service for photos. GeoURL got millions (?) of people to add latitude and longitude to their web pages. Who had any idea that there was so much pent up demand? I think there’s similar pent up demand for photos, but there needs to be a “geophoto” or similar service to kick start it, and it needs to be such a simple html mod that anyone can do it without having to look at the spec every time. If I had time I’d turn www.photorss.org into such a site.
Hope this helps.
– Frank Leahy
Richard Soderberg posted the following email to the geowanking list on Wednesday. It’s a nice review of the various geo-syntaxes currently in use.
If you know of any others, please let me know.
What all is out there currently, and what’s the conglomerate of them all look like for a given page?
The conglomerate of <HEAD> modifications from what I’ve looked at so far:
<head profile="http://geotags.com/geo">
<meta name="ICBM” content="44.07,-123.08″ />
<meta property="geo:lat">46.1</meta>
<meta property="geo:long">124</meta>
<meta name="geo.position” content="44.07;-123.08″>
<meta name="geo.region” content="US-OR">
<meta name="geo.placename” content="Eugene">
</head>There’s only one way I’ve found, so far, to associate the data with a given container element:
<span style="display:none” xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<geo:lat>46.1</geo:lat><geo:long>124</geo:long>
</span>Reading an XHTML specification, I find that <meta property> can be used with <link rel="profile"> to indicate the definitions of certain metadata attributes such as geo:lat, geo:long, and geo:alt. As such, the following syntax should be:
(a) XHTML compliant
(b) human and X?HTML-editor readable
© easy to detect with existing HTML spiders
(d) not limiting future development of shapes and so on.I think it’d be a worthy successor to the ICBM header, even if it’s slightly larger in byte-size. That said, it may not serve the one-tag desires or the per-item desires. I submit this for discussion.
<head>
<link rel="profile” href="http://www.w3.org/2003/01/geo/wgs84_pos#">
<meta property="geo:lat">46.1</meta>
<meta property="geo:long">124</meta>
</head>- R.
GeoURL:
- To tag an HTML document, put this in the HEAD block:
<meta name="ICBM” content="44.07,-123.08″ />Map Bureau:
- To tag an HTML document, put this in the HEAD block:
<meta property="geo:lat">46.1</meta>
<meta property="geo:long">124</meta>- To tag an HTML container element, include the following block:
<span style="display:none” xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<geo:lat>46.1</geo:lat><geo:long>124</geo:long>
</span>Blogmapper:
- To tag an HTML container element, include the following block:
<span style="display:none” xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<geo:lat>46.1</geo:lat><geo:long>124</geo:long>
</span>Geotags:
- To tag an HTML document, put this in the HEAD block:
<head profile="http://geotags.com/geo">
<meta name="geo.position” content="44.07;-123.08″>
<meta name="geo.region” content="US-OR">
<meta name="geo.placename” content="Eugene">Locative:
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:rdfs="http://www.w3.org/2001/02/rdf-schema#”
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#”
xmlns:dc="http://purl.org/dc/elements/1.1/”
xmlns:locative="http://locative.net/etcon2004/loc#”
xmlns:media="http://purl.org/dc/dcmitype/”
>
<locative:Packet><dc:coverage>
<geo:Point>
<geo:long>-0.0104</geo:long>
<geo:lat>51.5722</geo:lat>
</geo:Point>
</dc:coverage><locative:media>
<media:Image
rdf:about="http://iconocla.st/photo/2003/10/12/img_0299-m.jpg”
dc:format="image/jpeg"/>
</locative:media>
<rdfs:seeAlso rdf:resource="http://iconocla.st/photo/2003/10/12/img_0299.html"/></locative:Packet>
</rdf:RDF>
September 21, 2004
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:
- 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.
- 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.)
- Making Photos More Searchable: This has two components, the RSS and PhotoRSS feeds, and an enhanced <img> tag.
- 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.
- 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 guess what 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.
September 20, 2004
Placeholder. PhotoRSS documentation will go here.
Placeholder. RSS xmlns for photos will go here.
September 1, 2004
To make photos more searchable the information about the photo – the title, description, keywords, location, etc. – must be made explicit. There are two ways that this can be done: 1) you can embed the data in the photo, or 2) you can bind the data to the photo’s <img> tag.
Many cameras already embed data in your photos, using the EXIF portion of the JPEG header. The big benefit of EXIF is that the data stays with the photo – link the photo to a web page and it’s there, email the photo to me and the EXIF data gets emailed too. But there are so many downsides – the data is invisible to the human eye, the photo has to be opened to see if it has embedded data, EXIF data is not as structured as it needs to be, the format has some severe limitations, most resizing programs do not keep EXIF data intact, EXIF editing is difficult to do, and the data cannot be context dependent – that it’s pretty obvious that EXIF is not the right way to solve this problem (at least not in the foreseeable future).
This leaves us with only one way to make photos more searchable – by finding a way to bind a photo’s data to its <img> tag. And this problem, how to best bind photo data to the html <img> tag, leads me to ask the following four questions about XHTML.
-
Question 1: Is my analysis of the situation correct? Is the best/only way to make photos on the web more searchable to bind information to the photo’s <img> tag?
-
Question 2: Is it possible, using XHTML, to add attributes to the current html <img> tag?
Here’s an example of what such an “enhanced” <img> tag might look like:
<img src="/example.jpg” height="100″ width="100″ alt="Example” pc.geo.position="50.5836;-4.8972″ pc.geo.region="GB-CON” pc.geo.regionname="Cornwall, England” pc.geo.placename="Polzeath” pc.title="Flower In Our Garden” pc.keywords="flower, pink, open” pc.photographer="Frank Leahy” pc.copyright="© Copyright 2003, Frank Leahy” pc.exposure.date="18 Sep 2003″ pc.equipment.camera="EOS 10D” />
where the “pc” prefix might refer to an XML namespace “Photo Core".
-
Question 3: If the answer to question 2 is “no, not possible", how does one go about creating a new XHTML tag <photo>?
Here’s an example of what such a <photo> tag might look like:
<photo src="/example.jpg” height="100″ width="100″ alt="Example” geo.position="50.5836;-4.8972″ geo.region="GB-CON” geo.regionname="Cornwall, England” geo.placename="Polzeath” title="Flower In Our Garden” keywords="flower, pink, open” photographer="Frank Leahy” copyright="© Copyright 2003, Frank Leahy” exposure.date="18 Sep 2003″ equipment.camera="EOS 10D” />
-
Question 4: If one were to create a new <photo> XHTML tag, how would you “bind” it to a particular <img> tag?
Would you:
- surround it like this: <photo><img/></photo>, or would you
- use a “name” or “id” attribute to link the two tags, like this
<photo name="a_name” /> <img name="a_name">?
- surround it like this: <photo><img/></photo>, or would you
July 27, 2004
PhotoRSS is a multi-faceted approach for syndicating photos, and making them more searchable.
PhotoRSS builds on formats such as HTML, XML and RSS, bringing to photos what has already been done for weblogs and text.
PhotoRSS is comprised of the following three things:
- Three extensions to RSS 2.0
xmlns:photo, xmlns:album and xmlns:gallery are three RSS 2.0 xmlns extensions which define formats for syndicating photos, albums and galleries, so that your photos (albums and galleries) can be viewed with existing RSS readers.
- A new RSS-like syndication format for photos
PhotoRSS is an RSS-like format that provides an extensible photo-centric mechanism for syndicating your photos – think of it as xmlns:photo on steroids. With this new format the next generation of RSS readers will be able to search for, and display, photos in ways that aren’t possible with the xmlns:photo RSS extension.
- A new XHTML tag
<photo></photo> is an XHTML tag that can be used with the <img> tag, to define photo-specific information in your web pages. By adding this tag to the photos that appear in your web pages, search engines such as Gooogle will no longer need to guess what your photos are about, they’ll know what they’re about.
NOTE: At this point, I’m unsure about how to proceed with step 3, defining a new XHTML tag, and so I’m going to write a piece on my A Year In Cornwall weblog and see if anyone can help me flesh it out before I stick my foot too far into my mouth.