| 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 n.d.). HTTP 1 connections are serial and reusable, and concurrent connections is common. HTTP/2 adds asynchronous responses and multiplexed streams (Belshe, Peon, and Thomson 2015) but still has TCP+TLS startup costs. For reduced latency, HTTP/3 (Bishop 2022) use QUIC (Iyengar and Thomson 2021) rather than TCP, already adapted heavily (30% of EMEA traffic) of which Instagram & Facebook video is the majority of traffic (Joras and Chi 2020). |
| 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 (MDN 2023) 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 (e.g. 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 (Berners-Lee 1998). 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, and 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 detail1. Implementation details may leak into URIs (e.g. search.aspx), countered by deliberate design of URI patterns (Berners-Lee 1998)) 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 (Wright et al. 2022)) |
Syntactically Media Type with multiple suffixes (Sporny and Guy 2023) (mainly used with +json), declaration of subtypes as profiles (RFC6906) . In metadata, semantic type systems (RDFS (Guha and Brickley 2014)), OWL2 (W3C OWL Working Group 2012), SKOS (Isaac and Summers 2009)). OpenAPI 3 (Miller et al. 2021) inheritance and Polymorphism. XML xsd:schemaLocation or xsd:type (Thompson et al. 2012), JSON $schema (Wright et al. 2022)), JSON-LD @context (Sporny et al. 2020). 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, and Thomson 2015), Web Sockets (Rice et al. 2022), Linked Data Notifications (Capadisli and Guy 2017), AtomPub (Gregorio and de hÓra 2007), SWORD (Jones and Jefferies 2021), Micropub (Parecki 2017), 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 (Roy T. Fielding and Reschke 2014b), (extended by registration), URI Templates (Gregorio et al. 2012), OpenAPI operations (Miller et al. 2021), HATEOAS2 incl. Hydra (Lanthaler 2021), schema.org Actions (“Schema.org Actions” n.d.), JSON HAL (Kelly 2016) & 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 (Roy T. Fielding and Reschke 2014a) chunked transfer, HLS (RFC8216) (Pantos and May 2017), MPEG-DASH (ISO/IEC 23009-1:2022 — Information Technology — Dynamic Adaptive Streaming over HTTP (DASH) — Part 1: Media Presentation Description and Segment Formats 2022) |
The http protocol (port 80) can in theory also upgrade (Khare and 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.↩︎
HATEOAS: Hypermedia as the Engine of Application State (Roy Thomas Fielding 2000), an important element of the REST architectural style.↩︎