This section will describe the DCSO creation process, as well as the methodology used to iteratively develop the DCSO. “The application profile as starting point” section offers a brief characterisation of the DCS application profile and describes the key requirements to be accomplished by the DCSO. “Initial version” section follows with a description of the DCSO origins by focusing on its initial version (2.0.2). The first stable version (3.0.2) is subsequently described in “First stable version” section. This version was a complete redesign of the DCSO, in an effort that took place during the RDA Hackathon on Machine-Actionable Data Management Plans in 2020 [8]. And finally, the latest (4.0.0) version of the DCSO is characterised in “Towards DCSO adoption by the DCS working group” section. It primarily reports on a number of pre-requisites which the first stable version did not meet, and needed to be addressed by the creation of a new version. The compliance with these pre-requisites and the resulting DCSO version 4.0.0 is part of an ongoing effort to have the DCSO adopted by the DCS working group as the official serialisation of the DCS application profile.

The application profile as starting point

To comply with the goal of establishing a set of universal terms to characterise a DMP, the DCS working group has strived to create an application profile. According to the definition, an application profile is a metadata design specification that uses a selection of terms from multiple metadata vocabularies, with added constraints, to meet application-specific requirementsFootnote 3. However, due to the fact that not all of the terms selected by the DCS working group are yet associated with established metadata vocabularies, the concept of application profile is not fully materialised, and therefore it is still an ongoing task. Regardless of this fact, and as part of the overall goal, there was the need to develop serialisations of the application profile. 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 DCS 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 [9]. 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 [10]. 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 [11, 12]. The usage of semantic technologies is therefore in compliance with the overarching requirements established by the concept of a 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. The following sections describe DCSO creation process, from its origins to its current iteration.

Initial version

The first attempt at creating a semantic-based serialisation of the DCS application profile took place in the spring of 2019. This version (2.0.2) was created to serve primarily as a proof of concept. Thus, the creation process was expedited and simplified by not fully abiding by the best practices in ontology engineering. This first version proved the viability of a semantic-based representation of the DCS application profile, however, it also failed in fully complying with the three key requirements that the DCSO concept should accomplish.

The DCS application profile references multiple terms and fields from standardised vocabularies (e.g., Data Catalog Vocabulary (DCAT)Footnote 4 and Dublin Core (DC)Footnote 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. In addition to this, the decision was made to represent multiplicity and type constraints through the usage of Web Ontology Language (OWL) constraints. Despite this being a viable means of constraint representation in ontology engineering, this solution would not allow for compliance validation of the data with the specification. As a result it was, for all effective purposes, impossible to enforce the use of controlled vocabularies, thus failing to comply with yet another key requirement.

Finally, there were also other issues in the pursuit of following the best practices in ontology engineering, such as using the digital repository links as the ontology namespace, opposed to assigning a persistent namespace via a Uniform Resource Identifier (URI).

First stable version

After this initial attempt, the community decided to develop a stable version that comply with the three key requirements for DCSO and follow the best practices in ontology engineering. The RDA Hackathon on Machine-Actionable Data Management Plans [8] 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 version 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 of the first version. As such, it should comply 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 Fig. 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. Due to the time constraints imposed by the duration of the hackathon the development process was divided into three iterative stages, resulting in the first stable DCSO version (3.0.2).

Fig. 1

The class structure of DCSO. a The class structure of the DCSO Core. b The class structure of the DCSX

First stage - DCSO core

The first stage focused solely on the development of DCSO core. The resulting ontology was serialised using the Terse Resource Description Framework (RDF) Triple syntax (Turtle)Footnote 6. 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 Fig. 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 cardinality being provided. The data properties followed a similar naming convention, with the distinction being that no prefix was added. However, some of the terms in the DCS application profile required compliance with controlled vocabularies. The solution to represent this select set of terms was to use object properties establishing a relation between classes of DCSO Core and classes of DCSX (see “Second stage - DCSX and validation layer” section). These object properties followed the same naming convention as those representing relations between concepts in the DCS application profile, e.g., dcso:hasCurrencyCode.

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. The DCS application profile specifies a set of three controlled vocabularies: (1) International Organization for Standardization (ISO) 639-3 [13], 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 [14], 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, 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 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 Fig. 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) [15]; and (3) the Shapes Constraint Language (SHACL) [16]. None of the three validation languages stands out in terms of dedicated usage in semantic data validation scenarios. We chose ShEx as this is the option used to validate schemas in Wikidata, providing already a big community of practice. WikidataFootnote 7 is an open knowledge base corresponding to structured data for Wikimedia sister projects, e.g., Wikepedia. In Wikidata, ShEx shapes are supported by the WikiProject SchemasFootnote 8, which includes access to examples and tutorials. 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 dcso:dmp class are shown in Fig. 2. An explained excerpt corresponding to these shapes is shown in Fig. 3.

Fig. 2

Diagram showing the shapes describing a DMP according to DCSO together with additional elements describing the associated project, cost, contributors and contacts. Validation related to Datasets is not included in this diagram

Fig. 3

Excerpt of a ShEx schema validating a DMP

