dataesr/scientific-paragraphs-categorization huggingface dataset:
For simple actions, like typo correction, the QAR support role in the CMS can apply changes to the published QARs, whereas for more complex editing, the EQC team shall withdraw the QAR for updating. In this case, the EQC main contact restarts the QAR; • regular updates that require manual intervention to take into account possible novelties in the documentation, for instance. The regular update depends on the QAT field and on the dataset category: o the general rule is that it is usually done once a year manually and only for the QAT common fields; o variable definitions might improve over time, for instance. In this case, C3S warns the EQC team about the improvement and the non-common fields are updated by changing manually the tables containing these fields. The manual update of the tables triggers an automatic update of the QARs affected.
In the future, both the non-common fields tables and the Catalogue would benefit from automatic synchronisation preventing manual intervention; and o seasonal forecasts QARs need a more frequent manual update because new versions of the systems are upgraded frequently, often yearly. The update is done by restarting the common fields once every three months, focusing on a few QAT fields preselected (e. g. , operational status of the system); • regular updates of the assessments that do not require human intervention, that is, data checker and Toolbox compatibility software. This is particularly valuable for datasets that are regularly extended in time, such as seasonal forecasts and reanalysis (a. k. a. near real-time datasets). The appropriate parts of the QARs are automatically updated once a month, considering the last month of data available; and • additional independent assessment analyses.
This can happen during the in-depth cycle for non-common fields only. If new analyses are available (e. g. , inter-comparison assessments), the in-depth cycle restarts to update the appropriate QAR. It shall be noted that in case a new version of a dataset is available, a completely new QAR has to be produced. In this respect, a new dataset version is not considered a trigger for QAR updates, but the workflow follows the usual QAR production.
As far as the scientific assessment is concerned, this refers to scientific analyses of the physical content described by the dataset to check for its scientific soundness. Given the nature of this assessment, it is typically carried out by domain experts. Analyses may include uncertainty estimation, validation against reference datasets, and reproducibility of temporal/spatial patterns. Once clear what is considered as technical and what is considered as scientific, part of the assessments described in this paper are about documentation (availability and completeness) and file accessibility, archiving and compatibility within the service (i. e. , with the Toolbox). All these analyses are neither purely technical nor scientific because they are not about the files per se, but about the associated material needed to access and understand the dataset.
These analyses enter the group of stewardship assessment. It is true that stewardship regards all the aspects about distribution of the dataset and so potentially also technical and scientific assessments enter in this category. However, with stewardship assessments here we consider any assessment that guarantees accessibility and understandability of the dataset distributed, and so anything of relevance in dataset quality that is not associated with the data and metadata file content, such as documents accompanying the dataset describing how to use it. Typical examples regard the description of the algorithms or models used to produce and process the data, provision of the DOI and licence of use, grid description, verified network address to access the data, and information about the archiving procedures.
The goal is to ensure that the dataset is well documented, the processing chain is visible, and the data is readily obtainable and usable. At times, the assessments described above are accompanied by maturity assessment models. These are formal approaches to support compliance verification, usually defined in discrete stages to evaluate practices applied in organisations, services, or products. Maturity is meant as a desired or anticipated evolution from a more ad hoc approach to a more managed process  (Peng 2018 ). Datasets associated with high maturity are produced following best practices of the community and in a more managed fashion, increasing user trust in the data record provided. It should be noted that a low maturity rating does not necessarily imply a low scientific value for a dataset.
Correction of QAR content (e. g. , broken links), new dataset documentation is made available (e. g. , validation reports), a dataset is extended backward or forward in time (e. g. a new month of seasonal forecasts), additional independent analyses are performed (e. g. , inter-comparison with other datasets). In this case, the dataset version remains the same, but some information in the EQC scope is updated and the QAR needs maintenance. It corresponds to 'manage updates' in the steps described above.
To favor the development of data checker tools, common standards for data and metadata (formats and conventions) shall be enforced by C3S. Overall, climate services play a crucial role in disseminating relevant standards, in this case metadata standards (GFCS WMO 16 ). A service aiming at providing seamless products necessarily needs to disseminate data in a common format with files structured similarly and with sufficient metadata uniformly stored. This supports interoperability of data files and archives for automated data processing through improved and extended standards and metadata. As a first step, datasets served in NetCDF should comply with the CF 17 convention, but this covers only units, dimensions, and a few variables' metadata attributes. It is beneficial to ingest input data following a more constrained and controlled common vocabulary, covering variable naming, file names, grid descriptions, and global attributes.
ACKNOWLEDGEMENTS This study is based on work carried out in the C3S_512 contract funded by  Copernicus Programme  and operated by ECMWF on behalf of the  European Commission  (Service Contract number:  ECMWF/COPERNICUS720187C3S_512_BSC ). We would like to acknowledge the work of colleagues from several European institutions, the data providers and  C3S , who contributed to the development of the EQC framework as well as to the QAR production. We would also like to acknowledge the focus group users, who took time to review and provide valuable feedback on the QARs, QATs, minimum requirements and the CDS quality assessment tab. The authors are grateful to the anonymous reviewers for their constructive comments that have helped for the improvement of this paper.
Lacagnina et al. Data Science Journal DOI: 10. 5334/dsj-2022-010 5 https://www. ecmwf. int/sites/default/files/medialibrary/2017-10/System5_guide. pdf. 6 https://confluence. ecmwf. int/display/UER. 7 http://datastore. copernicus-climate. eu/documents/in-situ/GRUAN_product_traceability_chain_ GAIA_CLIM_Humidity. pdf. 8 https://gcos. wmo. int/en/. 9 https://gmd. copernicus. org/articles/7/1297/2014/.
Correction of QAR content (e. g. , broken links), new dataset documentation is made available (e. g. , validation reports), a dataset is extended backward or forward in time (e. g. a new month of seasonal forecasts), additional independent analyses are performed (e. g. , inter-comparison with other datasets). In this case, the dataset version remains the same, but some information in the EQC scope is updated and the QAR needs maintenance. It corresponds to 'manage updates' in the steps described above. • Output: Lacagnina et al. o QARs released to support the C3S governance board while deciding whether to Data Science Journal DOI: 10. 5334/dsj-2022-010 publish or reject a CDS dataset • End: o C3S governance board approves/rejects the QAR in the CMS Figure 3 Sketch showing the • Manage updates: basic roles, their interactions, o caused by issues identified by users, indications by providers, new data available from operational datasets extending over time, regular review of new dataset and their responsibilities during the QAR production within the CMS.
Note the documentation, additional independent assessment analyses iteration loop between roles The trigger for a new assessment is associated with two main causes: to allow refinement of the content. The sketch gives a • A completely new dataset appears or a new version of an already existing dataset is made available (e. g. ERA5 reanalysis replaced by ERA6). As a consequence, new QARs are grasp of the more complex workflow shown in the next figures. produced. It corresponds to 'start' in the steps described above. •.
Lacagnina et al. Data Science Journal DOI: 10. 5334/dsj-2022-010 13 https://www. temis. nl/airpollution/absaai/. 14 https://climate. copernicus. eu/charts/c3s_seasonal/. 15 https://confluence. ecmwf. int/display/ECC/WMO%3D14+element+table.
Examples of domain-specific conventions are CMIP 18 and ESA-CCI. 19For the latter, C3S and ESA are coordinating to homogenise their metadata standards for satellite observation datasets. In addition, the ACDD 20 conventions cover the global attributes Lacagnina et al. Data Science Journal DOI: 10. 5334/dsj-2022-010 16 https://gfcs. wmo. int/. 17http://cfconventions. org/cf-conventions/v1. 6. 0/cf-conventions. html. 18https://pcmdi. llnl. gov/mips/cmip5/requirements. html. 19https://climate. esa. int/sites/default/files/CCIDataStandards_v2-1_CCI-PRGM-EOPS-TN-13-0009. pdf. 20 https://wiki. esipfed. org/Attribute_Convention_for_Data_Discovery_1-3.
The scoring scheme would not aim at determining whether one dataset is better than another comparable dataset in an absolute sense, but only Lacagnina et al. Data Science Journal DOI: 10. 5334/dsj-2022-010 21 https://gcos. wmo. int/en/essential-climate-variables/surface-temperature. 22 https://github. com/PCMDI/cmip6-cmor-tables/blob/master/Tables/CMIP6_3hr. json.
Fifth/Sixth generation of ECMWF atmospheric Re-Analyses ESA-CCI -European Space Agency Climate Change Initiative ESMValTool -Earth System Model Evaluation Tool FAIR -Findable, Accessible, Interoperable, Reusable ERA5/6 - Lacagnina et al. 22 Data Science Journal DOI: 10. 5334/dsj-2022-010 ACDD -Attribute Convention for Data Discovery ATBD -Algorithm Theoretical Baseline Document C3S -Copernicus Climate Change Service CAMS -Copernicus Atmosphere Monitoring Service CDS -Climate Data Store CF -Climate and Forecast CMEMS -Copernicus Marine Environment Monitoring Service CMIP -Coupled Model Intercomparison Project CMS -Content Management System CORDEX -COordinated Regional climate Downscaling EXperiment CORE-CLIMAX -COordinating Earth observation data validation for RE-analysis for CLIMAte ServiceS DOI -Digital Object Identifier ECMWF -European Centre for Medium-Range Weather Forecasts ECV -Essential Climate Variables EQC -Evaluation and Quality Control.
The concept of Data Management Plan (DMP) has emerged as a fundamental tool to help researchers through the systematical management of data. The Research Data Alliance DMP Common Standard (DCS) working group developed a core set of universal concepts characterising a DMP in the pursuit of producing a DMP as a machine-actionable information artefact, i. e. ,machine-actionable Data Management Plan (maDMP). The technology-agnostic approach of the current maDMP specification: (i) does not explicitly link to related data models or ontologies, (ii) has no standardised way to describe controlled vocabularies, and (iii) is extensible, but has no clear mechanism to distinguish between the core specification and its extensions. Currently, the maDMP specification provides a JSON serialisation and schema to operationalise the approach.
Introduction With the continuous growing of research data and the ultimate goal of sharing FAIR data, researchers face the challenge of systematically managing that data and its corresponding metadata. Data Management Plans (DMP) make it easier for researchers to respond to this challenge. The DMP, produced as a text-based document, describes techniques, methods and policies on how data is produced and managed throughout its life cycle  [1]. Additionally, it establishes associations between data management activities and actors responsible for their execution  [2]. The concept of DMP as a document has evolved towards that of the machineactionable DMP (maDMP). The implementation of maDMPs will allow to overcome some of the identified obstacles linked to the current text-based representation of DMPs  [3].
This paper reports on the creation of the DMP Common Standard ontology (DCSO), a community effort towards the creation of an ontology serialisation of the DCS application profile. The creation of DCSO aimed to address the aforementioned challenges with the current DCS terms and existing serialisations. The remaining of this paper details the resulting ontology and its components, and is organised as follows. Section 2 offers a report on the conceptualisation and creation process of DCSO. In particular, it addresses the requirements and methodology followed to achieve this goal. Section 2. 2 describes the first attempt at creating a semantic-based serialisation of the DCS application profile. Section 2. 3 presents the first stable version of DCSO and its three stages of development. Section 3 presents the adoption of DCSO in the Data Stewardship Wizard (DSW) DMP creation tool, as a use case for DCSO.
These would allow any tools or systems engaged in research data processing, not only to consume data but also to add data to maDMPs, thus automating data interchange. The DCSO was created as a community initiative with the overall goal of expanding the set of existing serialisations of the DCS application profile, by adding a semantic-based serialisation. With DCSO, information from the application profile is represented using semantic technologies, specifically ontologies, which allow for the representation of a shared conceptualisation of knowledge through the usage of formal semantics  [11]. One of the key characteristics behind the selection of ontologies was their extensibility, as concepts can be matched or relations established between ontologies covering distinct domains. This characteristic enforces the suitability of ontologies as a means to represent the DCS application profile, for it is also designed with modularity in mind.
Additionally, ontologies enable reasoning, and thereby knowledge inference from the information explicitly represented  [12]. In spite of the traditional perception of ontologies as highly formal means of knowledge representation, their suitability for creation of Linked Open Data (LOD) has been proven  [13, 14]. The usage of semantic technologies is therefore in compliance with the overarching requirements established by the concept of maDMP. In the process of creating a semantic-based serialisation of the DCS application profile, three key requirements that DCSO should accomplish were identified. These are: (1) DCSO should allow for ontologies referenced in the DCS application profile to be integrated through the reuse of its terms; (2) DCSO should allow and enforce the usage of controlled vocabularies; and (3) DCSO should be extendable, so as to comply with any future extensions of the DCS application profile.
g. , Data Catalog Vocabulary (DCAT) [4] and Dublin Core (DC) [5] ). In this initial version of DCSO, all of the terms and fields were redefined. This was contrary to the best practice of reusing terms through the integration of existing domain ontologies. In spite of having all terms and fields represented, the lack of reuse of referenced terms and fields meant that this version of DCSO would not meet one of the key requirements for its development. In order to simplify the creation process, it was decided that a set of custom literal datatypes was to be created to accommodate the usage of the controlled vocabularies specified in the DCS application profile. This solution is in breach of the best practices of ontology engineering, and albeit users of DCSO could potentially use controlled vocabularies, this was not a scalable solution moving forward.
First Stable Version With the concept of having a semantic representation of the DCS application profile being proven viable by the first version of DCSO. It was therefore necessary to create a stable version, that would not only comply with the three key requirements for DCSO, but also follow the best practices in ontology engineering. The RDA Hackathon on Machine-Actionable Data Management Plans  [15]  proved to be the perfect opportunity to tackle this objective. The motivation for the Hackathon was to promote the usage of the maDMP concept by the research community. Participants were encouraged to submit topics and assemble teams that would collaborate for two days to tackle the submitted topics. In line with the motivation of the hackathon, it was decided that the creation of a stable of DCSO should be one of the proposed topics in the hackathon.
The new version of DCSO was to be a fresh start, that would benefit from the experience acquired during the creation the first version. As such, it should comply [4] Data Catalog Vocabulary -Version 2. https://www. w3. org/TR/vocab-dcat-2/. Accessed 09 Mar 2022. [5] The Dublin Core specification. https://www. dublincore. org/specifications/dublin-core/ dcmi-terms/. Accessed 09 Mar 2022. with all of the previously identified key requirements, whilst following the best practices in ontology engineering. In order to achieve this objective, it was decided that DCSO was to be organised into DCSO Core and DCSO Extensions (DCSX) (as can be seen in Figure  1 ). The first would be a representation of the DCS application profile, which would reuse terms from a selection of domain ontologies, whilst the later would support DCSO core by providing an aggregation of all the controlled vocabularies referenced in the DCS application profile.
First Stage -DCSO Core The first stage focused solely on the development DCSO core. The resulting ontology was expressed using the Terse Resource Description Framework (RDF) Triple syntax (Turtle) [6] , and reused classes and terms from imported domain ontologies. In DCSO Core all relations between DCS application profile concepts are represented as object properties, whilst data properties are used to represent DCS application profile terms, as can be seen in Figure  1a. The object properties are named after the class to which they pertain, using a CamelCase notation, and using the prefix 'has'. This solution solved an existing issue with the DCS application profile, where relations between concepts were left unnamed, with only information regarding their multiplicity being provided. The data properties followed a similar naming convention, with the distinction being that no prefix was added.
Second Stage -DCSX and Validation Layer The second stage had two objectives: (1) The incorporation of controlled vocabularies in DCSO; and (2) the creation of a constraint validation layer. This led to the development of DCSX and DCSO constraints validation layer, respectively. The DCS application profile specifies a set of three controlled vocabularies: (1) ISO 639-3  [16] , whose language codes are used to represent the language in which multiple concepts (e. g. , dataset, distribution, and metadata) are expressed; (2) ISO 3166-1, whose country codes are used to describe the geographical location of where data is hosted; and (3) ISO 4217  [17] , whose currency codes are used to identify the currency in which costs associated with data management are being described in the DMP. In the initial version of DCSO controlled vocabularies were represented using custom literal datatypes.
This solution originally implemented solely as a means of simplifying the creation process, was inadequate for a stable version. The hackathon team opted to resort to the creation of a separate ontology that would serve as an extension to DCSO, and where controlled vocabularies could be represented by classes [6] The Turtle syntax. https://www. w3. org/TR/turtle/. Accessed 09 Mar 2022. and their terms as individual instances of those classes. The result was the creation of DCSX, and its classes (dcsx:Language, dcsx:Country and dcsx:CurrencyCode), each associated with a set of individual instances, as can be seen in Figure  1b. Additionally, the necessary object properties required to establish relations to classes belonging to DCSO Core were also created. The motivation for the creation of DCSO constraints validation layer, was to provide users with the means to assess the compliance of their maDMPs with the DCS application profile, whilst also promoting data completeness and consistency.
In the initial version of DCSO constraints were represented using the OWL language, however due to the limitations of OWL it was impossible to validate the compliance of individual DMP instances with DCSO. A solution to this issue was to select a constraint representation language that allowed for compliance validation. Three validation languages are generally regarded as most prevalent: (1) JSON schema; (2) Shape Expression (ShEx)  [18] ; and the Shapes Constraint Language (SHACL)  [19]. None of the three validation languages stands out in terms of dedicated usage in semantic data validation scenarios. As such, the ultimate selection of ShEx as the validation language was not solely based on its adequacy for the task at hand but also on the expertise and familiarity of the team members with the ShEx language.
ShEx is a data modelling language used to describe RDF graphs, Sets of individual ShEx expressions are collected into a ShEx schema, defining conditions on element relations, their cardinality (e. g. , one or more, zero or more, zero or one, etc. ) and their existence (e. g. , mandatory or optional). DCSO constraint validation layer comprises two distinct ShEx schemas, that follow the constraints established in the DCS application profile. The first schema named 'dcso-dmp', focuses on the validation of the DMP document. As such, it comprises of elements targeting identifiers, contacts, contributors, costs and projects. The second schema named 'dcso-dataset', focuses solely on the validation of the datasets referenced in the DMP document. This modularity improves readability (for humans) and makes extensions easier to create.
Within a schema, one shape per DCSO class is provided with and initial validation of data properties (e. g. , dates or strings) and then a validation of relations expressed by object properties. Validation elements related to the dmp DCSO class is shown in Figure  2. An explained excerpt corresponding to these shapes is shown in Figure  3. There are different options to try and test ShEx schemas, here we use the RDFShape validation service supported by the Web Semantics Oviedo Research Group  [20, 21] ; an early version of this service is also used in the Validating RDF Data online book  [22]. RDFShape provides an end-user interface where users can directly enter an instance to be validated (either as direct input, by URL or by file) as well as the corresponding ShEx schema. Here we describe the process step by step using the ShEx schema for DMPs, also illustrated in Figure  4.