I saw several references to "GeoRSS 2.0" recently by people who are attending
the OGC TC meeting in St. Louis. Here's my 2 cents on 2.0:
- Deprecate the simple geometry encoding and just go with GML in a georss:where
element already. Yes, this is a complete about face from my position in 2006.
Nevermind XML Schema, I'm just saying that the GML encoding is more
expressive, more clearly defined, and not significantly more difficult to
produce or parse. I've even contributed a GML parsing patch for the
Universal Feed Parser. If I can do it, how hard can it be?
- Specify cardinality: an entry should have 0 or 1 geometry (see following
comments about multiple locations).
- According to the 1.0 spec: "GeoRSS geometry is meant to represent a real
feature of the Earth's surface". Why not above the surface, or below? Do you
really think that's going to stop Satan from using GeoRSS to geo-tag news
from the hellish center of the Earth? I think this language can go in 2.0 and
take elev, floor, and radius along with it. We're all better off using
3D coordinate reference systems, and the quick adoption of KML shows that a
third dimension isn't a serious stumbling block.
- In the next paragraph, it is written: "GeoRSS is a way of relating Web
content to Earth features". That statement is more dense and chewy that it
seems. To me, it seems like specifying nothing more than how to add location to entries is a
worthy enough effort. The relationship of entries to the real world is really
more of a semantic web concern.
- The semantics of featuretype tag and relationship tag better belong to
entry entities than to location entities. The fact that they are not
significantly used is, in my opinion, tacit acknowledgement of the truth of
that statement. Atom and RSS already allow you to categorize entries and
items, which makes featuretype tags unnecessary. Atom also provides a
mechanism to relate entries to other entities on the Web: links obviate the
need for relationship tags.
- Multiple locations I have already blogged. Entries are cheap.
- The 1.0 spec only considers literal geometries. Referencing external
geometries is something else that's being considered for a future version.
I'm -0 on the first option (inspired by
http://rest.blueoxen.net/cgi-bin/wiki.pl?XMLSemanticWeb) and -1 on the second
(inspired by http://tools.ietf.org/html/rfc4287#section-4.1.3.2). I now
prefer an approach that first came up on the GeoRSS list here, and which Tom
Elliot and I had also been discussing that fall: using Atom links and custom
relations. The equivalent of that first option could instead be something like:
<entry>
...
<link
rel="http://www.georss.org/relations/is-colocated-with"
href="http://pleiades.stoa.org/places/639166.atom"
type="application/atom+xml;type=entry"
/>
</entry>
Update (2008-03-28): Notes on my adventures in this direction are at http://atlantides.org/trac/concordia/wiki/AtomLocationByReference.
If you push more semantics from the location up into the entry, using Atom and
its extensions, the ground that GeoRSS has to cover shrinks, a good thing for
any specification. But what about RSS 1.0 and 2.0? The former can draw on RDF,
of course. Maybe the latter needs links from SSE.