ケーススタディ#2 – CSVから共通データ仕様の形式への変換 (1/14)

ケーススタディ概要

 ケーススタディ#1で述べたように、多くの自治体では「CSV等の自治体職員が利用可能な形式で電子データの提供」を求めている例が多くあります。CSVの利点は表形式であり、Excel等の表計算ソフトでも読み込めることから、目的に合わせてうまく設計すると受け取った側が便利である事が挙げられます。一方、CSVの課題はケーススタディ#1で詳しく述べた様に数々の制約を回避する過程で多くの情報が欠落してしまう事でしたが、もう一つ大きな課題はデジタル庁などの政府が推し進めているエリア・データ連携基盤の仕様に合致しないため、エリア・データ連携基盤の入力としては使えない点です。そこで、ケーススタディ#2ではケーススタディ#1で策定したCSVファイルから共通データ仕様のデータモデルへの変換例を示します。本ケーススタディの目的はケーススタディ#1で策定した仕様が共通データ仕様の形式に変換可能である事を示す事であり、この手法を推奨するものではありません。つまり、ケーススタディ#1の補足情報として提示するものです。

 このケーススタディでは、JSON Schemaという新しい考え方を導入したり、ネット上の無償のソフトを活用したりします。従って、もしCSVから共通データ仕様の形式に変換するのであればPython等の簡易な言語を使って変換プログラムを個別に作成した方が簡便かもしれません。また、元々CSVには多くの課題があり、事業者のFMシステムはもっと複雑なデータ構造で管理している筈であり、一旦CSVとして出力してから共通データ仕様の形式に変換すると、有用な情報が欠落してしまうため、引き継ぎ等には相応しくない可能性があります。 

利用ツール概要

 このケーススタディでは、無償公開されているCoppell Technologiesの”ctoj“というツールを利用します。このケーススタディの末尾にツールを自製する記事を掲載しましたので、ctojがうまく動作しない場合や機能が足りない場合は自製も検討してみては如何でしょうか。このツールでは、JSON Schemaを独自に拡張した拡張JSON Schemaを使っています。拡張JSON Schemaの元となるJSON Schemaは各データモデル説明のWebページからダウンロードできます。そのJSON SchemaにCSVから変換するルールを追記する事で、拡張JSON Schemaは作成できます。

CSV表と共通データ仕様のデータモデルとの関係

 ケースタディ#1ではデータモデルの項目(Attribute)から各CSVの項目を前提してきました。本ケーススタディでは逆にCSVから共通データ仕様の形式の電子データを作るので、CSV表とデータモデルとの関係は以下となります。

元となるCSV表の名称変換後のデータモデル
オーナー情報表法人(Organization)
所管部門一覧部門 (Department)
建物一覧土地 (Land)
建物一覧、場所一覧建物 (Building)
施設一覧施設 (Facility)
部位一覧部位 (BuildingComponent)
設備一覧設備 (Device)
機種 (DeviceModel)
案件一覧案件(Complaint)
報告一覧報告(Report)

“id”の形式ルール

 ケースタディ#1の各CSVの例では、各データモデルの”id”に相当する○○IDという項目は定義しましたが、例示したCSVでは採用しませんでした。そこで、”id”をどの項目から生成するのかのルールを以下の様に定めます。その代わりにCSVで各行を区別するために設定した項目が「”id”の元の項目」です。この項目は共通データ仕様に該当する項目がある場合も無い場合もあります。

データモデルCSVの項目名“id”の元の項目“id”への変換ルール
法人(Organization)法人ID国コード、法人番号”urn:ngsi-ld:Organization:”<国名コード><法人番号>
<国名コード>は日本の場合は”JP”、法人番号は13桁の数字からなる文字列です。
部門 (Department)部門ID国コード、法人番号、部門コード”urn:ngsi-ld:Department:”<国名コード><法人番号>”-“<部門コード>
らなる文字列。部門コードは組織の中で一意となる文字列であり、本ケーススタディでは7桁の文字列です。
施設 (Facility)施設ID国コード、法人番号、施設コード”urn:ngsi-ld:Facility:”<国名コード><法人ID>-<施設コード>
施設コードはオーナーの法人内で施設を一意に識別する文字列であり、本ケーススタディでは7桁の文字列です。
建物 (Building)建物ID国コード、法人番号、管理通番”urn:ngsi-ld:Building:”<不動産ID>
但し、本ケーススタディでは不動産を登記していないと想定しており、不動産IDが無いため以下とします。
”urn:ngsi-ld:Building:”<国名コード><法人番号>-<管理通番>
土地 (Land)土地ID国コード、法人番号、管理通番”urn:ngsi-ld:Land:”<不動産ID>
但し、本ケーススタディでは不動産を登記していないと想定しており、不動産IDが無いため以下とします。
”urn:ngsi-ld:land:”<国名コード><法人番号>-<管理通番>
管理通番は建物の管理通番です。本ケーススタディは土地を個別に管理せず、建物と一体で管理する想定のため、建物の管理通番を利用しています
部位 (BuildingComponent)部位ID(なし)”urn:ngsi-ld:BuildingComponent:”<一意となる文字列>
ケーススタディ#1ではCSVの行を区別する項目はありませんでした。しかし、現実のFMシステムでは何等かの項目があったはずで、それを使えば良いでしょう。尚、”id”は半角英数字と幾つかの限られた記号しか使えない事に注意してください。本ケーススタディでは、「部位コード」を追加します。中身は単純な通番です。
設備 (Device)設備ID国コード、法人番号、モデル名、製造番号”urn:ngsi-ld:Device:”<国名コード><メーカの法人番号>-<モデル名>-<製造番号>
機種 (DeviceModel)機種ID国コード、法人番号、モデル名”urn:ngsi-ld:DeviceModel:”<国名コード><メーカの法人番号>-<モデル名>
報告(Report)報告ID国コード、法人番号、案件コード、枝番”urn:ngsi-ld:Report:<国名コード><メーカの法人番号>-<案件コード>-<枝番>
<案件コード>は次の案件に関する項目です
案件(Complaint)案件ID国コード、法人番号、案件コード”urn:ngsi-ld:Complaint:”<国名コード><法人番号>-<案件コード>