共通データ仕様 / データモデル (コンピュータ用の帳票のひな形)

データモデルへのインデックス

　リンクをクリックすると、データモデルの定義にジャンプします。データモデルやデータモデルを使う上でのルールについては、このページの後半に記載してあります。各データモデルの記載で、丸数字で示しているカラムは、帳票を使う目的に応じた項目への登録の要否です。「必須」と書いてある項目(Attribute)は継承元のデータモデルまたはNGSI V2で必須項目と指定されている項目、またはデータモデル間の関係上などアプリに因らず必須となる項目です。

■データモデル / 施設の基本情報

　これらの情報は施設管理だけでなく、一般的に使われるであろうデータモデルの定義です。従って、これらのデータはオープンデータなどとして幅広く公開される事が期待されます。

• 法人 (Organization)
  自治体と民間団体共通の法人を表現するデータモデルです
• 部門 (Department)
  法人 (Organization) 内の部門や機能を表現するデータモデルです
• 土地 (Land)
  土地、敷地、公園などを表現するデータモデルです
• 建物 (Building)
  物理的な建物を表現するデータモデルです。一般的な”ビル”だけてなく、アパート、集会所、住宅、神社仏閣などの建物一般を表現します
• 施設 (Facility)
  施設を表現するデータモデルです
• 統計 (FacilityStatistics)
  施設の統計情報を表現するためのデータモデルです。施設カルテなどへの掲載を想定しています

■データモデル / 公共施設の施設管理向けの情報

　主に施設管理向けに策定した、建物や施設の詳細部分に関するデータモデルの定義です。これらのデータは次の「各作業報告書」から参照されるため、次項の公開範囲と同じ範囲で公開される事が期待されます。

• 部位 (BuildingComponent)
  建物の部位を表現するデータモデルです。部位とは、「フェンス」「門扉」などを指します。但し、全ての部位について事細かにデータ登録する事は想定しておらず、建物の中で名称が付くような部位や不具合の発生状況を時系列に分析したい部位などを登録します。例えば名称の観点で言えば「正面玄関」「職員玄関」などを想定しています。分析の観点で言えば、ユースケース#5の様な使い方をします。これらの名称は、「建物」や「施設」のZonesでもある程度管理できるため、どちらをどう使うのかは事業者やオーナーの裁量の範囲と考えています。
• 設備 (Device)
  建物や施設に設置されている設備を表現するためのデータモデルです。設備は運搬可能なものを含みます。
• 機種 (DeviceModel)
  設備の機種などの設備の共通情報を登録するためのデータモデルです。

■データモデル / 各作業報告書

　主に施設管理向けに策定した、建物や施設の詳細部分に関するデータモデルの定義です。これらの情報は関係者間で共有されるシェアードデータとする事が期待されます。データを共有する範囲には少なくとも自治体などのオーナーと包括施設管理事業者を含む必要があると考えられます。ここで言う包括施設管理事業者とは、包括施設管理業務委託を受託している事業者だけでなく、受託を検討している事業者なども排除しない事が必要です。また、CivicTechなどとの連携の際にも一部の情報を共有する必要がありますので、自治体の判断でデータを共有する範囲を拡大できる様にする事が必要です。

• 案件 (Complaint)
  不具合(故障・破損等)案件を表現するデータモデルです
• 報告 (Report)
  施設管理を行う事業者から自治体へのレポートを表現するデータモデルです

データモデルとは

　コンピュータに都合がよい形式の帳票のひな形をデータモデルと呼びます。一般の帳票には多数の項目が並んでいますが、コンピュータ向けの帳票であるデータモデルもまったく同じです。例えば、ある「土地」の情報を登録する帳票やデータモデルには、どちらも「名称」「形状」「住所」などの項目があります。この様にどちらも帳票も複数の項目が並んでいるだけです。

　データモデルでは、項目のことを属性とか、Attributeとか、Propertyとも呼びますが、同じものだと理解しておいてください。

データモデルに関する技術情報

■準拠規格

　　各データモデルは、準拠規格に記載した通り、NGSI V2に準拠するとともに、基本的にGIFのコア・データモデルを継承して作られています。コア・データモデルに継承すべきデータモデルが無い場合は、Smart Data Models等の標準的なものを継承しています。何を継承したかは、各データモデルの技術情報に記載してあります。

