• Coppell Technologies

    Coppell Technologies

    Data Model Use Cases

    • トップ
    • 1. データモデルの共通パーツ
    • 2. 推奨データセット
    • 3. 公共施設管理

    Menu


    Coppell Technologiesトップ
    Fiwareで都市OSを動かしてみよう
    NGSI-LDにも挑戦
    データ仕様の現状と課題
    データ交換の標準規格 (案)

    Data Model Use Cases
    ユースケース
    • トップ
    • はじめに
    • 1. データモデルの共通パーツ
    • 2. 推奨データセット
    • 3. 公共施設管理

    Column
    Link集
    用語集

    Coppell

    Technologies

    はじめに


    2022-09-15

     本書では、実際にスマートシティで利用するデータモデルの定義を行います。また、データモデルの前提となる共通定義も並行して定義します。尚、GIFにコア語彙が統合され、DSAでドメイン語彙の作成方法の策定も進みつつあります。そのため、語彙とは何か、どの様なものを語彙と呼ぶかなどが変わっていく可能性があります。そこで、この共通定義はドメイン語彙とは呼ばず、データモデルの共通ハーツとして策定するとともに、共通パーツ策定時には語彙に相当する基本的な定義も併せて記載していく事にします。本書ではこの共通定義を「データモデルの共通パーツ」と呼ぶことにします。


    ■目次

     1 データモデルの共通パーツ
      1.1 StructuredValue type
      1.2 Attribute
      1.3 列挙型項目
     2. 推奨データセット
      2.1 モノ・コトの抽出
      2.2 モノ・コトのデータ項目策定
      2.3 データ項目定義書の仮作成
      2.4 データ項目定義書の作成
     3. 公共施設管理
      3.1. データモデル - 基本情報
       3.1.1 自治体
       3.1.2 所管部門
       3.1 3 公共施設
       3.1.4 土地
       3.1 5 建物
      3.2. データモデル - 公共施設管理
       3.2.1 施設管理事業者
       3.2.2 設備/デバイス
       3.2.3 障害・通報
       3.2.4 レポート
       3.2.5 受託事業者
       3.2.6 担当事業所
      3.3 列挙型メンバ定義



    定義の前提
     グローバルに見ても国内を見てもインタネットで使用されるデータ交換のための多くの規定があります。当然の事なから、各種規定はインタネット技術のの進化や応用範囲の広がりに伴い、進化し或いは淘汰されていきます。淘汰されるといっても、完全になくなるのではなく、その趣旨は次の規定群に継承され生き続ける事が多い状況です。
     今年、一般社団法人データ社会推進協議会からエリアデータ連携基盤の推奨モジュールの情報公開がありました。この「推奨」とは、デジタル庁がデジタル田園都市国家構想の活動の中で、推奨としているものです。スマートシティは一般に自治体が関係する事が多く、この推奨モジュールを活用する事が予想されます。このため、本書では推奨モジュールの規定や仕様に従い定義を行います。具体的には以下の通りです。詳細な内容は、「データ交換の標準規格」をご覧下さい。

    分類 説明
    文字セット 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桁を標準とします
    単語 揺れ予想される場合は、語彙またはデータモデルで列挙型項目とし、設定して良い単語を限定します。但し、読み手が人間であることを期待する項目については、この限りではありません。
    コード 国コードの様にグローバルに統一されているもの以外は、なるべく列挙型項目とします。
    列挙型メンバ 各々のメンバが何を指しているのか、個々に規定します。共通化すべきものは語彙や共通パーツとして規定します。



      
    Coppell Technologies