Considering FDO and Web according to the quality levels of the Interoperability Framework for Fast Data (Delgado 2016).
| Symbiotic: to what extent multiple applications can agree to interact, align, collaborate or cooperate |
The purpose of FDO is to enable federated machine actionable digital objects for scholarly purposes, in practice this also requires agreement of 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 (Roy Thomas Fielding 2000) end up being mandated centrally by dominant (often commercial) providers (Roy T. Fielding et al. 2017), and the clients are required to use each API 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 (Canonical Workflows; CWFR Group (2021)). 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 (Miller et al. 2021), schema.org Actions (“Schema.org Actions” n.d.), WSDL/SOAP (Liu and Booth 2007), but frequently just as human-readable developer documentation with 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 |
“Digital Object Interface Protocol Specification, Version 2.0” (2018) is transport-independent, commonly TLS TCP/IP port 9000, DOIP over HTTP (CNRI 2023) |
HTTP/1.1, TCP/IP port 80 (Roy T. Fielding et al. 1999); HTTP/1.1+TLS, TCP/IP 443 (Rescorla 2000); HTTP/2, as HTTP/1* but binary (Belshe, Peon, and Thomson 2015); HTTP/3, like HTTP/2+TLS but UDP (Bishop 2022) |
| 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 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. |