定義の前提 |
分類 | 説明 | ||
文字セット | Unicodeです。国内の規定ではJIS X 0213と決められていますが、Unicode 3.2で規定に包含されており、現在はUnicodeを採用する事はJIS X 0213に準拠する事が可能であることを意味します | ||
符号化方式 | UTF-8です。BOM無しです。 | ||
語彙 | 日本では、GIFのコア語彙というものが策定されています。但し、個々の業務から見るとコア語彙は選択肢が多く、Property Nameも決められておらず、schema.org等の標準とも異なる場合があります。そこで、データモデル間の揺れを抑え、グローバル標準と整合するために、より細かな規定をデータモデル策定時に規定していく必要があります。 | ||
呼出しインタフェース | WebAPIです。NGSI V2では具体的なエンドポイントなども指定してあります | ||
情報モデル | NGSI v2に準拠する三階層モデルです。但し、後継のNGSI-LDへの移行容易性を考慮する必要があり、三階層目のMetadataの利用はなるべく避けた方が無難です。 | ||
データ形式 | JSONです。地図上の位置や形状を示す座標についてはGeoJSONです。 | ||
データ モデル |
データモデル名 | 大文字で始まる米国英語で構成されるキャメルケース文字列 (UCC) です。 | |
データ構造 | 個々のコトやモノに対応して、策定していく必要があります。データモデルを策定するとは、このデータ構造を具体的なデータ関係の関係や項目名や値を策定する事になります。 | ||
データ間の関係 | EntityのidをPropertyのValueとして保持することで表現します。Value typeはRelationshipです。 | ||
項目 | 項目名 | 小文字で始まる米国英語で構成されるキャメルケース文字列 (LCC) です。 | |
値 | 表記 | idは将来のNGSI-LDへの移行を考えNGSI-LDの規定に従います。 数値、文字列、日付、時刻、電話番号はGIFのコアデータパーツに複数ある規定の内、グローバル標準に合致するものを採用します。 住所はGIFの規定は自由度が高く、多数定義されていますので、schema.orgのPostalAddressに合わせた3項目に分離する形態を採用します。 曜日はGIFの規定は純粋な国内規定なので、グローバルに合わせる事にします。 座標はGeoJSONの規定に従いますが、精度についてはGIFの規定通り小数点以下6桁を標準とします |
|
単語 | 揺れ予想される場合は、語彙またはデータモデルで列挙型項目とし、設定して良い単語を限定します。但し、読み手が人間であることを期待する項目については、この限りではありません。 | ||
コード | 国コードの様にグローバルに統一されているもの以外は、なるべく列挙型項目とします。 | ||
列挙型メンバ | 各々のメンバが何を指しているのか、個々に規定します。共通化すべきものは語彙や共通パーツとして規定します。 |