JSON semantic format (JSON-NTV)

1.1. Presentation

The semantic level of JSON or CSV shared data remains low. It is often limited to the type of data defined in those exchange formats (strings for CSV formats; numbers, strings, arrays and objects for JSON formats).¶

JSON-NTV proposes to increase the semantic level of the JSON entities [RFC8259] by adding two additional pieces of information to a JSON entity :¶

• name: interpretation of the JSON value in human language or detailed information or link to external information,¶
• type: interpretation of the JSON value in a data standard (eg. GeoJSON, datetime), in a data catalog or in a software language.¶

The NTV entity is thus a triplet with a mandatory element (value) and two additional elements (name, type).¶

• For example, Paris location can be represented by : ¶

  • a name : "paris",¶
  • a type : geoJSON Point coordinates [RFC7946],¶
  • a value : [2.3522, 48.8566]¶

The easiest way to add that information into a JSON value is to use a JSON object with a single member. The first term is the additional elements using the syntax JSON-ND [JSON-ND]. The second term is the JSON value.¶

• The JSON value of the previous example is:¶

  • { "paris:point" : [2.3522, 48.8566] }¶

With this approach, two NTV entities are defined :¶

• a primitive entity which is not composed of any other entity,¶
• a structured entity which is an ordered sequence of NTV entities.¶

as well as two JSON formats depending on the presence of the additional elements :¶

• simple format when name and type are not present¶
• named format when name or type is present¶

• Example (entity composed of two other primitive entities): ¶

  • { "cities::point": [[2.3522, 48.8566], [4.8357, 45.7640]] } simple format for primitive entities¶
  • {"cities::point": {"paris":[2.3522, 48.8566], "lyon":[4.8357, 45.7640]}} named format for primitive entities¶

A JSON-NTV generator produces a JSON value from a NTV entity and vice versa a JSON-NTV parser transforms a JSON value into a NTV entity.¶

The document [NTV-TAB] presents a variation of this format for tabular and multidimensional data.¶

The conversion between NTV entity and native entity is outside the scope of this note.¶

1.2. Key design features

The format is focused on simplicity, lightness and web usage.¶

The key features of this format are the following:¶

• JSON as the base format¶

  • JSON is simple and readable as simple text¶
  • JSON supports rich structure including nesting and basic types¶
  • JSON is web-native and very widely used and supported¶
  • JSON format has binary representation (eg. CBOR format)¶

• high semantic level of data¶

  • wide variety of data typing¶
  • tree-like and customisable data typing¶

• compatibility with existing formats¶

  • All JSON data is a JsonNTV data¶
  • All NTVtypes are standard types¶

• compatibility with any type of platform¶

  • types and structures are independent of software and hardware platforms¶
  • the NTV concept is applicable to all types of "jsonable" data¶

• reversibility¶

  • the NTV entity coming from a JSON value is identical to the NTV entity from which the JSON value comes¶
  • the JSON representation of an NTV entity is the same as the JSON value used to construct the NTV entity¶

• tree structure¶

  • all NTV entities are trees¶
  • tree properties are applicable to NTV entities¶

1.3. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document also uses the following terms:¶

JsonText, JsonMember, JsonElement :

These terms are defined as text, member, element in the JSON grammar [RFC8174].¶

JsonValue, JsonObject, JsonArray, JsonNumber, JsonString, JsonFalse, JsonNull, JsonTrue:

These terms correspond to entities whose representation is defined as value, object, array, number, string, false, null, true in the JSON grammar [RFC8174].¶

JsonPrimitive:

A JsonNumber, JsonString, JsonFalse, JsonTrue or JsonNull.¶

JsonUnnamed:

A JsonObject without a single member.¶

JsonNamed:

A JsonObject with a single member.¶

NTVsingle, NTVlist:

NTVlist and NTVsingle entities can be abbreviated as:¶

• NVsingle : entity with default NTVtype "json",¶
• NVlist : entity without NTVtype,¶
• TVsingle, TVlist : entity without NTVname,¶
• Vsingle, Vlist : NVsingle or NVlist without NTVname.¶

2.1. NTV layers

NTV and JsonNTV structures are defined as shown in Figure 1:¶

