[georss] Discovery of georss and other geographic information?

Stefan F. Keller sfkeller at gmail.com
Tue Sep 19 02:47:48 EDT 2006


Carl,

Thank you for the hints. I'm aware of most of theses documents except for
the GML simple features profile (yet another one?).

The background of these activities is that there is a growing malaise about
how metadata is being approached by the specifications you mentioned. So,
there grew up a felt need for a really simple metadata exchange protocol
which is low barrier and lean to implement. See here
http://wiki.osgeo.org/index.php/Simple_Catalog_Interface and below the
reasons. These finally let me propose a harvesting protocol like OAI-PMH 2.0,
together with a slightly specialized Dublin Core metadata model (still tbd).

2006/9/18, Carl Reed OGC Account <creed at opengeospatial.org>:
>
>  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.
>

Why do we need GML machinery just for the encoding of a bounding box? Dublin
Core's dct:spatial or GeoRSS seem to be much more parsimounious.

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

CAT/CSW is based on a distributed query architecture and there's redundant
spec. (and therefore code) to WFS. Why another protocol when there is WFS?

As explained in http://www.gis.hsr.ch/wiki/OAI-PMH distributed query like in
CAT/CSW means that search is at best limited to the slowest server and to a
least denominator of implemented specs. That is because each server needs to
implement exactly the same query functionality. OAI-PMH does harvesting and
indexing before hand.

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

You mentioned CSW implementations. To me it's like somebody who owns a truck
saying "why don't all take trucks to move metadata around?" when bicycles
would make the job. OAI-PMH is there since five years and even Google
accepts it as alternative to Sitemaps.

 From my experience, what you can expect at most from a data owner is
nothing more than what's in Word/Visio (metadata) properties or what's
mentioned in WMS GetCapabilities. So to me nothing more than Dublin Core is
needed like the common returnable properties of Catalogue Services
Specification 2.0.1, OGC 04-021r3, p.22 (as Josh mentioned) but extended by
additional semantics which includes more URI for automation.

I take ISO 19115, ISO 19119, ebRIM and all those forthcoming profiles
as templates for the specification of information models internal to an
organization. When talking about geodata discovery we are not talking about
catalog services but search services on top of catalogs; see
http://www.gis.hsr.ch/wiki/OSGeodata_Discovery and
http://www.foss4g2006.org/contributionDisplay.py?contribId=234&sessionId=70&confId=1
 .

Stefan

>
>
>  ----- Original Message -----
> *From:* Stefan F. Keller <sfkeller at gmail.com>
>  *To:* Raj Singh <raj at rajsingh.org>
> *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.osgeo.org/pipermail/geodata/attachments/20060919/221f5fc0/attachment.html


More information about the Geodata mailing list