Stefan -
I browsed the wiki sites mentioned in your email. A couple of questions/observations:
1. I believe that WFS 1.1 supports both GML 2.1.2 and GML 3.1.1 (see outputFormat) and by restriction, the new GML simple features profile. The new GML app schema is only 61 pages long with 20 pages of examples.
2. I was wondering why OAI-PMH page compares OAI-PMH with WFS? WFS is not designed for harvesting or for being a Catalogue service. WFS is designed so that once a content resource has been discovered (and perhaps registered in a Catalogue/Registry) that source can then be queried and asked to return a set of features (as a GML payload).
3. Was wondering if the new OGC Catalogue 2.0.1 19119/19115 Application Profile has been looked at.? Seems to me that there could be some real synergy between this Cat App Profile and OAI-PMH. https://portal.opengeospatial.org/files/?artifact_id=8305 . There are already quite a few implementations of this Application Profile.
Cheers
Carl
----- Original Message -----
From: Stefan F. Keller
To: Raj Singh
Cc: georss at lists.eogeo.org
Sent: Tuesday, September 05, 2006 2:58 AM
Subject: Re: [georss] Discovery of georss and other geographic information?
Raj,
I agree that encodings can differ as long there is a common understanding on the semantic level and as long 'best encoding practices' are fulfilled (what currently is the case in GeoRSS).
But newly published encodings should consider established ones, which seems to not the case actually (in W3C draft?). I know that standardization is slow but programmers often don't care...
But my initial question was not only targeted to adjust GeoRSS to be accepted as a Microformat. What I'm thinking about currently is (auto-)discovery of geodata and services as documented here http://www.gis.hsr.ch/wiki/OSGeodata_Discovery .
I'd like to discuss if GeoRSS icons are means to guide webcrawlers to xml-encoded content or if there is a need for a 'friend' attribute in a (yet to be re-defined ISO 19115) metadata as described in http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm
-- Stefan
2006/9/4, Raj Singh <raj at rajsingh.org>:
If you have a hammmer, everything looks like a nail.
I say that because the hammer many people on this list have is information
architecture. We try hard to make everything elegant in the information
model. I think interoperability occurs best at the programmer level, and
therefore we shouldn't try to hard to make all encodings of geography
interoperable from an encoding standpoint. If it takes less time for
programmers to code with less elegant encodings, then that's the "right" way
to do it.
This is a long way to say that I agree that GeoRSS should stop with support
for Atom and some other RSSes. If it's simpler to diverge from this encoding
to do microformats and/or XHTML, so be it.
My 2 cents,
Raj
On 8/30/06 10:38 AM, "Andrew Turner" < georss at highearthorbit.com> wrote:
> Stefan F. Keller <sfkeller at gmail.com> wrote:
>>
>> P.S. Still: Anyone who knows the status of GeoRSS (simple) as microformat?
>>
>
> What is the purpose of a GeoRSS microformat? Isn't Geo*RSS* targeted
> and meant for RSS/Atom? There already is a 'geo' and 'adr' Microformat
> with widespread support. If you're just looking at adding line,
> polygon, etc. to a Microformat then expand on geo, but it doesn't seem
> worth it, or a good idea, to try and force GeoRSS into XHTML.
>
> There was a howto on possibilities of mixing RDF and GeoRSS:
> http://www.geospatialsemanticweb.com/2006/06/08/mixing-rdfa-with-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/20060918/19f902fb/attachment.html