[OSGeodata] Re: [georss] Discovery of georss and other geographic information?

Tue Sep 19 11:28:54 EDT 2006

This is a great thread, and I'm glad the conversation is taking  
place. I do see a bit of drift away from the main topic of the GeoRSS  
list so perhaps this thread should be continued in just the  
geodata at geodata.osgeo.org list.

The people on georss at lists.eogeo.org can subscribe to the geodata  
list at
   https://geodata.osgeo.org/servlets/ProjectMailingListList
Note that you do have to first register as an osgeo.org member first,  
you do that here
   https://www.osgeo.org/servlets/Join

	Allan

On Sep 19, 2006, at 11:18, Carl Reed OGC Account wrote:

> 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
> To: Carl 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  
> andhttp://www.foss4g2006.org/contributionDisplay.py? 
> contribId=234&sessionId=70&confId=1  .
>
> Stefan
>
> ----- 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 herehttp:// 
> 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 inhttp://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
>
>
>

-- 
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org