Protocols specifications
The overall strategy is to implement the prototype in roughly two phases:
Esential: implementing an MVP of the prototype (DFC), to showcase the potential of the project and help raise additional funds.
Target : the full implementation of the prototype (DFC). It will complete phase 1 to enable industrialization and professionalization of the standard through improvement of the tools, of the technical architecture, and of the possibilities of integration with external actors.
Essential Platorm | Essential DFC | Target Platform | Target DFC | |
Protocole | Data must be expressed in a semantic way in the API and must respect the OWL DFC model User-friendly and easy to implement DONE | Essential Platorm DONE | Essential Platorm + LDP IN PROGRESS | Essential DFC + Full Semantic protocol (LDP + SPARQL) DONE |
Stateless or stateful | Stateless DONE | Essential Platorm DONE | Stateless DONE | Target Platform DONE |
Granularity | low granularity service (get all data of an authentified user) DONE | Essential Platorm ABANDONED | optional : Essential platorm to read + mandatory : high granularity (atomic) via LDP to write & read IN PROGRESS | NO DIRECT WRITE read :high granularity (atomic) via DONE |
URL | REST resource driven sémantic, without parameter DONE | Essential Platform DONE | Essential Platform DONE | Target DFC + parameters enabling queries (SPARQL or HyperGraphQL) SPARQL : DONE HyperGraphQL : OUTLOOK |
Service specifications | OpenAPI except for the input/output data structure, for which use OWL. LDP specification compliant. OUTLOOK | Essential Platform OUTLOOK | Complete OpenAPI specifications for standard services. LDP specification compliant. OUTLOOK | SPARQL spec for high granularity service by Query OUTLOOK |
Serialization | JSON-LD LDP specification compliant. DONE | Essential Platform DONE | Essential Platform DONE | Essential DFC + JSON-LD in the data attribute if HyperGraphQL OUTLOOK |
Transport layer | HTTP DONE | Essential Platform DONE | Essential Platform DONE | Essential DFC DONE |
Single or multi-source | Simple access to one logical source DONE | Essential Platorm DONE | Essential Platform DONE | Query on multiple sources OUTLOOK |
Right delegation | Standardized OIDC authentification + platform manage acces to data using authentification : authentified user data or more DONE | Essential Platorm IN PROGRESS | Yes (web ACL Compliance) OUTLOOK | Yes (web ACL implementation) OUTLOOK |
Identification and authentication | OIDC (hosted by lescommuns.org) DONE | Essential Platorm DONE | webId-OIDC (decentralised authentification serveur : need platform implémentation) OUTLOOK | Target Platform OUTLOOK |
Data storage | Distributed data on each platform DONE | linked uri directory DONE | Essential Platform DONE | Essential DFC +semantic cache IN PROGRESS |
User data | ID centralized by lescommuns.org DONE | Essential Platform DONE | webId-OIDC (decentralised authentification serveur : need platform implémentation) OUTLOOK | Target Platform OUTLOOK |
Product data | Decentralized ID management reconcile thanks to linked uri directory DONE | Essential Platform DONE | Essential Platform DONE | Essential DFC DONE |
Interface & server of prototype | NA | Native web components & NodeJs DONE | NA | Semantic Serveur (Semapps) Interface could be React OR Startin’blox server : DONE interface : OUTLOOK |
Federation vs Syndication Summary
Federation: all entities follow the same protocol
Syndication: entities may have different protocols
Ontology: Federation
Taxonomy: Federation
Storage: Syndication
Identification and authentication : Federation
Validation: ?
Synchronisation / caching: Federation
Notification: ?
Serialisation : Federation
Others aspects of the protocol: Federation
Last updated