Devices Ontology Working Group Meeting 2008.01.15

A. This and That

1. Note Taker.
2. Comments/corrections of last minutes.
3. Comments/corrections on Agenda.
4. Roll Call.

B. Status of Action Items

See the TRAC page for the latest list of action items (due by current telecon) and list of action items from most recent telecon.

C. Presentation: Dr. Femke Reitsma, Edinburgh University, COMPASS

COMPASS is an organization working on an ontologically driven knowledge infrastructure for the marine domain. One of the areas they will be considering Very Soon is instrument ontologies. I've invited them to talk a bit about their project, and to hear us talk about our project, to get an idea of what synergies may result.

D. Proposed Addition to the Use Cases

E. Going over Roy Lowry's "P012" vocabulary product

F. Questions from Reviewing Sensor Variable Lists

The following questions arose when trying to normalize the sensor variable lists into a single list.

Result's of Roy's action item to create a visible implementation of the BODC vocabulary without the device or process complexities.

New version of the VINE tool.

(From last telecon:)

1. Parameter Names: We have several different kinds of parameter names. Examples are:
   • CNDC: very short and semantic code
   • CNDCZZ01: long, nominally not semantic(?) code with very detailed properties associated
   • electrical conductivity: a measurable phenomenon with no domain context, not usable as a variable
   • sea_water_electrical_conductivity: semantic, unique, variable-capable term with metric and context
   • speed: semantic description of a metric, with no domain context
   • maxgust: abbreviated semantic, unique, variable-capable term with implied domain context
   • bathymetry: descriptive semantic concept, seemingly for more than a single variable
   There is no obvious commonality among these terms, and I suspect many of them would be useless to the average person wanting to learn which instrument types could produce the variable they cared about. So I think the question becomes, what kind of parameter names do we want to represent in our ontology? (To those familiar with the Advancing Domain Ontologies workshop, the a similar question came up in the form "What does it mean to say term A is the 'same as' term B?" See the related guidance (will download PDF).)
2. Information to Track: I'm trying to create a single spreadsheet with everything in it, and I am still struggling to track the right information about each variable. To get to the ontology construction stage, I think at a minimum we need:
   • Manufacturer
   • Model
   • Semantic Variable Name
   • Connection to Controlled Vocabulary Term
   To make it possible to recognize similarities and differences between terms, and to trace terms back to their providers, I think we also need:
   • Provider Identifier (your Institution and/or Name)
   • Your Local Unique ID for the device
   • A globally unique ID for the device (built from previous 2 items)
   • Description
   To make the use case reasonably useful, I think the search also needs to distinguish between typical variables from that device, and other variables that the device can be configured to produce. This suggest a flag for typical variables:
   • Variable Group ('typical' or any other string)
   . These are quite a set of data to collect, and I don't have them all in hand.

Recall Nan's email to the list on this topic.

G. Getting to an Ontology

Depends on outcome of the vocabulary harmonization process.