• NTV is a data triplet (NTVname, NTVtype, NTVvalue) that contains all the information needed to build the native entity.¶
• JsonNTV is the JsonValue of the NTV entity. JsonNTV is used to build an interchangeable JsonText¶

Example:¶

• Native layer¶

  • new_year_2022 = datetime.date(2022, 01, 01) is a Python variable "new_year_2022" corresponding to a datetime object¶

• NTV layer¶

  • ("new_year_2022", "date", "2022-01-01") is a triplet¶

• JsonNTV layer¶

  • { "new_year_2022:date" : "2022-01-01" } is a JsonValue¶

• JsonText layer¶

  • '{"new_year_2022:date":"2022-01-01"}' is a JsonString¶

2.2. NTV entities

Two categories of entities (one primitive and one structured) are defined:¶

• NTVsingle for the primitive entity,¶
• NTVlist for an ordered sequence of NTV entities¶

An NTV entity is therefore a tree where the leaves nodes are the NTVsingle entities and where the inner nodes are the NTVlist entities¶

2.3. NTVtype and Namespace

NTVtype is defined in a nested structure called Namespace.¶

This structuring of type makes it possible to reference any type of data that has a JSON representation and to consolidate all the shared data structures within the same tree of types.¶

; representation of NtvType and Namespace (LongName)

NTVtypeLongName     = NamespaceParentLongName NTVtypeName

NamespaceLongName   = NamespaceParentLongName NamespaceName
NamespaceParentLongName = NamespaceLongName

NamespaceName   = [ ["$"] JsonString "." ]      ; REQ2 REQ3
NTVtypeName     = ["$"] JsonString              ; REQ3

3.1. JsonNTV format

The JsonNTV format is the JSON representation of an NTV entity (JsonValue). This JsonValue is converted in JsonText with a Json generator. The JsonNTV format is defined in Figure 3, which uses ABNF from [RFC5234].¶

; JSON representation of NTV entities (JsonNTV)

JsonNTV        = JsonNTVnamed / JsonNTVsimple      ; REQ5

JsonNTVnamed   = beginObject JsonNTVMember endObject
JsonNTVsimple  = JsonNTVvalue / ArrayValue         ; REQ6
ArrayValue     = beginArray JsonNTVvalue endArray

JsonNTVMember  = JsonNTVname nSep JsonNTVvalue

; Extract of JSON grammar used in this document

beginArray    = ws "[" ws
beginObject   = ws "{" ws
endArray      = ws "]" ws
endObject     = ws "}" ws
nSep          = ws ":" ws
vSep          = ws "," ws
ws = *( %x20 / %x09 / %x0A / %x0D )

JsonValue  = JsonValue   ; indicates that rule is defined in RFC8259
JsonString = JsonString  ; indicates that rule is defined in RFC8259

The JsonNTV format is built with the NTVname, NTVvalue and the JsonNTVtype.¶

Two JsonNTV formats are defined:¶

• named format (if NTVname or JsonType is not an empty string):¶

  • { JsonNTVname : JsonNTVvalue }¶

• simple format (if NTVname and JsonType are empty string):¶

  • JsonNTVvalue¶

The corresponding rules are as follows:¶

• REQ4:

  If JsonNTVname is empty, simple format is used¶

  REQ5:

  If JsonNTVname is empty and JsonNTVvalue is a JsonObject with a single member, ArrayValue is used¶

Note :¶

• JsonNTV : 21, { ":" : 21 } and { ":json" : 21 } represent the same Vsingle entity,¶

3.2. JsonNTVname

JsonNTVname is the concatenation of NTVname and JsonSepType.¶

JsonSepType is composed with the separator singleSep or listSep and the JsonNTVtype.¶

JsonNTVname and JsonSepType are defined in Figure 4, which uses ABNF from [RFC5234].¶

; JSON representation of NTVname and NTVtype (JsonNTVname)

JsonNTVname = NTVname JsonSepType
JsonSepType = [singleSep [JsonNTVtype]]/[listSep JsonNTVtype]
    ; REQ7 REQ8

NTVname = JsonString

singleSep   = ":"      ; NTVsingle separator
listSep     = "::"     ; NTVlist separator

For NTVsingle entities:¶

