Vision Mission and Goals
The core of what OOSTethys is about (draft)
Vision
Inspire environmental data interoperability through the use of recognized standards, including OGC, W3C, ISO, and OASIS.(Discussion of this is ongoing on OOSTETHYS@LISTSERV.TAMU.EDU and googledocs -- see the thread "[OOSTETHYS] Vision, Mission, and Goals" for an invitation to edit and the discussion.)
Mission
- OOSTethys mission is to facilitate integration of environmental observed
data, by:
- providing guidance of open source tools and standards
- promoting interoperability test beds
- developing tools when needed - Integrate data (current almost real time) from ALL platforms and sensors in the marine world
- Provide guidance for data providers of marine observation offerings ( seminars, guides, cookbooks..)
- (More discussion on the OOSTETHYS@LISTSERV.TAMU.EDU thread with subject [OOSTETHYS] OOSTethys mission)
Goals
- Help developed standardized environmental observing systems
- For each component in an observing system: Research, Check tools, Decide, Implement, Validate and Facilitate
Excerpt from OOSTethys Community Document
Standards Enable Innovation – Which standards?
Organizations and Processes
The point of this section is that there are a variety of processes for setting standards, a variety of standards organizations and the standards themselves can be quite complex. Futhermore, the standards evolve with time. Keeping up with the complexity and change is time consuming, and can become an impediment to adoption of standards. All of this complexity points to the value of a community approach where a collection of experts with complementary perspectives work together, leveraging and respecting each others expertise and producing a shared tool set. This is the philosophy underlying OOSTethys.Design Requirements – Let function drive technology
This section should answer the question: What is it we’re trying to achieve? Interoperability isn’t a goal, it’s a feature of a useful network of shared information. Our goal for the Environmental Web 2.0 is a networked “system of systems” that provides value to some (the data users), and is sufficiently compelling for data providers that they want to go to the effort to become part of the system. It helps when the data users are also data consumers. In any case, we need to build the network to a set of design requirements that provide a goal of usefulness. The high level requirements for OOSTethys:- Data in the network should be discoverable through common interfaces, regardless of the data provider,
- Data should include documentation of provenance and processes (such as quality control), while respecting the authority of the original data provider without whom the data wouldn’t be in the network,
- Data should be accessible through a standarized single documented interfaces, regardless of data provider,
- Data should be accompanied by sufficient documentation (i.e., metadata) to be easily used in an application.
adding to first para (about standards)
Posted by
graybeal
at
2008-04-03 13:13
Beyond the first sentence under Organizations and Processes: Even when you have selected your standard, you may have to develop a method for using it that is consistent with your goals. I think one of the big goals of OOSTethys was to develop GOOD methods for using OGC/SWE/SOS standards, that others could use as templates for their own work. (Ideally coming to a common place in the end, so our products can interoperate. To be really useful I think that has to be a profile, at some point, but didn't want to bring it up right way. Ooops.)
Possible Immediate Next Steps
Posted by
eric
at
2008-04-04 12:37
Hardly a Vison Mission contribution :-)
Most of the development work has focused on the GetObservation request aimed at moored buoys in which the "sensor" was really a platform holding numerous physical sensors at numerous depths, some of which are profilers. Little focus was placed on the DescribeSensor responses which were kept, in the templates, to the bare minimum required. I think a good next step would be working on tools, cookbooks, examples for a fuller richer sensor description utilizing SML and perhaps integrating the work done by John Graybeal's Devices Ontology group.
Related to this would be work dealing with new observation types and features of Interest being developed by the IOOS Program Offices Web Services work which Luis B. has been contributing to, e.g. how to describe and transfer profiles, etc. As well as dealing with netCDF and model data.
Most of the development work has focused on the GetObservation request aimed at moored buoys in which the "sensor" was really a platform holding numerous physical sensors at numerous depths, some of which are profilers. Little focus was placed on the DescribeSensor responses which were kept, in the templates, to the bare minimum required. I think a good next step would be working on tools, cookbooks, examples for a fuller richer sensor description utilizing SML and perhaps integrating the work done by John Graybeal's Devices Ontology group.
Related to this would be work dealing with new observation types and features of Interest being developed by the IOOS Program Offices Web Services work which Luis B. has been contributing to, e.g. how to describe and transfer profiles, etc. As well as dealing with netCDF and model data.