[georss] Discovery of georss and other geographic information?

Tue Sep 19 20:31:34 EDT 2006

Hi Stefan:

Of course you could have still more restricted profiles of GML as well as we
did for geoRSS and still have full support from WFS.

Ron

  _____  

From: georss-bounces at lists.eogeo.org [mailto:georss-bounces at lists.eogeo.org]
On Behalf Of Carl Reed OGC Account
Sent: September 19, 2006 8:18 AM
To: Stefan F. Keller
Cc: geodata at geodata.osgeo.org; georss at lists.eogeo.org
Subject: Re: [georss] Discovery of georss and other geographic information?

Stefan -

Thanks for the quick and considered response.

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.

With regard to GML, I was not suggesting that you use GML - just that WFS
supports multiple versions of GML. Also, the GML Simple Features Profile is
the result of considerable work and consensus by the OGC members - as well
as public input. It is an adopted OGC standard. While not as parsimonious as
GeoRSS GML, it is a heavily restricted subset of GML this profile designed
to handle the encoding of the vast majority of non-topologically structured
geographic content.

And yes, I agree that discovery services access catalogues. We have violent
agreement there.

Carl

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

From: Stefan F. Keller <mailto:sfkeller at gmail.com>  

To: Carl <mailto:creed at opengeospatial.org>  Reed OGC Account 

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
<http://www.foss4g2006.org/contributionDisplay.py?contribId=234&sessionId=70
&confId=1> &sessionId=70&confId=1  .

Stefan 

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

From: Stefan <mailto:sfkeller at gmail.com>  F. Keller 

To: Raj <mailto:raj at rajsingh.org>  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" < <mailto:georss at highearthorbit.com>
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/20060919/a30ee49c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3638 bytes
Desc: not available
Url : http://lists.eogeo.org/pipermail/georss/attachments/20060919/a30ee49c/attachment.bin 