Observations About This Content Standard
This file documents the results of the team working with this content standard.
Comments may address the technical standard itself, or the context in which it is provided (availability, documentation, working examples, etc.).
Team Experience
Please indicate the levels of experience of each of the team members with this standard (no names required), according to the following scale: 1=no experience, 2=slight knowledge, 3=moderate understanding/slight use, 4=significant use, 5=strong knowledge.
The team had 5 members ranging from 3 to 5 in knowledge.
- - - - -
Resulting Specifications
Our sensor specifications are found at:
Strengths
The following strengths have been identified in working with this standard.
- Historical perspective
- Love/hate attributes - depends on dataset you want to describe as to how easy or how well it works
- Able to capture much of the info about CTD, but not all
- Good for basic data discovery
- Covers a lot of basics about data set, what it is, where to get it, remote sensing extensions allow for naming sensors, linking to reference documents
Recommendations, Weaknesses, Issues, and Unresolved Questions
The following issues and recommendations were identified.
- Needs to support more instruments
- Needs support for locating in situ sensors
- Elements need to be more constrained for machine-to-machine interoperability
- FGDC can accomodate sensor descriptions, but needs more elements and further constraints to accomodate sensor driven datasets
Controlled Vocabularies Needed
The following controlled vocabularies were used (indicate element(s) for which they were used).
Controlled vocabularies for the following topics were needed but not available.
- Instruments and sensor types
- Need to check to see if adequate thesauri exist for OOI variables
- Need to ensure writer links attribute names to theme keywords in a constrained manner so it is machine-to-machine interoperable
Other Comments on the Standard
Note any other comments about this standard here.
The following are comments made throughout the breakout session in chronological order.
- Need to add "long instrument name" in descriptive section of RS extension
- Need controlled vocabulary (CTD) Need to add other instrument type description
- May want to develop in situ extensions including terminology
- No place for instrument ID, included it in instrument short name
- Need to document data differently in the std if moving or fixed Location of sensor may be different than geo location of data set
- Need a way to define location of sensor (like platform location)
- Location in relation to platform, or as an individual lat/lon
- Can include inst manufacturer in free-text, will need to extend std if need it as a controlled element
- Variable names and info can be put in entity and attribute area, may need controlled vocabulary
- Thesaurus needs to be registered
- Keyword vocabularies are critical for discovery - need known variable names
- Definitions are not clear - "status" is interpreted differently
- FGDC - not so good with time series
- Sensor location and data location may be different
- Would have been nice to have someone in the room who knew something about CTDs
- Anytime we had questions, we decided whether the std could be handled by the std or not
- Can handle the different sensors (C, T, D) on the instrument (CTD) by treating CTD as a platform, or treating it as the instrument and linking to records for each sensor
- Can we adopt "satellite" fields to "buoy" needs, "other collection description" needs to include more vocabulary so it can be used in other sciences
- instrument needs to be recursive to have complexity that's needed to describe instrument/sensor issues
- need recursiveness for a number of metadata elements - location (multiple instruments at diff depths), etc.
- Might be able to use "Location_Information" for oceanography
- Might want to reference a sensorML record from the FGDC record if sensorML is the better way to record sensor info
