It’s just data

Which Way Is Up?

Nigel Tao: we now support GeoRSS as a data format for geographic content in Google Maps.  We want to enable users to create data in whatever format is most convenient for them, and feel that by supporting both KML and GeoRSS we can enable a wider variety of people and applications to contribute content to Google Maps.  We’ve built support for the Simple, GML, and W3C Geo encodings of GeoRSS — all you have to do is enter the full URL of a GeoRSS file into the Maps query box to load the file.  For example, take a look at SlashGeo’s GeoRSS on Google Maps.

That support is certainly cool, but GeoRSS was news to me, and the Feed Validator previously only supported the W3C Geo encoding, so I added the examples from the GeoRSS documentation as an initial set of test cases and set off to add support to the validator.  And thus begins the journey...

Doubling back to validate the SlashGeo feed, and the result is two warnings.  The first represents the transplanting of the controversial RSS 2.0 practice of double encoding titles as HTML — which is discouraged by a number of Google, Microsoft, and Mozilla tools — into the context of RSS 1.0.  The second is the use of a comma as a separator for latitude and longitude values, where the spec requires whitespace.  Another place in the spec requires a [single?] space.  A third place in the documentation indicates that the preferred serialization of this uses a [single?] space to separate the two values.

Update: this latter issue has been addressed in the slashgeo feed.  Thanks!

OK, but the SlashGeo feed is not only supported by Google, but held up as an exemplar, so I’ve downgraded the message that is produced when a comma appears where a space ought to be to a warning.

So, just when I think I’m done, and get ready to commit these changes, I find this:

Simon Willison: My photos tagged “cheese” on a Google Map. You can paste a Flickr GeoRSS feed directly in to the Google Maps query box

Validating that feed produces two errors.

For starters, does anybody know where dc:date.Taken is defined?  If there is documentation, I will add support for it in the Feed Validator.

Update: as spotted by Kevin H, this is valid "Qualified" Dublin Core, and I’ve updated the feed validator to accept it.

But the more interesting one is the second error.  It points to georss:point and says that geo:point is undefined.  Looking further, we find that while the GeoRSS spec suggests:

xmlns:georss="http://www.georss.org/georss"

and the W3C Geo spec suggests:

xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"

... the Flickr feed contains a mashup of these two:

xmlns:georss="http://www.w3.org/2003/01/geo/wgs84_pos#"

These two namespaces aren’t compatible.  The W3C Geo spec defines a Point with a capital P and utilizes nested child elements (per this example), and Simple GeoRSS defines a point with a lowercase p, and omits the child elements (per this example).

If anybody can shed any further light on this, please either leave a comment here or on the feedvalidators-users mailing list; the latter I am seriously considering shutting down and moving the whole Feed Validator project to Google Code as the mailinglist is being overrun by spammers.


The slashgeo feed was a random choice, I think, not an exemplar.

Posted by Sean Gillies at

I assert that examples that are pointed to by Google, and supported by Google Maps, will be imitated, are (or will become) representative, will serve as a pattern that others will follow, and copied.

In short, Nigel’s post has (undoubtedly inadvertently) effectively promoted the SlashGeo feed as an exemplar.

Posted by Sam Ruby at

Flickr is wrong. The correct namespace is xmlns:georss="http://www.georss.org/georss"

Posted by Raj Singh at

Agreed on the Google effect. I don’t know why they didn’t pick a feed from the GeoRSS community. Something from Mapufacture, for example.

Posted by Sean Gillies at

Sam Ruby: Which Way Is Up?

[link]...

Excerpt from del.icio.us/mikel_maron at

Another example: feeds from eventful.com contain georss data sometimes. e.g., [link]

Posted by Edward O'Connor at

Thanks for telling us. slashcode’s GeoRSS feed plugin is in development, it is not considered completed yet. We’ll fix the issues - thanks for mentioning them! :-)

Posted by Alexandre Leroux at

For starters, does anybody know where dc:date.Taken is defined?  If there is documentation, I will add support for it in the Feed Validator.

I’m no metadata expert, but it looks like an example of "Qualified" Dublin Core

Based on the following guidance:

The guiding principle for the qualification of Dublin Core elements, colloquially known as the Dumb-Down Principle, is that a client should be able to ignore any qualifier and use the description as if it were unqualified. While this may result in some loss of specificity, the remaining element value (without the qualifier) should continue to be generally correct and useful for discovery. (source)

I would expect the FeedValidator to throw no more than a warning, so long as the unqualified element is part of Dublin Core.

Posted by Kevin H at

