| 30 | | * |
| 31 | | * |
| 32 | | * |
| 33 | | |
| 34 | | |
| 35 | | |
| 36 | | |
| 37 | | |
| 38 | | |
| 39 | | |
| 40 | | |
| 41 | | |
| | 30 | * List of the datasets (OAI-PMH sets) bundled per data provider and per CLARIN centres/countries (MUST) |
| | 31 | * Status and statistics of the sets within the ingestion pipeline (errors, progress indicator) (MUST) (export as PDF, XML, CSV etc (SHOULD)) |
| | 32 | * Simple visualisation of the statistics 2), including pie charts, bar charts etc (CLOUD) |
| | 33 | * Browse the data quality reports per set (MUST) (export as PDF, XML, CSV etc (SHOULD)) |
| | 34 | * Send email of the data quality report to a data provider/CLARIN centre (SHOULD) (automatic email (COULD)) |
| | 35 | * Edit the concept mapping (MUST) |
| | 36 | * Edit the value mapping and normalisation (MUST) |
| | 37 | * Manual data management (deactivate indexing of the sets, delete the data sets, harvesting of data sets) (MUST) |
| | 38 | * Synchronise the component registry, CLAVAS, and CCR with the data sets (MUST) |
| | 39 | * Browse the log files of the VLO systems (COULD) |
| | 40 | * Browse the Puwik web traffic monitoring (COULD) (do it per data set (CLOUD)) |
| | 41 | * Link checker which lists broken links (per set) (COULD) |
| 45 | | |
| 46 | | |
| 47 | | |
| 48 | | |
| 49 | | |
| 50 | | |
| 51 | | |
| 52 | | |
| | 45 | * (Re-)harvesting of the data set |
| | 46 | * Disable indexing |
| | 47 | * Delete the data set |
| | 48 | * Show the data quality report (various statistics e.g mapping coverage, facet coverage, controlled vocabulary coverage, broken links etc)(download them as PDF, CSV, etc) |
| | 49 | * Show the error messages (download them as PDF etc) |
| | 50 | * Show the metadata sets |
| | 51 | * Show the schema/profile (with the link to Component Registry, CLAVAS, and CCR) |
| | 52 | * Send an email to the data provider (eg data quality report) |
| 54 | | |
| 55 | | As well as the single data set actions, there will be batch processing options. The users can search, sort, and filter the data in this table view. In addition, s/he can |
| 56 | | select multiple data sets by clicking the checkboxes on the left. With this table view, the user should be able to see the overall statistics (and/or selected data sets), including the number of datasets, countries, data providers, the status, the number of records indexed and distributed. Those figures are extremely important for the performance indicators (for CLARIN board etc). The user should also be able to export the statistics as PDF and CSV or directly into Google Spreadsheet (this is useful to work with internet traffic statistics of Google Analytics or Piwik). |
| | 54 | As well as the single data set actions, there will be batch processing options. The users can search, sort, and filter the data in this table view. In addition, s/he can select multiple data sets by clicking the checkboxes on the left. With this table view, the user should be able to see the overall statistics (and/or selected data sets), including the number of datasets, countries, data providers, the status, the number of records indexed and distributed. Those figures are extremely important for the performance indicators (for CLARIN board etc). The user should also be able to export the statistics as PDF and CSV or directly into Google Spreadsheet (this is useful to work with internet traffic statistics of Google Analytics or Piwik). |
| 64 | | |
| 65 | | |
| 66 | | |
| 67 | | |
| 68 | | |
| 69 | | |
| 70 | | |
| 71 | | |
| 72 | | |
| 73 | | |
| | 62 | * Import of Component Registry CMDI profiles (especially the recommended profiles which will be defined by the curation team soon) and selection of them to create metadata (MUST) |
| | 63 | * Export of a new CMDI profile defined by a data provider to the Component Registry, and save it in there (MUST) |
| | 64 | * Use of controlled CMDI components/elements (mandatory fields and occurrence etc), when defining/editing a profile (MUST) |
| | 65 | * Browsing CCR concepts and create a link, when defining/editing a profile (MUST) |
| | 66 | * Simulation of VLO display based on the defined profile (MUST) |
| | 67 | * Import and export of the XML Schema of a CMDI profile (SHOULD) |
| | 68 | * Use of controlled vocabularies (CLAVAS) when filling the metadata records (MUST) |
| | 69 | * Browse the data quality report based on the metadata created. If the data is not compliant, it will include warnings to explain the consequences. (SHOULD) |
| | 70 | * The MD authoring tool (including the enhanced functionalities above) will be modualised to be split from the local application, so that it can be re-used in other CLARIN data providers and centres, as well as the future possibility to be included in the CLARIN central environment (see Phase III). (COULD) |
| | 71 | * Link checker which lists broken links (COULD) |
| 102 | 100 | As an option, the Phase III could be implemented with Content Management System (CMS). Strictly speaking, it is not a part of normal VLO data workflow, however, it would be an important development plan, as it is certainly related to VLO record issues (eg. commenting, persistent identifiers, etc). The CMS may work especially well as a end-user management system. If VLO will require more user oriented services, the CMS may make the life of developers easier to manage registered users and user generated content such as tagging, commenting, bookmarking, saved search, uploading, forum, and other social network functionalities. It may also help to quickly build a multilingual website. For more details, please look at Implementing CMS for VLO. |
| 103 | 101 | |
| 105 | 103 | Local repository applications (COMEDI, Dspace) needs to be still operational, physically separated from the central environment, unless they want everything to be integrated in CLARIN. Only the MD authoring tool/module needs to be extracted and attached to the central environment where metadata storage also takes place. Maybe the CMDI data would be pushed to the local repository. >> Check how the CLARIN centre repositories work and modify the workflow accordingly. |
| 106 | 104 | There should be different levels of access permission to the VLO Dashboard. Although some members of CLARIN team have multiple roles, it is envisaged that there should be at least three different roles for the Dashboard: data providers/CLARIN centres who work on the data ingestion, VLO curators who work on the overall data ingestion of all the data providers, and the coordinators (Centre Registry, Component Registry, CLAVAS, CCR, Persistent Identifiers) who work on the maintenance of the corresponding services. It is recommended that the last two roles would become one, because their jobs are closely related. On top of the three roles, there should be admin accounts which can do everything with the central management, and are assigned to the lead VLO developer(s). >> Clarify the roles of the three stakeholders. |
| 107 | 105 | |
