7. データ形式 -- JSON

6.1 JSONの定義

2022年5月11日

　JSONの文字列は以下の通り定義されています。厳密な定義はこちら。

	<JSONの文字列> = <値>
	<値> = false \| null \| true \| <object> \| <繰返し> \| <数値> \| <文字列>	# falseという5文字です　# nullという4文字です　# trueという4文字です
	<object> = {} \| { <要素> } \| { <要素>, <要素>,・・・}	# 要素が無い場合　# 要素がひとつの場合　# 複数の要素はカンマで区切る
	<要素> = <キー> : <値>	# 値は入れ子になることも出来ます
	<キー> = <文字列>
	<繰返し> = [] \| [ <値> ] \| [ <値>, <値>, ・・・]	# 値が無い場合　# 値がひとつ　# 複数の値はカンマで区切る
	<数値> = 0 \| (-)<1-9の数字><0-9の数字列> \| (-)<1-9の数字><0-9の数字列>.<0-9の数字列> \| (-)<1-9の数字><0-9の数字列>e(+\|-)<0-9の数字列>	# 値がゼロの場合　# 先頭は0以外> 　# <0-9の数字列>はゼロ個でも良い　# 小数点以下は1個以上の数字　# 指数は1個以上の数字　# eは大文字のEでも良い
	<文字列> = "" = "<文字><文字>・・・"	# 長さがゼロの文字列　# 任意の長さの文字のの並び
	<文字> = <\と"と制御文字以外の文字> \| \" \| \\ \| \/ \| \b \| \f \| \n \| \r \| \t \| \u<4文字の数字>	# 日本語も可　# "の書き方　# \ 　# / 　# バックスペース　# フォームフィード　# LF 　# キャリッジリターン　# タブ　# ユニコード

　この他に以下の決まりがあります。

ユニコードが16ビットを超える場合は、UTF-16の規定に従ってユニコードを32ビット、つまり\u0123\u5678"の様に表すことも可能だが、それを処理可能かどうかは環境依存としている。つまり、スマートシティの様な不特定多数間でデータ交換する場合、顔文字の様な16ビットを超える文字は使うべきではないとの注意書きも標準に記載がある。
同じキーが複数回出現した場合、どれかひとつが有効となり、他は無視されます。

JSONを拡張したJSON-LD文字列では、@で始まる文字列は特別な意味を持ちます。このため、将来の互換性を考慮して@が付いたなるべく避けて置いた方が良さそうです。

6.2 JSONの記述例

2022年8月13日

　例えば、以下は全てJSONの文字列です

	"abc"	: 単純な文字列です。文字列はダブルクォートで囲みます。
	"広島県"	: 日本語も使えます
	123.456	: 数値はそのまま書きます
	{"都道府県": "広島県"}	: 波括弧で囲ってkey-valueベアを書きます。
	["広島県", "北海道"]	: 繰返しは大括弧で囲みます。
	{"都道府県": ["広島県", "北海道"]}	: 入れ子になっていても構いません。
	{"出身地": [{"都道府県": "広島県", "市町村": "呉市"}, {"都道府県": "北海道", "市町村": "札幌市"}]}	: どんどん入れ子になっていっても構いません。
	{ "出身地": [ { "都道府県": "広島県", "市町村": "呉市" }, { "都道府県": "北海道", "市町村": "札幌市" } ] }	: 前の例と全く同じ意味です。空白や改行は無視されます

6.3 JSON-LDの定義

2022年〇月〇日

未稿

6.3 当面の実装で用いるデータ形式(案)

2022年8月13日

　前章で検討したように、NGSI-V2を使いつつ、将来的にNGSI-LDへの移行が必要となったときに、出来る限り機械的な移植や、何らかの連携基盤経由でNGSI-LDのインタフェースも受け付けられるように工夫する事を提案します。
　具体的には、以下の方策で進めてはどうかと考えます。

Coppell Technologies