[georss] Geolocation by reference

[Sean Gillies]

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.

More comments below ...

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>

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.

Cheers,
Sean

> 
> On Nov 11, 2007, at 10:54 AM, Sean Gillies wrote:
> 
>> Raj,
>>
>> The use case in your third paragraph is exactly what I want to support.
>>
>> Sean
>>
>> Raj Singh wrote:
>>> I agree, I too get nervous making location too much like content.
>>> First let me say the src attribute on <where> sounds reasonable in
>>> that it's pretty non-invasive, but I'm not sure what problem you're
>>> solving.
>>>
>>> If the goal is to simplify the process of adding <where> to the
>>> <entry> you could do that with a nice OpenLayers application to "drill-
>>> down-to-my-location-while-looking-at other-known-locations".
>>>
>>> The location by reference makes sense if you expect the actual
>>> location to change in the future (e.g. a more accurate location is
>>> determined through later research), and people know that in this case
>>> their <entry>'s location should change too.
>>>
>>> ---
>>> Raj
>>>
>>>
>>> On Nov 9, 2007, at 6:59 PM, Sean Gillies wrote:
>>>
>>>> There is precedent in Atom for remote sourcing, but only to my
>>>> knowledge
>>>> for atom:content. The src attribute feels pretty good to me, though
>>>> I do
>>>> think that it has the potential to make location (which is metadata) a
>>>> bit too much of content (data). Does anybody have other ideas for
>>>> non-literal locations?
>>>
>>> _______________________________________________
>>> 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
> 
> --Andrew Turner
> ajturner at highearthorbit.com      42.2774N x 83.7611W
> http://highearthorbit.com              Ann Arbor, Michigan, USA
> Introduction to Neogeography - http://oreilly.com/catalog/neogeography
> 
> 
>