• REQ6:

  If JsonNTVtype is not "json", JsonSepType is identical to singleSep joined with JsonNTVtype,¶

  else if JsonNTVvalue is not a JsonArray and not a JsonObject, JsonSepType is empty,¶

  else JsonSepType is identical to singleSep.¶

For NTVlist entities:¶

• REQ7:

  If JsonNTVtype is not empty, JsonSepType is identical to listSep joined with JsonNTVtype¶

  else JsonSepType is empty.¶

3.3. JsonNTVtype

The JSON representation of a NTVtype (JsonNTVtype) is a compact representation of the NTVtype in the context of the NTVtypeParent.¶

The JsonNTVtype is defined in Figure 5, which uses ABNF from [RFC5234].¶

; JSON representation of NtvType (JsonNTVtype)

JsonNTVtype = [ NTVtypeLongName / relativeNTVtypeLongName ]
    ; REQ9

relativeNTVtypeLongName = *NamespaceName NTVtypeName
    ; REQ9

The corresponding rules are as follows:¶

• REQ8:

  if NTVtype is identical to NTVtypeParent, JsonNTVtype is empty,¶

  else if NTVtypeParent is a Namespace and if NTVtype is including in NTVtypeParent, JsonNTVtype is the NTVtypeLongName relative to the NTVtypeParent.¶

  else JsonNTVtype is the NTVtypeLongName¶

Example:¶

• If "fr." is the name of a Namespace attached to the global Namespace and containing the NTVtype 'dep', then:¶

  • { "::fr." : { "department1:dep": "name1", "department2:dep": "name2" } } is a valid JsonNTV representation.¶

3.4. JsonNTVvalue

The JsonNTVvalue is the JsonValue representation of NTVvalue as defined in Figure 6, which uses ABNF from [RFC5234].¶

; JSON representation of NTVvalue (JsonNTVvalue)

JsonNTVvalue       = JsonNTVsingleValue / JsonNTVlistValue

JsonNTVsingleValue = NTVsingleValue
JsonNTVlistValue   = JsonNTVarrayValue / JsonNTVobjectValue
    ; REQ10

JsonNTVarrayValue  = beginArray ListJsonNTVvalue endArray
ListJsonNTVvalue   = [JsonNTV  *( vSep JsonNTV )]
JsonNTVobjectValue = beginObject ListJsonNTVmember endObject
ListJsonNTVmember  = [JsonNTVMember *( vSep JsonNTVMember)]

NTVsingleValue     = JsonValue

For a NTVsingle, JsonNTVvalue is the NTVvalue.¶

For a NTVlist, JsonNTValue has two representations:¶

• a JsonArray where JsonElements are the JsonNTV of included NTV entities,¶
• a JsonObject where the JsonMembers are the JsonMembers of the JsonNTV of included NTV entities.¶

The corresponding rules are as follows:¶

• REQ9:

  if NTVlistValue has more than one NTV entities and if all NTVname are different and not empty, JsonNTVobject is used,¶

  else JsonNTVarray is used¶

Example:¶

• { ":point" : [2.3522, 48.8566], ":point" : [4.8357, 45.7640] } is not a valid JsonNTV¶

5.1. JSON decoding

This part is not detailed and consists of:¶

• exploit the JSON structure to identify JsonNTVname and JsonNTVvalue,¶
• extract the following data from the JsonNTVname string: JsonNTVtype, NTVname and singleSep or listSep¶

5.2. NTV entity decoding

The NTV entity is inferred from the JSON structure of JsonValue or JsonNTVvalue:¶

• PARS1:

  The tables Table 1 and Table 2 define the entity identification rules (NTVsingle or NTVlist)¶

5.3. NTVvalue decoding

The NTVvalue is inferred from the JsonNTVvalue:¶

• PARS2:

  The NTVvalue of NTVsingle is the JsonNTVvalue.¶

  PARS3:

  The NTVvalue of NTVlist is the list of NTV entities parsed for each JsonElement or JsonMember including in the JsonNTVvalue.¶

5.4. NTVtype decoding

NTVtype is inferred from the JsonNTVtype:¶

• PARS4:

  If JsonNTVtype is a valid NTVtypeLongName NTVtype is the decoded JsonNTVtype,¶

  else NTVtype is "json" NTVtype if concatened ParentNTVtypeLongName with JsonNTVtype is empty,¶

  else NTVtype is the decoded of concatenation of ParentNTVtypeLongName with JsonNTVtype if it is a valid NTVtypeLongName,¶

  else NTVtype is the defaultNTVtype¶

