[georss] GeoRSS Multiple Locations, References & Excerpts

[Mikel Maron]

Andrew and I chatted a bit about this. 

One convincing argument for a georss:collection is that many publishers want to stick to a limited number of entries, say 10, and that if each "entity" or story is composed of multiple actual entires, each with a single geometry, then the publisher must choose between limiting the number of actual entities, or publishing a potentially large number of entries. In either case, it could be confusing for the user, using a vanilla feed reader that doesn't understand the convention of "link rel='related'".


However, in order to support either way of encoding a multigeometry, feed readers would need to adapt. Of course, Mapufacture will be ready :). But there will be a delay between spec decision and adoption, and one way to approach this is look to see which option causes the least pain in the interim. Unfortunately, I think both georss:collection and multiple entries encodings would break things in different ways. Curiously, Google Maps can already either, apparently their parser is just looking for any georss child nodes within an entry.


Another factor, what I think Josh is describing, is that a collection increases the complexity of associating each geometry with other facets. For instance, each geometry might only apply for a particular timeframe, and be associated with a piece of media. We'd then need to come up with special case applications of other namespaces within the georss:collection, and who knows if anyone would ever even support that, if we ever possibly came to agreement in the standard. Keeping the "entry" as the primary holder of all these facets is the cleanest and surest way forward.


Also, Sean's proposal doesn't actually require any changes to the specification. This would be a big bonus to our process. It would be a recommended convention. No need for a GeoRSS 2.0. 


Really, I'm curious to hear opinion on these two proposals from the people clamouring for this support. What do everyblock and everytrail think of the options?

-Mikel

----- Original Message ----
From: Joshua Lieberman <josh at oklieb.net>
To: GeoRss <georss at lists.eogeo.org>
Sent: Wednesday, March 19, 2008 10:10:58 AM
Subject: Re: [georss] GeoRSS Multiple Locations, References & Excerpts

Andrew,

Thanks for stirring this up. I've had a GeoRSS 2.0 proposal sitting on  
my desk for a long time but haven't gotten to it.

This may come as a bit of a shock, but I have to agree with Sean about  
some of these things. Entries are already a pretty lightweight entity  
and links are already a pretty good way to, well, link to additional /  
voluminous resources for various purposes which may or may not be  
specialized in the view of a particular client or user.

About multiple geometries: every time we've drilled down into the use  
case for this, it has ended up being important to express their  
relationships. Geometry "bags" are hardly every really usefully  
expressive. One approach is to create relationships within a  
collection which give meaning to the order. That gets more and more  
specialized, though, as we saw a few months ago with various <dataset>  
proposals.

The "story graph" is an interesting problem which GML btw does not yet  
solve, but a graph of Atom entries is at once more compatible with  
simple viewers and more robust in terms of expressiveness. Pointers  
such as the threading proposal use would be the way to go (not sure  
links couldn't do this as well), except that we don't seem to be there  
yet referencing and managing entries as first class Web objects. Yes,  
there is a unique identifier, but not necessarily a "home" URL.

The CGDI pilot, in leveraging GeoAtom, suggested some useful link  
types to support this. I'll see if we can converge on a general  
proposal next week at the OGC TC and post it for comment.

Josh



On Mar 19, 2008, at 12:13 PM, Andrew Turner wrote:

> Sorry for not posting about this to the list earlier, but I wrote up
> several proposal extensions to GeoRSS to handle: Multiple Locations
> for a single 'Story', References to externally geometries, and
> Excerpts.
>
> My blog post outlining the ideas, and why the current proposal is
> framed as such is in this post:
> http://highearthorbit.com/georss-multiple-locations/
>
> Sean Gillies has already countered with some good thoughts &  
> suggestions here:
> http://zcologia.com/news/711/multiple-locations-in-georss/
>
> I also created a Proposals page on GeoRSS.org site with links to the  
> proposals:
> http://georss.org/proposals
>
> I know these ideas have been discussed in the past, but then kind of
> petered out. But I think there is immediate interest in nominally
> agreeing to and implementing a solution in the very near term. In
> fact, I would like to suggest that we have something ready for
> Where2.0.
>
> Also understand that this proposal is for "Simple" - I know there are
> GML people that will point to the semantics of the proposal and wag
> their fingers. I suggest to them to draft a tasty Semantic/GML
> parallel version.
>
> Thanks!
> Andrew
> _______________________________________________
> 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20080321/9bbfa541/attachment.html