FAIR service suite

1. Resource facilitation to scientific research

a. Interoperability Resource: Briefly describe the function of the Interoperability Resource

The FAIR Service suite aims to support data managers, data owners and other end-users in the process of making data FAIR. It offers services (software tools) and specifications to create, publish, find and annotate FAIR data. The suite has been built using existing (metadata) standards and open source software. The services have been designed, and continue to be updated, to follow the FAIR guiding principles and metrics. The services have been made available under an open source license and can be used as a reference implementation, or as components to support FAIR in other frameworks and platforms.

b. Scope statement: describe the scope , and the users of the resource. How is the Interoperability Resource positioned with respect to other similar Interoperability Resources ? Include the base URL and, if relevant, the introductory or “about” page URL.

The FAIR Service suite (https://github.com/DTL-FAIRData) offers specifications and reference implementations of solutions to be used by data infrastructure providers, data creators, users and annotators. To the best of our knowledge there are no similar Interoperability Resources that support a generic, domain-independent FAIR workflow. However, the FAIR Service suite does make use of, and can be further extended with, other (domain-specific) interoperability resources. The FAIR Data Point (meta)data publication solution can include references from different controlled vocabularies such as Schema.org, BioSchemas and EDAM. It can also make use of identifier mapping from Elixir identifier mapping services to facilitate matching between concepts using different identifiers. Since all of the elements of the suite make extensive use of Semantic Web technologies, services like the Ontology Lookup Service are very closely related.

Current registries offer precious information for different types of digital resources such as tools and training services and material. However, integrating the (meta)data from these repositories is still a challenge. By extending these registries with the FAIR Data Point behaviour, interfaces and metadata approach, they offer facilities to improve and ease interoperability workflows across resources. 

c. Resource url

https://www.dtls.nl/fair-data/find-fair-data-tools/

d. Inter-organisational recognition: does the Interoperability Resource have community recognition? (e.g. demonstrated through a collaboration, geographical diversity in the source of the submissions, international diversity of delivery partners and/or funders)

In line with the interoperability focus of ELIXIR-NL, DTL/ELIXIR-NL coordinates between internationally collaborating FAIR service developers and stakeholders such as from Plant breeding and rare disease communities. Continuous feedback in the RD community is organised in monthly cross-institutional ‘Rare Disease FAIR data Task Force’ conference calls. A demonstrator of federated queries with FDPs was co-developed with rare disease developers (https://goo.gl/g55751), presented with RD and Plant Breeding cases (https://goo.gl/1BVkkn), and the basis for rolling-out FDPs in the RD community. The European Genome-Phenome Archive (EGA) has previously participated in a FAIR hackathon to adopt the FDP and is currently working on a production-ready implementation. Private organisations such as DSM are also starting the adoption of the suite; a BYOD has been organised at DSM to evaluate the solutions to be used for their internal data. Similarly, government agencies such as the Dutch Health Authority conducted a pilot in which the FAIR Services suite has been used and the agency is now planning the widespread adoption in the Dutch healthcare environment. The early adoption in the Netherlands is in line with the Dutch focus on interoperability in ELIXIR, and is used to advocate FAIRification, for example by health care providers in European Reference Networks (https://goo.gl/Sxqhqr). Similarly, to address research questions proposed through a national laymen survey, the Dutch National Research Agenda supports use of the suite for federated analysis across networks of FDPs as a prototype of the ‘Personal Health Train’ paradigm (https://goo.gl/sFuPV2).

2. Community

a. Community impact: If applicable, provide documented evidence of community impact (e.g., publication citations, API calls, projects using the resource, etc.)

The FAIR service suite is used for FAIRification training, ‘Bring Your Own Data’ workshops (BYOD; https://goo.gl/z3Pgw3), and FAIRification under auspices of the cross-project ‘Rare Disease Data Linkage Plan’ (RDDLP). These are supported by ELIXIR, ELIXIR-EXCELERATE, RD-CONNECT, BBMRI-ADOPT, BBMRI-NL, FAIR-dICT, ODEX4All, and domain stakeholders. BYODs have been held in the plant domain, with oncology researchers (manuscript in preparation), and in the health/rare disease domain. The suite was used in FAIRification collaborations with Ghent and Wageningen University (Plant breeding), the LUMC (Neurology and Library), RadboudUMC (VASCERN), Newcastle University, the Istituto Superiori di Sanita (Rome), the Rizzoli hospital (Bologna), Imperial college London, and many RD patient representatives in BYODs. The demonstrator of the suite (1d) convinced rare disease stakeholders to invest in the RDDLP (https://goo.gl/DdDHa6). FAIR and the suite were presented to the leaders of European Reference Networks, leading to a role in the European Joint Program CO-FUND application for rare diseases and formation of a GO FAIR implementation network for RDs. Reference FDPs were implemented by MOLGENIS (BBMRI sample catalogue), the RD-Connect biobank-and-registry-finder (Austria/Italy), patient registry software OSSE (Germany), RDRF (Australia), and Castor-EDC (The Netherlands). The suite played a role in obtaining the status of a ‘recognized resource’ for the FAIR guiding principles by the International Rare Disease Research Consortium. The suite provides the basis for the Personal Genetic Locker in a Personal Health Train-related project (Dutch Digital Delta) and for a generic federated reasoning system in VWData (Dutch National Science Agenda).

b. Potential usage: Describe other systems that could use this candidate resource, but currently do not.

The FAIR service suite provides the specification of a set of behaviours that can be incorporated in existing applications/tools to support the FAIR guiding principles, particularly the suite’s middleware services: FAIR Data Search Engine, FAIR Data Point API and metadata (FDP), Graph Annotator. The FDP provides the default computer-access mechanism for FAIRified metadata (the intended role of the suite). The Metadata editor and the FAIRifier provide a reference implementation for the steps of a FAIRification process that can be integrated into other tools and software development platforms. The FDP is designed to be implemented during FAIRification ‘at source’ as a complement to any existing system. Tools such as the sample catalogue or the patient registry software system Castor-EDC provide the end-user experience. The FDP has been implemented in a few systems so far (see 1.d above), while the FAIRifier and Metadata editor feature in our default FAIRification procedure.

c. Outreach & support: Provide resource support publication(s)/user documentation(s) describing the Interoperability Resource (e.g. scientific journal publications, community preprints, resource user’s documentations etc.), resource dissemination plan (e.g. workshops, conference presentations), and other equal-opportunity research support (if applicable).

Information about FAIR and more, including the service suite, is available on the DTL/ELIXIR-NL web site (https://www.dtls.nl/fair-data/fair-tools-and-more/). Tutorials are available for the steps of FAIRification, including the use of the FAIR service suite and other supporting services (such as bioportal and OLS). These are applied in FAIR workshops, BYOD workshops, and training courses (e.g. https://goo.gl/zjqhy1). The FAIRification procedure and the suite are also introduced in webinars, a recording of the webinar that introduces the service suite is available via ELIXIR (https://goo.gl/iUk3eU). The webinar is also a standard feature of a BYOD, preceding the hands-on event by one or two months. BYODs typically appear on TESS. For each BYOD material is shared with the participants (to avoid privacy issues, this is open only to participants by default). For developers hackathons are organised from time to time. The first prototype FDP was developed at a hackathon following a rare disease BYOD. Up[dates on FAIR, BYODs, FAIRification, and the FAIR services are regularly presented at conferences and workshops, such as SWAT4HCLS (e.g. https://goo.gl/YTRZSk, https://goo.gl/GcPAiV), ISMB/ECCB (https://goo.gl/XwHVbM TT23), and stakeholder conferences. The FAIRification steps and access to the FAIR service suite are currently also being drafted for ELIXIR-EXCELERATE deliverable 8.2 and milestone 8.4.

d. Dependency of other resources: How is this resource critical to the user(s)? Do other resources depend on the resource described here to provide downstream service? Please list, or provide a link to a diagram.

The FAIR Service suite offers specifications and reference implementations for servicing creating and servicing FAIR data. When solution providers incorporate these specifications into their solutions, the suite becomes critical to their FAIR efforts. Examples are patient registry or biobank sample managers that apply the suite to make their data FAIR. 

Users are data stewards and ‘at source’ data access providers. The services are essential for them when conducting the FAIRification procedure that is offered for instance through the rare disease data linkage plan. The service suite is essential as source of reference components for federated FAIR data. FAIR requires data to be findable (FAIR Data point API+Metadata, FAIR data point metadata indexing), Accessible (Access mechanism of FAIR Data point, the FDP-based ‘myConsent’ component), Interoperable (FAIRifier), Reusable (FAIRifier). As such, the suite provides a practical reference for users for the possibility to make their data more FAIR.

The FAIRification workflow developed by DTL/ELIXIR-NL and its collaborators for BYODs and the RDDLP depends on the FAIR service suite. 

3. Quality of resource

a. Uptime: Average percentage uptime/month during the last 12 months, response time of the resource. In case of ontology/standards production, interval of update/release, adaptability of ontology design patterns to evolving data. Provide information where applicable: uptime of resource, software release cycle (please state week/month etc), update frequency.

The uptime of the implementations of the FAIR service suite depends on the local underlying servers. The FAIRifier component is a web based tool, an extension of OpenRefine with RDF plugin. The code of the reference designs, the specifications of the services, is on GitHub, i.e. the uptime for providing this reference as a service depends on GitHub. The specification of the behaviour of the FAIR service suit is in active development. The repositories are hosted on GitHub since 2015. Software increments automatically trigger the build and deployment of a Docker image on Docker Hub containing the latest changes. Releases are scheduled every 6 months. The release artifacts are published on GitHub, Maven Central, and Docker Hub.

b. Accessibility: what are resource retrieval mechanisms? Does the resource provide web-based user interface, application programmable interface (API), containers, and/or other channels? Please list resource access mechanism, provide URLs as applicable.

For the reference implementations and the specifications of the tools, they are accessible through their respective GitHub repositories. Once someone deploys the reference implementation or incorporates the specifications on their own existing applications, all the solutions of the suite offer web-based user interfaces, and REST APIs. The APIs provide community standard access through a Swagger API interface and RDF formatted responses. In the specific case of the FAIR Data Point, the data can be accessible through links to whatever accessibility infrastructure is used to store the data (see FDP specifications).

c. Maintenance quality: Is there a maintenance SOP or plan, reflecting sustainability and scalability? Does it align with guidelines for sustainable software development? Please include a resource commitment statement (description text or URL).

DTL/ELIXIR-NL coordinates maintenance and a sustainability model based on contributing organisations, developers, and stakeholders. Maintenance of implementations of the reference designs is relatively light-weight. The tools and specifications are available as documented open source on Github. Many are reference implementations of specific standards that have been developed in collaboration with others in the FAIR community. Through DTL learning, we work on outreach (e.g. BYOD events) that teaches others how to optimally apply the tools and the underlying standards in their own projects. The number of people who know the standards grows, facilitating scalability of the approach.

d. Support quality: Please list support mechanisms (e.g., point of contact, request ticketing, resource’s response time where a solution is identified, etc.), and methods to collect user feedback. If available, list tutorial documentations or tutorial materials and format, including linking on the ELIXIR’s Training Portal (TeSS) (or other training platforms) where applicable.

Contact information for the FAIR service suite and other FAIR developments can be found on the DTL web site (https://www.dtls.nl/fair-data/). For the FAIR service suite we have set up Atlassian Jira, for sprint management and internal communication (https://goo.gl/1LS1ZK), GitHub, for bug reporting and issue tracking (https://github.com/DTL-FAIRData). Direct support is available by organising collaboration projects between source data stewards and experienced FAIR data stewards close to FAIR service developers. A contribution of stakeholders is required. Communities furthermore organise support mechanisms, such as the telephone conferences in the context of the RDDLP (also advertised via ELIXIR mailing lists). In the rare disease community, FAIR is included in data quality recommendations (Kodra et al., under review) and by identifying 10 simple rules to become more FAIR (Jacobsen et al., manuscript in preparation). In the Netherlands, following a BYOD with oncology researchers, data stewards have organised a data steward network (facilitated by DTL/ELIXIR-NL). This now serves as paradigm for stimulating self-help networks in communities such as the rare disease community.

NB Support for quality FAIRification is also sought by organising collaboration with tool developers in order to incorporate the service suite to make existing tools FAIR data generating tools. At the LUMC, FAIR principles have been included as a requirement in tenders for data management tools, further incentivizing support for FAIR.

4. Legal framework, funding, and governance

a. Legal framework: What are the resource’s license/terms of use? Can the license facilitate Open Science? Please include the url for the license the resource uses.

All the specifications and reference implementations of the FAIR suite are offered with the MIT license, which is one of the open source licenses, allowing users to freely use, modify and derive work from them. We believe that this facilitates the adoption and adaptation of the solutions.
https://spdx.org/licenses/MIT

b. Privacy/Ethics policy: If applicable, is there a publicly available privacy policy in which use and security around personal data are described (e.g. the EU General Data Protection Regulation (GDPR), ELIXIR Ethics Policy, other relevant ELIXIR Policies)? Please include the url of the privacy/ethics policy, if applicable.

Not applicable in principle, because we provide reference designs and reference implementations. Compliance with ethical, legal, and societal constraints is a responsibility of the stakeholder deploying FAIR services or applying FAIRification tools ‘at source’. Nevertheless, the FDP is constructed to provide a transparent access mechanism. In a next phase of development, ‘GDPR compliance by design’ will be assessed for the FAIR services.

c. Funding & sustainability plan: List of funding sources supporting the resource, and sustainability plan.

Funding for further development of the tools is coming from various projects related to ELIXIR-NL and Rare Disease consortia, as well as collaborations through international standards organisations such as GO-FAIR. The tools are therefore mostly developed for the purpose of a specific project, but keeping general applicability in mind. ELIXIR-NL provides coordination for the various contributions and contributors. The fact that there is not a single source of funding limits the risk of all funding disappearing at the same time. Sustainability is also positively influenced by the fact that many developers from several different research groups are directly involved. ELIXIR-EXCELERATE is currently one of the contributors; other examples are currently the Dutch Digital Delta, the Dutch National Science Agenda, the LUMC, RadboudUMC/VASCERN, Rizzoli/BOND-ERN, ENDO-ERN, and previously RD-Connect, ELIXIR, BBMRI-NL, BBMRI-ADOPT, the LUMC, etcetera.

d. Governance: Describe the Resource’s QA/QC plan that guarantees similar quality governance to that of ELIXIR. Please link SAB members, if applicable.

As an ELIXIR-NL service, the FAIR tools are subject to regular review by the ELIXIR-NL strategy board, who, as described in the ELIXIR-NL Service Delivery Plan, work with the development team to optimize 5 criteria: Openness, FAIRness, Quality, Fit (to the node goals) and Plan (for the future). In addition, we coordinate every two weeks between the FAIR team and other ELIXIR-NL teams via DTL and there is also a weekly meeting between the ELIXIR-NL CTO and several members of the FAIR tools development team. Progress of the FAIR development team is reported in the ELIXIR Interoperability Platform meetings. Stakeholders organise their own mechanisms to monitor progress of FAIR service suite development and give feedback or identify domain-specific requirements. For example, the rare disease community organises a monthly ‘rare disease data linkage plan’ teleconference to address practical issues with FAIRification and the suite, and a bimonthly ‘rare disease cross-project FAIR data task force’ teleconference for higher-level knowledge exchange and expert advice on FAIRification.