Ready for a lean and mean Catalogue Service Protocol Spec.?

[Kralidis,Tom [Burlington]]

In the absence of a simple implementation, we developed a JSP front end
harvester (OGC:WMS 1.1.1, OGC:WFS 1.0.0) and registry, and then
publishes via OGC:WFS.  A sample instance of the JSP front end is at:

http://devgeo.cciw.ca/owscat/

..the rest is out-of-the-box parts (PostGIS for spatial storage,
MapServer for OGC:WFS [and OGC:WMS, it's kind of neat to be able to
OGC:WMS the bbox'es of services/layers as part of a discovery]).

This has been deployed, with success, for Canada's ResEau water portal
(http://www.environmentandresources.ca/reseau/), as well as well as some
activities within UNEP (http://www.gemswater.org/).

Still, it's a workaround until a solid OGC:Cat2.0 implementation comes
around.

..Tom



> > >>
> > >>Re. simple RESTful APIs, you've looked at mapdex's? 
> > >>http://www.mapdex.org/cfcdoc/mapdex.html
> > >>
> > >>I'd love to make a prototype implementation - plugging 
> OWSLib into 
> > >>the little metadata engine i've been very slowly writing for OSGeo
> > >>- discovery is the better part of access. On these grounds
> > >>i'm not sure about the word 'cataloguing' - well, that's what
> > >>your enjoyable
> > >>rant is about, Paul - 'catalogue' is the overfocus on
> > >>production and not consumption.
> > >>
> > >>code first, ask later! ;)
> > >>
> > >>
> > >>jo
> > >>On Thu, Jul 20, 2006 at 08:34:48AM -0700, Paul Ramsey wrote:
> > >>>My rant on simple catalogues is here 
> <http://geotips.blogspot.com/ 
> > >>>2005/10/simple-web-services-catalogues.html> along with
> > >>examples.  As
> > >>>you can see, our "catalogue" goes well beyond "lean and 
> mean" into 
> > >>>"emaciated and ghoul-like", so it is not suitable for
> > >>anything except
> > >>>proof that even dog-simple solutions are better than the
> > >>standards-as-
> > >>>currently-constituted.  Tom Kralidis' solution has more
> > >>flesh and has
> > >>>actually paid some attention to the standards it is
> > >>serving, and in
> > >>>fact uses a standard (WFS) as its transport.
> > >>>
> > >>>All that really needs to happen is for someone to think 
> about the 
> > >>>catalogue problem from the user down towards the data, 
> instead of 
> > >>>starting from the data and building up.
> > >>>
> > >>>For a "web services client"-centric catalogue (as opposed to a 
> > >>>data- centric catalogue, circa 1995) I find it hard to get much
> > >>beyond this
> > >>>list:
> > >>>"What is the user looking for? (web services, in particular the 
> > >>>components of services, layers and featuretypes and
> > >>coverages).  "How
> > >>>are they looking for them? (by keyword, usually, perhaps with a 
> > >>>bounding box, occasionally with a service type)" "What do
> > >>they want
> > >>>back? (the best services, the fastest ones, the most
> > >>reliable ones,
> > >>>the ones that are most "relevant" to their keywords, in an
> > >>order that
> > >>>reflects those quality metrics)"
> > >>>
> > >>>Paul
> > >>>
> > >>>On 20-Jul-06, at 6:40 AM, Jody Garnett wrote:
> > >>>
> > >>>>I think some of your ideas have been done with WFS 
> already, talk 
> > >>>>to Tom (think there is a link on the OSGEO site right now for 
> > >>>>him).
> > >>>>
> > >>>>Paul Ramsey is already running a lite web service that 
> we use for 
> > >>>>searching from the uDig application because CSW was not 
> ready in 
> > >>>>our application timeframe....
> > >>>>
> > >>>>The CSW2 definition seems fine to me, and it is almost 
> identical 
> > >>>>to WFS in practice (complete with Transaction operation and so 
> > >>>>on). What it does do (that is only proposed for WFS 
> right now), is 
> > >>>>let you search on data related to the information you want to 
> > >>>>return.
> > >>>>
> > >>>>What remains fun for all is the conflict between defining the 
> > >>>>information for reuse (normalize out
> > >>data/application/association),
> > >>>>or defining the information that we want to see today (layer).
> > >>>>
> > >>>>If you want a good starting place grab the constructs 
> defined by 
> > >>>>the OWS Context document (that define a "layer" for WFS,
> > >>WMS, WCS)
> > >>>>and place them in an existing CSW-2, or place them in a WFS for 
> > >>>>that matter. Or talk to Paul Ramsey and grab the 
> information uDig 
> > >>>>uses (basically something small and specific based on Dublin 
> > >>>>core).
> > >>>>- 
> http://udig.refractions.net/docs/api-udig/net/refractions/udig/
> > >>>>catalog/IGeoResourceInfo.html
> > >>>>- 
> http://udig.refractions.net/docs/api-udig/net/refractions/udig/
> > >>>>catalog/IServiceInfo.html
> > >>>>(For more details talk to Paul Ramsey as he wrote a 
> paper up last
> > >>>>year...)
> > >>>>
> > >>>>So I am all ears towards doing something, and am paying 
> attention 
> > >>>>to Paul and Tom who have done something. Usually when 
> you extend 
> > >>>>an existing plain text approach (say as used in
> > >>GeoNetwork)
> > >>>>you are limited to bbox queries... but for a quick catalog that 
> > >>>>may not be bad.
> > >>>>
> > >>>>Jody
> > >>>>>Dear all,
> > >>>>>
> > >>>>>I'm bothered on how implementation of catalog services 
> proceeds. 
> > >>>>>I asked this Allan and he pointed me to you.
> > >>>>>
> > >>>>>I am following discussions at ISO/OGC about defining CSW 2, 
> > >>>>>testing UDDI and including ebRIM and so on and I came to the
> > >>conclusion that these
> > >>>>>proposals are too heavy weight - and it get's currently
> > >>even worse
> > >>>>>(i.e.
> > >>>>>more complicated)...
> > >>>>>
> > >>>>>I think we need a RESTfull protocol that is lean and 
> mean. So I y 
> > >>>>>idea is either define a profile of WFS together with a profile
> > >>of metadata
> > >>>>>(ISO 19115/19119) or to extend a general search protocol with 
> > >>>>>geospatial types (thus including information retrieval 
> > >>>>>community). I am inclined to
> > >>>>>follow the former and entered something here:
> > >>>>>http://wiki.osgeo.org/index.php/
> > >>>>>Geodata_Discovery_Working_Group#Search_P
> > >>>>>rotocols
> > >>>>>
>