You are here

Open Water Data Information Architecture (OWIA)

1 The Open Water Information Architecture (OWIA)

An information architecture is a means of mobilizing information to satisfy a set of objectives. This means that an information architecture has a purpose and a focus. It may be as broad as to provide an archive for the preservation of all published materials, such as the university and public library systems, or it may be as narrow as providing decision-support for the water resource management of California. The OWIA addresses the water resource management problem with proven methods, conventional to information sciences community, using modern cyberinfrastructure and computing methods.


PIC

Figure 1: Requirements baseline documents and their relationship to OWIA data node implementations.


This paper discusses the OWIA both from an objectives perspective, from the top-down, as well as a bottom-up requirements baseline as a framework to provide high quality, digital information products for water resource management in perpetuity. The reader is encouraged to think of what ensues in this paper as being about data, not computers. This is important because whatever underlying cyberinfrastructure is in use at any particular time to implement the OWIA, the cyberinfrastructure changes rapidly with respect to the specification of the information products which change relatively slowly. The OWIA must be robust to technology changes if it is to be long-lived and sustainable.

By translating the objectives, currently realized as Stakeholder Use-cases, into functional and technical requirements, in the form of a System Requirements Document (SRD), with an accompanying set of standard operating procedures (SOPs), we provide a means to control cost, schedule, technical and operational risk. At the same time, providing project managers (a) a basis for measuring the performance of system(s) built to satisfy the objectives and to (b) compare the relative merit of alternative designs, a (c) rational path for technology updates over time, and a (d) framework for controlling the long-term operations and maintenance costs.

The Open Water Information Architecture (OWIA) does these things for the community of stakeholders with an interest in water resources and open-data. The OWIA establishes a federation of peer data systems sharing standards and conventions to govern cyberinfrastructure, data and operations. It is a system of systems allowing organizations and individuals to leverage existing investments in staff and data systems while providing a means for interoperability and cooperation. Some of the benefits of the OWIA approach are (i) greater access to standardized data in (ii) an open-system providing for (iii) growth in data holdings, (iv) flexible integration of changing technology and innovation, (v) responsiveness to emergent stakeholder objectives with (vi) an elimination of stranded assets.


PIC

Figure 2: Illustration of the OWIA federation concept-of-operations with a triumvirate governance structure of general partners (GP) supported by interacting with a stakeholder working group (SWG) and a technical working group (TWG). The federation is comprised of dedicated OWIA system implementations to enable individual data providers to independently integrate the OWIA into their existing operations. Shared OWIA system implementations provide the flexibility for the harvesting non-compliant data sources without insisting that the data producers be OWIA-compliant.


2 Concept of Operations

This document contains the functional and technical requirements for the Open Water Information Architecture (OWIA) and is called the OWIA System Requirements Document (SRD). It has within it an ?? that contains narrative explanations that are referred to within individual requirements where appropriate. This is done because the requirements are meant to be terse, declarative, testable statements that are not overloaded with narrative exposition. There are two companion documents to the SRD: (1) the subordinate document OWIA Standard Operating Procedures (SOPs) and the (2) parent document California Council for Science and Technology (CCST) Stakeholder Use Case document.


PIC

Figure 3: Open Water Data Information Architecture (OWIA) framework.


The SOPs are compliant with the requirements specified here yet written at a more detailed level of abstraction with examples of programming code or sometimes pseudo-code to exemplify the implementation details important to developers as well as precisely documenting the processing steps (i.e., procedures) used to operate on data. It is meant to be analogous to an OWIA Programmer’s Guide and, as the OWIA implementation proceeds, there will be open-source code repositories with minimal working examples (MWE) for use in improvements and innovations to current procedures and applications implementing those procedures.

Each of these documents is intended for a technical audience although it is hoped that they are comprehensible to a motivated non-technical reader. There is a glossary in the back of the SRD to aid in navigating the technical language and as an effort to disambiguate some of the terms for which there may be competing and inconsistent definitions. In addition to these two, there is a third document that contains the stakeholder use cases used to develop the stakeholder objectives from each use case. These objectives are being used to define and constrain the requirements contained in the SRD and the procedures for satisfying them defined in the SOPs.

The SRD and SOPs are designed to provide a foundation for a community-based OWIA development of a federated set of cyberinfrastructure resources (i.e., computers, networks, data, metadata, and standards and conventions) that are interoperable and highly-automated to minimize labor as well as idiosyncratic anomalies. We therefore refer to them as the baseline documents (Figure 1). The objective of these baseline documents is to establish a framework for sustainable water resource management and to formalize that framework to a degree exemplified by other systems of standard methods such as those found in [6].

