Evaluating FAIR Digital Object as a distributed object system

This manuscript (permalink) was automatically generated from stain/2022-fdo-paper@64d3fd6 on January 24, 2023.



TODO: Rewrite from notes below to actual abstract.

FAIR Digital Object is an emerging concept from EOSC. This is important. Worthwile to understand how semantic technologies and semantic web vision relate to this emerging landscape. Here we do this systematically by comparing the technologies introduced under the banner of FAIR digital Object and Semantic Web.

What is the message of this paper?

  1. These are the overlaps
  2. This is what FDO is requiring but not commonly deployed
  3. DOI indirection is emphasized. It is used in SW, but the idea for stability. Embrace it!
  4. PROV had the idea of using indirection to help us represent provenance of objects - digital twin
  5. Lessons for Semantic Web community. What is missing in FDO and in SW.
  6. Contribution is also about thinking about Semantic Web as different architectural levels. Interoperability level, Middleware level. Governance level. Data level.
  7. Go back to the old SW layer cake. Explains why we picked these frameworks.
  8. Lessons for SW: Parts of the stack that is less. FDO contributions.

Semantic Web in a way already implements FDO, but other things that SW perhaps should drop in emphasis to better support FDO and FAIR vision. More about indirection, visibility.

Have all the ingredients, but not cooking properly.

Systematic through frameworks.

Emerging stack - how does it compare to what we’ve already done? What are the implications for our design and research? What new technology is needed?

1 Introduction

The FAIR principles (Wilkinson et al., 2016) encourage sharing of scientific data with machine-readable metadata and the use of interoperable formats, and are being adapted by a wide range of research infrastructures. They have been widely recognised by the research community and policy makers as a goal to strive for. In particular, the European Open Science Cloud (EOSC) has promoted adaptation of FAIR data sharing of data resources across electronic research infrastructures (Mons et al., 2017). The EOSC Interoperability Framework (Corcho et al., 2021) puts particular emphasis on how interoperability can be achieved technically, semantically, organisationally, and legally – laying out a vision of how data, publication, software and services can work together to form an ecosystem of rich digital objects.

Specifically, the EOSC Interoperability framework highlights the emerging FAIR Digital Object (Schultes & Wittenburg, 2019) (FDO) concept as a possible foundation for building a semantically interoperable ecosystem to fully realise the FAIR principles beyond individual repositories and infrastructures. The FDO approach has great potential, as it proposes strong requirements for identifiers, types, access and formalises interactive operations on objects.

In other discourse, Linked Data (Bizer, Heath & Berners-Lee, 2009) has been seen as an established set of principles based on Semantic Web technologies that can achieve the vision of the FAIR principles (Bonino Da Silva Santos et al., 2016; Hasnain & Rebholz-Schuhmann, 2018). Yet regular researchers and developers of emerging platforms for computation and data management are reluctant to adapt such a FAIR Linked Data approach fully (Verborgh & Vander Sande, 2020), opting instead for custom in-house models and JSON-derived formats from RESTful Web services (Meroño-Peñuela, Lisena & Martínez-Ortiz, 2021a; Neumann, Laranjeiro & Bernardino, 2021). While such focus on simplicity gives rapid development and highly specialised services, it raises wider concerns on interoperability (Turcoane, 2014; Wilkinson et al., 2022).

One challenge that may, perhaps counter-intuitively, steer developers towards a not-invented-here mentality (Stefi, 2015; Stefi & Hess, 2015) when exposing their data on the Web is the heterogeneity and apparent complexity of Semantic Web approaches themselves (Meroño-Peñuela, Lisena & Martínez-Ortiz, 2021b).

These approaches, thus, form two of the major avenues for allowing developers and the wider research community to achieve the goal of FAIR data. Given their importance, in this article, we aim to examine the relationships between FAIR and FAIR Digital Objects, contrasted with Linked Data and the Web in general.

Concretely, the contribution of this paper is a systematic comparison between FDO and Linked Data using 5 different conceptual frameworks that capture different perspectives on interoperability and readiness for implementation.

2 Background and related work

In the following, we discuss the related work with respect to FAIR Digital Objects and Linked Data. For the later, we do so by looking through the lens of its development overtime.

2.1 FAIR Digital Object

2.1.1 Next steps for FDO

The FAIR Digital Object Forum (‘FAIR Digital Objects Forum |’) working groups are preparing more detailed requirement documents setting out the path for realising FDOs, named FDO Recommendations. As of 2023-01-05, these documents are in draft stages in Google Docs for internal review and have not yet formally been made public. As these drafts clarify the future aims and focus of FAIR Digital Objects, we provide their brief summaries below:

FAIR Digital Object Overview and Specifications (Anders et al., 2022a) is a comprehensive overview of FAIR Digital Object specifications listed below. It serves as a primer that introduces FDO concepts and the remaining documents.

The FDO Forum Document Standards (Weiland et al., 2022b) documents the recommendation process within the forum, starting at Working Draft (WD) status within the closed working group and later within the open forum, then Proposed Recommendation (PR) published for public review, finalised as FDO Forum Recommendation (REC) following any revisions. In addition, the forum may choose to endorse existing third-party notes and specifications.

The FDO Requirement Specifications (Strawn et al., 2022) is an update of (Bonino et al., 2019) as the foundational definition of FDO. This sets the criteria for classifying an digital entity as a FAIR Digital Object, allowing for multiple implementations. The requirements shown in Table 3 are largely equivalent, but in this specification clarified with references to other FDO documents.

The Machine actionability (Weiland et al., 2022a) sets out to define what is meant by machine actionability for FDOs. Machine readable is defined as elements of bit-sequences defined by structural specification, machine interpretable elements that can be identified and related with semantic artefacts, while machine actionable are elements with a type with operations in a symbolic grammar. The document largely describes requirements for resolving an FDO to metadata, and how types should be related to possible operations.

Configuration Types (Lannom et al., 2022a) classifies different granularities for organising FDOs in terms of PIDs, PID Records, Metadata and bit sequences, e.g. as a single FDO or several daisy-chained FDOs. Different patterns used by current DOIP deployments are considered, as well as FAIR Signposting (Van de Sompel et al., 2022)

PID Profiles & Attributes (Anders et al., 2022b) specifies that PIDs must be formally associated with a PID Profile, a separate FDO that defines attributes required and recommended by FDOs following said profile. This forms the kernel attributes, building on recommendations from RDA’s PID Information Types working group (Weigel et al., 2018). This document makes a clear distinction between a minimal set of attributes needed for PID resolution and FDO navigation, which needs to be part of the PID Record, compared with a richer set of more specific attributes as part of the metadata for an FDO, possibly represented as a separate FDO.

Kernel Attributes & Metadata (Working Group & Working Group, 2022) elaborates on categories of FDO Mandatory, FDO Optional and Community Attributes, recommending kernel attributes like dateCreated, ScientificDomain, PersistencePolicy, digitalObjectMutability, etc. This document expands on RDA Recommendation on PID Kernel Information (Weigel et al., 2018). It is worth noting that both documents are relatively abstract and do not establish PIDs or namespaces for the kernel attributes.

Granularity, Versioning, Mutability (Working Group, 2022b) considers how granularity decisions for forming FDOs must be agreed by different communities depending on their pragmatic usage requirements. The affect on versioning, mutability and changes to PIDs are considered, based on use cases and existing PID practices.

DOIP Endorsement Request (Working Group, 2022a) is an endorsement of the DOIP v2.0 (Foundation, 2018) specification as a potential FDO implementation, as it has been applied by several institutions (Wittenburg et al., 2022). The document proposes that DOIP shall be assessed for completeness against FDO – in this initial draft this is justified as “we can state that DOIP is compliant with the FDO specification documents in process” (the documents listed above).

Upload of FDO (Blanchi et al., 2022a) illustrates the operations for uploading an FDO to a repository, what checks it should do (for instance conformance with the PID Profile, if PIDs resolve). ResourceSync (‘ResourceSync Framework Specification - Table of Contents’) is suggested as one type of service to list FDOs. This document highlights potential practices by repositories and their clients, but adds no particular requirements (e.g. how should failed upload checks be reported?).

Typing FAIR Digital Objects (Lannom et al., 2022b) defines what type means for FDOs, primarily to enable machine actionability and to define an FDO’s purpose. This document lays out requirements for how FDO Types should themselves be specified as FDOs, and how an FDO Type Framework allows organising and locating types. Operations applicable to an FDO is not predefined for a type, however operations naturally will require certain FDO types to work. How to define such FDO operations is not specified.

Implementation of Attributes, Types, Profiles and Registries (Blanchi et al., 2022b) details how to establish FDO registries for types and FDO profiles, with their association with PID systems. This document suggest policies and governance structures, together with guidelines for implementations, but without mandating any explicit technology choices. Differences in use of attributes are examplified using FDO PIDs for scientific instruments, and the proto-FDO approach of DARIAH-DE (Schwardmann & Kálmán, 2022).

It is worth pointing out at that, except for the DOIP endorsement, all of these documents are abstract, in the sense that they permit any technical implementation of FDO, if used according to the recommendations.

The concept of FAIR Digital Objects (Schultes & Wittenburg, 2019) has been introduced as way to expose research data as active objects that conform to the FAIR principles (Wilkinson et al., 2016). This builds on the Digital Object (DO) concept (Kahn & Wilensky, 2006), first introduced in 1995 (Kahn & Wilensky, 1995) as a system of repositories containing digital objects identified by handles and described by metadata which may have references to other handles. DO was the inspiration for the ITU X.1255 framework (‘X.1255 : Framework for discovery of identity management information’) which introduced an abstract Digital Entity Interface Protocol for managing such objects programmatically, first realised by the Digital Object Interface Protocol (DOIP) v1 (‘Digital Object Interface Protocol Version 1.0 | DONA Foundation’).

In brief, the structure of a FAIR Digital Object (FDO) is to, given a persistent identifier (PID) such as a DOI, resolve to a PID Record that gives the object a type along with a mechanism to retrieve its bit sequences, metadata and references to further programmatic operations. The type of an FDO (itself an FDO) defines attributes to semantically describe and relate such FDOs to other concepts (typically other FDOs referenced by PIDs). The premise of systematically building an ecosystem of such digital objects is to give researchers a way to organise complex digital entities, associated with identifiers, metadata, and supporting automated processing (Wittenburg et al., 2019).

Recently, FDOs have been recognised by the European Open Science Cloud (EOSC) as a suggested part of its Interoperability Framework (Corcho et al., 2021), in particular for deploying active and interoperable FAIR resources that are machine actionable. Development of the FDO concept continued within Research Data Alliance (RDA) groups and EOSC projects like GO-FAIR, concluding with a set of guidelines for implementing FDO (Bonino et al., 2019). The FAIR Digital Objects Forum has since taken over the maturing of FDO through focused working groups which have currently drafted several more detailed specification documents (see section 2.1.1).

2.1.2 FDO approaches

FDO is an evolving concept. A set of FDO Demonstrators (Wittenburg et al., 2022) highlight how current adapters are approaching implementations of FDO from different angles:

From this it becomes apparent that there is a potentially large overlap between the goals and approaches of FAIR Digital Objects and Linked Data, which we’ll cover in the section 2.2.

2.2 From the Semantic Web to Linked Data

In order to describe Linked Data as it is used today, we’ll start with an (opinionated) description of the evolution of its foundation, the Semantic Web.

2.2.1 A brief history of the Semantic Web

The Semantic Web was developed as a vision by Tim Berners-Lee (Berners-Lee & Fischetti, 1999), at a time the Web had been widely established for information exchange, as a global set of hypermedia documents that eare cross-related using universal links in the form of URLs. The foundations of the Web (e.g. URLs, HTTP, SSL/TLS, HTML, CSS, ECMAScript/JavaScript, media types) were standardised by W3C, Ecma, IETF and later WHATWG. The goal of Semantic Web was to further develop the machine-readable aspects of the Web, in particular adding meaning (or semantics) to not just the link relations, but also to the resources that the URLs identified, and for machines thus being able to meaningfully navigate across such resources, e.g. to answer a particular query.

