[OSGeodata] information model

Wed Sep 20 02:33:40 EDT 2006

> It would be great to discuss the information model layed out here *
> http://tinyurl.com/kfkyv* <http://tinyurl.com/kfkyv>

- which URIs point to a machine readable ressource?
- which URIs point to a human readable ressource?
- is multiple human language forgotten or tabled?

Claude

----- Original Message -----
From: "Stefan F. Keller" <sfkeller at gmail.com>
To: <georss at lists.eogeo.org>; <geodata at geodata.osgeo.org>
Cc: "Carl Reed OGC Account" <creed at opengeospatial.org>
Sent: Tuesday, September 19, 2006 10:16 PM
Subject: [OSGeodata] Re: [georss] Discovery of georss and other geographic
information?


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