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. Appendixes
  2. Appendix 2. Technical decisions

Serialization

In our case data serialization is the process of converting the semantic data to a format that allows sharing it in a form that then allows recovery of its original structure. Historically the standard used was RDF (XML), which has evolved to TTL which simplifies the syntax. The last evolution is JSON-LD, which is like JSON but expresses a context which allows an equivalence with RDF or TTL, but which is not serialized on files. TTL simplifies RDF, while JSON-LD offers another radically different way of doing things using the most common standard (JSON). When we enter the semantic world, we can have trouble reading RDF or TTL, while JSON-LD is easy to read. JSON-LD is the standard that has been chosen by Google and Facebook in their journey towards the semantic web.

Conclusion: the consortium's vision is therefore that we must adopt the JSON-LD standard.

The consortium, however, anticipates that this choice will require a bit of thinking around the server implementing, because standard SOLID servers return semantic data in RDF or TTL. We could also contribute to the global common good so that SOLID servers can provide JSON-LD.

PreviousService standardNextTransport layer

Last updated 10 months ago

Was this helpful?