W3C home > Mailing lists > Public > public-xg-geo@w3.org > August 2006

Re: [georss] Transport of Toponyms with GeoRSS

From: <Josh@oklieb>
Date: Mon, 28 Aug 2006 11:25:22 -0400
Message-Id: <5FFE6213-F4AD-4E5D-BD96-FCFDFD015E51@oklieb.net>
To: georss@lists.eogeo.org, GeoXG GeoXG <public-xg-geo@w3.org>


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.
<georss:point>-71.2342 34.234</georss:point>

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.



On Aug 28, 2006, at 10:23 AM, creed@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@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@highearthorbit.com        42.4266N x 83.4931W
>> http://highearthorbit.com              Northville, Michigan, USA
>> _______________________________________________
>> georss mailing list
>> georss@lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
> _______________________________________________
> georss mailing list
> georss@lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
Received on Monday, 28 August 2006 15:25:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:25 UTC