1. U.S. Department of the Interior U.S. Geological Survey NWIS, STORET, and XML National Water Quality Monitoring Council August 20, 2003

2. 22 Purpose  Describe progress in providing an integrated view of NWIS and STORET data  Show preliminary ideas for turning ACWI Water Quality Data Elements into a practical XML Schema for describing sampling stations

3. 33 NWIS and STORET  USGS and EPA signed an agreement on Management of Water Quality Data on January 13, 2003. Key elements include:  Geospatial internet-based query tool  Joint team of technical staff to outline options and identify tasks  References ACWI Data Elements

4. 44 Geospatial query tool STORET (national) STORET Warehouse NWIS NWISWeb Local STORET Transactional Distribution Query Tool

5. 55 Phases of development become more challenging PhaseCommon data in portalMapping interfaceHow users get full data sets for stations 1 Station name/number; lat/lon One-time prototype transfer of locations to geospatial query tool Table of links to STORET and NWISWeb 2 Location (watershed, state, county); agency; general site type (surface- water, well, lake, etc.) Regular updates provided to geospatial query tool Station-by-station links to STORET and NWISWeb 3 Summary info. on constituent groups and sampling frequency "" 4 Links to all data, allowing detailed selections Standards-based web mapping services support many interfaces Portal acts as intermediary to deliver data in single format 5 "Standards-based web feature services allow interfaces to manipulate data display Delivered in a standard XML schema for water- quality data

6. 66 Why do we need an XML Schema?  Any advanced “Water Portal” concept (index, warehouse, distributed database, web service, etc.) works a lot better with a standard way to transfer data  Designing an XML schema enforces a discipline on the data model  ACWI Data Elements is a good start  The devil is in the details!

7. 77 DRAFT A (very) DRAFT XML schema for water- quality data: station description

8. 88 Cautions!!!  We need to determine the scope of the data elements. Which ones actually will be needed in a data repository?  Elements must be matched to missions and goals. Most data systems probably will use a subset of the schema.  Need critical review by experts in XML Schema.

9. 99 Some design principles  Strictly define critical elements on which we commonly perform searches, such as  lat/lon;  station identification; and  standard station type.  Allow more flexibility on documentation elements (e.g. method of altitude determination).  Allow documentation by citation  Individual databases can redefine by restriction.

10. 10 Standards and Recommendations  ACWI Data Elements  (Draft) Federal XML Developers Guide  XML Schema style  EPA Environmental Data Registry  Data element names  OpenGIS ® Geography Markup Language  Describe geographic features  ISO 8601  Date, time  HR-XML Consortium  Names and addresses They don’t all agree!

11. 11 Name and address elements are defined by HR-XML Consortium No need to invent our own!

12. 12 Authority: A Reference  Defines code sets, names, methods, or explanations  Allows great flexibility in documentation

13. 13 Station – where you sample New! Simple, standard types (5-6?) plus user-defined types

14. 14 Station Location New Link to GML for subfeatures

15. 15 Extension of Schema  Tie results of sampling to station or sub- features of a station  6.0 Sample Collection  7.0 Sample Analysis  Field trip information?  Where does “3.0 Reason for Sampling” fit?  Why did we select this station?  Why did we collect this sample?

16. 16 Next Steps for XML Schema  Refine schema with expert help  Determine role of schema in a water portal  Scope of data elements – which are needed and which can we defer?  Redefine schema by restriction to match business requirements  Test with data output from NWIS and STORET