The federated nature of the OWIA extends to its (1) human governance structure as well as its (2) cyberinfrastructure (cf. Section ?? and Figure 2). Therefore we speak of the OWIA federation as including both these aspects and will differentiate the two parts contextually when using the term. The open aspect means open-access, open-source and open-architecture: encouraging innovation and automation while precluding the siloing and stove-piping that occurs when proprietary software and systems pose restrictive technology dependencies and requirements. The planning horizon is open-ended although intended to provide for a near-term operational system with an initial operating capability (IOC) within 1-2 years evolving to a final operating capability (FOC) over five (5) years that is operationally sustainable while responsive to technology innovation and risk minimization (i.e, cost, schedule, technical and operational) over its lifetime.

The approach is to follow standard system engineering practices [20] that: (1) define stakeholder objectives and, from these, (2) enumerate functional requirements in terms of functional components and major interfaces both of which are implementation-independent, and (3) enumerate technical requirements which specify fundamental technical features such as network transfer rates, storage capacities, reliability, maintainability and availability (RMA), interface dependencies and contingencies and similar quantitative or qualitative requirements at a level of specificity (or abstraction) that is more detailed than the functional requirements on which they are based. It is also designed to present an initial evaluation of some of the obvious design trade-studies to explicate and focus on the key risk areas related to technical, schedule, cost and operational risks.

This is an interative and recursive, hierarchical design approach (Figure ??) which prioritizes Stakeholder Objectives, Functional Requirements, and Technical Requirements respectively and cross-correlates them to each other via a traceability matrices (Section ??) to ensure that there are no widows or orphans in the sense that there are no unsupported Objectives or Functional Requirements (i.e., widows) as well as no lower-level design features that are not specified in the Functional Requirements (i.e., orphans). As a development methodology, the system engineering method used here is sometimes contrasted with the agile development method. Every methodology has pros and cons and the reason we use this approach for the OWIA is because we already know a great deal about what is needed to improve access-to and reuse-of the collective set of water resource data and the OWIA focus is on the data content. This is not primarily a process of discovery and prototyping of software applications. For a broader discussion of the pros and cons of alternative software development approaches, the reader is encouraged to consider the discussions provided in [17] and [20].

Finally, some historical perspective is helpful. This document is meant to integrate the thinking on water resource information broadly and digital data about water resources specifically. The OWIA concept developed independently of the AB1755 legislation [1][18] that is currently, as of this writing, driving many efforts across the State of California to comply with its mandates and schedule. Fortuitously, the development of the OWIA and the activation of AB1755-related efforts overlap strongly such that AB1755 requirements are a subset of the broader OWIA requirements. The implementation of the OWIA will satisfy the requirements of AB1755 and support the Sustainable Groundwater Management Act (SGMA) in such a way that we can treat AB1755 as an OWIA use-case as described in Appendix ??. The OWIA concept is a reflection and integration of a wide range of on-going efforts especially those in the UC WATER Security and Sustainability Research Initiative and CITRIS [7], California Council on Science and Technology (CCST), the Center for Western Weather and Water Extremes (CW3E)[23], the San Diego Supercomputer Center (SDSC) [3139151224211119482214521016] and the UC Santa Barbara Bren School. We expect to grow this community to include private California universities, national laboratories and private sector partners as we go.

References

[1]   California Legislature, AB-1755 The Open and Transparent Water Data Act. (2015-2016), Assembly Bill 1755, California Legislature, 2015.

[2]   Dan Cayan and John Helly, The Wireless Watershed at the Santa Margarita Ecological Reserve, Southwest Hydrology September/October (2003).

[3]   B. Chadwick, P.F. P.F. Wang, M. Brand, R. Flick, A. Young, W. O’Reilly, P. Bromirski, W. Crampton, R. Guza, J. Helly, T. Nishikawa, S. Boyce, M. Landon, M. Martinez, I. Canner, and B. Leslie, A Methodology for Assessing the Impact of Sea Level Rise on Representative Military Installations in the Southwestern United States https://pubs.er.usgs.gov/publication/70178493, Technical Report RC-1703, SPAWAR Systems Center Pacific, 2014.

[4]   CODATA-ICSTI Task Group on Data Citation Standards and Practices, Out of Cite, Out of Mind: The Current State of Practice, Policy, and Technology for the Citation of Data, Data Science Journal 12 (2013), 1–75.

[5]   B. W. Eakins, S.P. Miller, J. Helly, and B. Zelt, The fully electronic IODP Site Survey Data Bank, Scientific Drilling 2 (2006), 40–42.

