# Presentation: 455828

## Common Data Content

## 	Overview

**What is a data content standard?**
**	****Source material and development process**
**	****	****IOOS PO Data Integration Framework**
**	****	****	****Recommendations**

- 2/17

## 	What is a Data Content Standard?

- 3/17

**Notes:**
A well defined list of elements that constitute a logical record
CSDGM, FGDC framework, street address
Not inclusive of metadata
Not a file format, not a data model
Usually fits into a larger context of a feature catalogue

## 	Purpose of a Content Standard

- 4/17

**Notes:**
Informs our process.....to build data structures, encodings and exchange processes
DTL work and the GML – SFP work for Time series – DMAC nugget (Flow chart)
In a federated system...it may be the only...and most valuable common thread to tie pieces together
Reduce cost and data miss-use, errors, non-use
Requires an authority to manage and extend

## Prevailing Content Standards

**Notes:**
The Myth: a standard exists – ready to be adopted
Depends on the scope in which you work and the audience (project and international)
Many component parts exist
ISO/ ANSI / W3C (time, location, data types, other major pieces)
Nat’l Geodetic Survey has  pieces
WMO (GRIB2), IOC, GEOSS – too high level - 
O&M, IHO and NODC
RCOOS data providers

## 	CSC Observation Database

_**	**__**CSC Observation Database**_

- 6/17

**Notes:**
ERD
Our purpose, our audience
Design principles
What does it tell you......what we learned from it?
Future plans

## 	Client Observation Database

**Notes:**
Driving the content specification - understanding the client requirements
Borrowed from previous efforts
Common design to many other GIS application areas 

## 	IOOS   Data Integration Framework

- 8/17

**Notes:**
Chris will provide general overview for DIF separately (DCS, common data provider services, registry)
Early scope and purpose of the DIF content standard work
Workgroup, schedule – NDBC, CO-OPS, and the HAB’s input
Important – this is a minimum – not exclusive
Interoperability tests were informative

## 	Date & Time

**2008-02-06T10:53:07Z**

- ISO/FDIS 8601:2000(E)
- W3C - Schema XSD
- RDBMS vendors
- SWE

- <dateTime>

- 9/17

**Notes:**
ISO spec reference and details
W3C / XSD
SWE
Breaking apart date and time did not make sense regarding actual observation process
Decimal seconds are optional

## 	Horizontal Location

**42.3551 -71.0517**

- (Boston Harbor)

- EPSG 4326 as default
- Latitude Longitude
- WGS 84 ellipsoid
- 2D, no elevation included
- “WGS84(orig) is identical to NAD83(86) within the CONUS”

- <horizontalPosition>
- 	Geodetic values

- Projected, planar or geometry values

- TBD

- 10/17

**Notes:**
ANSI reference
Axis order is extremely important when packaging
This uses the EPSG 4326, ie. WGS 84 as 2D

Projected, planar, Geometry-based values are another story
Geodetic values (lat/long) are inherently 3D and should not be used to analytical calculations using Cartesian math

## 	Vertical Position & Datum

**2.5**

- EPSG designators not used
- Default units - meters
- Positive above datum

- <verticalPosition>

- <verticalDatum>

**MLLW**

- Ellipsoidal
- Tidal
- Orthometric

- (see dictionary)

- (height)

- (verticalReferenceSystem)

- 11/17

**Notes:**
Considering label changes to meet other ANSI framework standards
Height – depth nomenclature

## 	 Identifier

**NDBC:8447930:ADCP002**

- <observationIdentifier>

- organization

- platform

- device

- 12/17

**Notes:**
Unique and retain origin
Locally managed, can implement other conventions
No consensus on device/package description
Human viewable version of a identity field
Imperfect approach, and could adjust as schemas and encodings mature
Borrows from the URN standard

## 	 Status Elements

**3600**

- <sampleInterval>

**preliminary**

- <processingLevel>

**http://xyz.org/meta/file.01.xml**

- <documentation>

- 13/17

**Notes:**
Sample interval – when merging different frequency data streams
Processing level – may overlap – tie into future quality work – perhaps an ISO quality record
Similar situation for documentation 

## 	 Observation Elements

**waterTemperature**

- <observationName>

**23.5**

- <observationValue>

**degreeCelsius**

- <observationUnit>

- (see dictionary)

- (see dictionary)

- (encoding dependencies)

- 14/17

**Notes:**
Actual labeling can be encoding dependent for Name field
Other terms used – observedProperty, result, resultOf, target

## 	 Content Summary

## 	 Examples

- 16/17

**Notes:**

At this stage we’re only talking about what, not how.....this could be in a spreadsheet or an email, or an RSS feed

## 	Recommendations

- Use the DIF minimum content specifications
- Coordinate extensions with other grantees and IOOS PO DIF