1. LEGACY MEETING – SUMMARY NOTES LEGACY MEETING SUMMARY NOTES September 3-5, 2008 Palisades, NY

2. LEGACY MEETING – SUMMARY NOTES paradigm shift -> fleet as a global observing system NSF-supported research vessels routinely report to central fleet repo – cruise metadata (expedition summary, instrument profile, event logs) standard underway data free operators from responding to archival requests enable science community to develop integration+visualization apps

3. LEGACY MEETING – SUMMARY NOTES existing science community data management efforts MGDS (Ferrini) BCO-DMO (Chandler) SIOx (Miller) GeoMapApp – Java app developed by MGDS to integrate+visualize data offers features like Arc GIS and Fledermaus export deployed to ships at sea (Langseth, Knorr, Healy, Palmer)

4. LEGACY MEETING – SUMMARY NOTES ships can deliver basic block of cruise metadata if central repo provides – published schema based on UNOLS Data Committee draft controlled vocabularies (reconciled with STRS) operator assigns cruise id (may just be sail date), unique for institution+ship must minimally satisfy NGDC and NODC (and POGO)

5. LEGACY MEETING – SUMMARY NOTES forms-based webapp to manage cruise metadata standalone deployable to sea (maybe laptop with cellular modem) can maintain history (load from a template or past cruise) provide additional functionality (one-click CG manifest, data report, etc) versioned, encrypted xml files can be exchanged by email/ftp/rsync shoreside instance can be pre-populated by marine offices

6. LEGACY MEETING – SUMMARY NOTES reduce growing # of custom data feeds that ships are asked to provide DACs like SAMOS can grab raw data from central repo, process, then give direct feedback to ship (exception: VOS, NWS are useless if not near-realtime) next target for fleet standard delivery after nav: salinity

7. LEGACY MEETING – SUMMARY NOTES ships can deliver realtime subset of underway data to central repo small enough to deliver by satellite to email/ftp/rsync dropbox navigation at a minimum, maybe also tsg and met central repo will then publish standard products (control points, track maps)

8. LEGACY MEETING – SUMMARY NOTES central repo will publish open-source code to create final navigation start with SIO “navd” (accepts N GPS inputs, calculates 1 output + log) work with global operators to enhance for e.g. antenna offsets repo will create final nav automatically for ships that send raw GPS next target for standard processing after nav: potential fields

9. LEGACY MEETING – SUMMARY NOTES delivery of ship's complete data distro to central repo USB drive rotation via physical shipment - or - ftp/rsync dropbox include manifest (file names, checksums) central repo will notify/confirm released data with chief scientist can accomodate non-NSF data if guaranteed secure

10. LEGACY MEETING – SUMMARY NOTES central repo services for multibeam data (priority focus) patch test defined as fleet standard practice (if PI wants good data!) publish global list of reference patch test areas publish data location (swath track only) immediately contribute released data to Legacy synthesis + NGDC

11. LEGACY MEETING – SUMMARY NOTES inventoried and categorized data types – 1.routine underway data types - deliverable to central repo (includes engineering data) (long-term goal - define a fleet standard minimum) 2.facility data - deliverable to facility repos e.g. NDSF, NMSF 3.event logs, sample inventories - deliverable to central repo (these are actually metadata)

12. LEGACY MEETING – SUMMARY NOTES vessel instrument profile flush out UNOLS Data Committee draft and publish formal schema – 1.type/class 2.make 3.model 4.serial# 5.firmware 6.install date 7.last calibration date 8.3D position 9.photo + instrument type-specific details profile may change many times during cruise technician "peer review"/education - visit other ships

13. LEGACY MEETING – SUMMARY NOTES central repo could satisfy "9 of 10" data requests for State Dept. clearances deliver standard underway data in a specified time window deliver standard data report composed from cruise metadata

14. LEGACY MEETING – SUMMARY NOTES event/sample logging is imperative to successful science, data preservation well-designed logging system should - 1.enforce a unique event id for a given cruise 2.auto timestamp 3.control vocabularies for event types 4.be multi-headed (usable throughout ship, someday on bridge) several ships already maintain routine digital event log R2R project will target several ships for prototype work in coming year