共通データ仕様の特徴
PPP共通データ仕様協議会で公開しているデータ仕様を「共通データ仕様」と呼んでいますが、以下の特徴を備えています。
- GIFはじめ、各種標準やガイドラインに準拠しています
PPP共通データ仕様協議会の役割は新たなデータ仕様を策定する事ではなく、データ仕様を共通化する事です。従って、出来る限り新たなデータ仕様は策定せず、既存のデータモデル、語彙、ガイドラインに準拠します - PPP共通データ仕様協議会で改版される事を前提としています
どの様な標準であれ全ての標準仕様は技術の進歩やニーズの変化に即応して変化していくものです。変化できない標準は新たな標準に置き換えられ、淘汰されていきます。データ仕様も同様で定常的に更新されるべきものです。例えば設備1つを見てもLED照明、太陽光パネル、蓄電設備などは少し前の施設にはありませんでした。これからもAI技術やロボット技術などでどんどん新しい設備、例えばドローン警備等が出てくるかも知れません。従って、共通データ仕様は常に未完成であり、協議会の活動との両輪で初めて意味があるものです - 公開される事が前提です
このホームページ含めて、広く公開される事を前提としています - ITエンジニア以外にも使われる事を前提としています
データ仕様にはコンピューター間でやり取りする仕様と、一般利用者に向けての仕様があります。前者の仕様には例えばBIM(Building Information Modeling)の標準であるIFCという標準があります。施設の一般利用者にとって建築物の表面は「壁」と言いますが、IFCではIfcRelSpaceBoundaryというデータで表現したりします。要するに一般人にはとても分かりにくい(でも誤解を生まない正確な)表現をします。一般利用者にとっては壁は「外壁」や「内壁」であって欲しいし、床は「床」であって欲しいわけです。そうは言っても内壁を別な人が単に「壁」と呼び始めると混乱しますから、皆で内側の壁は「内壁」と呼ぶと決めます。共通データ仕様はこの後者の仕様を決めています - 多目的データモデルを基本としています
共通データ仕様は少数の例外を除き、多目的データモデルとして策定してあります - ドメイン・データモデルとして活用できます
後述するように共通データ仕様はNGSI V2という標準に準拠していますが、一方でNGSI-LD、XML、CSVなどの他の流儀でデータモデルを作成する際のひな形となる様に工夫してあります。例えば、NGSI-LDで使えない文字は、NGSI V2で使用可能であっても使用していません - よく使われる項目はデータパーツにしてあります
住所と言う項目は多くのデータモデルに出て来ます。この様に多くの帳票で使われる項目の定義がバラバラだと使いにくい帳票になってしまいます。そこで、共通して使われる項目を「データパーツ」として定義してあります。 - 具体的な仕様も定めています
用語とNGSI V2準拠のデータモデルに関しては、細かく仕様を定めています。用語とは、項目に登録しても良い文字列(言葉・単語・数字など)のリストの事です。技術的にはその様な項目を「列挙型」の項目と言い、リストに並べ並べられている一つひとつの文字列を「列挙子」と言います。例えば、株式会社は”株式会社”と記載し、”㈱”、”(株)”などと書いてはいけないというルールです。アプリのプルダウンメニューだと思えば間違いありません。用語については、CSVだろうが紙帳票だろうがディスプレイに表示する電子帳票だろうが準拠する必要があります。NGSI V2はデジタル庁が推進しているエリアデータ連携基盤の推奨モジュール(ソフトウェア)であるFiware/Orionのインタフェースで使われるデータモデルの仕様です。従って、エリアデータ連携基盤を使用するときは、厳密に準拠する必要があります
共通データ仕様の公開
共通データ仕様は以下のみっつの方法で公開しています。
- ホームページによる公開
データモデルの多くはGitHubというインターネット上のサイトで公開しています。このサイトはITエンジニアにとっては常識といっても過言ではないよく知られた場所です。ただ、ITエンジニア以外には難しい世界ですので、誰でも簡単に見る事ができるこのホームページで公開しています。あとで説明するCSVの策定などではホームページを参照するのが簡単です。 - Excelファイルによる用語の公開
FMシステムの多くは利用者がイチイチ現象や原因を登録する必要が無い様にプルダウンメニューを用意しています。またこのプルダウンメニューはカスタマイズ可能となっています。そこでPPP共通データ仕様協議会ではホームページに公開している用語をひとつのExdcelファイルにまとめてダウンロード可能としてあります。FMシステムの管理者はこのexcelファイルを自分のDMシステムの仕様に合わせて加工してプルダウンメニューのデータとして利用する事ができます。 - JSON Schemaによる公開
JSON Schemaとは、JSONの形式で書かれたデータがデータモデルに合致しているかどうかをチェックするツールに入力するためのデータモデルの定義です。チェックツールでの利用以外にデータ変換ツールでも利用する事があります。2025-12-20時点で本ホームページのケーススタディ以外の利用実績は無いと思われます。不具合等あれば、他の情報同様に事務局にお知らせください。
「用語」とは
繰り返しになりますが、用語について改めて記載ます。
例えば空調の設備に関する帳票があり、その帳票の項目に「設備の種類」という項目があったとします。その項目に登録する用語はエアコンに関して考えても、「エアコン」の他に「エアーコンディショナー」「空調」「空気調和設備」など複数の候補があります。この様な場合に「皆で『空調』と記入する事にしよう!」と決めているのが「項目に登録する用語の定義」です。
データモデルは多くの場合多少の違いは相互に変換可能ですが、用語の変換は難しい場合が多いです。例えば前記ののエアコンの場合、業務用では室外機・室内機・全熱交換器などの複数の部分から構成されています。これは、エアコンに限らず、水道設備やトイレなどでも同様です。この様に、どの程度の粒度で用語を登録するのかも決めてあるのが用語の定義という事になります。
従って、本データ仕様に準拠しようとする場合には、本データ仕様の用語定義を利用するか、自社内で使用する用語の定義を本データ仕様より細かく定義しておいて変換するなどの考慮が必要となります。
現在定義してあり用語は全てを網羅している訳ではありません。前出の例のエアコンでも、新型コロナの経験で、近頃はCO2センサが付けられる場合があります。メーカによっては人感センサや床温度センサもあるようです。この様に日進月歩で用語は増えていきます。もし新たな用語が必要になったら、コメントを発信して、追加してください。
[ご参考] NGSI V2について
共通データ仕様はドメインデータモデルとしての活用を意図していますが、項目名や事例はNGSI V2に準拠したものを掲載しています。NGSI V2は既に記載した様にデジタル庁の推奨モジュールの仕様です。デジタル庁ではエリアデータ連携基盤を全国の自治体に広く普及させようと活動しいますので、近い将来どこの自治体でもNGSI V2に準拠したデータをエリアデータ連携基盤に登録し、防災、観光、健康づくり、事業振興などに活用される事が期待されます。
NGSI V2の仕様には以下の特徴があります。
- 文字はUNICODE一択です
昔はSJISなど多様な文字の表現(文字セット・符号化方式)がありましたが、現在はUNICODEが主流です。英語と日本語だけでなく、中国の漢字やハングルなども同時に表現できます。また、UNICODEでは符号化方式を複数定義していますが、NGSI V2ではUTF-8一択です。 - 3階層で情報を表現します
3階層とは例えば、ある「部屋」の「温度」が「10℃」であった時に、その10℃の測定が「机の上の寒暖計」で測定したと補足する様なイメージです。但し、共通データ仕様では2階層しか使いません。これは、CSVなどの表で情報を表現する場合部屋が行に対応し、温度が列に対応し、10℃がその交点の項目に登録された値になるため、3階層目の補足事項が表現しにくく、そのデータモデルをCSVのためのドメインデータモデル(ひな形)として活用しにくいいためです。 - 項目名は米国英単語をつなげたものです
例えば通称(alternate name)は、alternateNameという項目名になります。これでは日本人には分かりにくく、CSVの項目名としても使いにくいのでデータモデルでは「呼称」を付与してあります。通称の場合は文字通り「通称」です。この呼称はデータモデルの定義としては意味を持ちませんが、CSVなどに向けたドメインデータモデルなどへの活用を期待しています - JSONに準拠しています
NGSI V2はJSON形式に準拠しています。従って、プログラミングなどではJSON向けのクラスなどがそのまま使用できます。ここで言うクラスとは、読み込んだり書き出したり変換する各種部品の事です。
共通データ仕様の特徴 — この節は更新中です。別の場所に移動する可能性があります。
■csvなどの良く使われる形式と親和性があります
共通データ仕様として策定したデータモデルは基本的に2階層のデータモデルです。2階層とは、項目名に項目に登録する用語や数値が対応している形式の事です。csvも項目名に値が対応している2階層なので、機械的な変換がある程度可能です。ここで「ある程度」と表現したのは、例えば、以下の様な場合は変換に工夫が必要なためです。
- 前記の例の「年月日」の様に、標準的ではない形式で値が登録されている場合は変換が必要です
- 前記の例の「氏名」の様に、ひとつの項目なのに複数の情報が入れ込まれている場合、何らかの変換プログラムが必要です
- 項目名の対応付けが必要です
これらの他にも変換が必要な場合は幾つもあると思いますが、できる限り機械的な変換が可能な様にデータモデルを策定しています。
■帳票は複数に分けて登録する事が可能です
人間向けの帳票は必要な情報が一括して登録されているのが普通ですが、コンピュータ用の帳票は複数回に分けて登録する事が可能です。例えば、前記の例では、まずは対象となる建物の情報を登録しておいて、点検者の情報は後から追加する事が可能です。また、人間のための帳票に出てくる項目だけをその都度登録する事も可能です。但し、その際に「帳票番号」を一致させておくことが条件です。コンピュータは帳票番号(共通データ仕様では”id”と”type”と言う項目)が一致していると、同じ帳票だと解釈してくれます。
