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 present in a facet 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 (Datatype browser). 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 browses the existing properties present in a facet and either selects an existing property or enters the property name in the same facet. He/she repeats this step until all the required properties are associated the data type. 6) After submitting the form, 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 and generates a persistent identifier. 8) Persistent identifier should now be present with that data type along with the creation time of that data type (populated by the system). 9) 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) Step 6 results in Data Type Registry retrieving similar data types and displaying those at DCO Datatype browser. 2) Scientist can select a data type retrieved by the Data Type Registry instead of registering his/her data type. 3) Scientist should not be able to edit any registered data type that was registered by someone else. 4) Scientist cannot ignore to associate his/her dataset with data type as data type would be enforced as a mandatory field while 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. That registered data type should be displayed in a facet of the DCO dataset browser screen. Another facet in the same screen should show all the properties associated with that data type. That registered data type can be searched at DCO data portal by its label and its associated DCO ID. DCO dataset browser should show all the registered data types for a data set. DCO dataset browser should list down all the datasets associated with a data type. 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. UseCase- -Template 5

6 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 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 UseCase- -Template 6

7 Resource Owner Description Availability Source System UseCase- -Template 7