Through W3C, the Semantic Web was realised with the Resource Description Framework (RDF) (‘RDF 1.1 Primer’) that used triples of subject-predicate-object statements, with its initial serialisation format (‘Resource Description Framework (RDF) Model and Syntax Specification’) being RDF/XML (XML was at the time seen as a natural data-focused evolution from the document-centric SGML and HTML).

While triple-based knowledge representations were not new (Stanczyk, 1987), the main innovation of RDF was the use of global identifiers in the form of URIs2 as the primary identifier of the subject (what the statement is about), predicate (relation/attribute of the subject) and object (what is pointed to). By using URIs not just for documents3, the Semantic Web builds a self-described system of types and properties, the meaning of a relation can be resolved by following its hyperlink to the definition within a vocabulary.

The early days of the Semantic Web saw fairly lightweight approaches with the establishment of vocabularies such as FOAF (to describe people and their affiliations) and Dublin Core (for bibliographic data). Vocabularies themselves were formalised using RDFS or simply as human-readable HTML web pages defining each term. The main approach of this Web of Data was that a URI identified a resource (e.g. an author) had a HTML representation for human readers, along with a RDF representation for machine-readable data of the same resource. By using content negotiation in HTTP, the same identifier could be used in both views, avoiding index.html vs index.rdf exposure in the URLs. The concept of namespaces gave a way to give a group of RDF resources with the same URI base from a Semantic Web-aware service a common prefix, avoiding repeated long URLs.

The mid-2000s saw a large academic interest and growth of the Semantic Web, with the development of more formal representation system for ontologies, such as OWL, allowing complex class hierarchies and logic inference rules following open world paradigm (e.g. a ex:Parent is equivalent to a subclass of foaf:Person which must ex:hasChild at least one foaf:Person, then if we know :Alice a ex:Parent we can infer :Alice ex:hasChild [a foaf:Person] even if we don’t know who that child is). More human-readable syntaxes of RDF such as Turtle (shown in this paragraph) evolved at this time, and conferences such as ISWC (Horrocks & Hendler, 2002) gained traction, with a large interest in knowledge representation and logic systems based on Semantic Web technologies evolving at the same time.

Established Semantic Web services and standards include SPARQL (‘SPARQL 1.1 Overview’) (pattern-based triple queries), named graphs (triples expanded to quads to indicate statement source or represent conflicting views), triple/quad stores (graph databases such as OpenLink Virtuoso, GraphDB, 4Store), mature RDF libraries (including Redland RDF, Apache Jena, Eclipse RDF4J, RDFLib, RDF.rb, rdflib.js), and numerous graph visualisation (many of which struggle with usability for more than 20 nodes).

The creation of RDF-based knowledge graphs grew particularly in fields like bioinformatics, e.g. for describing genomes and proteins (Goble & Stevens, 2008; Williams et al., 2012). In theory, the use of RDF by the life sciences would enable interoperability between the many data repositories and support combined views of the many aspects of bio-entities – however in practice most institutions ended up making their own ontologies and identifiers, for what to the untrained eye would mean roughly the same. One can argue that the toll of adding the semantic logic system of rich ontologies meant that small, but fundamental, differences in opinion (e.g. should a gene identifier signify which protein a DNA sequence would make, or just the particular DNA sequence letters, or those letters as they appear in a particular position on a human chromosome?) lead to large differences in representational granularity, and thus needed different identifiers.

Facing these challenges, thanks to the use of universal identifiers in the form of URIs, mappings could retrospectively be developed not just between resources, but also across vocabularies. Such mappings can be expressed themselves using lightweight and flexible RDF vocabularies such as SKOS (‘SKOS Simple Knowledge Organization System Primer’) (e.g. dct:title skos:closeMatch schema:name to indicate near equivalence of two properties). Automated ontology mappings have identified large potential overlaps (e.g. 372 definitions of Person) (Hu et al., 2011) .

The move towards open science data sharing practices from the late 2000s encouraged knowledge providers to distribute collections of RDF descriptions as downloadable datasets 4, so that their clients can avoid thousands of HTTP requests for individual resources. This enabled local processing, mapping and data integration across datasets (e.g. Open PHACTS (Groth et al., 2014)), rather than relying on the providers’ RDF and SPARQL endpoints (which could become overloaded when handling many concurrent, complex queries).

With these trends, an emerging problem was that adopters of the Semantic Web primarily utillised it as a set of graph technologies, with little consideration to existing Web resources. This meant that links stayed mainly within a single information system, with little URI reuse even with large term overlaps (Kamdar, Tudorache & Musen, 2017). Just like link rot affect regular Web pages and their citations from scholarly communication (Klein et al., 2014), for a majority of described RDF resources in the Linked Open Data (LOD) Cloud’s gathering of more than thousand datasets, unfortunately they do not actually link to (still) downloadable (dereferenceable) Linked Data (Polleres et al., 2020, p. handle:20.500.11811/7183). Another challenge facing potential adopters is the plethora of choices, not just to navigate, understand and select to reuse the many possible vocabularies and ontologies (Carriero et al., 2020) , but also technological choices on RDF serialisation (at least 7 formats), type system (RDFS (‘RDF Schema 1.1’), OWL (‘OWL 2 Web Ontology Language Document Overview (Second Edition)’), OBO (Tirmizi et al., 2011), SKOS (‘SKOS Simple Knowledge Organization System Primer’)), hash vs slash, HTTP status codes and PID redirection strategies (Sauermann, Cyganiak & Völkel, 2011).

2.2.2 Linked Data: Rebuilding the Web of Data

The Linked Data concept (Bizer, Heath & Berners-Lee, 2009) was kickstarted as a set of best practices (‘Linked Data - Design Issues’) to bring the Web aspect back into focus. Crucially to Linked Data is the reuse of existing URIs, rather than making new identifiers. This means a loosening of the semantic restrictions previously applied, and an emphasis on building navigable data resources, rather than elaborate graph representations.

Vocabularies like schema.org evolved not long after, intended for lightweight semantic markup of existing Web pages, primarily to improve search engines’ understanding of types and embedded data. In addition to several such embedded microformats (Open Graph (‘The Open Graph protocol’), RDFa (‘RDFa 1.1 Primer - Third Edition’), Microdata (‘HTML Standard’)) we find JSON-LD (‘JSON-LD 1.1’) as a Web-focused RDF serialisation that aims for improved programmatic generation and consumption, including from Web applications. JSON-LD is as of 2022-05-13 used5 by 42.7% of the top 10 million websites (‘Usage Statistics of JSON-LD for Websites, May 2022’).

Recently there has been a renewed emphasis to improve the Developer Experience (‘Designing a Linked Data developer experience’, 2018) for consumption of Linked Data, for instance RDF Shapes (expressed in SHACL (‘Shapes Constraint Language (SHACL)’) or ShEx (‘Shape Expressions (ShEx) 2.1 Primer’)) can be used to validate RDF Data (Gayo et al., 2017; Thornton et al., 2019) before consuming it programmatically, or reshaping data to fit other models. While a varied set of tools for Linked Data consumptions have been identified, most of them still require developers to gain significant knowledge of the underlying technologies, which hampers adaption by non-LD experts (Klímek, Škoda & Nečaský, 2019), which then tend to prefer non-semantic two-dimensional formats such as CSV files.

A valid concern is that the Semantic Web research community has still not fully embraced the Web, and that the “final 20%” engineering effort is frequently overlooked in favour of chasing new trends such as Big Data and AI, rather than making powerful Linked Data technologies available to the wider groups of Web developers (Verborgh & Vander Sande, 2020). One bridging gap here by the Linked Data movement has been “linked data by stealth” approaches such as structured data entry spreadsheets powered by ontologies (Wolstencroft et al., 2011), the use of Linked Data as part of REST Web APIs (Page, De Roure & Martinez, 2011) , and as shown by the big uptake by publishers to annotate the Web using schema.org Bernstein, Hendler & Noy (2016), with vocabulary use patterns documented by copy-pastable JSON-LD examples, rather than by formalised ontologies or developer requirements to understand the full Semantic Web stack.

3 Comparing FDO and existing approaches

To better understand the relationship between the FDO framework and other exisiting approaches, we use the following for analysis:

  1. An Interoperability Framework and Distributed Platform for Fast Data Applications (Delgado, 2016), which proposes quality measurements for comparing how frameworks support interoperability, particularly from a service architectural view
  2. The FAIR Digital Object guidelines (Bonino et al., 2019), validated against its implementations for completeness.
  3. A Comparison Framework for Middleware Infrastructures (Zarras, 2004), which suggest dimensions like openness, performance and transparency, mainly focused on remote computational methods
  4. Cross-checks against RDA’s FAIR Data Maturity Model (Bahim et al., 2020) to find how the FAIR principles are achieved in FDO, in particular considering access, sharing and openness
  5. EOSC Interoperability Framework (Corcho et al., 2021) which gives recommendations for technical, semantic, organisational and legal interoperability, particularly from a metadata perspective

The reason for this wide-ranged comparison is to exercise the different dimensions that together form FAIR Digital Objects: Data, Metadata, Service, Access, Operations, Computation. We have left out further comparisons on type systems, persistent identifiers and social aspects as principles and practices within these dimensions are still taking form within the FDO community (see section 2.1.1).

Some of these frameworks invite a comparison on a conceptual level, while others relate better to implementations and current practices. For these we consider FAIR Digital Objects and the Web conceptually, and for implementations we contrast between the main FDO realisation using the DOIPv2 protocol (Foundation, 2018) against Linked Data in general.

3.1 Considering FDO/Web as interoperability framework for Fast Data

The Interoperability Framework for Fast Data Applications (Delgado, 2016) categorises interoperability between applications along 6 strands, covering different architectural levels: from symbiotic (agreement to cooperate) and pragmatic (ability to choreograph processes), through semantic (common understanding) and syntactic (common message formats), to low-level connective (transport-level) and environmental (deployment practices).

We have chosen to investigate using this framework as it covers the higher levels of the OSI Model (Stallings, 1990) better with regards to automated machine-to-machine interaction (and thus interoperability), which is a crucial aspect of the FAIR principles. In Table 1 we use the interoperability framework to compare the current FAIR Digital Object approach against the Web and its Linked Data practices.

Table 1: Considering FDO and Web according to the quality levels of the Interoperability Framework for Fast Data (Delgado, 2016).
Quality FDO w/ DOIP Web w/ Linked Data
Symbiotic: to what extent multiple applications can agree to interact/align/collaborate/cooperate The purpose of FDO is to enable federated machine actionable digital objects for scholarly purposes, in practice this also requires agreement of or compatibility between FDO types. FDO encourages research communities to develop common type registries to be shared across instances. In current DOIP practice, each service have their own types, attributes and operations. The wider symbiosis is consistent use of PIDs. The Web is loosely coupled and encourages collaboration and linking by URL. In practice, REST APIs (Fielding, 2000) end up being mandated centrally by dominant (often commercial) providers (Fielding et al., 2017), which clients are required to use as-is with special code per service. Use of Linked Data enables common tooling and semantic mapping across differences.
Pragmatic: using interaction contracts so processes can be choreographed in workflows FDO types and operations enable detailed choreography (see CWFP). 0.TYPE/DOIPOperation has lightweight definition of operation, 0.DOIP/Request or 0.DOIP/Response may give FDO Type or any other kind of “specifics” (incl. human readable docs). Semantics/purpose of operations not formalised (similar operations can be grouped with 0.DOIP/OperationReference). “Follow your nose” crawler navigation, which may lead to frequent dead ends. Operational composition, typically within a single API provider, documented by OpenAPI 3 (‘OpenAPI Specification v3.1.0 | Introduction, Definitions, & More’), schema.org Actions (‘Schema.org Actions - schema.org’), WSDL/SOAP (‘Web Services Description Language (WSDL) Version 2.0 Part 0: Primer’), but frequently just as human-readable developer documentation/examples.
Semantic: ensuring consistent understanding of messages, interoperability of rules, knowledge and ontologies FDO semantic enable navigation and typing. Every FDO has a type. Types maintained in FDO Type registries, which may add additional semantics, e.g. the ePIC PID-InfoType for Model. No single type semantic, Type FDOs can link to existing vocabularies & ontologies. JSON-LD used within some FDO objects (e.g. DISSCO Digital Specimen, NIST Material Science schema) (Wittenburg et al., 2022) Lightweight HTTP semantics for authenticity/navigation. Semantic Type not commonly expressed on PID/header level, may be declared within Linked Data metadata. Semantic of type implied by Linked Data formats (e.g. OWL2, RDFS), although choice of type system may not be explicit.
Syntactic: serialising messages for digital exchange, structure representation DOIP serialise FDOs as JSON, metadata commonly use JSON, typed with JSON Schema. Multiple byte stream attachments of any media type. Textual HTTP headers (including any signposting), single byte stream of any media type, e.g. Linked Data formats (JSON-LD, Turtle, RDF/XML) or embedded in document (HTML with RDFa, JSON-LD or Microdata). XML was previously the main syntax used by APIs, JSON is now dominant.
Connective: transferring messages to another application, e.g. wrapping in other protocols DOIP (Foundation, 2018) is transport-independent, commonly TLS TCP/IP port 9000), DOIP over HTTP HTTP/1.1 (TCP/IP port 80), HTTP/1.1+TLS (TCP/IP 443), HTTP/2 (as HTTP/1* but binary), HTTP/3 (like HTTP/2+TLS but UDP)
Environmental: how applications are deployed and affected by its environment, portability Main DOIP implementation is Cordra, which can be single-instance or distributed. Cordra storage backends include file system, S3, MongoDB (itself scalable). Unique DOIP protocol can be hard to add to existing Web application frameworks, although proxy services have been developed (e.g. B2SHARE adapter). HTTP services widely deployed in a myriad of ways, ranging from single instance servers, horizontally & vertically scaled application servers, to (for static content) multi-cloud Content-Delivery Networks (CDN). Current scalable cloud technologies for Web hosting may not support HTTP features previously seen as important for Semantic Web, e.g. content negotiation and semantic HTTP status codes.

