[georss] Transport of Toponyms with GeoRSS
Josh@oklieb
josh at oklieb.net
Mon Aug 28 11:25:22 EDT 2006
Hi,
If we step back a second from just the syntax of GeoRSS, what we have
been trying to do is provide simple and effective geotagging which is
also rigorous. In other words, someone can easily communicate
location with GeoRSS. Someone else can then parse that GeoRSS and
understand how the provider intended to represent information and
geography in the context of a feature model and reference framework.
There are basically three ways of combining the feature concept with
the generalized Web resource concept:
1) There is only the feature, derived from an abstract feature
concept. Everything else is a property of that feature. This is very
clean in a geospatial and GML sense, but clashes violently with the
fact that Web resources exist independently of feature
conceptualization. Hence the lack of compatibility between the world
of information on the one hand, and well-structured geodatasets on
the other.
2) Web resources and features are independent, first-class concepts
which are sometimes related. This is the most flexible approach in
terms of respecting each first-class concept, but involves a possibly
overwhelming amount of administration to maintain the resources, and
the features, and valid relationships between them. In many ways,
this may be the ultimate goal of a geospatial semantic web, but a lot
of infrastructure has to be built first for this to work. Parts of it
are underway!
3) We assert the "featureness" of Web resources by adding properties
such as geometry to a representation of / reference to the resource.
This is the most natural role for RSS. RSS, after all, fundamentally
asserts the "news-ness" of some Web resource, by connecting news-y
properties such as title, date, etc to a resource reference (URI).
Adding georss:point or other georss property to the RSS similarly
asserts the "featureness" of the resource; it turns the RSS item also
into a feature in a lightweight manner suitable to the lightweight
location concept which is being asserted.
My contention is that our aim with GeoRSS is case 3) above. We wish
to augment, to add value to existing information rather than to
replace or administrate it. This does not eliminate the possibility
of an alternate form (FeatureRSS?) which implements case 2) by
asserting a link between a remote Web resource and a remote defined
feature, such as a TIGER administrative boundary.
As Chris Goad has elegantly observed in the question of how to
represent GeoRSS properly as RDF, this means that other feature
properties have either to exist at the same level as the georss tags
georss:where, georss:point, georss:line, etc. so that they are
represented properties of the RSS item, or be added as properties of
some other feature object buried in / referenced by a georss
property. Leaving aside the latter for a moment, this means that such
properties as both toponym properties (e.g. georss:featurename) and
address properties properly should be included alongside georss:point
as below and work quite well using other specifications such as xAL.
This doesn't really change the GeoRSS model (slight editing is
required), but it makes much clearer both how it can be adopted into
w3c geo and how it should coexist with other RSS practices, whether
xAL or dc:coverage. It does have the slight disadvantage that where
additional georss properties are used (e.g. relationshiptag,
featuretypetag, radius, elev, floor), there will be more than one
georss tag directly under item, e.g.
<item>
.
.
.
<georss:radius>5000</georss:radius>
<georss:point>-71.2342 34.234</georss:point>
.
</item>
this seems like a small amount of overhead, since other namespace mix-
in's such as dublin core are handled in the same way.
There is another case which still requires some refinement in regard
to case 3). That has to do with a GeoRSS item which describes a
resource which is already a feature or feature collection. There is
presently a lot of experimentation on this topic; patiences and/or
another discussion thread would probably be appropriate to work this
case out.
Cheers,
Josh
On Aug 28, 2006, at 10:23 AM, creed at opengeospatial.org wrote:
> Andrew -
>
> Yes! This is what I was thinking but you expressed much better.
> FYI, Pat,
> OASIS also wants a GML Application Schema for xAL. Also, not sure if
> anyone has seen the following:
>
> "August 1, 2006: Google Earth KML 2.0 uses OASIS CIQ xAL for
> representing
> and expressing addresses on Earth
> ".
>
> And Marc, xAL/xNAL uses ISO 11180 as one of their foundation
> requirements
> documents. A bit more info on xNAL can be found on XML Coverpages.
> From
> this page:
>
> The (OASIS) CIQ TC has spent close to two years in building xNAL
> that is
> application independent and truly global, and hence, can be readily
> applied to any name and address specific applications including Postal
> services and address validation. . . . Given that xNAL is designed to
> handle the address structures of all countries at an abstract or
> detailed
> level, it make it easier for applications to concentrate on building
> domain specific standards/applications around xNAL.
>
> Cheers
>
> Carl
>
>
>> On 8/27/06, Marc <marc at geonames.org> wrote:
>>>> If the georss group does decide to enable encoding of civil address
>>>> information, why re-invent the wheel?
>>>
>>> I would not go as far and speak about 'invention' in the context of
>>> GeoRSS or RSS. All I am suggesting is using the country code
>>> invented by
>>> ISO, use it for the vehicle RSS and call this combination GeoRSS.
>>> (The
>>> same is true for ISO 3166-2, the postal code and similarly for
>>> the place
>>> name.)
>>> The really hard work, the invention and maintenance is done by
>>> ISO. They
>>> have invented the wheel. Using it in a xml schema is a piece of
>>> cake and
>>> I don't really care how this combination is called. I have therefore
>>> setup a draft for a "geonamesRSS" encoding :
>>> http://www.geonames.org/geonamesRSS.html
>>>
>>
>> Marc, aren't you in fact reinventing the wheel/overloading the domain
>> by adding YAN (Yet Another Namespace)?
>>
>> You're right that making an XML schema can be easy. The problem is in
>> use and adoption. Adding another namespace works against that. What I
>> had suggested was leaving GeoRSS as is, and then bringing in
>> something
>> else (existing, like xNAL) for address encoding. Other people have
>> already spent a lot of time thinking of the problems and a solution.
>>
>> Just as an example:
>> <georss:point>45.256 -71.92</georss:point>
>> <xnl:AddressDetails>
>> <xnl:Country>
>> <xnl:CountryName>United States</CountryName>
>> <xnl:Locality Type="City">
>> <xnl:LocalityName>Seattle</LocalityName>
>> <xnl:Thoroughfare>
>> <xnl:ThoroughfareName>MainStreet</ThoroughfareName>
>> <xnl:ThoroughfareNumber>16</ThoroughfareNumber>
>> </xnl:Thoroughfare>
>> </xnl:DependentLocality>
>> </xnl:Locality>
>> </xnl:Country>
>> </xnl:AddressDetails>
>>
>>
>> --
>> Andrew Turner
>> ajturner at highearthorbit.com 42.4266N x 83.4931W
>> http://highearthorbit.com Northville, Michigan, USA
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
More information about the georss
mailing list