...
How Linked Data is Serialised
The FI-Platform currently supports three serialisation formats for Linked Data: Turtle, RDF/XML and JSON-LD. The list might be expanded in the future, but these These three were chosen as the initial primary formats for the following reasons:
- Turtle is an extremely easy to read format where the triples are expressed very explicitly. It is not very compact though and does not support multiple graphs in the same document, but as an introductory format to reading and understanding Linked Data it is extremely useful and widely supported.
- RDF/XML is the primary serialisation format for RDF supported by practically any tool and leveraging the XML ecosystem tools. It should primarily be seen as a legacy format that is easy to parse and manage with the vast spectrum of XML tools. RDF/XML does not support multiple graphs in one document.
- JSON-LD (JSON for Linking Data, see https://json-ld.org/) is a novel and extremely versatile format that allows multiple graphs and is easily employed by developers already familiar with JSON. JSON-LD is rapidly growing in popularity and is recommended as the primary format for Linked Data exchange.
Lately, the list has been expanded with OpenAPI serialisation. If necessary, other serialisation formats can be added, too.
Graphs and Document
As mentioned above, JSON-LD supports multiple graphs in one document. What does this mean? A graph in Linked Data is a "bucket" for a set of triples. It is used for grouping a specific set of triples together for various purposes ranging from logical and semantic separation of data to targeted querying. Each graph (naturally) has its own IRI, making it possible to annotate it and thus describe the graphs contents and their provenance as a single entity. You should not mistake graphs as having anything to do with namespaces except for the fact that the contents of a graph are separated from the contents of other graphs.
...
When creating a new model (core vocabulary or application profile), you will mint a permanent static identifier for the model. This identifier acts as the resource describing the identity of your model. All the resources you create in your model will also be minted with permanent static identifiers. These resources will reside in a graph acting as a "sandbox" or "staging area" where you are free to modify the contents between publications. The identifiers for these resoSurcesresources are not resolvable to anything, their content is specified explicitly by the model contents (the triples in the graph).
...
At this point we can move onto discussing the two primary model types on the FI-Platform. You should be aware that the implementation of models on the FI-Platform is not universal, in other words it does not currently serve all the possible use cases the user base might have. Nevertheless, the platform will can be expanded and refined gradually according to the needs of its user base.
The primary aim of the tool is however fixed: it is meant for producing annotations which are used to semantically label data in the form of core vocabularies, and restrictions for validating labeled data in the form of application profiles.
...