I would expect the FeedValidator to throw no more than a warning, so long as the unqualified element is part of Dublin Core.

I’ve updated the Feed Validator to accept without warning qualified elements, but only for the Dublin Core namespace, and only if the unqualified element would otherwise be accepted by the Feed Validator.

Thanks for tracking this down!

Posted by Sam Ruby at

I’m sorry to say it, but I fear I may have steered you wrong.  What nagged at me after submitting my last comment was that I never did find any recommendation on how element refinements should be represented in an XML context.

I took a little time and dug some more through the DCMI site, and I’ve now found that recommendation, Guidelines for implementing Dublin Core in XML. (Check Section 5 and Note 1)

I’m a bit confused, now, if the recommendation even allows arbitrary extension, considering this MUST:

- Each property must be either:

But some hope is given in Recommendation 8, with this SHOULD:

Element refinements and encoding schemes should use the names specified in the DCMI Metadata Terms recommendation

I’ll also mention, since I happened across it, that the “Date.Taken” dot-notation seems to have lost favor even in HTML/XHTML meta and link elements:

2. Previous recommendations specified prefixing element refinements by the element 
being refined, for example 'DC.Date.modified' rather than 'DCTERMS.modified'.


These forms of encoding are acceptable but are no longer considered the preferred form.


Posted by Kevin H at

transplanting of the controversial RSS 2.0 practice of double encoding titles as HTML

Where in the RSS spec is this specified?

We design our RSS so that the result can be dropped right into HTML.  There is no standard for this in the spec, but it was discussed on the rss-dev mailing list awhile back, and there were several
proponents for the method we use.

Posted by tf23 at

There is no standard for this in the spec, but it was discussed on the rss-dev mailing list awhile back, and there were several proponents for the method we use.

Citation?

Posted by Sam Ruby at

Oh, good me: I was looking in bug 313441 to give me an approximate idea of when it had been, but I actually left a link to the citation there, too.

That was pretty much when I completely gave up on RSS 1.0.

Posted by Phil Ringnalda at

Jeremy Zawodny : Which Way Is Up? - Which Way Is Up?: GeoRSS is a partially undefined spec... anyone surprised by that? Tags : links...

Excerpt from HotLinks - Level 1 at

links for 2007-03-24

Lift Web Framework I’ve begun considering what language and/or framework to learn next. I doubt it’ll be Scala, but this does sound interesting. (tags: frameworks lift scala) Dean Edwards: Yet Another JavaScript Library Without Documentation “This...

Excerpt from a work on process at

[from zhangyining] Sam Ruby: Which Way Is Up?

[link]...

Excerpt from del.icio.us/network/Kianhui at

[link]

Can’t the value in georss:elev be negative?

Posted by Franklin Tse at

Can’t the value in georss:elev be negative?

Fixed.  Thanks!

Posted by Sam Ruby at

Google MyMaps and GeoRSS

O’Reilly’s Where 2.0 Conference isn’t until the end of May, but Google just released two sweet new map-related features: GeoRSS support and MyMaps. The GeoRSS support means that any application that can output it’s geocoding...

Excerpt from MaisonBisson.com at

Flickr: Two new subtle geo updates

Mainly being geoRSS update and more location information goodness for you in the flickr.photo.getInfo call.1.... If the photo has been dropped onto the map from a fairly high level you may only get region or country.We’re still recording the...

Excerpt from geobloggers at

OMG I AM TEH FAMOS!!!!!!!

To be precise, I’m on the Slashdot , which means I now have +1 Nerd Cred. Admittedly, it popped up on Easter Friday, which would probably be in the top 3 slowest news days of the year. And you have to dive in to the numerous links (no, not from a...

Excerpt from The Other Sort of Tao at

Google MyMaps and GeoRSS

O’Reilly’s Where 2.0 Conference isn’t until the end of May, but Google just released two sweet new map-related features: GeoRSS support and MyMaps. The GeoRSS support means that any application that can output it’s geocoding...

Excerpt from MaisonBisson.com at

More Like This, Please

First, Sam Ruby on GeoRSS, and now Stefan Tilkov on REST and CRUD: lessons from the Web for we who would build the Geo-Web. Listen up....

Excerpt from Entries for import cartography at

OMG I AM TEH FAMOS!!!!!!!

To be precise, I’m on the Slashdot, which means I now have +1 Nerd Cred. Admittedly, it popped up on Easter Friday, which would probably be in the top 3 slowest news days of the year. And you have to dive in to the numerous links (no, not...

Excerpt from The Other Sort of Tao at

Add your comment