Copy of Device Ontology Use Cases

Use Case 1: Discover and plot data from common sensor types automatically
-> e.g., via SOS Services

1. Portal presents a category "CTD" for a user to get data from a CTD sensor
2. Users goes to a portal and searches data from CTD sensors
3. Portal asks a registry for Sensor Observation Services which have as a method a CTD sensor
[ need a URI to categorize this type ]
4. Registry looks for services whose method is a CTD sensor
[URI of CTD ]
5. Registry returns services that uses a CTD sensor
[ that matches the URI of the CTD ]
6. Portal uses the service information retrieve from the registry to get the data.
7. Portal knows how to plot CTD data and presents a preview to the user

The term 'CTD' could be replaced by vertical profiler or any other type of sensor.


Use Case 2: Classify devices according to functionality.

1. User begins entering a device record into a data base.
(Could also be creating a device metadata record, e.g., in XML).
2. User is prompted to enter the functional capability of the device.
(Selects from drop down list or controlled vocabulary.)
3. Auxiliary functional capabilities are solicited. (Any number may be entered.)


Use Case 3: Find devices that can be deployed from a given platform.

This use case involves searching for devices that can be deployed from a given platform, for example a ship. It is one that would be performed by system operators, and asks where a device is capable of being deployed. (Other criteria besides platform include medium in which the device is deployed, and whether the device is tethered or not.)


Use Case 4: Find devices that can produce certain output variables
-> or provide all the information necessary to produce those output variables?

(This may not be different than Use Case 1.)

Salinity might be a direct output variable for some CTD devices, and a post-processed variable for data from other CTD devices. See for example email from J Zedlitz [http://mmi.mbari.org/pipermail/ontdev/2007/000013.html]. The mechanism by which the device produces the outputs -- direct measurement or measurement plus calculation -- is not relevant to this use case.

For more detail on the concept of output variables, visit the device variables page [http://marinemetadata.org/examples/mmihostedwork/ontologieswork/observableont/ontdevices/ontdevices/devicedata].


Use Case 5: Find devices associated with certain real-world properties.

The user wants to know what instruments can measure a given environmental property, for example conductivity (for example, to obtain an instrument to perform the measurement, or to analyze those instruments for some other purpose).

In this case the important concept is not what variables are ultimately produced, but what measurements are directly sensed. That is the primary distinction from Use Case 4.

Note the relationship (but not equivalence) to Use Case 8, which focuses on the sensors rather than the device as a unit.

There is another use case, Use Case 12, which is almost the inverse of this use case. It involves using the variable terms to produce higher-level documentation of an instrument.

A scientist wants to buy equipment to study a particular phenomenon, and wants to find ALL the instruments that are capable of studying that phenomenon (not just those discoverable through manual or on-line searches through catalogs, or through Google entry of a keyword).

The user workflow is:
1. User enters phenomena of interest into search tool.
2. Search tool derives parameters of interest to study that phenomenon.
3. (Search tool may present parameters list for user confirmation/edit.)
4. Search tool returns a list of instruments associated with those parameters, including links to manufacturer's on-line catalogue.

The developer workflow is:
1. Parameters in ontology are mapped into a vocabulary of observed phenomena.
2. Parameters in ontology are mapped into a list of instrument types.
3. Add inferencing to tool to get from observed phenomena to parameters,
and parameters to instruments.
4. Execute geospatialtemporal and other filters as appropriate to
obtain only instruments of interest.
5. Return instrument list.

Use Case 6: Find devices that can supply the expected data in the expected format.

(This was previously called "Apply post-processing automatically to appropriate devices", but the new formulation seemed more general.)

Identify those devices that produce a data stream that can be post-processed or used by a given set of algorithms. (The use case assumes one can describe what kind of data the algorithms can automatically post-process.)


Use Case 7: Identify devices that operate via a given method.
-> Includes whether that method is remote or in-situ.

Rather than consider end results, it may be valuable at times to understand what devices are capable of performing a particular method, e.g., fluorometry, or coring.

(Note: This use case was pursued in the Advancing Domain Vocabularies workshop. See http://marinemetadata.org/examples/mmihostedwork/ontologieswork/mmiworks... for the resulting thought process, vocabulary, and issues.)


Use Case 8: Find all sensors that perform a particular measurement.

This use case focuses not on the devices, but on the sensors contained within them. Otherwise it is identical to Use Cases 4/5.


Use Case 9: Find devices that can obtain certain physical samples.

The workflow is essentially similar to the first workflow given under Use Case 5, except that the scientist's target is samples for subsequent analyis rather than in-situ measurements.

A mechanism is needed for adequately describing samples. For example, is it sufficient to use 'sediment sample' or do we need additional attributes such as 'sediment sample with undisturbed sediment/water interface?


Use Case 10: Find all the devices that meet certain criteria.

Use Case 3 is one example of this type of scenario. Others follow.

Use Case 10A: Find all the devices that can operate at all depths from 50 meters to 3000 meters.

Presumably to be combined with other criteria, this enables users to find devices that can be deployed on platforms at those depths. To respond to this query, the operational depth limits of each device would have to be provided in the device description.


Use Case 11: Learn about data context from sensor information.

This use case has two distinct circumstances. Both start with the user having access to a dataset, and wanting to learn contextual information about that dataset. Both involve learning about the instrument used to collect the data.

In the first situation, the user wants to use the knowledge about the instrument to better evaluate or process the data. For example, the user may want to know expected accuracy and resolution of the instrument's measurements, or the appropriateness of the calibration status that has been provided.

In the second situation, the user wants to know what related data parameters are likely to be available for this dataset. One way to discover additional metadata is to find what other data can be collected by the instrument that collected this data. (Another way, learning what other devices were deployed with this one, is outside the scope of this project.)

The workflow is something like this:

1. User has data set of interest.
2. User goes to provider of data set and looks up the data set and its metadata.
3. User finds metadata describing the metadata used to collect the metadata.
4a. User obtains device metadata directly from the metadata description, or
4b. User learns the type of device (manufacturer, model, and in some cases serial number is needed) used to collect the data, and does additional research on that device to learn the necessary information.


Use Case 12: Specifying Equipment - Summary Metadata
-> Metadata Documentation by Inference

A developer of software tools to support simple metadata creation wants to help manufacturers create useful, accurate, reproducible discovery metadata for their instruments. To do so, the developer plans to provide software that can analyze a list of parameters measured or produced by the device, and from that create a set of keywords that summarizes the functionality of the device.

User workflow:
1. Create metadata for the instrument using the tool, starting with parameters the instrument can measure.
2. Press the 'Autofill Keywords from parameters' button.
3. Software ascertains, from the measurable parameters and on ontology, the related keywords.

Developer workflow:
1. Obtain list of instrument measurement parameters that describe measurements that can be taken by instruments.
2. Map the relationships between those parameters and higher-level categories of interest (e.g., science keywords, or instrument type).
3. Build the tool to fill out the broader metadata by inference from the narrower metadata.