The [JSON-NTV] repository gives some examples of NTV usage.¶

6.1. NTV tree

An NTV entity is a tree where the leaf nodes are the NTVsingle entities and where the inner nodes are the NTVlist entities.¶

Therefore the tree property are applicable:¶

• tree indicators can be calculate:¶

  • breadth : number of NTVsingle entities (leaves)¶
  • size : number of NTV entities (nodes)¶
  • height : length of the longest downward path to a leaf¶
• An ordering list of nodes can be defined to explore the tree for example according to the DFS pre-ordering algorithm[DFS] (this order is the same as the order in a JsonValue ),¶

6.2. NTV Pointer

A NTV Pointer is a string syntax for identifying a specific NTV entity within a NTV tree.¶

The syntax defined for JSON Pointer [RFC6901] (json-pointer, reference-token) is transposable to NTV Pointer (ntv-pointer, reference-token):¶

• The ntv-pointer is a Unicode string containing a sequence of zero or more reference-tokens, each prefixed by a '/'.¶
• The reference-token is the NTVname if it exists otherwise the zero-based index of the NTV entity in the NTVvalue list.¶

The ntv-pointer is equal to the json-pointer of the JsonNTV representation in most cases except :¶

• if the JsonNTV is a JsonObject with a single member where the value is a JsonPrimitive,¶
• - if the JsonNTV contains a JsonArray containing a JsonObject with a single member where the value is a JsonPrimitive¶

6.3. NTV Comparison

Three levels of equality are defined.¶

Strict equality:¶

• Two NTV entities are strictly equals if :¶

  • the NTVname are identical¶
  • the NTVtypes are identical¶

  • the NTVvalue are identical¶

    • if the NTVvalue is a list of NTV entities, each NTV entity has to be identical¶
    • if the NTVvalue is a JSONvalue, the JSONvalues have to be identical¶

Structural equality:¶

• Two NTV entities are structurally equals if :¶

  • the NTVname are identical¶
  • the NTVtypes of NTVsingle are identical¶

  • the NTVvalue are structurally identical:¶

    • if the NTVvalue is a list of NTV entities, each NTV entity has to be structurally identical¶
    • if the NTVvalue is a JSONvalue, the JSONvalues have to be identical¶

• Example of structural equality (JsonNTV representation):¶

  • {"::int32": [10, 20] } and [{":int32": 10}, {":int32": 20}]¶

Semantic equality:¶

• Two NTV entities are semantically equals if :¶

  • the NTVname are identical¶

  • the NTVvalue are semantically identical:¶

    • if the NTVvalue is a list of NTV entities, each NTV entity has to be semantically identical¶
    • if the NTVvalue is a JSONvalue, the native entity associated to the JSONvalue have to be identical¶

• Example of semantic equality (JsonNTV representation):¶

  • {":datetime": "2011-11-04T10:05:23+00:00" } and {":datetime": "2011-11-04T11:05:23+01:00"}¶

6.4. NTV Canonical

The NTVtype of the NTVlist entities is only useful for constructing the JSON representation (two NTVlists with two different NTVtypes are equal according to the structural equality criteria).¶

A canonical (single) format is chosen to facilitate sharing and analysis of NTV and JsonNTV data. It is defined by setting a value for the NTVtype of an NTVlist entity.¶

The rule is as follows:¶

• REQ10:

  If an included entity is an NTVlist with an empty NTVtype, its NTVtype is empty¶

  If all included entities have an NTVtype 'json', its NTVtype is empty.¶

  In other cases, the NTVtype is the same as that of the first included entity.¶

This rule is simple to implement and allows you to have a compact JsonNTV format (another more complex choice would have been to take the most frequent NTVtype among the included entities).¶

6.5. JSON as a subtype of NTV

The Appendix C shows that there is an equivalence between Json entities (JsonArray, JsonObject, JsonNumber, JsonString, JsonFalse, JsonTrue or JsonNull) and the corresponding NTV entities called JNTV (resp. NTVarray, NTVobject, NTVnumber, NTVstring, NTVfalse, NTVtrue , NTVnull).¶