[6]   Eugene W. Rice and Roger B. Baird and Andrew D. Eaton and Lenore S. Clesceri (ed.), Standard Methods for the Examination of Water and Wastewater, vol. 22nd Edition, American Public Health Association, American Water Works Association, Water Environment Federation, 2012.

[7]   Steven Glaser, Martha Conklin, and Roger Bales, Building an Intelligent Water Information System – American River Prototype, Technical report, CITRIS, 2013.

[8]   Kay Gross, Edie Allen, Caroline Bledsoe, Robert Colwell, Paul Dayton, Megan Dethier, John Helly, Robert Holt, Nancy Morin, William Michener, Steward T. Pickett, and Susan Stafford, Report of the Committee on the Future of Long-term Ecological Data (FLED), Tech. report, Ecological Society of America, Washington, D. C., 1995.

[9]   J. Helly, T. T. Elvins, D. Sutton, D. Martinez, S Miller, S. Pickett, and A. M. Ellison, Controlled Publication of Digital Scientific Data, CACM 45 (2002), no. 5, 97–101.

[10]   J. J. Helly, Visualization of ecological and environmental data, LTER Network Office, University of New Mexico, Albuquerque, New Mexico, 1998.

[11]   John Helly, New concepts of publication, Nature 393 (1998).

[12]   ____________ , Digital libraries in hydrology, Hydroinformatics: Data Integrative Approaches in Computation, Analysis, and Modeling (Praveen Kumar, Mike Folk, Momcilo Markus, Jay C Alameda, and Peter Bajcsy, eds.), Taylor and Francis, London, England, 2005, p. 552.

[13]   John Helly and Maggi Kelly, Collaborative Management of Natural Resources in San Diego Bay, Coastal Management 29 (2001), 16.

[14]   John Helly, Hubert Staudigel, and Anthony Koppers, Scalable models of data sharing in Earth sciences, Geochemistry Geophysics Geosystems 4 (2003).

[15]   John J. Helly, Cyberinfrastructure for data authorship, publication and application interoperability, no. 1501928, AGU, AGU, December 2012.

[16]   John J. Helly and Kevin T. Herbinson, Visualization of the salinity plume from a coastal ocean water desalination plant, Water Environment Research 66 (1994), no. 5, 753–758.

[17]   ISTQB EXAM CERTIFICATION, What is Agile model – advantages, disadvantages and when to use it?, http://istqbexamcertification.com/what-is-agile-model-advantages-disadvantages-and-when-to-use-it (2018).

[18]   J. Gage Marchini, Connecting the “Drops” of California Water Data: Chapter 506: The Open and Transparent Water Data Act, The University of the Pacific Law Review (2017), 785–799.

[19]   William K. Michener, James W. Brunt, John J. Helly, Thomas B. Kirchner, and Susan G. Stafford, Nongeospatial metadata for the ecological sciences, Ecological Applications 7 (1997), no. 1, 330–242.

[20]   NASA, NASA Systems Engineering Handbook, Tech. Report NASA-SP-2007-6105-Rev-1-Final-31Dec2007, NASA, 2007.

[21]   Paul F. Uhlir Rapprteur, For Attribution – Developing Data Attribution and Citation Practices and Standards: Summary of an International Workshop, Report ISBN 978-0-309-26728-1, National Acadeies Press, 2012.

[22]   J. Pundsack, R. Belland, D. Broderson, G.C. Fox, J. Dozier, J. Helly, W. Li, P. Morin, M. Parsons, A. Roberts, C. Tweedie, and C. Yang., Report on Workshop on Cyberinfrastructure for Polar Sciences. St. Paul, Minnesota. University of Minnesota Polar Geospatial Center., Report, National Science Foundation, 2013.

[23]   F. M. Ralph, K. A. Prather, D. Cayan, J. R. Spackman, P. DeMott, M. Dettinger, C. Fairall, R. Leung, D. Rosenfeld, S. Rutledge, D. Waliser, A. B. White, J. Cordeira, A. Martin, J. Helly, and J. Intrieri, CalWater Field Studies Designed to Quantify the Roles of Atmospheric Rivers and Aerosols in Modulating U.S. West Coast Precipitation in a Changing Climate., Bulletin of the American Meteorological Society (2015).

[24]   Hubert Staudigel, John Helly, Anthony A. P. Koppers, Henry F. Shaw, William F. McDonough, Albrecht W. Hofmann, Charles H. Langmuir, Kerstin Lehnert, Baerbel Sarbas, Louis A. Derry, and Alan Zindler, Electronic data publication in geochemistry, Geochem. Geophys. Geosyst. 4 (2003), no. 3.