| 페이지 속성 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
User stories
| 정보 | ||
|---|---|---|
| ||
No. | User stories |
|---|---|
US1 | Infrastructure provider perspective. The motivation for the EAP is that since the end of the STARS4ALL EU project, the number of photometers has been continuously growing, until reaching 100 units. They expect to double this quantity this year, multiplying the number of units in the following years. Each minute, our system receives a measurement from each photometer, so there is a need to increase in the future the capacity of the network. Also the information (data, code, presentations, videos) generated by our initiatives is currently scattered over our Zenodo community and other platforms, thus being difficult to access and discover. We need a mechanism to bundle all this information. |
US2 | End user perspective. Each photometer, besides the measurements, has its own metadata associated (sensors, location, calibration parameters, etc …). As a user, I want to create a persistent id for each photometer so I can access to all its information and that this information may be integrated in GEOSS platform. Besides the photometer network, STARS4ALL gives support to citizen science initiatives like Cities At Night. As a user, I want to bundle all the information related to my research (as a research object) so I can see and share my research outputs (data, code, presentations, papers, etc …) following the Open Science principles. In addition to these characteristics, as a user, I want to access deposited data from a Jupiter Notebook, so I can process them to make some analysis, and add them to my research object. |
... |
Use cases
| 정보 | ||
|---|---|---|
| ||
A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system to achieve a goal. Include in this section any diagrams that could facilitate the understanding of the use cases and their relationships. |
General considerations
STARS4ALL is based on a set of initiatives, which a great variety of outputs. We want to model each initiative as a research object, or a composition of them. For practical purposes, an initiative is a project.
Step | Description of action | Dependency on 3rd party services (EOSC-hub or other) |
|---|---|---|
UC1 | Creation of an initiative. | The user wants to register a new initiative by creating a description in B2SHARE. As a result, a persistent identifier or PID identifying the initiative will be created. |
UC2 | Creation of a research object in B2SHARE | The user wants to register a new research object in B2SHARE. As a result, a persistent identifier or PID will be created identifying the RO and the initiative |
UC3 | Add objects to a research objects in B2SHARE. | The user wants to deposit a resource in B2SHARE (uploading a file to B2SHARE or giving a uri of the resource). This resource will be linked (filling in with the appropriate metadata) with the research object via the RO id and because of that with the initiative. In the case of Zenodo, the metadata of a research object will be completed with the metadata present in Zenodo.
|
| UC4 | Discover and navigate among the resources of a research object, or the elements of an initiative. | The user will be able to consult all the outputs of an initiative /research object in B2SHARE, that has previously been registered in B2SHARE and indexed in B2FIND. All the resources’ links will be actionable in other words, the user will be able to navigate through them, as a webpage.
|
| UC5 | Register a photometer | The user wants to register a new monitoring station in B2HANDLE, generating a persistent identifier (PID) in the system. This station will have information associated such as location, sensors information (the schema based on SOAF, etc …). This PID will be used and referred to when a user deposit the measurements of the sensor (in UC3). |
| UC6 | data integration in GEOSS portal | When a user deposits a dataset (UC3) related to a sensor (UC5), all this information will be integrated in the GEOSS platform. As a consequence, the user will be able to consult all the information and measurements generated by this sensor.  |
| UC6UC7 | Analyzing the observation data with a set of Jupiter Notebooks | The user needs access to a dataset (deposited in B2SHARE or Zenodo) to analyze them. Later, these analysis data will be deposited in B2SHARE |
Requirements
Technical Requirements
| 정보 | ||
|---|---|---|
| ||
- Requirement number: Use numbers RQ1, RQ2, RQ3, ... |
Requirement number | Requirement title | Link to Requirement JIRA ticket | Source Use Case | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Example | EOSC-hub to provide an FTS data transfer service |
| UC1 | ||||||||
RQ1 | STARS4ALL Research object metadata schema | UC2, UC3 | |||||||||
RQ2 | photometer sensor PID schema | UC5 | |||||||||
| RQ3 | STARS4ALL RO md schema B2FIND mapping | UC4 | |||||||||
| RQ4 | Actionable research objects in B2FIND & B2SHARE | UC4 | |||||||||
| RQ5 | JN access to B2SHARE stored data | UC6 | |||||||||
| RQ6 | JN access to Zenodo stored data | UC6 | |||||||||
| RQ7 | mapping between photometer schema and GEOSS schema to integrate data in GEOSS | UC6 |
Capacity Requirements
EOSC-hub services | Amount of requested resources | Time period |
|---|---|---|
| VM | 1x (1CPU, 8GB RAM, 20GB) | Q3 |
| VM | 1x (1CPU, 4GB RAM, 10GB) | Q3 |
| VM | 2x (1CPU, 4GB RAM, 50GB) | Q3 |
| JN Hub | light version | Q1 |
| 목차 |
|---|