DFC standard specifications
DFC Use Cases
DFC Use Cases
  • Introduction
  • Sources and licences
  • Contact and partners
  • Semantic specifications
    • Business ontology
    • Product ontology
    • Technical ontology
  • Technical specifications
    • Protocols specifications
    • Decentralized identifier matching reference system
    • Specifics API
    • Authentication strategy
    • Architecture representations
  • Prototype specifications
  • đźš§Solid client protocol
  • đźš§Connector
    • Model specifications
    • Semantizer specifications
    • Connector specifications
  • Use Cases
    • Enterprise Use Cases
    • Product Use Cases
      • Product Transformations
      • CSA Use Cases
    • Orders
    • Order Use Cases
      • Wholesale Order Processing
    • Glossary of terms
  • Appendixes
    • Appendix 1. General decisions
      • Federation vs Syndication
      • Stateless or stateful?
      • Service granularity
      • Directionality
      • Identification and authentication
      • Centralized or decentralized data storage
      • Metadata repository
    • Appendix 2. Technical decisions
      • Libraries to develop in semantic
      • Transition strategy fron current to ideal
      • Service standard
      • Serialization
      • Transport layer
      • Multi- or single-resource requests?
      • Right delegation between platforms and DFC
      • Data validity and inferences
    • Appendix 3. Practical Examples
      • Version 1.9
      • Version 1.8.2
      • version 1.7.4
      • version 1.7.3
      • version 1.7.1
      • version 1.7
      • version 1.6.2
      • version 1.6.1
      • version 1.6
      • version 1.5.1
      • version 1.5
      • version 1.3
      • version 1.2
  • Contributing
    • Procedures
      • Updates to the ontology
        • Patch releases procedure
        • Minor releases procedure
        • Major releases procedure
      • Taxonomy enrichment
        • Taxonomy updates
    • Platform Notifcations
  • Platform Register
    • Platform Register
Powered by GitBook
On this page

Was this helpful?

  1. Technical specifications

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

PreviousTechnical specificationsNextDecentralized identifier matching reference system

Last updated 10 months ago

Was this helpful?