<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Stefan -</DIV>
<DIV> </DIV>
<DIV>Thanks for the quick and considered response.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>And yes, I agree that discovery services access catalogues. We have violent
agreement there.</DIV>
<DIV> </DIV>
<DIV>Carl</DIV>
<DIV> </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=sfkeller@gmail.com href="mailto:sfkeller@gmail.com">Stefan F.
Keller</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=creed@opengeospatial.org
href="mailto:creed@opengeospatial.org">Carl Reed OGC Account</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=georss@lists.eogeo.org
href="mailto:georss@lists.eogeo.org">georss@lists.eogeo.org</A> ; <A
title=geodata@geodata.osgeo.org
href="mailto:geodata@geodata.osgeo.org">geodata@geodata.osgeo.org</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, September 19, 2006 12:47
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [georss] Discovery of georss
and other geographic information?</DIV>
<DIV><BR></DIV>
<DIV>Carl,</DIV>
<DIV> </DIV>
<DIV>Thank you for the hints. I'm aware of most of theses documents except for
the GML simple features profile (yet another one?). </DIV>
<DIV> </DIV>
<DIV>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 <A
href="http://wiki.osgeo.org/index.php/Simple_Catalog_Interface">http://wiki.osgeo.org/index.php/Simple_Catalog_Interface</A>
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). <BR> </DIV>
<DIV><SPAN class=gmail_quote>2006/9/18, Carl Reed OGC Account <<A
href="mailto:creed@opengeospatial.org">creed@opengeospatial.org</A>>:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<DIV bgcolor="#ffffff">
<DIV>Stefan -</DIV>
<DIV> </DIV>
<DIV>I browsed the wiki sites mentioned in your email. A couple of
questions/observations:</DIV>
<DIV> </DIV>
<DIV>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.</DIV></DIV></DIV></BLOCKQUOTE>
<DIV> </DIV>
<DIV>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. </DIV><BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<DIV bgcolor="#ffffff">
<DIV>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).
</DIV></DIV></DIV></BLOCKQUOTE>
<DIV> </DIV>
<DIV>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? </DIV>
<DIV> </DIV>
<DIV>As explained in <A
href="http://www.gis.hsr.ch/wiki/OAI-PMH">http://www.gis.hsr.ch/wiki/OAI-PMH</A> 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. </DIV><BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<DIV bgcolor="#ffffff">
<DIV>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. <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="https://portal.opengeospatial.org/files/?artifact_id=8305"
target=_blank>https://portal.opengeospatial.org/files/?artifact_id=8305</A> .
There are already quite a few implementations of this Application
Profile.</DIV></DIV></DIV></BLOCKQUOTE>
<DIV> </DIV>
<DIV>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. </DIV></DIV>
<DIV> </DIV>
<DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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 <A
href="http://www.gis.hsr.ch/wiki/OSGeodata_Discovery">http://www.gis.hsr.ch/wiki/OSGeodata_Discovery</A> and
<A
href="http://www.foss4g2006.org/contributionDisplay.py?contribId=234&sessionId=70&confId=1">http://www.foss4g2006.org/contributionDisplay.py?contribId=234&sessionId=70&confId=1
</A> .</DIV>
<DIV> </DIV>
<DIV><SPAN class=sg><FONT color=#000000>Stefan</FONT> </SPAN></DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<DIV>
<DIV> </DIV></DIV>
<DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"></BLOCKQUOTE></DIV>
<DIV><SPAN class=q>
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV style="BACKGROUND: #e4e4e4; FONT: 10pt arial"><B>From:</B> <A
title=sfkeller@gmail.com
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:sfkeller@gmail.com" target=_blank>Stefan F. Keller</A>
</DIV></SPAN></DIV>
<DIV><SPAN class=e id=q_10dc2c9b1563945a_4>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=raj@rajsingh.org
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:raj@rajsingh.org" target=_blank>Raj Singh</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=georss@lists.eogeo.org
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:georss@lists.eogeo.org"
target=_blank>georss@lists.eogeo.org</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, September 05, 2006 2:58
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [georss] Discovery of
georss and other geographic information?</DIV>
<DIV><BR> </DIV>
<DIV>Raj,</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>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...</DIV>
<DIV> </DIV>
<DIV>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 <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.gis.hsr.ch/wiki/OSGeodata_Discovery"
target=_blank>http://www.gis.hsr.ch/wiki/OSGeodata_Discovery</A> .</DIV>
<DIV> </DIV>
<DIV>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 <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm"
target=_blank>http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm</A> <BR> </DIV>
<DIV>-- Stefan<BR> </DIV>
<DIV><SPAN class=gmail_quote>2006/9/4, Raj Singh <<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:raj@rajsingh.org"
target=_blank>raj@rajsingh.org</A>>:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">If
you have a hammmer, everything looks like a nail.<BR><BR>I say that
because the hammer many people on this list have is information
<BR>architecture. We try hard to make everything elegant in the
information<BR>model. I think interoperability occurs best at the
programmer level, and<BR>therefore we shouldn't try to hard to make all
encodings of geography <BR>interoperable from an encoding standpoint. If
it takes less time for<BR>programmers to code with less elegant encodings,
then that's the "right" way<BR>to do it.<BR><BR>This is a long way to say
that I agree that GeoRSS should stop with support <BR>for Atom and some
other RSSes. If it's simpler to diverge from this encoding<BR>to do
microformats and/or XHTML, so be it.<BR><BR>My 2
cents,<BR>Raj<BR><BR><BR>On 8/30/06 10:38 AM, "Andrew Turner" <<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:georss@highearthorbit.com" target=_blank>
georss@highearthorbit.com</A>> wrote:<BR><BR>> Stefan F. Keller
<<A onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:sfkeller@gmail.com" target=_blank>sfkeller@gmail.com</A>>
wrote:<BR>>> <BR>>> P.S. Still: Anyone who knows the status of
GeoRSS (simple) as microformat? <BR>>><BR>><BR>> What is the
purpose of a GeoRSS microformat? Isn't Geo*RSS* targeted<BR>> and meant
for RSS/Atom? There already is a 'geo' and 'adr' Microformat <BR>> with
widespread support. If you're just looking at adding line, <BR>>
polygon, etc. to a Microformat then expand on geo, but it doesn't
seem<BR>> worth it, or a good idea, to try and force GeoRSS into XHTML.
<BR>><BR>> There was a howto on possibilities of mixing RDF and
GeoRSS: <BR>> <A onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.geospatialsemanticweb.com/2006/06/08/mixing-rdfa-with-georss"
target=_blank>http://www.geospatialsemanticweb.com/2006/06/08/mixing-rdfa-with-georss</A><BR><BR><BR></BLOCKQUOTE></DIV><BR></SPAN></DIV>
<DIV>
<P>
<HR>
<P></P></DIV>
<DIV><SPAN class=q>
<P></P>_______________________________________________<BR>georss mailing
list<BR><A onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:georss@lists.eogeo.org"
target=_blank>georss@lists.eogeo.org</A><BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://lists.eogeo.org/mailman/listinfo/georss"
target=_blank>http://lists.eogeo.org/mailman/listinfo/georss</A><BR></SPAN></DIV>
<DIV>
<P></P>
<BLOCKQUOTE></BLOCKQUOTE></DIV></DIV></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>