Collecting data types from the thermodynamic data and registering those at the DCO data portal.

Transcription

1 Use Case: Collecting data types from the thermodynamic data and registering those at the DCO data portal. Point of Contact Name: Apurva Kumar Sinha Use Case Name Give a short descriptive name for the use case to serve as a unique identifier. Consider goal-driven use case name. Collecting data types from the thermodynamic data (legacy literature) and registering those at the DCO data portal. Goal The goal briefly describes what the user intends to achieve with this use case. Register data type at the DCO data portal and associate the data type with a registered thermodynamic dataset. Summary Give a summary of the use case to capture the essence of the use case (no longer than a page). It provides a quick overview and includes the goal and principal actor. Scientist wants to associate his/her dataset with any existing data type at the DCO dataset browser. When he/she could not find an appropriate data type available at the DCO dataset browser, he/she tries to register the required data type. This use case focuses on identifying data types in the thermo dynamic datasets (several papers related to thermo dynamic features of chemicals and minerals) and registering those data types at the DCO data portal. Every dataset would be associated with one or more data types by using an object property dco:hasdatatype. UseCase- -Template 1

2 Actors List actors, people or things outside the system that either acts on the system (primary actors) or is acted on by the system (secondary actors). Primary actors are ones that invoke the use case and benefit from the result. Identify sensors, models, portals and relevant data resources. Identify the primary actor and briefly describe role. Primary actor: Scientist Secondary actor: DCO Data portal, Data Type Registry, DCO Data portal site admin Preconditions Here we state any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about other systems can also be stated here, for example, weather conditions. List all preconditions. Scientist is logged into DCO data portal. Scientist has a dataset that he/she wants to publish at DCO data portal. Scientist is able to register new data types on the DCO data portal. DCO dataset browser should automatically show the scientist all the registered data types related to his/her dataset. UseCase- -Template 2

3 Triggers Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or when a set of conditions are met, List all triggers and relationships. Scientist searches for the data type that is not registered yet and so he wants to register that data type. Basic Flow Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required) 1) Scientist browses the registered data types at the DCO dataset browser. 2) Scientist could not find any relevant data type to associate with his/her dataset. 3) Scientist navigates to the form for registering data type. 4) Scientist enters a label for his/her data type and gives other important information related to that data type like description, expected uses, source standard, and provenance information. 5) Scientist searches for children data types in the facet of the dataset browser and selects the required ones. 6) Data Type Registry searches for any similar data type both within and outside DCO and alerts the scientist of any similar existing data type. 7) Data Type Registry registers that data type along with the newly created children data types and generates a persistent identifier for all. 8) Creation time of the data types are obtained from the system present date time. 9) Scientist can now use this data type for registering another data type. Thus, a data type would generally have a collection of already registered data types, thus creating a hierarchy of data types. 10) DCO Data Portal Site Admin can register a data type or modify an already registered data type. In addition to these, DCO Data Portal Site Admin also has the privilege to remove the registered data types. UseCase- -Template 3

4 Alternate Flow Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow. 1) In step 5, scientist finds that a required children data type is not present. 2) Then, he would have to register that children data type in the same way and then use it. 3) Step 6 results in Data Type Registry retrieving similar data types from other sources and displaying those in a facet at DCO Dataset browser. 4) Scientist may then choose that existing data type from other source instead of registering it. 5) Scientist should not be able to edit any registered data type that was registered by someone else. 6) Scientist cannot ignore to associate his/her dataset with data type as data type would be enforced as a mandatory field when publishing dataset. Post Conditions Here we give any conditions that will be true of the state of the system after the use case has been completed. All the registered data types should be displayed in the facet of the DCO dataset browser screen. Registered data types could be searched at DCO data portal by its label or its associated DCO ID. That data type should show all its children data types in another facet of the same DCO dataset browser screen. DCO data portal should show all the registered data types for a particular data set in another facet at the dataset browser. UseCase- -Template 4

5 Activity Diagram Here a diagram is given to show the flow of events that surrounds the use case. It might be that text is a more useful way of describing the use case. However often a picture speaks a 1000 words. Notes There is always some piece of information that is required that has no other place to go. This is the place for that information. DCO Deep Carbon Observatory DTR Data Type Registry UseCase- -Template 5

6 Resources In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include data and services, and the systems that offer them. This section will call out examples of these resources. Data: Data Type Characteristics Description Owner Source System Modeling Services Model Owner Description Consumes Frequency Source System Event Notification Services Event Owner Description Subscription Source System Application Services Application Owner Description Source System Other resources Resource Owner Description Availability Source System UseCase- -Template 6