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

[Sean Gillies]

Joshua Lieberman wrote:
> 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.
> 

Adding multipart geometries to the GML profile solves 1, right?

I don't think a "ground state" (still loving that name) spec needs to
address cartographic scaling at all. Providing a low-res and a high-res
feed seems to be a good enough approach. Entries in the low-res feed
could link to entries in the high-res feed. The high-res "feed" could
even be KML -- Google Earth has already engulfed so much of what GeoRSS
was originally envisioned to become.

> 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.
> 

Yes. Unless publishers use internal anchors there is nothing specific to
link to.

>   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

Linking from one Atom entry to another is solved: atom:link between
documents, Atom threading extension refs within a document.

Well-designed Web resources (RDF, HTML with internal anchors, XML docs
with XML IDs) will be easy to link to, poorly-designed Web resources
(paper docs scanned as GIFs, etc) will be hard to link to. IMO, a
"ground state" spec doesn't need to solve the general linking problem.

Sean