SolutionsUseCase CoastsOcean Arctic 2a
Return to: Use_Cases
Plain Language Description
Short Definition
Background: This use case was developed during a small workshop that brought together scientists from diverse physical, biological, and social science disciplines to address how they would search for and assess interdisciplinary data to address important Arctic coastal science questions. A small breakout group also discussed scenarios for delivering metadata from their research projects to the data managers responsible for providing a means of discovering and using these data.
Purpose
- Metadata Creators don’t receive guidance regarding metadata requirements (e.g., templates, help with using self-describing data archival formats) or the archiving process.
- It is difficult and time consuming to obtain accurate metadata after the data collection/analysis period, and particularly after the metadata have been contributed to an archive. Metadata Creators are usually dissatisfied with metadata as written by Metadata Archivers (data centers). These metadata are usually gleaned from project descriptions and project documentation, and typically aren’t accurate. Too much time is spent iterating back and forth between the Metadata Creator and Metadata Archiver in an attempt to create accurate metadata.
- Data Seekers need metadata which will help them find connections between data (archive location), PIs, where/how data were obtained (project), and similar datasets. They need to be able to easily navigate from metadata to data.
- Metadata Creators don’t create metadata throughout the research process.
- Project metadata already exist in various forms in Project Funder records. Metadata Creators or Metadata Archivers frequently need to re-enter project metadata when populating dataset metadata records, even though those metadata could be retrieved directly from the Project Funder.
Describe a scenario of expected use
A Metadata Creator wishes to contribute metadata to a Metadata Archiver. The actual data will be archived by the Metadata Creator in the form of files available via FTP.
Definition of Success
Metadata are discoverable through Metadata Archiver interface.
Formal Use Case Description
Use Case Identification
- Use Case Designation
- CoastsOcean.Arctic.2a
- Use Case Name
- Contribute Metadata Representing Outcome of Arctic Coastal Processes Research
Revision Information
- Prepared by:
- Julia Collins
- National Snow and Ice Data Center
- 17:43, 14 May 2007 (EDT)
- Version 0.1
- Modified by:
- <Modifier Name/Affil>, <Date/time>, <Brief Description>
Definition
First paragraph is short description, second paragraph, etc. may contain further details.
Through this use case, the system User locates and identifies datasets (collections of related grandules) for use or processing. This process results in the User having access to a subset of the datasets in the portal that meet the requirements of the User. Individual datasets, and their constituent granules, may then be identified for further action or processing (e.g. Visualization, analysis, download).
Successful Outcomes
- 1.Operation succeeds and user obtains QQQ.
Failure Outcomes
- 1.Operation fails to return any XXX. Should instead YYYY.
- 2.Illegal input of AAA, Should instead ZZZZ
General Diagrams
Schematic of Use case
Use Case Elaboration
This section is intended to be completed with the details of the use case that are required for implementation. This section is not intended to be filled in by an application user.
Actors
Always identify primary actors, may be more than one. Also identify other actor including any other systems or services which are important. Primary actors are usually ones that invoke the use case and are beneficiaries of the result. They may be human or computer. They are actionable. Other actors are those that support the primary actor, i.e. would be part of the use case without the tasks, work flow, resource, or requirements implied by the needs of the primary actor.
Primary Actors
The actor that initiates this use case is the portal User. Providers may also initiate this use case as a precursor to use case EIE05, Manage Collections/datasets.
Other Actors
Security actor, who authenticates the user requests and issues authorizations for access to relevant data/resources.
Preconditions
- 1.Collection metadata have been entered into the system
- 2.Collection metadata have been validated
- 3.Collection metadata have been published
Postconditions
- 1.Datasets or granules have been identified within the system for further action
- 2.Appropriate action (i.e. Map, download, process) controls have been provided to the user to initiate that action.
- 3.Controls are provided to the user to refine the criteria used to 'discover' the dataset.
Normal Flow (Process Model)
- 1)The user selects the 'dataset discovery' tool collection from the user interface
- 2)The user performs a 'simple' search using a simple interface that searches commonly queries dataset attribute fields for matching text/terms.
- 3)The results of the search are presented to the user with appropriate action controls associated with the datasets.
- 4)The user selects one of the action controls to 'use' the identified dataset(s) in a specified action (i.e. Visualization, download, processing)
Alternative Flows
- 1)The user selects the 'dataset discovery' tool collection from the user interface
- 2)The user selects a control that provides access to an advanced search tool that supports spatial, temporal, and parametric search methods. Flow then extends to EIE11-EIE14.
Special Functional Requirements
None
Extension Points
- <Cluster>.<SubArea>.<number>.<letter+1> something added or a variant.
E.g. AQ.Smoke.1.b something added or a variant
- <Cluster>.<SubArea>.<number>.<letter+2> something added or a variant
- <Cluster>.<SubArea>.<number>.<letter+3> something added or a variant
Diagrams
Use Case Diagram
State Diagram
Activity Diagram
Other Diagrams
Non-Functional Requirements
Performance
Reliability
Scalability
Usability
Security
Other Non-functional Requirements
Selected Technology
Overall Technical Approach
Architecture
Technology A
Description
Benefits
Limitations
Technology B
Description
Benefits
Limitations
References
None