Based on the analysis shown in table 1, we draw the following conclusions:

The Web has already showed us how one can compose workflows of hetereogeneous Web Services (Wolstencroft et al., 2013). However, this is mostly done via developer or human interaction (Lamprecht et al., 2021). Similiarly, FDO does not enable automatic composition because operation semantics are not well defined. There is a question as to whether the plethora of documentation and broad developer usage that is available for Web APIs can be developed for FDO.

A difference between Web technologies and FDO is the stringency of the requirements for both syntax and semantics. Whereas the Web allows many different syntactic formats (e.g. from HTML to XML, PDFs), FDO realised with DOIP requires JSON. On the semantic front, FDO requires that every object have a well-defined type and structured form. This is clearly not the case on the Web.

In terms of connectivity and the deployment of applications, the Web has a plethora of software, services, and protocols that are widely deployed. These have shown interoperability. The Web standards bodies (e.g. IETF and W3C) follow the OpenStand principles (‘The Modern Standards Paradigm - Five Key Principles’) to embrace openness, transparency, and broad consensus. In contrast, FDO has a small number of implementations and corresponding protocols, although with a growing community, as evidenced at the first FDO conference (Loo, 1970). This is not to say that it is not worth developing further Handle+DOIP implementations in the future, but we note that the current FDO functionality can easily be implemented using Web technologies, even as DOIP-over-HTTP (‘DOIP API for HTTP Clients — Cordra documentation’).

It’s also a question as to whether a highly constrained protocol revolving around persistent identifiers is in fact necessary. For example, DOIs are mostly resolved on the web (‘DOI Resolution Documentation’) using HTTP redirects with the common https://doi.org/ prefix, hiding their Handle nature as an implementation detail (‘DOI Handbook - Resolution’).

3.1.1 Mapping of Metamodel concepts

The Interoperability Framework for Fast Data also provides a brief metamodel which we use in Table 2 to map and examplify corresponding concepts in FDO’s DOIP realization and the Web using HTTP semantics (Fielding, Nottingham & Reschke, 2022).

Table 2: Mapping the Metamodel concepts from the Interoperability Framework for Fast Data (Delgado, 2016) to equivalent concepts for FDO and Web.
Metamodel concept FDO/DOIP concept Web/HTTP concept
Resource FDO/DO Resource
Service DOIP service Server/endpoint
Transaction (not supported) Conditional requests, 409 Conflict
Process Extended operations (primarily stateless), 100 Continue, 202 Accepted
Operation DOIP Operation Method, query parameters
Request DOIP Request Request
Response DOIP Response Response
Message Segment, requestId Message, Representation
Channel DOIP Transport protocol (e.g. TCP/IP, TLS). JSWS signatures. TCP/IP, TLS, UDP
Protocol DOIP 2.0, ++ HTTP/1.1, HTTP/2, HTTP/3
Link PID/Handle URL

From this mapping we can identify the conceptual similarities between DOIP and HTTP, often with common terminology. Notable are that neither DOIP or HTTP have strong support for transactions (explored further in section 3.3), as well that HTTP has poor direct support for processes, as the Web is primarily stateless by design.

3.2 Assessing FDO implementations

The FAIR Digital Object guidelines (Bonino et al., 2019) sets out recommendations for FDO implementations. In Table 3 we evaluate the two current implementations, using DOIPv2 (Foundation, 2018) and using Linked Data Platform (Linked Data Platform Working Group, 2015), as proposed by (‘FAIR Digital Object Framework Documentation’).

