|
Revision 12
(checked in by graybeal, 3 years ago)
|
Added original version of use case.
|
- Property svn:eol-style set to
native
|
| Line | |
|---|
| 1 |
Use Case 5: Find devices associated with certain real-world properties. |
|---|
| 2 |
|
|---|
| 3 |
In this use case the use wants to measure a given environmental property, for example conductivity, or know what instruments are capable of doing so. In this case the important concept is not what variables are ultimately produce, but what measurements are directly sensed. Note the relationship (but not equivalence) to Use Case 8. |
|---|
| 4 |
|
|---|
| 5 |
This use case may have more than one potential user. The obvious user is a scientist with a budget but no equipment pool wanting to study a particular phenomenon who would like better access to instrument catalogues than typing the phenomenon name into Google. The workflow in this case is simply: |
|---|
| 6 |
1. User enters phenomena of interest into search engine |
|---|
| 7 |
2. Search engine returns a list of instruments associated with that phenomenon, including links to manufacturer's on-line catalogue |
|---|
| 8 |
|
|---|
| 9 |
However, another user is the developer of tools to support metadata creation from data that are (or at least should be) labelled with the parameters: |
|---|
| 10 |
1. Parameter labels may be transformed into a set of observed phenomena |
|---|
| 11 |
2. Observed phenomena transformed to a list of instruments |
|---|
| 12 |
3. Instruments transformed into categories using ontology classification |
|---|
| 13 |
4. Instrument categories used to populate discovery metadata fields |
|---|
