Main Navigation

User login

Devices Ontology WG Mtg 2008.10.28

Agenda/minutes for Device Ontology Working Group meeting 2008.10.28

Agenda

Logistics: Welcome, Minutes Review, Agenda Review
Discussion of new scenario (see below for details)
Voting on priorities (see below for details)
End Logistics: Next meeting, Action items, Attendees.

Minutes

Logistics: Welcome, Minutes Review, Agenda Review

.

Minutes review

No complaints.

Agenda approval

The agenda was presented from the email, quoted in each sections below.

Discussion of new scenario

Alas, Carlos left it to me to generate the agenda, and all I have managed is this silly use case (below, blending the previous use cases 4, 5, and 8. But if you'll read that, we can discuss the details of it tomorrow. ... The following new use case represents a blend of 4, 5, and 8, as we discussed in the last telecon. It has one place that I consider terribly imprecise; it will probably be obvious when you get there, but we'll save that for the discussion. The main question to assess: is this use case sufficient to derive key device ontology properties from? (And if so, what are those key properties?) Use Case 13: Find device or component that can measure a given real-world property or produce a given output parameter. Notes: (a) The mechanism by which the device produces the outputs -- direct measurement, measurement plus calculation -- is not really relevant to this use case. See for example email from J Zedlitz [http://mmi.mbari.org/pipermail/ontdev/2007/000013.html]. (b) For more detail on the concept of output variables, visit the device variables page [http://marinemetadata.org/examples/mmihostedwork/ontologieswork/observableont/ontdevices/devicedata]. (c) An example of a real-world property that is directly measured is conductivity. A typical output parameter is salinity, which can be estimated from conductivity values (plus temperature and depth). (d) The search space for the device arguably doesn't matter, for example take these 3 search scenarios: (1) Operational devices deployed in a certain ocean region. (2) Devices in storage in the warehouse, ready for deployment. (3) Devices available for purchase. It is assumed (and reasonable) in each case that 'traditional' search methods are insufficiently robust. (e) The role of post-processing can be arbitrarily included or not in the description of the use case; the result is equivalent, though for some applications the fact post-processing is required to produce a given output is an important property. (f) Whether we are searching for a device or sensor is arbitrary, but again necessary to distinguish for proper searching results. Scenario: The user/scientist wants to know what instruments can measure a given environmental property or phenomenon, for example conductivity (for example, to obtain an instrument to perform the measurement, or to analyze those instruments for some other purpose). A. User (or Scientist) Workflow: 1. User enters phenomenon of interest into search tool, for example salinity or hurricanes. 2. Search tool derives parameters necessary to study that phenomenon. (For salinity, conductivity, temperature, and depth are example parameters; for hurricanes, wind speed, wind direction, and air pressure are example parameters. 3. (The search tool may present a parameters list to the user for confirmation, prioritization, or editing.) 4. Search tool returns a list of instruments that can produce those parameters, including links to instruments' metadata. B. Developer Workflow: 1. A mapping from phenomenon to desired output parameters is created, using phenomenon and parameter vocabularies. 2. A mapping from output parameters to measurable properties is created, using those vocabularies. 3. A mapping from "instrument types" to measurable properties is created, OR a database of measurable properties for each instrument model is created. 4. Add inferencing to search tool to get from observed phenomenon to output parameters, and from those output parameters to instrument types or instrument models. 5. Execute geospatialtemporal and other filters as appropriate to obtain only instruments of interest. 6. Return instrument list.

Do we need to keep track of whether things are directly measured or not? Different users will have different needs -- some will need real-time output and not be able to do post-processing. There are 3 ways observational data gets produced:

directly measured
computed on board
computed in standard post-processing

It may be useful additional information to keep track of these distinctions, but for our purposes in this scenario, there is no direct requirement for them.

There is also a different axis, that of constructing a measurement using various sensors. We need to know what additional information is needed to construct a measurement.

Discussion of B.3

Not hearing any comments on this use case, John directed attention to B.3. Here we have the term "instrument types". What are these? Why, they are the distinctions or classifications used to group instruments -- but we haven't figured out any suitable classification system yet that can actually be associated with measurable properties.

What types of phenomena would we address? Maybe we should limit to more narrow concepts for 'phenomena'. A concept like 'hurricane' is quite large, maybe too large (at least for the semantic web of today!).

Addressing B.1 is outside of scope of this use case (we are assuming it is addressed elsewhere). Addressing B.2 may or may not be outside of scope

How do we define what are meaningful and not-meaningful groups of parameters? The permutations of all possible combinations won't be meaningful. (If people are interested in a particular parameter, and we know what individual devices measure what parameters, they could just search on that parameter. What value is the ontology adding, in that case?)

Are we focusing too much on what is measured and not how it is measured? This takes us back to all the complexities that can be associated with a measurement: where, how, when, etc. But these are addressed in other use cases. For this use case, we are focusing on what is measured.

Voting on Priorities

From the email:

Also, assuming the combined use case survives, we essentially have all the material we need to conduct the following poll:

You are given 3 votes, to be allocated any way you want. Of the remaining use cases -- 1, 2, 3, 6, 7, 9, 10, 11, 12, 13 -- how do you allocate your 3 votes for the most important use cases? Please think about that before the meeting, if you can.

We didn't have time to discuss this.