[georss] Discovery of georss and other geographic information?

Tue Sep 19 16:16:26 EDT 2006

Allan, good point to move the geodata list... Just to close up this thread:

2006/9/19, Carl Reed OGC Account <creed at opengeospatial.org>:
>
>  Would you mind if I share some of your observations with the OGC
> Catalogue WG? As you may know, there is considerable debate in the OGC
> regarding the way forward for the CSW spec.
>

Please share it. I don't mind if the discovery and harvesting approach from
OSGeo would end up as successful as GeoRSS became :->

It would be great to discuss the information model layed out here *
http://tinyurl.com/kfkyv* <http://tinyurl.com/kfkyv> on the publicly
accessible OSGeo geodata list in cooperation with OGC Catalogue WG members.

-- Stefan

 P.S. Excuse me being little bit enthusiastic: I'm aware that this
harvesting approach will not solve everything. Still, imagine: Combining
this model with OAI-PMH geoinformation would give a jump start through
Google, Yahoo and digital libraries like CiteSeer or OAIster, which in turn
would make geoinformation visible way outside this community!

----- Original Message -----

>  *From:* Stefan F. Keller <sfkeller at gmail.com>
>  *To:* Carl Reed OGC Account <creed at opengeospatial.org>
> *Cc:* georss at lists.eogeo.org ; geodata at geodata.osgeo.org
> *Sent:* Tuesday, September 19, 2006 12:47 AM
> *Subject:* Re: [georss] Discovery of georss and other geographic
> information?
>
>
> 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/d83dc15e/attachment.html