Devices Ontology Working Group Meeting 2007.11.06

Wiki page with list of participants will be created. User id and passwords will be generated and sent to the group

Notes of Meeting

A. Logistics and Such

John took notes today, which explains their limited nature.

No comments/corrections to minutes/agenda.

B. Status of Action Items

Action item status may be seen and reviewed via the TRAC system.

Open action items

All action items

At some point I hope to have more specific action item lists (e.g., view action items from last meeting, view action items due this meeting) but TRAC defeated me in my first attempt. I've since gotten this hack up and running.

C. Logistics - User name and passwords

This is done: User names and passwords for TRAC and SVN have been generated and sent to the group. Please contact Luis Bermudez (before 12/17) or John Graybeal (12/17 and after) if you need help.

D. Review of Sensor Variable Data

Several people reported on their experience, with some difficulties identified. (Links point to the TRAC entries for those problems.)

Jesper used the BODC Parameter Usage Vocabulary (the codes), but found it difficult to do both input and output. Roy found these terms difficult to grok (see the description of what we mean). He notes the vocabularies aren't really geared up for this job yet, he wants to try the MedAtlas vocabulary.

Eric identified several difficulties. Some inputs had complex device variables, either complex definitions ("sound velocity profile") or syntactically awkward (cases where variables were in multiple channels or arrays). Finding the right parameters for geophysics is difficult (there aren't so many geophysics parameters in the BODC vocabulary, for example).

Some would prefer a lower-level description, limiting the entries to discovery level keywords with fewer details. Another recommendation is to record all the information we have about the instrument, but treat its inner processes as a black box.

Operating context is not clearly provided, so one can't distinguish between shallow and deep level echosounders. Also it is impossible to tell which parameters a sensor can be used on. But note, there is the potential to do a lot of work parameterizing the sensor descriptions, but this would not necessarily meet the user needs. Some of this information can be included in your description of your sensor, but are not a part of this first use case/exercise.

For output parameters, how do we describe the formats of different records? This can be achieved with the suggestion documented in the instructions (see the bottom of the page) for describing multiple records. The semantic description of the content is the first priority for now. Note that it is not necessary for our use case to indicate which is the default configuration.

How to proceed?

Recommendations were along the following lines.

Re arrays: The semantic content is the important element for now. You can use 'array' in the name if you want to reflect that. Ranges of wavelengths, operating depths, valid values, etc. may be useful to have in comments, but aren't directly needed for first activity.

Re variable names: We need to continue to identify best lists for variable names. John will try to find the status of the GCMD keywords parameter-level list.

Re inputs and outputs, continue to do both, and ignore the internals of the machine.

Review inputsLook closely at what we have received so far in the way of submissions, and try to ask clarifying questions that will help move the process forward in a more precise way.

Closing Logistics

Next meeting will be on Nov 20th 2007 1600 GMT. San Francisco: 8:00 AM, London 1600, Paris 1700

Attendees