■本データモデルへの準拠の考え方

　本データ仕様のデータ形式(データモデル)に準拠したと称するには、ここに開示するデータモデルに従った形式でデータを提供する必要があります。但し、提供する時期は問いません。ケーススタディなどで記述している様に、通常はcsvファイルやExcelファイル等で提供しておいて、必要時に形式を変換しても構いません。仕様を拡張したい場合は、「共通データ仕様の使い方」を参照してください。繰返しになりますが、本データ仕様は団体間のデータ交換や都市OSにデータ登録するための仕様ですので、各事業者独自のシステム内まで準拠する必要はありません。
　既に記載した様に各データモデルにおいて、丸数字で示しているカラムは、目的別の登録の要否です。「必須」と書いてある項目(Attribute)は継承元のデータモデルまたはNGSI V2で必須項目と指定されている項目、またはデータモデル間の関係上などアプリに因らず必須となる項目です。丸印は登録が必要な項目、無印は登録を推奨している項目です。但し、丸印がある項目が登録されていないからと言って共通仕様に反していると言う訳ではありません。自治体毎に帳票やルールが異なるため、登録が出来ない、登録が不要となる場合には、関係者で相談の上、登録を省略する事も可能です。但し、本仕様で規定している情報を別の項目名(Attribute name)で登録したり、登録した項目の値が本仕様と合致していない場合は、準拠しているとは認められません。

■データモデルの見方

　各データモデルの定義は以下の通りです。

• Attribute name: 項目の名称です。NGSI V2の規定に従い、米国英語を繋げた小文字で始まるLCC形式になっています。
• 回数: 値を幾つ登録して良いかを示しています。回数は”a::b”の記号で書かれていますが、aが最小回数、bは最大回数です。つまり、”0::1″はデータを登録してもしなくても良いが、登録数は最大1個という意味になります。最大数bがnの場合は、登録する値の数に制限が無い事を示しています。回数が0の時は、そのAttributeやSub-attribute自体の記述を省略します。また、最終回数が0でないAttributeであっても、そのAttributeを省略したからと言って本データ仕様に準拠していないとは言いません。これは、本来的に最小回数は業務に依存するためです。勿論、本データ仕様は多目的に活用できる様に策定しているため、省略する場合は用途が制限されない様に配慮してください。
• type: 登録する値の形式です。例えばTextは単語などの文字列で、Numberは数値です。興味がある方は、準拠規格のデータタイプをご覧ください。データパーツを利用している場合、ここにデータパーツの名称が記入されています。typeがArrayの場合、どの様な構造のものが繰り返されているのか、カッコ内に補足している場合があります。但し、NGSI v2上はその様な技術を直接する箇所はありません
• 補足: Attributeの説明です
• 丸数字: 利用する際の参考情報です。登録の必要性が高いAttributeには印がついています。

　各データモデルには技術情報も掲載されていますが、技術情報の各項目は以下の意味を持ちます。

• 定義名: 定義に与えられた識別子であり、Entity typeです
• 継承元データモデル: その定義を策定する際に元となったデータモデルや規定類を示しています
• 参照データモデル: その定義を策定する際に元となったデータモデルや規定類で、継承元データモデル以外のものを示しています
• URI: 定義名には他の団体等で策定したものと同名の可能性があるため、識別するためのURLです。。尚、各ヘッダに記載しているURIは、NGSI V2の後継規格であるNGSI-LDが準拠しているデータ形式であるJSON-LDに規定されているものです。本来はIRIと記載すべきものですが、NGSI-LDの記載に倣い、URIと記載しています。このURIが一致していると、データモデルの定義が一致しているという意味を持ちます。
• JSON Schema: データの形式(データモデル)をコンピュータが理解しやすい形式(マシンリーダブルと言います)で記述したものです。主に、データの形式チェックツールで利用されます。JSON Schemaは多様な記述を許していますが、ここでは基本的な記述しかありませんので、必要に応じて加筆修正が必要です
• 補足: 文字通り、補足です

データモデル間の関係