[OSGeo-Board] questions about OGC membership

[Jo Walsh]

mpg, thanks for your note.

Hey, if any of you have time for reading i would like to dump these
notes about my experience trying to engage with the OGC's "mass
market" process which i never got round to blogging. So, now i am
licking my wounds and spending my evening attempting to read the CSW
and ebRIM specs. I think this is connected to why i'm sending so much
email ... ;)


--------------------------


Simplicity at the heart of specification

When I heard Raj give a presentation about the emerging WFS Simple
specification at the UK Geospatial Mashups event back in October, I
was sold immediately. This was the Web Feature Service cut right back
to the essentials - bounding box / temporal slice query, simplified
keyword query, that's it. Targeted at the "neogeography" audience, as
I perceived it; a good fit for GeoRSS, carrying data around using any
number of data syndication formats. I wrote a GeoRSS/RDF aggregator
library in python last year and this would be an ideal interface for
it. My head also rang with the prospect of using WFS Simple to base a
simple metadata discovery service on, very much in the way that Tom
Kralidis has done over WFS to produce OWSCat.

Rather than being a formal standards project in which paid membership
in the consortium is necessary for participation, Simple's
specification process is being run as part of the 'OGC Network' and
actively encouraging open contribution from free software developers.
A lot of people from the OSGeo community signed up to the Simple
discussion list; there's a lot of interest in simpler standards to
make vector data more distributable.

A few days later I had the chance to sit down and re-write bbox, the
GeoRSS aggregator and add a WFS Simple interface to it; i had a lot of
questions as a result of implementing what the informal specs
described, which got fed back into the docs, and which produced a good
feeling.

WFS Simple is directed at the casual implementor not versed in the
more traditional ISO or OGC standards, a very selfconscious attempt to
"lower the bar". In this i found it successful; apart from time spent
refactoring the original application, it took less than a couple of
hours to do everything required in the spec except
DescribeFeatureType, which there is still a lot of discussion about
omitting or adapting. One viable suggestion of Raj's is to put the
metadata describing the objects in the repository (the features) into
the metadata describing what the web service does and who to call
about it (the GetCapabilities request).

There are problems with simplicity. Everyone has a different view of
the simplest, least useless thing. Mine is pretty expansive; I want to
see a way of doing Transactions without having to implement full
WFS-Transactional. I reluctantly agree that this is a non-simple
request; in which case I want an approved way of extending the query
interface and advertising common extensions to it. 

Others are particularly interested in the use of WFS-Simple to offer a
carrier format of Atom or RSS decorated with GeoRSS and Dublin Core
properties. In theory there's nothing to stop one sending arbitrary
formats over WFS proper - GeoServer offers KML and GeoRSS outputs and
is planning a JSON output. WFS client support is working to some
extent in OpenLayers. But WFS is often too slow to use real-time;
there's more value in a data synchronisation protocol to make local
copies for processing purposes, or in a tile cache for many different
renderings of vectors as different resolution bitmaps, for web mapping
purposes.

I finally unsubscribed from the WFS Simple list yesterday. Not because
I'm no longer interested in the protocol and planning to build it into
different apps; but out of disillusionment with the discussion process
and how the goals are being expressed and met. 

I recall an audience reaction to Raj's presentation at the Ordnance
Survey; a meterologist who maintained that the full expressiveness of
GML and WFS was necessary for them; they could not be compelled to
accept a simpler alternative with less utility. One meme we had way
back when writing "Mapping Hacks" was of "locative" vs "GIS" - the
long tail, and the high priesthood, and the tendency of the priesthood
to look at anything simplified, fuzzily accurate or incomplete, as
somehow intrinsically inadequate. There's also been a long thread
about "spatial data infrastructures" vs the "geospatial web", and how
to integrate the two concepts. 

I am not a fan of WFS or GML, but recognise there is wide support and
a variety of sophisticated use cases which there is nothing else will
answer fully enough. But i'm exasperated by the dismissive attitude
often displayed by people deeply involved in the OGC and ISO standards
processes, to "grassroots" developments formed without the knowledge
in that deep involvement. OGC was happy enough to subsume GeoRSS into
their own offering once the community had done the work of specifying
it, but the RSS and RDF geoannotation work from which it emerged, is
bypassed. The rest of this post is most of the last email i wrote to
the Simple discuss list, before backing away from the OGCistas...

RSS's heritage is in the Semantic Web (cf the ill-fated RDF-expressed 
RSS1, which was forked by Dave Winer into RSS2 over widespread
community objections, and Atom was a Sam Ruby-led attempt to close the
divide. http://goatee.net/2003/rss-history.html GeoRSS is being used
to syndicate updates to data sets in public administrations, big
publishing organisations, and has extensive support in open source
geospatial software projects. It fits a market niche which is 
even larger than "annotating web pages". The use of the URI as a UUID
for any kind of object is a utility.

Raj's use case emphasis for Simple Web Feature Services is on
non-spatial elements and attributes which are connected to spatial
features, coming out of excel spreadsheets, conventional databases, etc.

To me, a web service is a convenient interface to a repository of data 
and of utilities with which to manipulate it. Web services, while an
awful lot better than having to screenscrape and steal data or having
no data at all, aren't "more valid" than having structured data
available at a repeatable URI, which has the advantage of being
discoverable and indexable by bots. The non-discoverability of OGC web
services has led to layers of superfluous registry models, service
discovery services, etc, all dancing around the issue of making data
available where it can easily be found, repackaged and reused. 

The "geospatial web" has been far ahead of "open data" or common
structured data in pretty much every domain, including the low-hanging
fruit of music and media. Good precedents in open standards and in
collaboration between SMEs inside consortia have been set. But if the
geospatial standards community continues on this path of isolating
itself, of looking upstream to the ISO rather than downstream to the
distributed neogeo developer community, it will miss out on being
connected to amazing things. 

So i'm surprised to see an effort in outreach and interoperability
seemingly retreating into itself. I turned up to the WFS Simple development discussion process really pleased to
hear of developments on a very simple, very implementable query
interface which would generously support a variety of output formats.
I'm losing sight of the value a bit now - it's difficult to see more
advantage to this than to, say, adding a bbox query option to OAI-PMH 
and building services on it; and that's the path i'm going to follow
for a while. 

Essentially i want a specification to operate in the way a software
project can so well - a small core and confined core, an extensive 
plugin architecture (e.g. encouragement to extend the query interface
for specific purposes like basic transactions or feature/tileset
metadata publishing), with every suggestion driven by a test case.
I know that what I want for Simple probably falls between two stools -
not expressive and flexible enough for the hardcore - not familiar
and straightforward enough for the much larger neogeo constituency. Right now the process risks failing both communities and emphasising the difference between them, and that's an awful shame.