- From: Josh@oklieb <josh@oklieb.net>
- Date: Mon, 28 Aug 2006 11:25:22 -0400
- To: georss@lists.eogeo.org, GeoXG GeoXG <public-xg-geo@w3.org>
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@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