GeoRSS Metadata
December 7th, 2006
GeoRSS has gained a large acceptance in the geo-community and is being implemented and used in many desktop and web-based tools. As is probably to be expected, currently georss:point is the most commonly used element, as it is very simple to understand, obtain data, and consume. It’s safe to assume that line, box, and polygon will start becoming more used as the tools become more mature.
However, a part of the GeoRSS spec that has not gained much attention, and very little if any actual implementation, are the additional metadata that can be used to associate the geometry to the RSS item. I’m speaking of relationshiptag and featuretypetag.
Based on the standard model, they are defined as:
- Feature Type Tag
- GeoRSS geometry is meant to represent a real feature of the Earth’s surface. The GeoRSS model allows for a single string containing a featuretypetag. No constraints are placed on this string. The intent is to allow a Feature Type folksonomy to emerge. The default is “location”.
- Relationship Tag
- GeoRSS is a way of relating Web content to Earth features. The GeoRSS model allows for a single string containing a relationshiptag. No constraints are placed on this string. The intent is to allow a relationship folksonomy to emerge.The default relationship, “is-located-at” simply indicates that the subject of the content is located at the GeoRSS feature.
These definitions are rather generic and offer little help as to best practices for these tags. Josh Lieberman is heading up a W3C Working group on updating the Geo Vocabulary to support tagging and metadata between GeoRSS, RDF, SemanticWeb, et al. However, it’s a rather broad canvas to start putting ideas to and implementing.
Mikel proposed using the relationshiptag for image overlays using the tag “image-extent-is”. Josh pointed out that relationshiptag can be useful for defining parts of an otherwise very large entity, such as “summit-of” “mountain”. This could be useful for other sub-locations such as “trailhead”, “entrance”, or “former-location-of”
As for featuretypetag there is the RFC4589: Location Types Registry that provides a standard list of location names and their definitions. This includes names like: airport, hospital, residence, or school.
It seems imperative to begin defining a standard dictionary of tags that are expected in the relationshiptag and featuretypetag GeoRSS elements. While folksonomic tagging can exhibit new and interesting relationships, it also makes interconnecting these tags with user-based idioms difficult. How else does someone “find all the restaurants in my area”?
December 8th, 2006 at 10:28 am
Some random thoughts on this. … I thought RFC4589 was pretty limited. I’ve noticed these days that I’m more interested in the interstitial spaces. Hallways, lobbies, courtyards, all of which have different characteristics depending on what they are close to. … As far as folksonomic tagging - don’t make the taggers be precise, let the aggregators be smart. If I tag a “diner” here and a “coffee shop” there, a “bistro” there and a “tapas bar” next door, I’m doing my best to be specific. I don’t want to have to use “restaurant” just so you can find a place to eat. But the aggregator can provide the folksonomy to taxonomy to ontology to whatever mapping that lets me tag my way and lets you search your way.
December 8th, 2006 at 11:59 am
Good points - I agree that RFC4589 isn’t “complete”, it’s very limited and targeted to larger/common spaces. I was pointing to it as a possible baseline or jumping off point for discussion (which it’s doing).
And you’re right that it should still be “folksonomic”. Aggregators can possible use something like an extended RFC4589 to serve as the broad bins (or bundles) into which “diner, coffee shop, et al.” go. This bundling could also be smart by learning that things marked “bistro” are sometimes/often also tagged “restaurant” so maybe bin these together.
As for your example of “hallways” - would this also perhaps include a tag for the building that it is within? GeoRSS is limited in this respect in that you can only tag/refer to a single geographic space, so just the hallway, and can’t reference another space - that it is “within” this building/extent.
December 8th, 2006 at 5:59 pm
While digging through my emails - I found some more resources:
From Bernard Vatant
December 8th, 2006 at 10:43 pm
I agree that RFC4589 is a good starting point for a discussion. And I can waffle many ways about these kinds of things. I think being able to characterize spaces could be good. But I’m not sure I’m ready to believe that IETF needs an RFC for that.
My current thinking about “hallway” is mediated strongly by wandering up and down the infinite corridor at MIT, thinking about how to talk about what makes it special. That plus an experience in a hotel recently. Hallways are *much* noisier near the elevator than at the ends.
Space needs to be simultaneously aggregated and differentiated. This square meter has a different ambience or story than that square meter. But if I move slowly enough from one spot to another, I don’t really notice the gradient. There’s a silly-putty like quality. Pull slowly, it stretches. Pull quickly, it breaks. Not sure if this makes any sense, but it comes down to the fact that for some purposes, 4589 is probably great. For others it’s not.
So back to GeoRSS. I’m not so worried about limitations in being able to express nuance. If we were to try to capture everyone’s nuance, we’d have to make things a tad more complex…
April 2nd, 2008 at 8:24 am
[…] This is a shame because metadata is very useful, especially when it comes to describing, finding and federating data. This is one of the shortcomings of KML - little/no metadata (although several argue it has no place in either of these formats). GeoRSS has limited metadata support with “Feature Type Tag” and “Relationship Tag” which are useful, but fairly confined. […]