[georss] GeoAtom (split from Re: GeoRSS Location References)

Tue Apr 1 15:21:18 EDT 2008

Really, I'll get to putting up the proposal, but here is a nutshell:

What are the cases for multiple geometries?

1) Feature with multiple geometries, such as Massachusetts which  
includes a number of islands and requires a "multipolygon" (with one  
set of other properties) to represent it in detail. Not so important  
for the sort of overview which GeoRSS generally provides, and it seems  
more straightforward to provide content of or a link to a GML feature  
for the more precise geometry.

2) Alternative geometries: a polygon / envelope and a point are both  
provided to represent the same feature for different clients or  
different scales. This seems to me to be the one straightforward  
semantic for multiple geometry elements in a georss:where element, but  
it must not get confused with other uses for multiple elements, such  
as 1), or it won't in general be interpretable by clients.

3) Fine-grained features: individual geometries refer to individual  
features within a resource, typically a web page. There are two  
challenges here for using multiple geometries. First and most  
difficult, each geometry needs to point to some part of the resource,  
without modifying the resource itself to add anchors, etc. Second, as  
Andrew pointed out, there is an open-ended need to further  
characterize each feature with more than a geometry, such as title,  
description, time, and even relationship links to other individual  
features (down the road from "X" we came to "Y").

While it is tempting to throw multiple geometries together with some  
ad hoc way of linking them to resource segments, it does in the end  
make more sense to take the approach already established of using full  
entries / items for each subfeature and link them together as needed  
into "story graphs". That still leaves the general subresource link  
problem, however.

  I like Andrew's idea of a summary entry for web pages where a copy  
of the HTML code (in <content/> ) can be annotated with anchors which  
are in turn referred to by detail entries. That reference scheme may  
prove more fragile than we'd like, however. An alternative which is  
harder to process but (one hopes) more robust would be to use XQuery  
to form links into the original resource. There are some other schemes  
for linking to video frames, audio timepoints, or image pixels, such  
as some podcasts use,  although I can't seem to put my browser on them  
at the moment.

To make any of this work,  the two types of links we need to figure  
out are: links from one  Atom entry into another, and links from an  
Atom entry into a segment of a Web resource, whether or not it is  
designated as an anchor / span / div / etc. Pretty general problems, I  
should think.

--Josh

On Apr 1, 2008, at 1:39 PM, creed at opengeospatial.org wrote:

> I am on travel but this dialogue triggered a memory about a  
> discussion I
> had with Tim Bray sevral years ago regarding geo and Atom. When I get
> back, I will check my archives and send the group these emails.
>
> Carl
>
>
>> On Tue, Apr 1, 2008 at 12:46 PM, Raj Singh <raj at rajsingh.org> wrote:
>>> On Apr 1, 2008, at 12:41 PM, Sean Gillies wrote:
>>>> Wait, are multiple entry locations making a comeback?
>>>
>>> No! Andrew, let me re-write your example. I thought we were agreeing
>>> to this:
>>
>> Mikel locked me in a car on a road trip and preliminarily convinced  
>> me
>> that Multiple entries is better. There are all the reasons that Sean,
>> Mikel, Josh all point out: works with existing, semantic, etc.
>>
>> However, the one that won me over was the fact that Atom entry  
>> already
>> supports (or can be expanded to support) many more rich attributes:
>> categories, time, authors... Simply, a story can have multiple
>> locations that happened at different "times". If we wanted to carry
>> georss:collection forward to handle this, we would get into a huge
>> quagmire of extending geo* to do all sorts of non-geo things: time,
>> categories, tags, et al.
>>
>> Instead, go back to the tenant that we should just be adding Geo to
>> existing formats/practices rather than bringing them into Geo.  or
>> something like that.
>>
>> Of course, I will follow-up by saying that I think multiple entries  
>> to
>> handle multiple geometries would also suggest that batch RESTful
>> operations are a good idea. While it's nice to be able to edit any
>> single geometry, I shouldn't have to hit the server 4 times just to
>> post 1 story with 3 locations. Or by editing that entry to remove a
>> location and add 2 would mean making 4 calls (PUT entry, DELETE
>> location, POST 2 locations).
>>
>> What seems better is to PUT the multiple entries - and if there is  
>> any
>> failure, then the entire request fails (transactional) with
>> appropriate error responses for why it failed (bad geometry or title
>> in one of the geometry-entries perhaps).
>>
>>
>>>
>>> <entry>
>>>    <link href="http://example.org/entries/1"/>
>>>    <title>Cedarburg Trip</title>
>>>    <summary>We went to visit
>>>       <span id="downtown">downtown Cedarburg</span>
>>>
>>>       before the conference. Had some great sandwiches at Joe's.
>>>       If you haven't been to Cedarburg, Wisconsin, then you haven't
>>>       really experienced the MidWest...
>>>    </summary>
>>>    <georss:where id="downtown">
>>>       <georss:point>...</georss:point>
>>>    </georss:where>
>>>  </entry>
>>
>> I admit that this I liked this idea originally. Very succinct.
>> However, there are several problems. First is that you probably would
>> have the summary wrapped in a CDATA, since it isn't really part of  
>> the
>> Atom XML. This would preclude id bashing, but also it's only a fake  
>> or
>> tenuous link from the georss:where id to the span id in the summary.
>> It would be just as meaningful to point to a binary address in an
>> image file.
>>
>>
>>>
>>> (2 identical IDs are probably a bad idea, so a different ID or
>>> attribute should be used)
>>>
>>
>> I suggest putting up your suggestions and basic thoughts on the  
>> GeoRSS
>> Proposals for Multiple Entries, Location Reference so we can start
>> collating for a poll.
>> _______________________________________________
>> 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