[georss] kml reference placemarks v/ georss?

[sgillies at frii.com]

> josh at oklieb.net wrote:
>> Pat,
>>
>> In thinking of the relative roles of these formats, they do overlap in
>> providing "featureness" to information, but have quite different intents
>> and strong points. GeoAtom is a light and very specific "news about"
>> format, while KML is very close to OWS Context in being able to contain
>> a
>> lot of information about setting up Google Earth (or similar blue marble
>> applications), including something close to full features as Gregor et
>> al
>> point out. Not surprising given some of the GML genes it carries.
>>
>> One interesting characteristic of Atom is that there is both an
>> atom:link
>> to the Web resource being reported on, and an atom:content for more
>> involved or specialized HTML / XML representation. Various ideas are
>> being
>> tested for using the atom:content element, including inline GML or WFS
>> requests/filters. KML is yet another possibility to represent in a more
>> specialized form (but processable by both Google Earth and Google
>> Search)
>> what GeoAtom is providing news about.
>
> i am also wondering about the other direction. are there things in Atom
> that would be interesting to have in KML? Atom / GeoRSS strike me as
> more web-native when it comes to linking to features.
>
> what i'd like to see is georss / kml features linking to each other. i
> guess this is already possible with some combination of WFS and other
> specs, but i would like to see this as part of the normal web, without
> the need for special protocols.
>
> avi has a nice writeup about this idea:
>
> "Now, I’m not aware of any sort of cross-linking among KML files yet,
> similar to how web pages can point to or reference each other without
> forcing each other to load. What would be fascinating to see is whether
> KML files will evolve as web pages have — my excellent Eiffel tower
> model could reference your fine Champs-Élysées and someone else’s Arc de
> Triumph. We would thereby cross-promote each other (in context: Paris
> Landmarks)
 We’ll have to wait and see. But if it’s not already there, a
> new field for KML which offers the idea of an optional (e.g., clickable)
> link to other KML files, coupled with a sort of page-rank algorithm
> using these links, might just do the trick to creating this sort of "web
> of goodness" we enjoy."
>
> http://www.brownianemotion.org/2007/02/14/the-fruits-of-integration/
>
>
>>>> disclosure: I'm on OGC staff and right in the middle of the KML->OGC
>>>> process
>
> disclosure: i work on KML things at google, but am not currently
> participating in the KML->OGC process.

Gregor,

The divide between HTML links and KML network links should be closed, with
KML joining the existing Web. Ditch <NetworkLink> for <a rel="KML-Link">
or something like that. Nevermind WFS, there's no web there.

Cheers,
Sean