Table 3: Checking FDO guidelines (Bonino et al., 2019; Strawn et al., 2022) against its current implementations as DOIP (Foundation, 2018) and Linked Data Platform (LDP) (‘FAIR Digital Object Framework Documentation’), with suggestions for required additions.
FDO Guideline DOIP 2.0 FDO suggestions Linked Data Platform LDP suggestion
G1: invest for many decades Handle system stable for 20 years, DOIP 2.0 since 2017. Ensure FDO types will not be protocol-bound as DOIP might be updated/replaced HTTP stable for 30 years, Semantic Web for 20 years. http:// URIs replaced by https://. Keep flexibility of RDF serialisation formats which may change more frequently
G2: trustworthiness DOI/Handle trusted by all major academic publishers and data repositories. DOIP relatively unknown, in effect only one implementation. Further promote DOIP and justify its benefits. Build tutorials and OSI open source implementations. Standardise DOIP-over-HTTP alternative. JSON-LD used by half of all websites (‘Usage Statistics of JSON-LD for Websites, May 2022’), however previous bad experiences with Semantic Web may deter adapters Ensure simplicity for end developers, rather than semantic overengineering. Example-driven documentation.
G3: follows FAIR principles See Table 5 Ensure all FAIR principles are covered, build complete examples. Touched briefly, see Table 5 Add explicit expression to show each FAIR pcinciple fulfilled.
G4: machine actionability CRUD and extension operations dynamically listed (see Table 4) Specify which operations should work for a given type, to reduce need for dynamic lookup. Specify input/output expectations formally (e.g. JSON Schema). HTTP CRUD operations, Open API (see Table 4) Document operations so client can make subsequent HTTP calls.
G5: abstraction principle Handle PIDs as abstraction base. DOIP operations can use any transport protocol. Document transport protocols as FDOs, recommend which transport to use. URI as abstraction base. Does not specify PID requirements. Give stronger deployment recommendations.
G6: stable binding between entities Machine-navigation through PIDs and operations specified per type. Unclear when metadata field is a PID or plain text. Make datatype of fields explicit to support navigation. Machine-navigation through URIs via properties and types. Unclear when URI should be followed or is just identifier, but always distinct from plain text.
G7: encapsulation Operations discovered at runtime (0.DOIP/Op.ListOperations). Allow method discovery by type FDOs in advance (see PR-TypingFDOs-2.0-20220608). HTTP methods discovered at runtime (OPTIONS), indempotent methods attempted directly. Unsupported methods reported using LDP constraints to human-readable text. Declare supported methods in advance, e.g. OpenAPI (‘OpenAPI Specification v3.1.0 | Introduction, Definitions, & More’)
G8: technology independence In theory independent, in reality depends on single implementations of Handle system and DOIP Encourage open source DOIP testbeds and lighter reference implementations Multiple HTTP implementations, multiple LDP implementations. No FDOF implementations. Develop demonstrator of FDOF usage based on existing LDP server.
G9: standard compliance Handle (Sun, Lannom & Boesch, 2003), DOIP (Foundation, 2018). FDO requirements not standardised yet. Formalise standard process of FDO requirements (Weiland et al., 2022b) HTTP, LDP. FDOF not yet standardised Formalise FDOF from FDOF-SEM working group
FDOF1: PID as basis Extensive use of Handle system. Clarify how local testing handles can be used during development, how “temporary” FDOs should evolve (Anders et al., 2022b). Register 0.DOIP/* and 0.FDO/* as PIDs. HTTP URLs as basis for identifiers, but they are frequently not persistent. Add strong guidance for PID services like w3id and persistence policies.
FDOF2: PID record w/ type Unspecified how to resolve from Handle to DOIP Service (!), in practice 10320/loc, 0.TYPE/DOIPService, URL, URL_REPLICA Document requirements for PID Record w3id/purl PIDs redirect without giving any metadata. Datacite DOIs content-negotiate to give registered metadata. Add FAIR Signposting at PID provider for minimal PID record
FDOF3: PID resolvable to bytestream & metadata Byte stream resolvable (0.DOIP/Retrieve), includeElementData option can retrieve bytestream or full object structure. No method/attribute defined for separate metadata, only directly in PID Record. Unclear meaning of multiple items and bytestream chunks. Clarify expectations for multiple items. Recommend chunks to not be used. URIs resolvable by default. Multiple ways to resolve metadata, unclear preference. Add FAIR Signposting and preference order.
FDOF4: Additional attributes Freetext attribute keys. Attributes should be defined for FDO type (?). Require that attribute keys should be PIDs (or have predefined mapping to PIDs). Explicitly allow attributes not already defined in type. All attributes individually identified. Any Linked Data attributes can be used by URI or with mapped prefix. Clarify type expectations of required/recommended/optional attributes.
FDOF5: Interface: operation by PID Extended operations use PID, but “pid-like” DOIP operations/types are not registered as handles. Register 0.DOIP/* and 0.FDO/* as PIDs. Clarify that operations can be mapped to protocol directly. CRUD operations used directly in HTTP (e.g. PUT). Unclear how to provide PID for additional operations. Specify how additional operations should be called over HTTP.
FDOF6: CRUD operations + extensions 0.DOIP/Op.Create, Op.Retrieve, Op.Update, Op.Delete but also 0.DOIP/Op.Search. Document PUT, GET, POST, DELETE, PATCH, HEAD – extension operations (e.g. WebDAV COPY) not used, resource patterns (martinekuan) are used instead. Document how operation resources can be discovered from an LPD container. Document search API.
FDOF7: FDOF Types related to operations Not yet formalised, by DOIP discoverable on a given FDO rather than type. PR-TypingFDOs leaves this open. Add explicit relation between type and operations OPTIONS per LDP Resource, but not by type. Common types (ldp:Resource, ldp:Container) indicate LDP support, but are not required. Always make LDP types explicit in FDO profile.
FDOF8: Metadata as FDO, semantic assertions DOIP includes all metadata in PID Record. Separate Metadata FDO need custom property. Specify a 0.FDO/metadata or similar to point to Metadata FDOs. Assertions are always with semantics, using RDF vocabularies. Unspecified how to find additional metadata resources, rdfs:seeAlso is common. Use FAIR Signposting describedby link relation to additional metadata PIDs
FDOF9: Different metadata levels Defines open-ended “Response Attributes” without namespaces, but mandated as “None” for all CRUD operations. Metadata would need to be bundled within custom FDO types/attributes. Unclear how levels are separated within single FDO representation (need FDOF8?). Declare which metadata are expected within response attribute or within FDO object. Require PIDs for custom attributes. Define how alternate metadata levels can be represented separately. Undefined how to handle multiple metadata granularities or domains, alternative LDP containers can present different views on same stored objects. Define how to navigate to alternate views and their semantic implications, e.g. owl:sameAs
FDOF10: Metadata schemas by community Metadata schemas are in practice managed on single CORDA server as local types, using JSON Schema. Require types to be FDOs with registered PIDs, implement shared types. Plethora of existing RDF vocabularies/ontologies managed by larger communities, e.g. OBO Foundry (Smith et al., 2007) Rather document better how individual ad-hoc schemas can be started for prototypes.
FDOF11: FDO collections w/ semantic relations Collection type undefined by DOIP. Informal use of HAS_PARTS Handle attribute (e.g. (‘Data Information View’)). LDP Containers required by specification, also user-created (eg. BasicContainer). Clarify relation to other collections like DCAT 3 (‘Data Catalog Vocabulary (DCAT) - Version 3’), Schema.org Dataset, OAI-ORE (‘ORE User Guide - Primer’)
FDOF12: Deleted FDO preserve PID w/ tombstone Tombstone for deleted resource undefined by DOIP. 0.DOIP/Status.104 status code does not distinguish “Not Found” or “Gone” Formalise tombstone requirements with new FDO type 410 Gone recommended, but 404 Not Found common. No requirement for tombstone serialisation Formalise tombstone requirements and serialisation

Note that the draft update to FDO specification (Strawn et al., 2022) (see box 2.1.1) clarifies these definitions with equivalent identifiers6 and relates them to further FDO requirements such as FDO Data Type Registries.

A key observation from this is that simply using DOIP does not achieve many of the FDO guidelines. Rather the guidelines set out how a protocol like DOIPs should be used to achieve FAIR Digital Object goals. The DOIP Endorsement (Working Group, 2022a) sets out that to comply, DOIP must be used according to the set of FDO requirement documents (see box 2.1.1), and notes Achieving FDO compliance requires more than DOIP and full compliance is thus left to system designers. Likewise, a Linked Data approach will need to follow the same requirements to comply as an FDO implementation.

From our evaluation, we can observe:

3.3 Comparing FDO and Web as middleware infrastructures

In this section we take the perspective that FDO principles are in effect proposing a global infrastructure of machine-actionable digital objects. As such we can consider implementations of FDO as middleware infrastructures for programmatic usage, and can evaluate them based on expectations for client and server developers.

We argue that the Web, with its now ubiquitous use of REST API (Fielding, 2000), can be compared as a similar global middleware. Note that while early moves for developing Semantic Web Services (Fensel et al., 2011) attempted to merge the Web Service and RDF aspects, we are here considering mainly the current programmatic Web and its mostly light-weight use of ★★★ Linked Data (‘5-star Open Data’).

For this purpose, we here utillise the Comparison Framework for Middleware Infrastructures (Zarras, 2004) that formalise multiple dimensions of openness, scalability, transparency, as well as characteristics known from Object-oriented programming such as modularity, encapsulation and inheritance.

Table 4: Comparing FAIR Digital Object (with the DOIP 2.0 protocol (Foundation, 2018)) and Web technologies (using Linked Data) as middleware infrastructures (Zarras, 2004)
Quality FDO w/ DOIP Web w/ Linked Data
Openness: framework enable extension of applications FDOs can be cross-linked using PIDs, pointing to multiple FDO endpoints. Custom DOIP operations can be exposed, although it is unclear if these can be outside the FDO server. PID minting requires Handle.net prefix subscription, or use of services like Datacite, B2Handle. The Web is inherently open and made by cross-linked URLs. Participation requires DNS domain purchase (many free alternatives also exists). PID minting can be free using PURL/ARK services, or can use DOI/Handle with HTTP redirects.
Scalability: application should be effective at many different scales No defined methods for caching or mirroring, although this could be handled by backend, depending on exposed FDO operations (e.g. Cordra can scale to multiple backend nodes) Cache control headers reduce repeated transfer and assist explicit and transparent proxies for speed-up. HTTP GET can be scaled to world-population-wide with Content-Delivery Networks (CDNs), while write-access scalability is typically manage by backend.
Performance: efficient and predictable execution DOIP has been shown moderately scalable to 100 millions of objects, create operation at 900 requests/second . DOIP protocol is reusable for many operations, multiple requests may be answered out of order (by requestId). Multiple connections possible. Setup is typically through TCP and TLS which adds latency. HTTP traffic is about 10% of global Internet traffic, excluding video and social networks (Sandvine). HTTP 1 connections are serial and reusable, and concurrent connections is common. HTTP/2 adds asynchronous responses and multiplexed streams (Belshe & Peon, 2015) but still has TCP+TLS startup costs. For reduced latency , HTTP/3 (‘draft-ietf-quic-http-34’) use QUIC (Iyengar & Thomson, 2021)) rather than TCP, already adapted heavily (30% of EMEA traffic) of which Instagram & Facebook video is the majority of traffic.
Distribution transparency: application perceived as a consistent whole rather than independent elements. Each FDO is accessed separately along with its components (typically from the same endpoint). FDOs should provide the mandatory kernel metadata fields. FDOs of the same declared type typically share additional attributes (although that schema may not be declared). DOIP does not enforce metadata typing constraints, this need to be established as FDO conventions. Each URL accessed separately. Common HTTP headers provide basic metadata, although it is often not reliable. A multitude of schemas and serializations for metadata exists, conventions might be implied by a declared profile or certain media types. Metadata is not always machine findable, may need pre-agreed API URI Templates (Gregorio et al., 2012), content-negotiation (‘Content negotiation - HTTP | MDN’) or FAIR Signposting (Van de Sompel et al., 2022).
Access transparency: local/remote elements accessed similarly FDOs should be accessed through PID indirection, this means difficult to make private test setup. Commonly a fixed DOIP server is used directly, which permits local non-PID identifiers. Global HTTP protocol frequently used locally and behind firewalls, but at risk of non-global URIs (e.g. http://localhost/object/1) and SSL issues (e.g. self-signed certificates, local CAs)
Location transparency: elements accessed without knowledge of physical location FDOs always accessed through PIDs. Multiple locations possible in Handle system, can expose geo-info. PIDs and URL redirects. DNS aliases and IP routing can hide location. Geo-localised servers common for large cloud deployments.
Concurrency transparency: concurrent processing without interference No explicit concurrency measures. FDO kernel metadata can include checksum and date. HTTP operations are classified as being stateless/idempotent or not (e.g. PUT changes state, but can be repeated on failure), although these constraints are occassionally violated by Web applications. Cache control, ETag (~ checksum) and modification date in HTTP headers allows detection of concurrent changes on a single resource.
Failure transparency: service provisioning resilient to failures DOIP status codes, e.g. 0.DOIP/Status.104, additional codes can be added as custom attributes HTTP status codes e.g. 404 Not Found, specific meaning of standard codes can be documented in Open API. Custom codes uncommon.
Migration transparency: allow relocating elements without interfering application Update of PID record URLs, indirection through 0.TYPE/DOIPServiceInfo (not always used consistently). No redirection from DOIP service. HTTP 30x status codes provide temporary or permanent redirections, commonly used for PURLs but also by endpoints.
Persistence transparency: conceal deactivation/reactivation of elements from their users FDO requires use of PIDs for object persistence, including a tombstone response for deleted objects. There is no guarantee that an FDO is immutable or will even stay the same type (note: CORDRA extends DOIP with version tracking). URLs are not required to persist, although encouraged (‘Hypertext Style: Cool URIs don't change.’). Persistence requires convention to use PIDs/PURLs and HTTP 410 Gone. An URL may change its content, change in type may sometimes force new URLs if exposing extensions like .json. Memento (Van de Sompel, Nelson & Sanderson, 2013) expose versioned snapshots. WebDAV VERSION-CONTROL method (Clemm et al., 2002) (used by SVN).
Transaction transparency: coordinate execution of atomic/isolated transactions No transaction capabilities declared by FDO or DOIP. Internal synchronisation possible in backend for Extended operations. Limited transaction capabilities (e.g. If-Unmodified-Since) on same resource. WebDAV locking mechanisms (Dusseault, 2007) with LOCK and UNLOCK methods.
Modularity: application as collection of connected/distributed elements FDOs are inheritedly modular using global PID spaces and their cross-references. In practice, FDOs of a given type are exposed through a single server shared within a particular community/institution. The Web is inheritently modular in that distributed objects are cross-referenced within a global URI space. In practice, an API’s set of resources will be exposed through a single HTTP service, but modularity enables fine-grained scalability in backend.
Encapsulation: separate interface from implementation. Specify interface as contract, multiple implementations possible Indirection by PID gives separation. FDO principles are protocol independent, although it may be unclear which protocol to use for which FDO (although 0.DOIP/Transport can be specified after already contacting DOIP). Cordra supports native DOIP, DOIP over HTTP and Cordra REST API) HTTP/1.1 semantics can seemlessly upgrade to HTTP/2 and HTTP/3. http vs https URIs exposes encryption detail7. Implementation details may leak into URIs (e.g. search.aspx), countered by deliberate design of URI patterns (‘Hypertext Style: Cool URIs don't change.’) and PIDs via Persistent URLs (PURL).
Inheritance: Deriving specialised interface from another type DOIP types nested with parents, implying shared FDO structures (unclear if operations are inherited). FDO establishes need for multiple Data Type Registries (e.g. managed by a community for a particular domain). Semantics of type system currently undefined for FDO and DOIP, syntactic types can also piggyback of FDO type’s schema (e.g. CORDRA $ref use of JSON Schema references (‘draft-bhutton-json-schema-00’)) Syntactically Media Type with multiple suffixes (‘draft-ietf-mediaman-suffixes-00 - Media Types with Multiple Suffixes’) (mainly used with +json), declaration of subtypes as profiles (RFC6906) (Wilde, 2013). In metadata, semantic type systems (RDFS (‘RDF Schema 1.1’), OWL2 (‘OWL 2 Web Ontology Language Document Overview (Second Edition)’), SKOS (‘SKOS Simple Knowledge Organization System Primer’)). OpenAPI 3 (‘OpenAPI Specification v3.1.0 | Introduction, Definitions, & More’) inheritance and Polymorphism. XML xsd:schemaLocation or xsd:type (‘W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures’), JSON $schema (‘draft-bhutton-json-schema-00’)), JSON-LD @context (‘JSON-LD 1.1’). Large number of domain-specific and general ontologies define semantic types, but finding and selecting remains a challenge.
Signal interfaces: asynchronous handling of messages DOIP 2.0 is synchronous, in FDO async operations undefined. Could be handled as custom jobs/futures FDOs HTTP/2 multiplexed streams (Belshe & Peon, 2015), Web Sockets (‘WebSockets Standard’), Linked Data Notifications (‘Linked Data Notifications’), AtomPub (Gregorio & de hOra, 2007), SWORD (‘SWORD 3.0 Specification’), Micropub, more typically ad-hoc jobs/futures REST resources
Operation interfaces: defining operations possible on an instance, interface of request/response messages CRUD predefined in DOIP, custom operations through 0.DOIP/Op.ListOperations (can be FDOs of type 0.TYPE/DOIPOperation, more typically local identifiers like "getProvenance") CRUD predefined in HTTP methods (Fielding & Reschke, 2014a), (extended by registration), URI Templates (Gregorio et al., 2012), OpenAPI operations (‘OpenAPI Specification v3.1.0 | Introduction, Definitions, & More’), HATEOAS8 incl. Hydra (‘Hydra W3C Community Group’), schema.org Actions [‘Schema.org Actions - schema.org’), JSON HAL (‘draft-kelly-json-hal-08’) & Link headers (RFC8288) (Nottingham, 2017)
Stream interfaces: operations that can handle continuous information streams Undefined in FDO. DOIP can support multiple byte stream elements (need custom FDO type to determine stream semantics) HTTP 1.1 (Fielding & Reschke, 2014b) chunked transfer, HLS (RFC8216) (May, 2017), MPEG-DASH (ISO/IEC 23009-1:2019) (14:00-17:00)

Based on the analysis in Table 4, we make the following observations:

3.4 Assessing FDO against FAIR

In addition to having “FAIR” in its name, the FAIR Digital Object guidelines (Bonino et al., 2019) also include G3: FDOs must offer compliance with the FAIR principles through measurable indicators of FAIRness. (PR-RequirementSpec-2.0?).

Here we evaluate to what extent the FDO guidelines and its implementation with DOIP and Linked Data Platform (‘FAIR Digital Object Framework Documentation’) comply with the FAIR principles (Wilkinson et al., 2016). Here we’ve used the RDA’s FAIR Data Maturity Model (Group, 2020) as it has decomposed the FAIR principles to a structured list of FAIR indicators (Bahim et al., 2020), importantly considering Data and Metadata separately. In our interpretation for Table 5 we have for simplicity chosen to interpret “data” in FDOs as the associated bytestream of arbitrary formats, with remainining JSON/RDF structures always considered as metadata.

Table 5: Assessing RDA’s FAIR Data Maturity Model (Group, 2020; Bahim et al., 2020) (first 2 columns) against the FDO guidelines (Bonino et al., 2019), FDO implemented with the protocol DOIPv2 (Foundation, 2018), Linked Data Platform (LDP) (‘FAIR Digital Object Framework Documentation’) and examples from Linked Data practices in general. (— indicates Unspecified, may be possible with additional conventions)
FAIR ID Indicator FDO guidelines FDO/DOIP FDO/LDP Linked Data examples
RDA-F1-01M Metadata is identified by a persistent identifier FDOF4 Optional Metadata FDO w/separate PID Content-negotiation to URL, not required to be PID Metadata typically don’t have own PID
RDA-F1-01D Data is identified by a persistent identifier FDOF1 PIDs required (FDOF1). Handle, DOI. FDOF-IR (Identifier Record). PID can be any URI “Cool” URIs [‘Hypertext Style: Cool URIs don't change.’;{https://www.w3.org/TR/cooluris/}], PURL services incl. purl.org, w3id.org
RDA-F1-02M Metadata is identified by a globally unique identifier FDOR4 FDOF8 Optional Metadata FDO, unspecified how to indicate Content-negotiation to URL Not required, content-negotiation can redirect to URL or Content-Location. FAIR Signposting.
RDA-F1-02D Data is identified by a globally unique identifier FDOF1 All FDOs have PIDs (FDOR1), DOIP uses Handle system FDOF-IR (Identifier Record) Always accessed by URL
RDA-F2-01M Rich metadata is provided to allow discovery FDOF2 FDOF4 FDOF8 FDOF9 FDO has key-value metadata. Unclear how to link to additional metadata. FDOF-IR links to multiple metadata records RDF-based metadata by content negotiation or FAIR Signposting. Embedded in landing page (RDFa).
RDA-F3-01M Metadata includes the identifier for the data id and type are required metadata elements PIDs, also implicit as requests must use PID PID only required in FDOF-IR record. PID inclusion typical, but often inconsistent (e.g. www.example.com vs example.com) or missing (use of <> as this subject)
RDA-F4-01M Metadata is offered in such a way that it can be harvested and indexed FDOF10 No, registries not required (except Data Type Registries). Handle registry only searchable by PID. Not specified Not specified, several registries/catalogues for vocabularies/types (e.g. (‘NCBO BioPortal’, pp. https://lod–cloud.net/)). Indexing by search engines if exposing HTML w/schema.org.
RDA-A1-01M Metadata contains information to enable the user to get access to the data FDOF3 FDOF6 Directly by DOIP, but not included in FDO metadata. handle.net HTTP resolution may redirect to landing page Any property can point to URIs, but unclear if it is data Common with clickable “follow your nose” URLs
RDA-A1-02M Metadata can be accessed manually (i.e. with human intervention) (Cordra HTML landing page from handle.net URIs) Optional content-negotiation, e.g. by Apache Marmotta, OpenLink Virtuoso HTTP content-negotiation to HTML is common
RDA-A1-02D Data can be accessed manually (i.e. with human intervention) (Cordra HTML landing page from handle.net URIs) Optional content-negotiation Direct download, HTML landing pages common for DOIs
RDA-A1-03M Metadata identifier resolves to a metadata record FDOF8+FDOF2 Content-Location or HTTP redirection may indicate metadata URI
RDA-A1-03D Data identifier resolves to a digital object FDOF2 Required, but frequently not directly resolvable Recommended, but any URI acceptable Resolvable HTTP/HTTPS URIs are most common, now infrequent URNs are not directly resolvable
RDA-A1-04M Metadata is accessed through standardised protocol G9 FDOF3 Retrievable from PID (FDOF3). Informal DOIP standard maintained by DONA Foundation LDP standard maintained by W3C, HTTP standards maintained by IETF, FDO components resolved by informal proposals (custom vocabulary, extra HTTP methods) or HTTP content negotiation) Formal HTTP standards maintained by IETF, HTTP content negotiation, informal FAIR Signposting
RDA-A1-04D Data is accessible through standardised protocol G9 (see above) HTTP (Fielding, Nottingham & Reschke, 2022) HTTP/HTTPS, FTP (now less common), GridFTP (Allcock et al.) (for large data), ARK (‘The ARK Identifier Scheme’)
RDA-A1-05D Data can be accessed automatically (i.e. by a computer program) G4 FDOF3 FDOF6 Required, but few client libraries Ubiquitous, hundreds of HTTP libraries
RDA-A1.1-01M Metadata is accessible through a free access protocol G1 G8 G9 Partially realised: Handle system is open10 protocol (Sun et al., 2003). One server implementation (‘Handle.Net Registry’), free11. One DOIPv2 implementation (CORDRA): free under BSD-like license (not recognised as Open Source). LDP is open W3C recommendation. Multiple LDP implementations. DNS, HTTP, TLS, RDF standards are open, free and universal, large number of Open Source clients and servers.
RDA-A1.1-01D Data is accessible through a free access protocol G9 (see above) URI, DNS, HTTP, TLS URI, DNS, HTTP, TLS. Non-free DRM may be used (e.g. subscription video streaming)
RDA-A1.2-01D Data is accessible through an access protocol that supports authentication and authorisation (FDOR9) TLS certificates, authentication field (details unspecified) Implied HTTP authentication, TLS certificates
RDA-A2-01M Metadata is guaranteed to remain available after data is no longer available FDOF12 Unspecified, however FDOF-IR links to separate metadata records
RDA-I1-01M Metadata uses knowledge representation expressed in standardised format FDOF8 Required, but not currently defined Always implied by use of RDF syntaxes.
RDA-I1-01D Data uses knowledge representation expressed in standardised format Common (e.g. HDF5, JSON, XML), yet common scientific data formats frequently not standardised
RDA-I1-02M Metadata uses machine-understandable knowledge representation FDOF8 Required Optional RDF metadata with any vocabulary Always implied by use of RDF syntaxes.
RDA-I1-02D Data uses machine-understandable knowledge representation G4 G7 FDOR2 No requirements on binary data formats Only indirectly, LDP Basic Container reference only information resources Common, specially for scientific data formats
RDA-I2-01M Metadata uses FAIR-compliant vocabularies G3 FDOF10 Informally required Unspecified, implied by use of RDF? FAIR practices for LD vocabularies increasingly common, sometimes inconsistent (e.g. PURLs that don’t resolve) or incomplete (e.g. unknown license)
RDA-I2-01D Data uses FAIR-compliant vocabularies Uncommon, except for some XML and RDF-embedding formats, e.g. Extensible Metadata Platform (XMP) (14:00-17:00)
RDA-I3-01M Metadata includes references to other metadata FDOR8 Implied (attributes to PIDs), currently unspecified if given attribute is value or reference By definition (Linked Data reference existing URIs (‘Data - W3C’)), rdfs:seeAlso, FAIR signposting (Van de Sompel et al., 2022) describedby
RDA-I3-01D Data includes references to other data G6 FDOR3 FDOR11 URL hyperlinks common in several formats (HTML, PDF, JSON, XML).
RDA-I3-02M Metadata includes references to other data G6 FDOR3 FDOR8 Implied from custom FDO type’s attribute LDP Direct Container members can be any resources URI objects are frequently data references, may be indirect via PID
RDA-I3-02D Data includes qualified references to other data FDOR3 FDOR11 Only indirectly through FDO metadata Indirectly through LDP membership Uncommon: Link relations, FAIR Signposting
RDA-I3-03M Metadata includes qualified references to other metadata (FDOR3) Qualification by attribute keys defined per FDO Type LDP Direct Container Qualifications by property, PROV bundles (‘Linking Across Provenance Bundles’), schema.org/Role
RDA-I3-04M Metadata include qualified references to other data (FDOR3) Qualification by attribute keys defined per FDO type LDP Indirect Container Qualifications by property, n-ary indirection (schema.org Role (Unknown), prov:specializationOf (‘PROV-O: The PROV Ontology’), OAI-ORE Proxy (‘ORE Specification - Abstract Data Model’))
RDA-R1-01M Plurality of accurate and relevant attributes are provided to allow reuse FDOF4 Required. Kernel metadata attributes desired (Working Group & Working Group, 2022) but not assigned PIDs yet. Unspecified. Multiple metadata records can allow multiple semantic profiles. Large number of general and domain-specific vocabularies can make it hard to find relevant attributes. Rough consensus on kernel metadata: schema.org (‘Schema.org - Schema.org’), Dublin Core Terms (‘DCMI Metadata Terms’), DCAT (‘Data Catalog Vocabulary (DCAT) - Version 2’), FOAF (‘FOAF Vocabulary Specification’)
RDA-R1.1-01M Metadata includes information about the licence under which the data can be reused licenseConditions URL/PID in kernel metadata (Working Group & Working Group, 2022) Dublin Core Terms dct:license frequently recommended, frequently not required, e.g. by DCAT 2 (‘Data Catalog Vocabulary (DCAT) - Version 2’)
RDA-R1.1-02M Metadata refers to a standard reuse licence SPDX and Creative Commons URIs common, identifiers often inconsistent
RDA-R1.1-03M Metadata refers to a machine-understandable reuse licence SPDX documents uncommon
RDA-R1.2-01M Metadata includes provenance information according to community-specific standards FDOR9 FDOR10 Unspecified (some CORDRA types add getProvenance methods). PID Kernel attributes? Unspecified W3C PROV-O, PAV
RDA-R1.2-02M Metadata includes provenance information according to a cross-community language FDOR9 FDOR8 W3C PROV-O (‘PROV-O: The PROV Ontology’), PAV (Ciccarese et al., 2013), Dublin Core Terms (‘DCMI Metadata Terms’, 2020)
RDA-R1.3-01M Metadata complies with a community standard FDOR10 FROR8 (Emerging, e.g. DiSSCo Digital Specimen (Hardisty et al., 2022)) Common, e.g. DCAT 2 (‘Data Catalog Vocabulary (DCAT) - Version 2’), BioSchemas (‘Bioschemas - Bioschemas’)
RDA-R1.3-01D Data complies with a community standard (FDOR3) Common, HTTP use registered IANA media types, additional scientific file formats frequently not standardised or identified
RDA-R1.3-02M Metadata is expressed in compliance with a machine-understandable community standard FDOF4 FDOF10 Recommended Common practice for ontologies, specially in bioinformatics, e.g. BioPortal (‘NCBO BioPortal’), Darwin Core (Wieczorek et al., 2012)
RDA-R1.3-02D Data is expressed in compliance with a machine-understandable community standard (FDOR2) No, FDO is typed but data can be any bytestream Occassionally, (e.g. GFF3, FITS, ESRI)

From this evaluation we observe:

4 EOSC Interoperability Framework

TODO: Introduce EOSC IF

The EOSC Interoperability Framework (Corcho et al., 2021) in section 3.6 recommends:

Layer Recommendation FDO Linked Data
Technical Open Specification FDO specifications are semi-open, process gradually more transparent Open and transparent standard processes through W3C & IETF
Technical Common security & privacy framework Unspecified TLS for encryption, multiple approaches for single-sign-on (e.g. ORCID, Life Science Login). Privacy largely unspecified.
Technical Easy SLAs for service providers Unspecified None
Technical Access data in different formats None formalised, custom operations or relations Content-negotiation, rel=alternate relations
Technical Coarse-grained/fine-grained search tools Freetext 0.DOIP/Op.Search on local DOIP, no federation Coarse-grained e.g. Google Dataset Search, fine-grained (e.g. federated SPARQL) require detailed vocabulary/metadata insight
Technical Clear PID policy Strong FDO requirements, tends towards Handle system. Not required, different communities set policies
Semantic Clear definitions for concepts/metadata/schemas Required by FDO requirements, but not yet formalised Ontologies, SKOS, OWL
Semantic Semantic artefacts w/ open licenses All artefacts are PIDs w/ license required by kernel metadata? Open License is best practice for ontology publishing
Semantic Documentation for each semantic artefact No direct rendering from FDO, no requirement for human-readable description Ontology rendering, content-negotiation
Semantic Repositories of artefacts Required, but not formalised Bioontologies, etc
Semantic Repositories w/ clear governance Recommended Largely self-governed repositories, if well-established may have clear governance.
Semantic Minimal metadata model for federated discovery Kernel metadata (Working Group & Working Group, 2022) DCAT, ++
Semantic Crosswalks from minimal metadata model FDO Typing recommends referencing existing type definitions, but not as separate crosswalks Multiple crosswalks for common metadata models, but frequently not in semantic format
Semantic Extensibility options for diciplinary metadata Communities encouraged to establish own types Extensible by design, domain-specific metadata may be at different granularity
Semantic Clear protocols/building blocks for federation/harvesting of artefact catalogues Collection types not yet defined SWORD, OAI-PMH
Organisational Interoperability-focused rules of participation recommendations Recommended Implied only by some communities, tendency to specialise
Organisational Usage recommendations of standardised data formats None None – but common for metadata (e.g. JSON-LD)
Organisational Usage recommendations of vocabularies Recommended by community Common (see RDMKit)
Organisational Usage recommendations of metadata Recommended by community RO-Crate, Bioschemas
Organisational Management of permanent organization names/functions Handle owner, but unclear contact. Contact info in DOIP service provider ROR. DCAT contacts.
Legal Standardised human and machine-readable licenses None SPDX
Legal Permissive licenses for metadata (CC0, CC-BY-4.0) Undefined Both CC0, CC-BY-4.0 common, e.g. in DCAT
Legal Different licenses for different parts Each part as separate FDO can have separate license DCAT, RO-Crate, Named graphs for splitting metadata
Legal Mark expired/inexistent copyright Undefined Unclear, semantics assume copyright valid
Legal Mark orphaned data Tombstone for deleted data, but no owner of DOIP server means FDO disappears Frequently data and endpoint has no known maintainer, archiving in common repositories becoming common
Legal List recommended licenses Undefined Best practice recommendations
Legal Track license evolution for dataset Undefined Versioning with PAV/PROV/DCAT
Legal Policy/guidance for patent/trade secrets violation Undefined Undefined, legal owner may be specified
Legal GDPR compliance for personal data Undefined Undefined
Legal Restrict access/use if legally required By transport protocol (undefined by FDO/DOIP) Diverging approaches, typically landing pages w/ auth&auth or click-thru
Legal Harmonised terms-of-use Undefined Undefined
Legal Alignment between EOSC and national legislation Not applicable Not applicable


5 Discussion


5.1 (What does it mean for Linked Data?)

The FAIR Digital Object approach raises many important points for Linked Data practictioners. At first glance, the explicit requirements of FDOs may seem to be easy to furfill by different parts of the Semantic Web Cake (‘Semantic Web - XML2000 - slide "Architecture"’). However, our deeper investigation, based on multiple frameworks, highlights that the openness and variability of how Linked Data is deployed makes it difficult to achieve the FDO goals without significant effort.

While RDF and Linked Data have been suggested as prime candidates for making FAIR data, we argue that when different developers have too many degrees of freedom (such as serialization formats, vocabularies, identifiers, navigation), interoperability is hampered – this makes it hard for machines to reliably consume multiple FAIR resources across repositories and data providers.

We therefore identify the need for an explicit FDO profile of Linked Data that sets pragmatic constraints and stronger recommendations for consistent and developer-friendly deployment of digital objects. Such a combination of efforts will utillise both the benefits of mature Semantic Web technologies (e.g. federated knowledge graph queries and rich validation) and data management practices that follow FDO guidance in order to grow a rigid (yet flexible) ecosystem of machine-actionable scholarly objects.

6 Conclusion

7 References

. Available at https://blog.cloudflare.com/http-3-vs-http-2/
. Available at https://www.rd-alliance.org/sites/default/files/Cordra.2022.pdf
14:00-17:00.ISO 16684-1:2019. Available at https://www.iso.org/standard/75163.html (accessed 24 January 2023b).
14:00-17:00.ISO/IEC 23009-1:2019. Available at https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/07/93/79329.html (accessed 26 May 2022a).
5-star Open Data. Available at http://5stardata.info/en/ (accessed 24 January 2023).
Allcock W, Bresnahan J, Kettimuthu R, Link M. The Globus Striped GridFTP Framework and Server. In: ACM/IEEE SC 2005 Conference (SC'05). IEEE,. DOI: 10.1109/sc.2005.72.
Anders I, Blanchi Ch, Broeder D, Hellström M, Islam Sh, Jejkal Th, Lannom L, Peters K, Quick R, Schlemmer A, Schwardmann U, Soiland-Reyes S, Strawn G, Uytvanck D van, Weiland C, Wittenburg P, Zwölf C. 2022a. FAIR digital object overview and specifications. (internal draft): FDO Forum.
Anders I, Hellström M, Islam S, Jejkal T, Lannom L, Schwardmann U, Wittenburg P. 2022b. FDO PID profiles & attributes. (internal draft): FDO Forum.
Bahim C, Casorrán-Amilburu C, Dekkers M, Herczog E, Loozen N, Repanas K, Russell K, Stall S. 2020. The FAIR data maturity model: An approach to harmonise FAIR assessments. Data Science Journal 19. DOI: 10.5334/dsj-2020-041.
Belshe M, Peon R. 2015. Hypertext Transfer Protocol Version 2 (HTTP/2). RFC Editor. DOI: 10.17487/rfc7540.
Berners-Lee T, Fielding R, Masinter L. 2005. Uniform Resource Identifier (URI): Generic Syntax. RFC Editor. DOI: 10.17487/rfc3986.
Berners-Lee T, Fischetti M. 1999. Weaving the Web: the original design and ultimate destiny of the World Wide Web by its inventor. San Francisco: HarperSanFrancisco.
Bernstein A, Hendler J, Noy N. 2016. A new look at the semantic web. Communications of the ACM 59:35–37. DOI: 10.1145/2890489.
Bioschemas - Bioschemas. Available at http://bioschemas.org/ (accessed 26 May 2022).
Bizer C, Heath T, Berners-Lee T. 2009. Linked data - the story so far. International journal on Semantic Web and information systems 5:1–22. DOI: 10.4018/jswis.2009081901.
Blanchi C, Broeder D, Jejkal T, Sharif I, Schlemmer A, Uytvanck D van, Wittenburg P. 2022a. FDO – upload of FDO. (internal draft): FDO Forum.
Blanchi C, Hellström M, Lannom L, Schwardmann U, Wittenburg P. 2022b. Implementation of attributes, types, profiles and registries. (internal draft): FDO Forum.
Bonino Da Silva Santos LO, Wilkinson MD, Kuzniar A, Kaliyaperumal R, Thompson M, Dumontier M, Burger K. 2016. FAIR data points supporting big data interoperability. In: Zelm M, Doumeingts G, Mendonça JP eds. Enterprise interoperability in the digitized and networked factory of the future. iSTE Press, 270–279.
Bonino L, Wittenburg O, Carroll B, Hardisty A, Leggott M, Zwölf C. 2019. FAIR digital object framework.
Carriero VA, Daquino M, Gangemi A, Nuzzolese AG, Peroni S, Presutti V, Tomasi F. 2020. The landscape of ontology reuse approaches. In: Cota G, Daquino M, Pozzato GL eds. Applications and practices in ontology design, extraction, and reasoning. Studies on the semantic web. IOS Press,. DOI: 10.3233/SSW200033.
Ciccarese P, Soiland-Reyes S, Belhajjame K, Gray AJ, Goble C, Clark T. 2013. PAV ontology: provenance, authoring and versioning. Journal of Biomedical Semantics 4:37. DOI: 10.1186/2041-1480-4-37.
Clemm G, Amsden J, Ellison T, Kaler C, Whitehead J. 2002. Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning). RFC Editor. DOI: 10.17487/rfc3253.
Content negotiation - HTTP | MDN. Available at https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation (accessed 26 May 2022).
Corcho O, Eriksson M, Kurowski K, Ojsteršek M, Choirat C, Sanden M van de, Coppens F. 2021. EOSC interoperability framework. Publications Office of the EU. DOI: 10.2777/620649.
Data - W3C. Available at https://www.w3.org/standards/semanticweb/data (accessed 26 May 2022).
Data Catalog Vocabulary (DCAT) - Version 2. Available at https://www.w3.org/TR/2020/REC-vocab-dcat-2-20200204/ (accessed 24 January 2023b).
Data Catalog Vocabulary (DCAT) - Version 2. Available at https://www.w3.org/TR/vocab-dcat-2/ (accessed 26 May 2022a).
Data Catalog Vocabulary (DCAT) - Version 3. Available at https://www.w3.org/TR/2022/WD-vocab-dcat-3-20220510/ (accessed 24 January 2023).
Data Information View. Available at https://handle-esgf.dkrz.de/lp/21.14100/2fcf49d3-0608-3373-a47f-0e721b7eaa87 (accessed 24 January 2023).
DCMI Metadata Terms. 2020. Available at https://www.dublincore.org/specifications/dublin-core/dcmi-terms/2020-01-20/ (accessed 24 January 2023).
DCMI Metadata Terms. Available at https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ (accessed 26 May 2022).
Delgado JCM. 2016. An Interoperability Framework and Distributed Platform for Fast Data Applications. In: Data Science and Big Data Computing. Springer International Publishing, 3–39. DOI: 10.1007/978-3-319-31861-5_1.
Designing a Linked Data developer experience. 2018. Available at https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/ (accessed 26 May 2022).
Digital Object Interface Protocol Version 1.0 | DONA Foundation. Available at https://www.dona.net/doipv1doc (accessed 26 May 2022).
DOI Handbook - Resolution. Available at https://www.doi.org/doi_handbook/3_Resolution.html (accessed 24 January 2023).
DOI Resolution Documentation. Available at https://www.doi.org/factsheets/DOIProxy.html (accessed 24 January 2023).
DOIP and Examples — Cordra documentation. Available at https://www.cordra.org/documentation/api/doip.html (accessed 26 May 2022).
DOIP API for HTTP Clients — Cordra documentation. Available at https://www.cordra.org/documentation/api/doip-api-for-http-clients.html (accessed 24 January 2023).
draft-bhutton-json-schema-00. Available at https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00 (accessed 26 May 2022).
draft-ietf-mediaman-suffixes-00 - Media Types with Multiple Suffixes. Available at https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/00/ (accessed 26 May 2022).
draft-ietf-quic-http-34. Available at https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34 (accessed 26 May 2022).
draft-kelly-json-hal-08. Available at https://datatracker.ietf.org/doc/html/draft-kelly-json-hal-08 (accessed 26 May 2022).
Duerst M, Suignard M. 2005. Internationalized Resource Identifiers (IRIs). RFC Editor. DOI: 10.17487/rfc3987.
Dusseault L (ed.). 2007. HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). RFC Editor. DOI: 10.17487/rfc4918.
FAIR Digital Object Framework Documentation. Available at https://fairdigitalobjectframework.org/ (accessed 26 May 2022).
FAIR Digital Objects Forum |. Available at https://fairdo.org/ (accessed 26 May 2022).
Fensel D, Facca FM, Simperl E, Toma I. 2011. Semantic Web Services. Springer Berlin Heidelberg. DOI: 10.1007/978-3-642-19193-0.
Fielding RT. 2000. Architectural styles and the design of network-based software architectures. {THESIS}.{DOCTORAL} Thesis. University of California, Irvine.
Fielding R, Nottingham M, Reschke J (eds.). 2022. HTTP Semantics. RFC Editor. DOI: 10.17487/rfc9110.
Fielding R, Reschke J (eds.). 2014b. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. RFC Editor. DOI: 10.17487/rfc7230.
Fielding R, Reschke J (eds.). 2014a. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC Editor. DOI: 10.17487/rfc7231.
Fielding RT, Taylor RN, Erenkrantz JR, Gorlick MM, Whitehead J, Khare R, Oreizy P. 2017. Reflections on the REST architectural style and "principled design of the modern web architecture" (impact paper award). In: Proceedings of the 2017 11th joint meeting on foundations of software engineering - ESEC/FSE 2017. New York, New York, USA: ACM Press, 4–14. DOI: 10.1145/3106237.3121282.
FOAF Vocabulary Specification. Available at http://xmlns.com/foaf/spec/ (accessed 26 May 2022).
Foundation D. 2018. Digital object interface protocol specification, version 2.0. DONA foundation.
Gayo JEL, Prud'hommeaux E, Boneva I, Kontokostas D. 2017. Validating RDF Data. Synthesis Lectures on the Semantic Web: Theory and Technology 7:1–328. DOI: 10.2200/s00786ed1v01y201707wbe016.
Goble C, Stevens R. 2008. State of the nation in data integration for bioinformatics. Journal of Biomedical Informatics 41:687–693. DOI: 10.1016/j.jbi.2008.01.008.
Gregorio J, de hOra B (eds.). 2007. The Atom Publishing Protocol. RFC Editor. DOI: 10.17487/rfc5023.
Gregorio J, Fielding R, Hadley M, Nottingham M, Orchard D. 2012. URI Template. RFC Editor. DOI: 10.17487/rfc6570.
Groth P, Loizou A, Gray AJG, Goble C, Harland L, Pettifer S. 2014. API-centric Linked Data integration: The Open PHACTS Discovery Platform case study. Journal of Web Semantics 29:12–18. DOI: 10.1016/j.websem.2014.03.003.
Group RDAFDMMW. 2020. FAIR data maturity model: Specification and guidelines. Research Data Alliance. DOI: 10.15497/rda00050.
Handle.Net Registry. Available at https://www.handle.net/download_hnr.html (accessed 24 January 2023).
Hardisty A, Brack P, Goble C, Livermore L, Scott B, Groom Q, Owen S, Soiland-Reyes S. 2022. The Specimen Data Refinery: A Canonical Workflow Framework and FAIR Digital Object Approach to Speeding up Digital Mobilisation of Natural History Collections. Data Intelligence 4:320–341. DOI: 10.1162/dint_a_00134.
Hasnain A, Rebholz-Schuhmann D. 2018. Assessing FAIR data principles against the 5-star open data principles. In: Gangemi A, Gentile AL, Nuzzolese AG, Rudolph S, Maleshkova M, Paulheim H, Pan JZ, Alam M eds. The semantic web: ESWC 2018 satellite events: ESWC 2018 satellite events, heraklion, crete, greece, june 3-7, 2018, revised selected papers. Lecture notes in computer science. Cham: Springer International Publishing, 469–477. DOI: 10.1007/978-3-319-98192-5_60.
Horrocks I, Hendler J (eds.). 2002. The Semantic Web — ISWC 2002. Springer Berlin Heidelberg. DOI: 10.1007/3-540-48005-6.
HTML Standard. Available at https://html.spec.whatwg.org/multipage/microdata.html (accessed 26 May 2022).
Hu W, Chen J, Zhang H, Qu Y. 2011. How matchable are four thousand ontologies on the semantic web. In: Antoniou G, Grobelnik M, Simperl E, Parsia B, Plexousakis D, De Leenheer P, Pan J eds. The semantic web: Research and applications. Lecture notes in computer science. Berlin, Heidelberg: Springer Berlin Heidelberg, 290–304. DOI: 10.1007/978-3-642-21034-1_20.
Hydra W3C Community Group. Available at https://www.hydra-cg.com/ (accessed 24 January 2023).
Hypertext Style: Cool URIs don't change. Available at https://www.w3.org/Provider/Style/URI (accessed 26 May 2022a).
Hypertext Style: Cool URIs don't change. Available at https://www.w3.org/Provider/Style/URI.html (accessed 26 May 2022b).
"info" URI Registry (Frozen). Available at https://oclc-research.github.io/infoURI-Frozen/ (accessed 24 January 2023).
Iyengar J, Thomson M (eds.). 2021. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC Editor. DOI: 10.17487/rfc9000.
JSON-LD 1.1. Available at http://www.w3.org/TR/json-ld/ (accessed 26 May 2022b).
JSON-LD 1.1. Available at https://www.w3.org/TR/json-ld/ (accessed 26 May 2022a).
Juty N, Le Novere N, Laibe C. 2011. Identifiers.org and MIRIAM Registry: community resources to provide persistent identification. Nucleic Acids Research 40:D580–D586. DOI: 10.1093/nar/gkr1097.
Kahn R, Wilensky R. 1995. A framework for distributed digital object services. CNRI.
Kahn R, Wilensky R. 2006. A framework for distributed digital object services. International Journal on Digital Libraries 6:115–123. DOI: 10.1007/s00799-005-0128-x.
Kamdar MR, Tudorache T, Musen MA. 2017. A systematic analysis of term reuse and term overlap across biomedical ontologies. Semantic Web 8:853–871. DOI: 10.3233/sw-160238.
Khare R, Lawrence S. 2000. Upgrading to TLS Within HTTP/1.1. RFC Editor. DOI: 10.17487/rfc2817.
Klein M, Van de Sompel H, Sanderson R, Shankar H, Balakireva L, Zhou K, Tobin R. 2014. Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot. PLoS ONE 9:e115253. DOI: 10.1371/journal.pone.0115253.
Klímek J, Škoda P, Nečaský M. 2019. Survey of tools for linked data consumption. Satya Widya 10:665–720. DOI: 10.3233/SW-180316.
Lamprecht A-L, Palmblad M, Ison J, Schwämmle V, Al Manir MS, Altintas I, Baker CJO, Ben Hadj Amor A, Capella-Gutierrez S, Charonyktakis P, Crusoe MR, Gil Y, Goble C, Griffin TJ, Groth P, Ienasescu H, Jagtap P, Kalaš M, Kasalica V, Khanteymoori A, Kuhn T, Mei H, Ménager H, Möller S, Richardson RA, Robert V, Soiland-Reyes S, Stevens R, Szaniszlo S, Verberne S, Verhoeven A, Wolstencroft K. 2021. Perspectives on automated composition of workflows in the life sciences. F1000Research 10:897. DOI: 10.12688/f1000research.54159.1.
Lannom L, Peters-von Gehlen K, Anders I, Pfeil A, Schlemmer A, Trautt Z, Wittenburg P. 2022a. FDO configuration types. (internal draft): FDO Forum.
Lannom L, Schwardmann U, Blanchi C, Wittenburg P. 2022b. Typing FAIR digital objects. (internal draft): FDO Forum.
Licenses & Standards | Open Source Initiative. Available at https://opensource.org/licenses (accessed 24 January 2023).
Linked Data - Design Issues. Available at https://www.w3.org/DesignIssues/LinkedData.html (accessed 26 May 2022).
Linked Data Notifications. Available at https://www.w3.org/TR/ldn/ (accessed 26 May 2022).
Linked Data Platform Working Group. 2015. Linked data platform 1.0. W3C.
Linking Across Provenance Bundles. Available at https://www.w3.org/TR/2013/NOTE-prov-links-20130430/ (accessed 24 January 2023).
Loo T (ed.). 1970. First International Conference on FAIR Digital Objects. DOI: 10.3897/rio.coll.190.
martinekuan.Web API design best practices - Azure Architecture Center. Available at https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design (accessed 24 January 2023).
May W. 2017. HTTP Live Streaming. RFC Editor. DOI: 10.17487/rfc8216.
Meroño-Peñuela A, Lisena P, Martínez-Ortiz C. 2021b. Web data apis over SPARQL. In: Web data apis for knowledge graphs: Easing access to semantic data for application developers. Synthesis lectures on data, semantics, and knowledge. Cham: Springer International Publishing, 27–38. DOI: 10.1007/978-3-031-01917-3_3.
Meroño-Peñuela A, Lisena P, Martínez-Ortiz C. 2021a. Conclusion and future challenges. In: Web data apis for knowledge graphs: Easing access to semantic data for application developers. Synthesis lectures on data, semantics, and knowledge. Cham: Springer International Publishing, 77–80. DOI: 10.1007/978-3-031-01917-3_7.
Mika P. 2015. On Schema.org and Why It Matters for the Web. IEEE Internet Computing 19:52–55. DOI: 10.1109/mic.2015.81.
Mons B, Neylon C, Velterop J, Dumontier M, Silva Santos LOB da, Wilkinson MD. 2017. Cloudy, increasingly FAIR; revisiting the FAIR data guiding principles for the european open science cloud. Information Services & Use 37:49–56. DOI: 10.3233/{ISU}-170824.
NCBO BioPortal. Available at https://bioportal.bioontology.org/ontologies (accessed 26 May 2022).
Neumann A, Laranjeiro N, Bernardino J. 2021. An analysis of public REST web service apis. IEEE Transactions on Services Computing 14:957–970. DOI: 10.1109/TSC.2018.2847344.
Nottingham M. 2017. Web Linking. RFC Editor. DOI: 10.17487/rfc8288.
OpenAPI Specification v3.1.0 | Introduction, Definitions, & More. Available at https://spec.openapis.org/oas/v3.1.0.html (accessed 26 May 2022).
ORE Specification - Abstract Data Model. Available at http://www.openarchives.org/ore/1.0/datamodel#Proxies (accessed 24 January 2023).
ORE User Guide - Primer. Available at http://www.openarchives.org/ore/1.0/primer (accessed 24 January 2023).
OWL 2 Web Ontology Language Document Overview (Second Edition). Available at http://www.w3.org/TR/owl2-overview/ (accessed 26 May 2022).
Page KR, De Roure DC, Martinez K. 2011. REST and Linked Data. In: Proceedings of the Second International Workshop on RESTful Design - WS-REST '11. ACM Press,. DOI: 10.1145/1967428.1967435.
Polleres A, Kamdar MR, Fernández JD, Tudorache T, Musen MA. 2020. A more decentralized vision for linked data. Satya Widya 11:101–113. DOI: 10.3233/SW-190380.
PROV-O: The PROV Ontology. Available at https://www.w3.org/TR/2013/REC-prov-o-20130430/ (accessed 24 January 2023a).
PROV-O: The PROV Ontology. Available at https://www.w3.org/TR/prov-o/#specializationOf (accessed 24 January 2023b).
RDF 1.1 Primer. Available at http://www.w3.org/TR/rdf11-primer/ (accessed 26 May 2022).
RDF Schema 1.1. Available at http://www.w3.org/TR/rdf-schema/ (accessed 26 May 2022).
RDFa 1.1 Primer - Third Edition. Available at http://www.w3.org/TR/rdfa-primer/ (accessed 26 May 2022).
Resource Description Framework (RDF) Model and Syntax Specification. Available at https://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ (accessed 26 May 2022).
ResourceSync Framework Specification - Table of Contents. Available at http://www.openarchives.org/rs/toc (accessed 26 May 2022).
Sandvine.Global Internet Phenomena Report 2022. Available at https://www.sandvine.com/global-internet-phenomena-report-2022 (accessed 26 May 2022).
Sauermann L, Cyganiak R, Völkel M. 2011. Cool URIs for the semantic web. Universität des Saarlandes. DOI: 10.22028/d291-25086.
Schema.org - Schema.org. Available at https://schema.org/ (accessed 26 May 2022).
Schema.org Actions - schema.org. Available at https://schema.org/docs/actions.html (accessed 26 May 2022).
Schultes E, Wittenburg P. 2019. FAIR principles and digital objects: Accelerating convergence on a data infrastructure. In: Manolopoulos Y, Stupnikov S eds. Data analytics and management in data intensive domains: 20th international conference, DAMDID/RCDL 2018, moscow, russia, october 9–12, 2018, revised selected papers. Communications in computer and information science. Cham: Springer International Publishing, 3–16. DOI: {10.1007/978-3-030-23584-0_1}.
Schwardmann U, Kálmán T. 2022. Two Examples on How FDO Types can Support Machine and Human Readability. Research Ideas and Outcomes 8. DOI: 10.3897/rio.8.e96014.
Semantic Web - XML2000 - slide "Architecture". Available at https://www.w3.org/2000/Talks/1206-xml2k-tbl/slide10-0.html (accessed 24 January 2023).
Shape Expressions (ShEx) 2.1 Primer. Available at http://shex.io/shex-primer/ (accessed 26 May 2022).
Shapes Constraint Language (SHACL). Available at https://www.w3.org/TR/shacl/ (accessed 26 May 2022).
SKOS Simple Knowledge Organization System Primer. Available at http://www.w3.org/TR/skos-primer/ (accessed 26 May 2022).
Smith B, Ashburner M, Rosse C, Bard J, Bug W, Ceusters W, Goldberg LJ, Eilbeck K, Ireland A, Mungall CJ, Leontis N, Rocca-Serra P, Ruttenberg A, Sansone S-A, Scheuermann RH, Shah N, Whetzel PL, Lewis S. 2007. The OBO Foundry: coordinated evolution of ontologies to support biomedical data integration. Nature Biotechnology 25:1251–1255. DOI: 10.1038/nbt1346.
SPARQL 1.1 Overview. Available at http://www.w3.org/TR/sparql11-overview/ (accessed 26 May 2022).
Stallings W. 1990. Handbook of computer-communications standards: The open systems (OSI) model and OSI-related standards. Carmel, IN, USA: Sams.
Stanczyk SK. 1987. Process modelling for information system description. The Open University. DOI: 10.21954/ou.ro.0000f821.
Stefi A. 2015. Do Developers Make Unbiased Decisions? - The Effect of Mindfulness and Not-Invented-Here Bias on the Adoption of Software Components. DOI: 10.18151/7217489.
Stefi A, Hess T. 2015. To develop or to reuse? Two perspectives on external reuse in software projects. In: Fernandes JM, Machado RJ, Wnuk K eds. Software business. Lecture notes in business information processing. Cham: Springer International Publishing, 192–206. DOI: 10.1007/978-3-319-19593-3_18.
Strawn G, Wittenburg P, Soiland-Reyes St, Peters K, Lannom L, Schwardmann U, Blanch Ch. 2022. FDO Forum FDO requirement specifications. (internal draft): FDO Forum.
Sun S, Lannom L, Boesch B. 2003. Handle System Overview. RFC Editor. DOI: 10.17487/rfc3650.
Sun S, Reilly S, Lannom L, Petrone J. 2003. Handle System Protocol (ver 2.1) Specification. RFC Editor. DOI: 10.17487/rfc3652.
SWORD 3.0 Specification. Available at https://swordapp.github.io/swordv3/swordv3.html (accessed 26 May 2022).
The ARK Identifier Scheme. Available at https://datatracker.ietf.org/doc/id/draft-kunze-ark.html (accessed 24 January 2023).
The Modern Standards Paradigm - Five Key Principles. Available at https://open-stand.org/about-us/principles/ (accessed 24 January 2023).
The Open Graph protocol. Available at https://ogp.me/ (accessed 26 May 2022).
Thornton K, Solbrig H, Stupp GS, Labra Gayo JE, Mietchen D, Prud E, Waagmeester A. 2019. Using shape expressions (ShEx) to share RDF data models and to guide curation with rigorous validation. In: Hitzler P, Fernández M, Janowicz K, Zaveri A, Gray AJG, Lopez V, Haller A, Hammar K eds. The semantic web: 16th international conference, ESWC 2019, portorož, slovenia, june 2–6, 2019, proceedings. Lecture notes in computer science. Cham: Springer International Publishing, 606–620. DOI: 10.1007/978-3-030-21348-0_39.
Tirmizi S, Aitken S, Moreira DA, Mungall C, Sequeda J, Shah NH, Miranker DP. 2011. Mapping between the OBO and OWL ontology languages. Journal of Biomedical Semantics 2:S3. DOI: 10.1186/2041-1480-2-s1-s3.
Turcoane O. 2014. Linked data, JSON-LD and the semantics of cultural and scientific heritage. Digital Presentation and Preservation of Cultural and Scientific Heritage 4:95–105. DOI: 10.55630/dipp.2014.4.11.
Unknown.Introducing 'Role'. Available at http://blog.schema.org/2014/06/introducing-role.html (accessed 24 January 2023).
Usage Statistics of JSON-LD for Websites, May 2022. Available at https://w3techs.com/technologies/details/da-jsonld (accessed 26 May 2022).
Van de Sompel H, Klein M, Jones S, Nelson ML, Warner S, Devaraju A, Huber R, Steinhoff W, Tykhonov V, Boruta L, Meijers E, Soiland-Reyes S, Wilkinson M. 2022.FAIR Signposting Profile. Available at https://signposting.org/FAIR/ (accessed 5 January 2023).
Van de Sompel H, Nelson M, Sanderson R. 2013. HTTP Framework for Time-Based Access to Resource States -- Memento. RFC Editor. DOI: 10.17487/rfc7089.
Verborgh R, Vander Sande M. 2020. The semantic web identity crisis: In search of the trivialities that never were. Satya Widya 11:19–27. DOI: 10.3233/SW-190372.
W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures. Available at http://www.w3.org/TR/xmlschema11-1/ (accessed 26 May 2022).
Web Services Description Language (WSDL) Version 2.0 Part 0: Primer. Available at http://www.w3.org/TR/wsdl20-primer/ (accessed 26 May 2022).
WebSockets Standard. Available at https://websockets.spec.whatwg.org/ (accessed 26 May 2022).
Weigel T, Plale B, Parsons M, Zhou G, Luo Y, Schwardmann U, Quick R, Hellström M, Kurakawa K. 2018. RDA Recommendation on PID Kernel Information. Research Data Alliance. DOI: 10.15497/rda00031.
Weiland C, Islam S, Broder D, Anders I, Wittenburg P. 2022a. FDO machine actionability. (internal draft): FDO Forum.
Weiland C, Schwardmann U, Wittenburg P, Kirkpatrick C, Hanisch R, Trautt Z. 2022b. FDO Forum Document Standards. (internal draft): FDO Forum.
Wieczorek J, Bloom D, Guralnick R, Blum S, Döring M, Giovanni R, Robertson T, Vieglais D. 2012. Darwin Core: An Evolving Community-Developed Biodiversity Data Standard. PLoS ONE 7:e29715. DOI: 10.1371/journal.pone.0029715.
Wilde E. 2013. The 'profile' Link Relation Type. RFC Editor. DOI: 10.17487/rfc6906.
Wilkinson MD, Dumontier M, Aalbersberg IjJ, Appleton G, Axton M, Baak A, Blomberg N, Boiten J-W, da Silva Santos LB, Bourne PE, Bouwman J, Brookes AJ, Clark T, Crosas M, Dillo I, Dumon O, Edmunds S, Evelo CT, Finkers R, Gonzalez-Beltran A, Gray AJG, Groth P, Goble C, Grethe JS, Heringa J, ’t Hoen PAC, Hooft R, Kuhn T, Kok R, Kok J, Lusher SJ, Martone ME, Mons A, Packer AL, Persson B, Rocca-Serra P, Roos M, van Schaik R, Sansone S-A, Schultes E, Sengstag T, Slater T, Strawn G, Swertz MA, Thompson M, van der Lei J, van Mulligen E, Velterop J, Waagmeester A, Wittenburg P, Wolstencroft K, Zhao J, Mons B. 2016. The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data 3. DOI: 10.1038/sdata.2016.18.
Wilkinson SR, Eisenhauer G, Kapadia AJ, Knight K, Logan J, Widener P, Wolf M. 2022. F*** workflows: when parts of FAIR are missing. arXiv. DOI: 10.48550/arxiv.2209.09022.
Williams AJ, Harland L, Groth P, Pettifer S, Chichester C, Willighagen EL, Evelo CT, Blomberg N, Ecker G, Goble C, Mons B. 2012. Open PHACTS: semantic interoperability for drug discovery. Drug Discovery Today 17:1188–1198. DOI: 10.1016/j.drudis.2012.05.016.
Wittenburg P, Anders I, Blanchi C, Buurman M, Goble C, Grieb J, Hardisty A, Islam S, Jejkal T, Kálmán T, Kirkpatrick C, Lannom L, Lauer T, Manepalli G, Peters-von Gehlen K, Pfeil A, Quick R, Sanden M van de, Schwardmann U, Soiland-Reyes S, Stotzka R, Trautt Z, Van Uytvanck D, Weiland C, Wieder P. 2022. FAIR digital object demonstrators 2021. Zenodo. DOI: 10.5281/zenodo.5872645.
Wittenburg P, Strawn G, Mons B, Bonino L, Schultes E. 2019. Digital objects as drivers towards convergence in data infrastructures. https://b2share.eudat.eu. DOI: 10.23728/b2share.b605d85809ca45679b110719b6c6cb11.
Wolstencroft K, Haines R, Fellows D, Williams A, Withers D, Owen S, Soiland-Reyes S, Dunlop I, Nenadic A, Fisher P, Bhagat J, Belhajjame K, Bacall F, Hardisty A, Nieva de la Hidalga A, Balcazar Vargas MP, Sufi S, Goble C. 2013. The Taverna workflow suite: designing and executing workflows of Web Services on the desktop, web or in the cloud. Nucleic Acids Research 41:W557–W561. DOI: 10.1093/nar/gkt328.
Wolstencroft K, Owen S, Horridge M, Krebs O, Mueller W, Snoep JL, du Preez F, Goble C. 2011. RightField: embedding ontology annotation in spreadsheets. Bioinformatics 27:2021–2022. DOI: 10.1093/bioinformatics/btr312.
Working Group FDO-TSIG. 2022a. DOIP endorsement request. (internal draft): FDO Forum.
Working Group FDO-TSIG. 2022b. FDO – granularity, versioning, mutability. (internal draft): FDO Forum.
Working Group FDO-TSIG, Working Group FDO-BIG. 2022. FDO – kernel attributes & metadata. (internal draft): FDO Forum.
X.1255 : Framework for discovery of identity management information. Available at https://www.itu.int/rec/T-REC-X.1255-201309-I (accessed 26 May 2022).
Zarras A. 2004. A Comparison Framework for Middleware Infrastructures. The Journal of Object Technology 3:103. DOI: 10.5381/jot.2004.3.5.a2.

  1. For a brief introduction to DOIP 2.0 (Foundation, 2018), see (‘DOIP and Examples — Cordra documentation’).↩︎

  2. URIs (Berners-Lee, Fielding & Masinter, 2005) are generalised forms of URLs that include locator-less identifiers such as ISBN book numbers (URNs). The distinction between locator-full and locator-less identifiers have weakened in recent years (‘"info" URI Registry (Frozen)’), for instance DOI identifiers now are commonly expressed with the prefix https://doi.org/ rather than as URNs with info:doi: given that the URL/URN gap has been bridged by HTTP resolvers and the use of Persistent Identifiers (PIDs) (Juty, Le Novere & Laibe, 2011). RDF 1.1 formats use Unicode to support IRIs (Duerst & Suignard, 2005), which extends URIs to include international characters and domain names.↩︎

  3. URIs can also identify non-information resources for any kind of physical object (e.g. people), such identifiers can resolve with 303 See Other redirections to a corresponding information resources (Sauermann, Cyganiak & Völkel, 2011).↩︎

  4. Datasets that distribute RDF graphs should not be confused with RDF Datasets used for partitioning named graphs.↩︎

  5. Presumably this large uptake of JSON-LD is mainly for the purpose of Search Engine Optimisation (SEO), with typically small amounts of metadata which may not constitute Linked Data as introduced above, however this deployment nevertheless constitute machine-actionable structured data.↩︎

  6. Newer (Strawn et al., 2022) renames FDOF* to FDOR* but follows same ordering.↩︎

  7. The http protocol (port 80) can in theory also upgrade (Khare & Lawrence, 2000) to TLS encryption, as commonly used by Internet Printing Protocol for ipp URIs, but on the Web, best practice is explicit https (port 443) URLs to ensure following links stay secure.↩︎

  8. HATEOAS: Hypermedia as the Engine of Application State (Fielding, 2000), an important element of the REST architectural style.↩︎

  9. Although it is possible with 0.DOIP/Op.Retrieve to request only particular individual elements of an DO (e.g. one file), unlike HTTP’s Range request, it is not possible to select individual chunks of an element’s bytestream.↩︎

  10. The Handle.net system was previously covered by software patent US6135646A which expired in 2013.↩︎

  11. The Handle.net public license] is not OSI-approved (‘Licenses & Standards | Open Source Initiative’) as an open source license – it includes usage restrictions and requires Service Agreements. It is not a DOIP requirement to host a local Handle instance, e.g. EOSC provides the B2HANDLE service for acquiring Handle prefixes.↩︎