[georss] Geolocation by reference

[Sean Gillies]

Andrew Turner wrote:
> On Nov 12, 2007, at 12:42 PM, Sean Gillies wrote:
> 
>> Andrew,
>>
>> The more I think about georss:where[@src], the bigger the issue raised
>> by Barry Hunter appears. The atom:content[@src] mechanism is trivial
>> because we already have existing representations (web pages) that can be
>> fetched and dropped straight into the content element. On the other
>> hand, how many of us expose bare (meaning without feature
>> member/collection containers)  GML geometries on the web? I've never
>> seen one. In order to work with existing WFS (or whatever), the
>> semantics of georss:where[@src] would have to differ from
>> atom:content[@src], and I don't think that's right.
>>
>> Extending atom:link (like Josh suggested) with new relationships seems
>> more and more the way to go. It's an Atom-only solution unless you
>> extend RSS 1/2 feeds with atom:link, but that's fine with me. If
>> OpenSocial takes off the Atom/Geo community is going to be huge.
> 
> Good points. This is what I suggested in this post on how to utilize
> GeoRSS & KML together:
>    http://highearthorbit.com/a-proposal-georss-kml/
> 
> However, to address the "knowing how to pull in the content", using the
> type attibute at least lets you inform the user what kind of
> representation is at the other side. So it may be GML, or a more complex
> atom:entry, KML, or HTML. I don't know if there is actually a
> prescription for how to 'handle' the atom:content[@src]?
> 

There is. The content type of the source must match the type attribute
of the content element.

rel="http://pleiades.stoa.org/relations/isColocatedWith" (or whatever)
would work best with links to other Atom entries or KML placemarks.

> I guess one issue was that by using atom:link you're making a reference
> to the entire entry rather than saying it is just an alternate
> geographic representation.
> 

Technically, "alternate" means alternate representation in the Web sense
-- not more or less detailed geometry representation, but yes, we're
thinking along the same lines.

> 
>> More comments below ...
>>

me too ...

>> Andrew Turner wrote:
>>> Let me say first that I really like this suggestion and think it has a
>>> lot of uses. It also falls in line with similar cases such as
>>> atom:category that can point to a scheme (what do you mean by 'book' or
>>> 'red'). atom:content 'src' is an optional uri that software can use to
>>> grab the actual content
>>> (http://atompub.org/2005/01/10/draft-ietf-atompub-format-04.html#rfc.section.5.12.2)
>>>
>>>
>>>
>>> So in Sean's case, he could point to a URI that would contain an updated
>>> geometry. Or another use for him might be to point to a resource that
>>> contained the location in various reference frames, such as WGS84, or
>>> Ptolemy's coordinates, or whatever ancient cartographer that may have
>>> mapped it at some point.
>>>
>>> I could also see that it would be useful for someone that wanted to just
>>> publish simple points (or MBR, or simplified Polygon) of say, a
>>> Country's border, but then reference a URI to point to a much
>>> higher-resolution version.
>>>
>>> Another mechanism that could be used here instead of, or in addition to,
>>> the potentially changing coordinates would be a toponymic location. I
>>> believe Pat Cappelaere and Marc from GeoNames came up with a mechanism
>>> for this. A topoynym location, esp. using a schema URI to say where the
>>> definition of this location can be found, would be very useful.
>>>
>>
>> IMO, extending atom:link handles the above very well.
>>
>>> I think that the current GeoRSS mechanisms of 'relationshiptag',
>>> 'featuretypetag' and 'featurename' are under-defined (from an
>>> application/example perspective) and therefore rarely used.
>>
>> Agreed. There is also a bit of redundancy in combination with Atom.
>>
>> One aspect of those that *is* useful: declaration of what the
>> georss:where element means to the containing entry. At the risk of
>> starting a completely new thread, that relationship may be better
>> expressed by new georss:where attributes than by use of a GeoRSS
>> relationship tag. In other words, I think something like:
>>
>>   <georss:where
>>     scheme="http://example.com/vocabularies/x"
>>     term="is-bounded-by">...</georss:where>
> 
> Good suggestion - I think somewhere in the archives someone pointed out
> a 'standard' ontology for geographic relationships that we could use
> nominally?

Josh and Raj's W3C report collects a few if them.

> 
> How would this work with multiple geometries for a single entry? Somehow
> referring to an element id within the content would be nice.
> 

Multiple geometries:

<georss:where
  scheme="http://example.com/vocabularies/x"
  term="is-bounded-by">...</georss:where>

<georss:where
  scheme="http://example.com/vocabularies/x"
  term="is-centered-on">...</georss:where>

I feel the story of different geometries related to different sections
of the content is beyond the scope of Atom. An Atom entry representing a
bibliographic record about "Voyage Autour Du Monde" or containing a blog
post about a backcountry ski trip would be well served by a single line
or multipoint geometry in a georss:where element.

>>
>> with the no attribute case defaulting to "is-located-at" works.
>>
>>>
>>> We're *way* behind on moving forward with some of the outstanding
>>> 'feature requests' that we were thinking about for GeoRSS v1.2 (I
>>> believe 1.1 was a 'bug fix'?). What say we put together this SRC
>>> proposal, Toponym, Multiple Geometry and others as potential specs and
>>> do an email discussion vote for a 1.2 update?
>>>
>>
>> Working my proposal into GeoRSS in some form would be great. I'm also
>> hoping to find some folks who would like to help me write a "best
>> geospatial practices for Atom" document.
> 
> Well, it would help if you put up a page on the GeoRSS.org CMS kind of
> summarizing the proposal. A BP for GeoAtom would be great!
> 

I want to field test this a bit to make sure that it's not just geo
wankery. How about another attempt at Geo-Atom interop?

Sean