There are different third-party tools to try and test ShEx schemas, for instance the RDfShape validation service supported by the Web Semantics Oviedo Research Group [17, 18] and ShEx2 Simple Online ValidatorFootnote 9 supported by ShEx Shape ExpressionsFootnote 10. Both of them provide an end-user interface where users can directly enter an instance to be validated as well as the corresponding ShEx schema. RDFShape supports direct input, by URL or by file while the ShEx2 Simple Online Validator only supports direct input. In Tabel 1, we describe the process step by step on how to use both the RDFShape and the ShEx2 Simple Online Validator to validate a DMP expressed using the DCSO (this process is also illustrated in Fig 4).

Fig. 4

Example of a validation using RDFShape validation service

Table 1 Steps for Validation DCSO instances using ShExThird stage - human readability and dissemination

By the third stage of the development process most of the functional requirements of DCSO had already been met. The objective was therefore to finalise the development process by addressing requirements that would facilitate its use and adoption. To that effect three tasks were considered: (1) the creation of human-readable descriptions in DCSO Core as well as DCSX, (2) the definition of a persistent namespace for DCSO, and (3) revising and expanding the existing documentation on the various artefacts that comprise DCSO. The creation of human-readable descriptions was done through the usage of rdfs:comment descriptions in all created classes, data properties and object properties. The lack of a stable URI to act as DCSO namepsace was one of the issues identified in the initial version of DCSO. To address that issue, and comply with the best practices of using URI namespace as a persistent identifiers, the team resorted to the W3IDFootnote 11 service of the W3C Permanent Identifier Community GroupFootnote 12, and registered the identifier ’https://w3id.org/dcso’. Finally, the existing documentation, that consisted mainly of markup files, was revised and deposited, along with DCSO, in a GitHub repository.

Towards DCSO adoption by the DCS working group

Upon the completion of the first stable version of DCSO (version 3.0.2), it was necessary to have it adopted by the DCS working group as the official serialisation of the DCS application profile. There were however a number of pre-requisites that needed to be met before any proposal for adoption could be formalised. This resulted in DCSO version 4.0.0, which is the latest version in existence. The pre-requisites were as follows:

Integration of DCSX namespaces into the Validation layer.

The use of DCSX as an extension of DCSO was rooted on the necessity of having the means to represent controlled vocabularies that applied to a specific set of DCS application profile terms (see “Second stage - DCSX and validation layer” section). However, in order to have a closer representation of the DCS application profile, where the terms covered by DCSX are represented with string values, it was decided that DCSX approach should be abandoned in favour of having these terms represented as data properties in DCSO Core. As a result, the controlled vocabularies were represented as constraints in the validation layer, so as to maintain the validation feature idealised in the original vision of DCSO.

Full coverage of the DCS application profile by DCSO.

A fundamental pre-requisite was to ensure that all of the DCS application profile terms were covered by a matching term in DCSO. The methodology adopted to comply with this pre-requisite was to perform a direct comparative analysis between the DCS application profile terms and the first stable version of DCSO (see “First stable version” section). As a result of this analysis, multiple discrepancies were found as it can be seen in Table 2. These discrepancies fell under two categories: Missing terms These DCS application profile terms were found not to have a corresponding match in DCSO. The most common case was the lack of representation for the various identifier terms that are associated with multiple DCS application profile concepts. In the first stable version of DCSO, there was an explicit attempt at defining a representation for the DCS application profile identifier concepts, through the dcso:Id class, its subclasses (e.g., dcso:ContactId, dcso:ContributorId, etc.), and the dcso:identifierType data property that had the dcso:Id class as its domain. However, there was no data property to represent the identifier term. The solution to this issue was the creation of the dcso:identifier data property, which had as domain the dcso:Id class. Three other additional data properties were also created, namely the dsco:created, dcso:modified, and dcso:type. Terms represented with the wrong type These discrepancies were a direct result of the decision to abandon DCSX as an approach to represent DCS application profile terms that specified a set of controlled vocabularies. The solution to this discrepancy was to change the representation type of DCSO terms from object property to data property. As a result the dcso:hasLanguage, dcso:hasGeoLocation, and dcso:hasCurrencyCode DCSO object properties were replaced by the dcso:language, dcso:geoLocation, and dcso:currencyCode DSCO data properties.

Table 2 Discrepancies found as a result of the comparative analysis between the DCS application profile and the first stable version of DCSO

Adoption of DCS application profile name and versioning scheme.

The current name and versions of DCSO are based on the development of the ontology, without any explicit connection with the reference DCS application profile. In order to ensure consistent DCS application profile usage across its various serialisations, the adoption of the ’maDMP’ term as the semantic serialisation name, in opposition to DCSO, and the adoption of the DCS application profile version number are under consideration. Such a decision would entail that new versions of the ontology would be released along with any revision of the DCS application profile.

Mechanisms for transformation between JSON and RDF representations of maDMP.

Due to the popularity of the JSON serialisation of DCS application profile, it is essential for the adoption of DCSO to provide mechanisms for transforming data between JSON and RDF serialisations. To this end, the availability of JavaScript Object Notation for Linked Data (JSON-LD) context to transform maDMP JSON to RDF serialisation and JSON-LD serialiser to transform maDMP RDF to JSON serialisation are important. We provide an initial approach to execute these functions and provides examples of the transformationsFootnote 13.

Exemplifications of funder profile as ontology extensions.

One of the main advantage of having RDF serialisation of maDMP is its capability to capture data model extensions without having to change the original DCS application profile. To this end, we plan in the future to provide a set of procedures to define such extension to the DCS application profile, and evaluate it to define funder profiles as ontology extensions.