Serialization Formats

[ThomasRanvikEriksen]

DIGIN Grunnprofil (Base Profile) places no restrictions on what the utillities or suppliers use as format and architecture requirements. But in order to run testing and validation, data exchange must be able to support this format list as a minimum:

• Json-ld
  • CGMES, CPSM
• Json
  • 61968-3 and -9 (Schedules)
• Geojson
  • 61968-13 (Geographical Location)
• ZIP

Supporting Reference:

• List of Formats
• Serialization Formats RDF

Several common serialization formats are in use, including:

Turtle,[26] a compact, human-friendly format.
TriG,[27] an extension of Turtle to datasets.
N-Triples,[28] a very simple, easy-to-parse, line-based format that is not as compact as Turtle.
N-Quads,[29][30] a superset of N-Triples, for serializing multiple RDF graphs.
JSON-LD,[31] a JSON-based serialization.
N3 or Notation3, a non-standard serialization that is very similar to Turtle, but has some additional features, such as the ability to define inference rules.
RDF/XML,[32] an XML-based syntax that was the first standard format for serializing RDF.
RDF/JSON,[33] an alternative syntax for expressing RDF triples using a simple JSON notation.

Related Issue

Contain and compress dataset using cimx

[VladimirAlexiev]

Hi @ThomasRanvikEriksen! (cc @Sveino )

• It's important to define the RDF representation regardless the RDF serialization used. I mean what quads are used and how they relate to each other.
  • In particular, CIM uses named graphs substantially: for models and differential models (Converting CIMXML DifferenceModel to CIMJSON-LD #321)
• JSON-LD has the nice property that you can interpret pretty much any "reasonable" JSON as RDF by attaching a JSON-LD context to it. This can be done at the protocol level, thus there's no need to modify the original JSON. See https://w3c.github.io/json-ld-syntax/#interpreting-json-as-json-ld. So there's no need to institute a "divide" and say "JSONLD is used for this kind of data, but mere JSON is used for that kind of data"
• GeoJSON alone is not sufficient to capture CIM data. And if you plan to store CIM data in a semantic repository, then you need to use GeoJSON in compliance with GeoSPARQL, see use geo:asGeoJSON instead of (or in addition to) GeoJSON-LD #337. Basically, the idea is to capture geometry as a datatyped literal: geo:asGeoJSONLiteral "..."^^geo:geoJSONLiteral
  • how to "retype" rdf:JSON to geo:geoJSONLiteral? w3c/json-ld-syntax#425 proposes to do this with the following jsonld context "incantation":
    "asGeoJSONLiteral": {"@id": "geo:asGeoJSONLiteral", "@type": "@json", "@json": "geo:geoJSONLiteral"}
• Finally, zip is not a distinct format but a compression method. It can be expressed in the content-type header (I think using +zip but I haven't checked)