<HTML>
<HEAD>
<TITLE>Re: [OSGeodata] WFS-basic and geometadata exchange</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Stefan,<BR>
<BR>
I am missing something: Why do you want to have this implemented by WFS-Basic?<BR>
I do not see how the output can be used by following WFS-Basic calls for data especially if we focus on GeoRSS/Atom output. <BR>
Please, enlighten me :)<BR>
Thanks,<BR>
Pat.<BR>
<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"><B>From: </B>"Stefan F. Keller" <sfkeller@gmail.com><BR>
<B>Reply-To: </B><geodata@geodata.osgeo.org><BR>
<B>Date: </B>Wed, 25 Oct 2006 11:18:48 +0200<BR>
<B>To: </B><geodata@geodata.osgeo.org><BR>
<B>Subject: </B>Re: [OSGeodata] WFS-basic and geometadata exchange<BR>
<BR>
Tom, Raj,<BR>
<BR>
I like this proposition. Sorry for my silence, I was busy implementing a directory which builds on the vision of a geometadata network :->.<BR>
It seems to me, that there are at least to different main scenarios for such a WFS-basic around: i) WFS as a data access point which delivers simple XML-encoded geospatial vector data (with GML as mandatory output) and ii) WFS-basic for geometadata exchange within a geometadata network. <BR>
<BR>
According to the thread this is my sketch of a geometadata network: A catalog (or repository or registry) is a collection of geospatial resource descriptions, like descriptions of datasets (html/ftp) or WMS/WFS services which in turn point to (= hasPart) dataset descriptions they are 'responsible' of. There exist also filter service descriptions which are responsible for processing feature types, not datasets. A catalog is tightly coupled with geospatial resource descriptions (= datasets, WMS/WFS and filter services) and can be searched by humans and/or machines. Geospatial resource owners register to catalogs (in OAI-PMH lingo catalogs are called (meta-)data providers). Sophisticated protocols - like WFS or SRU - allow interoperation of federated catalogs in real-time, with the advantage of complex queries but with the prize of dependency on common protocol versions and non-scalability. <BR>
To lower barriers, catalogs should have simple interfaces to other catalogs or to directories or to general search engines. Such collections of structured metadata are called (metadata) service provider in OAI-PMH lingo. Sophisticated web mapping applications or desktop GIS' could hook to these metadata service providers. Metadata service providers are loosely coupled among each other as well as to registered catalogs they are 'harvesting' periodically - and they may be greedy, i.e. looking actively for new catalogs.<BR>
<BR>
This is where WFS basic or OAI-PMH comes in. The operations needed are GetCapabilities (OAI: Identify), GetFeatureType (OAI: ListMetadataFormats ) and GetFeatures (OAI: ListRecords). What's crucial there is the query language and the response output. <BR>
<BR>
Query/protocol: In order to manage large catalogs, incremental harvesting comes in; thus the bounding box and a date start/end range. So far, compatibility with WFS seems maintained. As I said at FOSS4G I don't mind something like 'WFS-simple' although this is 'GIS-centric'. From a neogeographers perspective it seems to me unanswered, what's the value of compatibility to Google, which reads OAI-PMH already. <BR>
<BR>
Output/model: GML is a just an XML encoding specialized to geospatial types. A minimal geometadata model still remains to receive consensus. DClite4G could be such an information model. <BR>
<BR>
-- Stefan<BR>
<BR>
2006/10/23, Kralidis,Tom [Burlington] <Tom.Kralidis@ec.gc.ca>: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
> dear all,<BR>
><BR>
> I have not been thinking very hard about simple geometadata<BR>
> exchange interfaces recently but every time i hear someone <BR>
> mention Raj's WFS-basic effort I jump a bit. You look at the<BR>
> query interface to it and it is very simplified - no Filters,<BR>
> just a bounding box and date start and end range. There is a<BR>
> DescribeFeatureType function which right now is returning a <BR>
> pile of XMLSchema description verbiage.<BR>
> I see a big place for dclite4g / GeoRSS in here - i would<BR>
> like to see Tom's OWSCat done over WFSBasic. One could even<BR>
> add in OAI-PMH functions like ListRecordTypes [sic?] as well, <BR>
> if needed. Am i making sense?<BR>
><BR>
> <a href="http://www.ogcnetwork.net/wfsbasic">http://www.ogcnetwork.net/wfsbasic</a><BR>
><BR>
<BR>
I like WFS basic, as it lowers the barrier / buy-in cost for the<BR>
general. Although, from the OGC point of view, this may be confusing<BR>
(WFS-basic has always meant a non-transactional WFS, as opposed to this<BR>
new thing).<BR>
<BR>
The big advantage, IMHO, would be the easier filters. Building OGC <BR>
Filters, while not a huge huge job, may be cumbersome for the<BR>
non-converted.<BR>
<BR>
<a href="http://example.com/osgeocat?service=WFSBASIC&version=1.0.0&">http://example.com/osgeocat?service=WFSBASIC&version=1.0.0&</a> <a href="http://example.com/osgeocat?service=WFSBASIC&version=1.0.0&"><http://example.com/osgeocat?service=WFSBASIC&amp;version=1.0.0&amp;></a> <BR>
request=GetFeature&outputformat=dclite4g&typename=services&keyword=*road<BR>
s*<BR>
<BR>
...would search all Services whose keyword metadata matches roads.<BR>
<BR>
In either case, a client must do a DescribeFeatureType to see what's <BR>
going on under the hood of the typename.<BR>
<BR>
Note that something like owscat already does this, but the client has to<BR>
setup the <Filter> constructs.<BR>
<BR>
For me, I don't mind either interface for discovery. <BR>
<BR>
<BR>
..Tom<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>