ケーススタディ#1概要
共通データ仕様を活用頂いている自治体に限らず、多くの自治体で「CSV等の自治体職員が利用可能な形式での電子データの提供」を求める例が多くみられます。自治体職員が利用可能という指定ですので、現実的にCSVかExcelの様な表計算ソフトの形式での提供になるかと思います。共通データ仕様として公開しているデータモデルはNGSI V2に準拠する形式であり、CSVや表計算ソフトとは完全な互換はありません。自治体に提出する電子データの仕様も共通データ仕様を参考とするのかどうかは自治体により異なりますが、全く違う仕様のCSVファイルを作成する事は事業者の手間を増やすだけなので、共通データ仕様のデータ形式と変換可能なCSVファイルを設計する事が望ましいと考えます。そこでこのケーススタディでは、共通データ仕様を下敷きとしたCSVファイルの設計例を示します。
尚、電子データは自治体職員が自から利用する目的で提出する場合と事業者交替時に提出する場合があると思いますが、本ケーススタディでは自治体職員が利用するための電子データを前提とします。
本ケーススタディでは実際にCSVファイルを設計しますが、その前にまずはCSVファイルを活用する上では課題や、施設管理で予め考えておくべき事をまとめます。
尚、本ケーススタディで使用してる施設の情報はケーススタディ#0に記載しましたので、そちらもご覧ください。
利用しやすいCSVの設計
このケーススタディでは自治体の職員が利用する事を目的としていますから、以下の点について考慮する事にします。
| 説明 | |
|---|---|
| 視認性の確保 | 項目名から内容が容易に想像できる様に、項目名は日本語とします。また、単に「名称」の様な一般的な項目名ではなく「建物名」とか「設備名」などと具体的な名称とします。 |
| リンクの回避 | 人間が利用する事を考えると、ひとつの表内に必要な情報が収まっている事が必要です。例えば、汎用性を確保しようとすると、土地と建物は別のCSVとし、建物から土地をリンクした方が良い事があります。建物の敷地が複数の土地に跨っている場合や、ひとつの土地に複数の建物が建っている場合などもリンクを使えは表現できますがひとつの表で表現する事は困難です。しかし、施設管理の目的に限定するのであれば、建物のCSV表の各行に土地の情報も盛り込んだ方が使いやすいと考えられます。 |
| idを使わない | 共通データ仕様が準拠しているNGSI V2では”id”という項目を必須としています。”id”はデータの一つひとつを区別するための項目であり、NGSI V2では世界で一意に識別できるurnと呼ばれる識別子を使う事を推奨しています。しかし、idは結構長い文字列であり、またオーナーにとっては提出されるCSVの中でどの行なのか区別出来れば良いだけなので、idの代わりに出来る限りオーナーにとって馴染みやすい項目を検討します。 例えば「建物(Building)」であれば”id”とは別に”facilityID”という項目があります。これは事業者によっては”施設ID”などと呼ばれる管理上建物を区別するための文字列であり、同じ所有者の建物であれば重複する事はありません。チュートリアルでは、”facilityID”の日本語の項目名を”管理通番”としています。自治体職員が活用するCSVの場合はこの様な情報を活用する事で、”id”をCSVでは利用しなくても良い様に配慮する事が可能です。また、データを区別する情報は、出来る限り簡単な変換でidに変換できる様に考えておくべきでしょう。 |
| CSVでは意味のない項目の排除 | 共通データ仕様が準拠しているNGSI V2では”type”という項目を必須項目としています。これは、NGSI V2では複数の種類の情報をまとめてエリア・データ連携基盤に登録するため、情報の種類を区別するためです。しかし、CSVは情報の種類ごとにバラバラに作成するため、種類を区別する必要がありません。このため、”type”はCSVの項目とはしません |
CSVファイルの課題
CSVファイルはExcelなどの表計算ソフトで読み込んで活用できるなどの利便性がある一方、CSVは表形式である事から以下の様な多くの制約事項があります。
| 説明 | |
|---|---|
| リスト表現ができない | 共通データ仕様が準拠している仕様であるNGSI V2では、複数の値を持つリスト表現を許しています。リスト表現とは”通称”の様に幾つもの値を持つものを指します。例えば法人の通称を登録する事を考えると、東日本旅客鉄道株式会社の場合利用者はJR東日本、JR東、JR East、JREなどの多様な呼び方をしていますが、このように値が幾つあるのか分からない場合に表形式で表現するには、通称一覧の様な別のcsvファイルを作るか、通称の数を制限して「通称1」「通称2」「通称3」などといった複数の項目を設けるなどの方法をとる必要があります。また、カンマなどを挟んで複数の値を一つの項目内に並べて記述するなど、独自の記述方法で回避する場合もありますが、データを受け取った側は個別に対応する必要があり、余り望ましい回避方法とは言えません |
| 数値表現があいまい | CSVは基本的にすべての値は文字列ですが、文字列が数字だけからなり、数値にも見える場合の処理は処理系に依存します。例えば、Excelでは何も属性を指定しないで”0123”という文字列を読み込むと、数値であると解釈され”123″と書き換えられてしまい頭の”0″と言う文字が消えてしまいます。 |
| 論理表現ができない | 普及している表形式の仕様には値をTrueやFalseで表現する論理表現はありません。一般には”有”と”無”や、”真”と”偽”の文字を入れる事で代替えします。そうすると利用者は例えば”調査中”とか”不明”などの文字列を勝手に登録する事が可能となってしまい、データが”汚れる”原因となります。 |
| 構造表現ができない | 表形式では構造を持つ値は表現できません。構造を持つ項目とは例えば住所の様に「都道府県、市区町村、それ以下」の複数の値から構成されている様な項目です。この様な場合は一般に項目を分けます。前記の住所の例ではみっつの項目を分けて「住所の都道府県」「住所の市区町村」「住所のそれ以下」等の様に項目を分けて登録します。 |
| 不定な項目名を表現できない | 共通データ仕様はGIFのコア・データモデルのID情報型等を継承する事で項目名を値として利用時に定義可能な形式を含んでいます。例えばID情報型をNGSI V2の形式に変換したidentificationGroupという項目では “identificationGroup”: [ {“identificationType”: “自治体コード”, “identification”: “0123456”}, {“identificationType”: “法人番号”, “identification”: “4321-4940980123456”} ] と記載する事を可能としています。表形式では項目名を予め決めておく必要があるので、この形式はCSVでは表現できません。回避方法としては「自治体コード」と「法人番号」に項目を分けて登録すれば良いのですが、その代わり新たな項目を追加すると仕様が変わってしまい、柔軟性が低下します。 |
| 項目が無い状態を表現できない | CSVでは各行の構造は一致している必要があるので、ある行だけある項目が無いという状態を表現できません。まだ登録していない項目が、未登録なのか値が無いのかが区別がつきません。例えば前記の”通称”の例では、CSVでは通称をまだ登録していない状態と通称は無い事を登録している状態が区別できません。 |
| 値が無い状態を表現できない | 前項と似ていますが、CSVでは項目はあるが値が無いという状態を表現できません。値が空であるとか長さがゼロの文字列であるという事とは厳密には違います。表形式の場合は長さがゼロの文字列となってしまいます。 |
| 項目の順番が意味を持つ | 表形式の場合、項目には順番があり何番目の項目なのかに意味を持たせることが可能です。この様な使い方をすると、項目を追加すると順番がずれたりして処理する際に不具合を発生させます。一般的には一行目を項目名が並んでいる行とし、二行目からは一行目の項目名で区別して処理する事で回避します。 |
| 文字コードが多様 | インタネット上の文字コードはUTF-8に収れんしつつあります。NGSI V2の文字コードもUTF-8であり共通データ仕様もUTF-8ですが、CSVや表計算ソフトは多様なコードを許しています。文字コードの変換は可能ですが、変換時に文字化けするリスクがあります。 |
| 目的毎に表を作る必要がある | 前記の様な課題を回避する際、データーの利用目的に合わせて回避方法を選択する必要があります。従って、多様な目的に利用できる様な表の設計は困難であり、結果的に似て非なる表が沢山出来てしまいます。沢山の表が出来ると、項目値の更新や修正が困難であったり、コストが増大するなどの弊害があります。この課題が実用上は最も大きな課題なのかもしれません |
CSVの制約に対する対処方針
本ケーススタディでは、前記の制約に対して以下の方針で回避します。
| 対応方針 | |
|---|---|
| リスト表現ができない | 以下の選択肢から個々に回避方法を選択します。 ・CSVファイルを分離します。但し、分離した表がそれだけで意味を持つ場合に限ります。リストが多重になっている場合は末端の値を一行として展開して表の数が増えない様に配慮します ・値の個数を制限します。例えば、連絡先などは一つに限定します ・その項目を使わない事にします。例えば、通称は施設管理の観点だけからは無くても業務に支障が無いと想定します |
| 数値表現があいまい | 利用者責任とします。例えば、Excelの場合は全ての項目を文字列として読み込み、その後で手動で必要な項目を数値に指定しなおす操作となります。 |
| 論理表現ができない | ”有”と”無”や、”真”と”偽”の文字を入れる事で代替えします。 |
| 構造表現ができない | 項目を分けます。前節の住所の例ではみっつの項目を分けて登録します。 |
| 不定な項目名を表現できない | 項目を分けます。前節のidentificationGroupの例では、”自治体コード”という項目と”法人番号”という項目の二つの項目に分けて登録します |
| 項目が無い状態を表現できない | 利用者責任とし、存在しない項目には長さがゼロの文字列を登録します。 |
| 値が無い状態を表現できない | 利用者責任とし、項目値が無い(空である)場合には長さがゼロの文字列を登録します。 |
| 項目の順番が意味を持つ | 一行目を項目名の行とし、二行目からは一行目の項目名で区別して処理する事とします。従って、Excelでカラムに関数を設定していたりマクロを使っている場合には、項目の位置がずれると動作が不正になる場合があります。また、項目の順番に意味を持たせないので同じ項目名は許されず、全ての項目の項目名は異なるものでなければなりません。 |
| 文字コードが多様 | 利用者責任とし、オーナーと事業者が協議して決める事とします。尚、共通データ仕様が準拠しているNGSI V2はUTF-8を採用しており、インタネット上のデファクトスタンダードもUTF-8であることから、特に理由が無ければUTF-8の採用が望ましく本ケーススタディではCSVもUTF-8であるとして説明しますし、データーの提供者と利用者との間で、予めどのコードでやり取りをするのか取り決めをしておく必要があります。 |
| 目的毎に表を作る必要がある | 対応しません。本ユースケースではオーナーの担当者が分析等の作業を行うために提出する表に限定して検討を進めます |
CSVの単純化
前記のCSVの制約事項に対する処置方針に加え、以下の方針とすることで、CSVの単純化を図ります。尚、単純化するという事は情報が失われる事を意味しますので、これが受け入れ可能かどうかは建物の所有者と事業者間で事前合意しておく必要があります。また、事業者間の引継ぎでの活用は望ましくないので、注意が必要です。
| 対応の内容 | |
|---|---|
| 建物の棟別情報 | 共通データ仕様では「建物(Building)」を階層化して建物全体と棟毎の情報をそれぞれ登録する事が可能です。これを表形式で表現する時には棟毎の詳細情報は割愛する事にします。これにより、12条点検や防火点検の棟毎の情報は電子データ化されなくなります。但し、各棟の名称は建物全体の項目「場所(Zones)」に登録されているものと思われますので、名称は表形式に登録されます |
| 多重リスト表現 | 多重リストを別の表として分離する場合、単純にリスト毎に表を作成すると表の数が多くなってしまうので、最も内側のリストを表の各行に割り当てて、その外側のリストの各項目は各行に付加する。その側のリストは同じ値の行が出来てしまうが、CSVファイル数を減らす事を優先します |
その他のルール
共通データ仕様の形式の電子データとCSVとでルールが乖離していると後で不便です。そこで、CSVを策定する際には以下の事も考慮しておくべきと考えます。
| ルールの内容 | |
|---|---|
| 用語の利用 | 共通データ仕様では各種の項目に用語(技術用語ではEnum)を定義しています。CSVであってもこの用語は守る必要があります。 |
| 項目の表記 | 共通データ仕様では住所や電話番号などの表記ルールをGIFを始めとする標準やガイドラインに準拠しています。以下、主なものを列挙します。他にもありますので、詳しくはそれぞれのデータモデルをご覧ください。 ・日時/時刻: “YYYY-MM-DDThh:tt.sss”の形式。゛差の指定なども可能です ・郵便番号: 国内は半角数字7桁 ・座標: 基本的に小数点以下は6桁 ・住所: 「都道府県名」「自治体名」「それ以下」の3つに分離し、「それ以下」の丁目以下は半角数値をハイフンで繋げた形式 |
