This is version 2.
It is not the current version, and thus it cannot be edited.
[Back to current version]
[Restore this version]
Aug 31, 2009
Participants: Altintas, Barseghian, Cornillon, Crawl, Gallagher, Jones, Ludaescher, Potter, Riddle, Schultz
Engineering View Discussion
- Specification -- aka Inspection
- what are the usage benefits to the user/what is the scenario of use?
- documents sensor site
- helps with future design changes
- enables other use case scenarios (prereq)
- Design time versus execution-time: design time
- google earth in gui or external?
- should allow for a report describing site layout
- names, locations, communication path, wiring of sensors
- ability to import/export SensorML -- should be the principal metadata format
- wiring should not be a tab -- should be a separate window, as its for one sensor
- probably could put wiring diagram and monitoring info in the 'sensor' window along with the workflows
- Monitoring
- should have consistent 'sensor'-oriented view, and
- when can a QA/QC workflow be run? by the user?
- the QA/QC window might better dislay a report of the results of the QA runs, etc.
- the GUI for editing the wf in QA/QC window might be better handled outside of this area, and then 'attach' the resulting workflow to the sensor
- need to flesh out remote workflow execution framework
- Analysis
- need to determine more precisely how data searching for sensors would work
- aggregate metadata in a Metacat and search the index?
- or register individual DT servers and use the DT metadata facilities?
- Control
- need to differentiate 'Specification' editor from 'control' editor
- support only on/off, plus sampling rate
- sensor-specific driver that maps these simple control actions to vendor-specific control programs
- TODO: crawl - adjust mockups to accommodate today's discussion
- Round-the-room
- Bertram - will see
- Gallagher - we'll be working on xslt to create eml from ocean usecase datasets
|