JNTV entities have several properties:¶

• JNTV and JSON structures are substitutable with respect to functions associated with Json structures (e.g. generation of the JsonText format),¶
• Strict equality or Structural equality between two JNTV entities are equivalent to equality between JsonNTV representations¶
• JNTV are canonical NTV entity¶
• NTV Pointer of JNTV are identical to Json Pointer of JsonNTV representations¶

6.6. extended NTV structure

The NTVvalue of NTV entities are JsonValue. In the extended NTV structure, NTVvalue can be every kind of data.¶

With this structure, the NTV representation is a "json like" data where:¶

• JsonNTVvalue is always NTVvalue,¶
• JsonNTVtype is optional (if NTVtype can be deduced from the NTVvalue),¶
• JsonNTVname is optional (if NTVname can be deduced from the NTVvalue).¶

Examples of extended NTV representation:¶

• • { "python date" : [ datetime.date(2022, 1, 18), datetime.date(2023, 1, 12) ] }¶

• this "json like" structure can be converted in JsonNTV format:¶

• • { "python date::date" : [ "2022-01-18", "2023-01-12" ] }¶

6.7. nested NTVsingle entities

As defined in Section 2.2.1 an entity with Json representation can be taken into account.¶

Appendix A defines usual NTVtypes (e.g. date, coordinate, email) but also NTVtypes associated to structured data (e.g. dataset, NTV data, custom format):¶

The example in Figure 7 is the representation of a NTVlist with three NTVsingle:¶

• "dataset" is a NTVsingle build with a 'tab' structure (NTVdataset defined in [NTV-TAB]). This NTVdataset includes in 'field2' an NTV structure,¶
• "ntvdata" is a NTVsingle build with a 'ntv' structure. This structure includes an other NTV structure,¶
• "sensor" is a NTVsingle build with a custom structure. This structure includes a NTVdataset.¶

ex_list = {
  "structure": {
    "dataset:tab":{
      "field1": [1,2,3],
      "field2": [4,5,{":ntv": {"min": 6, "max": 7}]
    },
    "ntvdata:ntv":{
      "equinox:date": "2024-03-20",
      "paris:point": [2.35, 48.85],
      "other data:ntv": {"val1": 1, "val2": 2}
    },
    "sensor:$sensor": [
      8.51, 3.5, 4.2,
      {":tab": [[1,2,3,4], [5,6,7,8]]}
    ]
  }
}

Nested NTVsingle is treated as simple NTVsingle and can be used with extended NTV structures.¶

9.1. Normative References

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC7946]

Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S., and T. Schaub, "The GeoJSON Format", RFC 7946, DOI 10.17487/RFC7946, August 2016, <https://www.rfc-editor.org/info/rfc7946>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC6901]

Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/info/rfc6901>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC7950]

Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

9.2. Informative References

[DFS]

"Wikipedia", "Depth-first search algorithm", <https://en.wikipedia.org/wiki/Depth-first_search>.

[NTV-TAB]

Thomy, P., "NTV tabular format (NTV-TAB)", 2023, <https://datatracker.ietf.org/doc/draft-thomy-ntv-tab/>.

[JSON-ND]

Kleidon, G., "JSON-ND", 2020, <https://github.com/glenkleidon/JSON-ND>.

[JSON-NTV]

Thomy, P., "JSON-NTV", 2022, <https://github.com/loco-philippe/NTV#readme>.

[OLC]

"Google", "Open Location Code", 2016, <https://github.com/google/open-location-code>.

[W3C_TAB]

"W3C", "Recommendation : Model for Tabular Data and Metadata on the Web", 17 December 2015, <https://www.w3.org/TR/2015/REC-tabular-data-model-20151217/>.

[ISO_3166-1_alpha-2]

"ISO", "Codes for the representation of names of countries and their subdivisions - Part 1: Country code", 2020, <https://www.iso.org/standard/72482.html>.

[TABLE_SCHEMA]

"Frictionless", "Table Schema specification", 5 October 2021, <https://specs.frictionlessdata.io/table-schema/#types-and-formats>.

[JSON_SCHEMA]

"JSON Schema", "JSON Schema validation", 16 June 2022, <https://json-schema.org/draft/2020-12/json-schema-validation>.