SolutionsUseCase CoastsOcean Arctic 2a

From Earth Science Information Partners (ESIP)

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

Through this use case, the Metadata Creator contributes metadata to a Metadata Archiver. These metadata are the foundation of the use case described by SolutionsUseCase_CoastsOcean_Arctic_1a.

Successful Outcomes

  • Metadata are complete and available to Metadata Archiver.

Failure Outcomes

  • Required metadata fields are not complete.
  • Metadata are not available to data discovery processes.

General Diagrams

Schematic of Use case

[PDF version]

CoastsOcean.Arctic.2a.jpg

Use Case Elaboration

Actors

Primary Actors

  • Metadata Creator

Other Actors

  • Data Seeker
  • Project Coordinator
  • Metadata Archiver
  • Metadata Editor
  • Metadata Search Handler

Preconditions

  • “Metadata” may include:
    • Project (logistics) metadata (describing the entire funded activity).
    • Collection-level metadata (describing a dataset).
    • File-level (inventory) metadata (describing the individual data storage entity within a collection (dataset)).
  • There may be multiple collections (datasets) associated with each project.
  • There may be multiple files associated with each collection (dataset).
  • Metadata Creator already has username and password required for authentication with metadata editor interface.

Postconditions

  • Metadata are discoverable through Metadata Archiver interface.
  • Metadata are used to create a search/discovery interface which guides the Data Seeker to project information, project data, related data, and investigator.

Normal Flow (Process Model)

  • The use case begins when the Project Coordinator registers a project description and provides initial project metadata to the Data Archiver (for example, using the online NSIDC IPYDIS data registration form).
  • The Data Archiver exports preliminary metadata to the Metadata Search Handler (e.g. Mercury).
  • The Metadata Creator provides a user name and password to the Metadata Editor.
  • Metadata Creator is authenticated and is presented option to select project record(s) for modification.
  • Metadata Creator selects a project to update using IPY Project ID (IPYPID).
  • Metadata Editor presents existing metadata records for selected IPYPID.
  • Metadata Creator updates metadata record content.
  • Metadata Creator saves updates.
  • Metadata Editor sanity checks inputs and verifies that all required fields are completed.
  • Metadata Editor exports updated metadata in XML format to Metadata Search Handler.
  • Metadata Editor exports updated metadata in XML format to Data Archiver.

Alternative Flows

IPYPID has not yet been updated using Metadata Editor:

  • Metadata Creator selects a project to update using IPY Project ID (IPYPID).
  • Metadata Editor retrieves project metadata from Metadata Search Handler and pre-populates editor records.

Not all required metadata fields contain valid information:

  • Metadata Editor queries Metadata Creator to correct incomplete fields.

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