Warning:
This wiki has been archived and is now read-only.
Use Case Process Provenance
Use Case: Provenance/Process
Learn about data context from sensor information
Description
Primary Actor
User (Engineer/Scientist) evaluating the quality of results drawn from data collected from one or several experiments/missions.
Supporting Actors
TBD
Stakeholders and Interests
Pre-Conditions
The acquisition of the data has generated the contextual information which allows "follow your nose" exploration of the origin of the data, including the conditions in which it has been produced and the workflow which has been used to process it.
The end user needs some information (but don't necessarily know what type of information) to correctly interpret the data.
Post Conditions
-
Success end condition
The user has found the extra information he needed.
Failure end condition
The user has not found the extra information he needed.
Variations
The user can compare the process/workflow used for this piece of data with the theoretical process/workflow defined in the "manual of procedures" (e.g. check that the calibration of the instrument or sensor has been made correctly).
Extensions
The dynamic generation of workflow should go in a different use case.
Special Requirements
TBD;
Examples:
Performance
User Interface
Security
Issues/Follow-ups
TBD
References
- Use cases from the W3C Provenance XG Nothing sensor-related yet - check again
- First International Workshop on the role of Semantic Web in Provenance Management SWPM-2009
TO BE COMPLETED
(from mmi.svn.sourceforge.net) 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.) Note: This second situation is a hybrid discovery/provenance use case
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.