NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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
galeon archives: