Maybe I'm just being silly, but this feels like a fruitless exchange
at some level. (So I might as well add my 2 cents too....) It's as
if we were to say "sure, XML (or ASCII, for that matter) is nice and
generic, but who can write a parser that deals with all those possible
XML files?" (Well, a lot of people, it turns out -- but usually we
narrow the field a little bit for each application domain.)
My experience of "easy to use" standards is that they tend to be
useless (by themselves, anyway) for the purposes for which I want to
develop data systems (namely, the so a computer program can find many
kinds of things of interest and incorporate or process those things
automatically -- see the Ocean Observing Initiative's
Cyberinfrastructure Concept of Operations for a detailed use case of
this). DIF, FGDC, KML -- they all have a lot of uptake, and they all
provide a *certain level* of interoperable value, each in their own
way. But each lacked specificity in some areas that were needed to
provide computability at the level I want it.
Just like XML, FGDC and KML are extensible, and you can build your own
solutions on top of them and propose them for the interoperability
winner. This has value in each case, though the pervasive lack of
controlled vocabularies in FGDC, and the proprietary implementation
environment in KML, were enough to make them not a winner for me. But
hey, YMMV, that's fine.
With SensorML and O&M, I found a model that matched my own, was
largely internally consistent and relatively robust under new
applications, was more thought out than my own in some places, and
already had a fair number of people interested. Yes, some practical
refinement has been needed as we go forward, but nothing like the
refinement I've had to do with many other standards. The computability
and interoperability of the result across a wide range of system
implementations seems considerably more refined than I experienced
with other standards. (Though maybe not as high as netCDF/CF, within
its niche.) These are the things that the more complex standard
offers.
My point is not that SOS wins; my point is there inevitably will be
tradeoffs between simplicity and functionality. You can always take
the simple solution first, but by the time you graft on the capability
this person and that person and the other person wants, you will have
something fairly equivalent to the complex standard that this thread
seems to be dismissing. So I don't see that it's a meaningfully
decidable discussion.
John
On Oct 8, 2008, at 7:31 PM, Roy Mendelssohn wrote:
Hi Ben:
On Oct 8, 2008, at 3:44 PM, Ben Domenico wrote:
Hi Jon,
I think you've cut right to the heart of the matter again. Namely
your question: "How does this translate into interoperable
software?" That's a good way to ground the discussion for the
upcoming joint session at the OGC TC meeting where we will try to
determine how the OGC Coverages and Sensor Web Enablement (SWE)
thrusts fit together. (Note that Observations and Measurements O&M
conceptual framework is part of SWE).
I think it goes beyond that. Our experience so far with some of these
standards is that while they seem really neat and theoretically pure
on paper, they are almost impossible to translate into actual code. or
when you do the code is very complex and the service is very slow.
Just for laughs, go through the archive that existed for when John C.
was developing the WCS for THREDDS. There were many of the same
concerns - the devil is in the details with many of these when you try
to actually code it. We are running into similar problems trying to
write a general client for the IOOS SOS service.
I was not being flip when I mentioned Google. Google understands that
first and foremost services must be fast, easy to use, easy to
understand, and easy to program. I am concerned that as a community we
too are moving away from services that are relatively fast and easy to
use, to those that are extremely complex and difficult to understand
- and I would re-ask one of the original questions that started all of
these threads - what is it that is being gained by all of the added
complexity? Interoperability is often mentioned, but as you can see
from some of these discussions (and I think is was Peter Baumann that
mentioned this) it is interoperability only in theory, you could never
write a client that can deal with all of the cases.
My $0.02.
-roy
--------------
John Graybeal <mailto:graybeal@xxxxxxxxx> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project: http://marinemetadata.org
