[OSGeo-Discuss] Should OSGeo get involved in the Information Architecture realm and nurture the development of definitive spatial ontologies?

[jo at frot.org]

dear Bruce, all,
On Thu, May 22, 2008 at 09:20:08AM +1000, Bruce.Bannerman at dpi.vic.gov.au wrote:
>    Rob Atkinson has proposed that OSGeo may be the right body to nurture the
>    development of a set of consistent ontologies describing commonly used
>    spatial entities.
>    This could make it much easier for us to build targetted applications in
>    the long term.
>    This suggestion has merit and should be explored further.

Your suggestion interests me but it sounds *so abstract*. 
It would benefit this discussion to have a clear example and description
of what an "ontology describing commonly used spatial entities" would
consist of, who it would be intended for, how it would be re-used. 
I am not sure that OSGeo is an appropriate vehicle for this, though.

>    > > This "profiling pattern" is possibly within the OGC purview, but its
>    > > not handled well at the moment IMHO because its something that
>    > > affects deployers, not technology developers: the need to maintain a
>    > > consistent _information architecture_. OGC is a technology vendor
>    > > association primarily.

OSGeo would have the same issues to quite an extent - it is an
association of developers and people closely connected to developer
communities. Though this is changing, especially through the local
chapters, I think it would be hard to harness such a "loose association"
for a concerted effort - unless it was *really* clearly set out as a
marketing initiative that could provide OSGeo members with more
decision-making influence in their everyday working lives. 

>    > > GSDI could own a SDI reference architecture - but doesnt seem geared
>    > > up for it.

Really? Why not? I thought that data infrastructure building best practise
was at the heart of what GSDI was all about - the "cookbook", efforts at 
formalising design decisions in a way as to keep big institutions happy, etc:
http://www.gsdi.org/Association%20Information/Committees/TechnicalWorkingGroup.asp

>    > > OSGEO should at least consider the commonality between its projects,
>    > > out of business sense. If databases and services and clients and
>    > > registries dont handle common metadata, the pieces dont fit together
>    > > well. Every time I get asked to advise someone on building tools I
>    > > have to warn them they have a huge job gluing the pieces together
>    > > into a coherent whole, and there will huge amounts of redundant
>    > > information scattered across the configurations of each component
>    > > that will make it all expensive to build, test and maintain.
>    > >
>    > > Proprietary systems do tend to be better at this, since inter-
>    > > component interoperation is often the key to marketing success.
>    > > Peopele want an application - and they buy all the components with
>    > > the expectation the application will work. IMHO OSGEO could
>    > > significantly improve its offerings by having a common information
>    > > architecture (without necessarily mandating all projects use it).

Well, proprietary vendors may be better at marketing inter-operation,
and OSGeo could benefit from marketing cross-project success stories. 
But I don't see we have the kind of technical impedance you describe.
Hearing many "we're using projects X, Y and Z" stories was a common
feature of last year's conference. The open-source "stack" *is* coherent
and a lot of cross-project collaboration goes on behind the scenes. 
This tends more and more to the quiet, usage-driven development of
common components and interfaces when they prove really necessary. 

In any case these decisions emerge from practise and "formalisation"
comes along with the right "rough consensus and running code" and it
would be counter to "the OSGeo way" to propose anything different. 
Upfront formalisation could easily be the appearance, if not the reality, 
of an "information architecture". 

It would start to look somewhat like the OGC Abstract Specification.
This takes so much effort - time, money, brainpower - to maintain,
and needs a kind of process overhead to keep it stable that slows it
down, that it winds up being neglected and not updated. New efforts
(like GeoRSS, KML2.N) skip over it on the grounds of bypassing
cultural conflict. Over time it loses its valency as a marketing tool.


jo
--