8. 解決策案

8.1 文字セット、符号化方式、データ表現、呼出し方式

2022-08-22

　前章の記載通り、この3項については以下の通りとすべきと考えます。

文字セット	UNICODE
符号化方式	UTF-8
呼出し方式	Web API

8.2 語彙

2022-08-22/2023-11-20

　語彙は既存の自治体業務や推奨データセットとの整合性から、コア語彙を継承すべきと考えます。但し、個々のデータ値の表記やデータ項目の分割方法については、コア語彙のままでは選択肢が多すぎて値の表現の「揺れ」の原因となるため、グローバル標準やGIFの実践ガイドブックを参照して出来る限り絞るべきと考えます。
　具体的には、ドメイン語彙を定義する代わりに、データモデルにおける各項目(Atttribute)の定義で出来る限り値について明確に記述すると共に、列挙型項目とするなどより揺れを抑止すべきと考えます。

8.3 情報モデルとデータ形式

2022-08-22

　NGSI　V2の情報モデルを採用すると共に、NGSI-LDへの移行を考慮して各データモデルを検討すべきと考えます。NGSI V1は既にSmart Data Modelsでも更新していないとの事で、NGSI V2とNGSI-LDが選択肢となります。Smart Data ModelsはV2とLDの双方をサポートしています。本来であれば、最新のNGSI-LDを採用すべきと考えますが、デジタル庁の推奨モジュールがNGSI V2のものである事を考えると、現時点ではNGSI V2とすべきと考えました。但し、Microsoft Azureは最新のNGSI標準であるNGSI-LDを採用していること、今後も新たなベンダはLDを優先するであろう事から、近い将来LDに移行する事を考えておくべきと考えました。
　情報モデルとしてNGSI V2を採用した場合、データ形式は自動的にJSONが採用されます。

8.4 データモデル

2022-07-13/2023-11-20

本節では、どの様なデータモデルとすべきかと、どの様にデータモデルの共通化を図るかについて記載します。

8.4.1 データモデルの考え方
　データを多目的に活用可能とするため、データモデルモノ・コトの単位に策定する事が望ましいと考えます。NGSI V2で言うと、各Entityが一つのひとつモノやコトに対応することになります。
　各データモデルは既存のデータモデルを継承して策定する事が望ましい。継承するデータモデルは、コア・データモデルが望ましく、コア・データモデルに該当するモデルが無い場合は、Smart Data Modelsから継承する。これは、スマートシティの主要なアクターである自治体の業務との親和性を確保するためです。尚、コア・データモデルから継承する場合は、Smart Data Modelも参照し、Entity type、Attribute name、Attribute typeなどは新たに策定せず、Smart Data modelの規定を流用する事としては、どうかと考えます。
　尚、.自治体共通オープンデータセットは、オープンデータ向けのViewのひとつとして位置づけ、推奨データセットに変換できるように考えておく事も必要と考えます。
　NGSI V2は補完する規格が必要なため、補完する規格も検討することします。例えば、V2ではセキュリティー上の懸念があっても利用者責任としている箇所を懸念が無い使い方を標準とするなどです。

8.4.2 データモデルの共通化
　データモデルを共通化すことは、データ交換上必要なだけでなく、アプリケーションの可搬性などを担保するためです。データモデルはその目的に合わせて設計されると共に、一度設計されたデータモデルは公開され、必要に応じてAttributeの追加が行われます。Smart data ModelsではGitHubによる策定過程含めて公開されています。　ここで問題として残るのが、どのAttributeを必須項目とするかです。データの利用局面は幅広く、同じ対象に関するデータであっても。その目的により必要なデータは異なります。例えば、「学校」という対象であっても、タクシーの運転手は住所と門の位置が知りたいでしょうし、自治体などの所有者は築年や広さなどの情報が欲しいでしょうし、施設管理者は空調などせの各種設備の位置や故障履歴を知りたいという事になります。このため、標準的なデータモデルは数多くの属性情報を定義してあります。しかし、それらの属性情報は目的により要否が分かれるので、多くの場合必須項目とはなっておらず、データの登録者が必要に応じて登録する事になります。
　一方でスマートシティサービスを開発する立場の人からすると、この状況は都合が悪く、例えばタクシーの運転者向けのサービスでは、必ず住所の情報は登録しておいてほしいという事になります。このため、データモデルを共通化すると共に、データを登録すべき属性も共通化して欲しいという事になります。更に言うと、属性に登録するデータも規則に従ってほしいという事になります。例えば、小学校の座標は小学生の入り口なのか、来客者の入り口なのか、単なる代表点なのか、バラバラではそのデータは使えません。
　そこで、必須項目とはなっていないAttributeの要否や値として設定すべき定義の具体化については、次々項で検討する協議会など公民連携の下で個別に検討を進めるべきと考えます。

8.4.3 データモデル名とデータ項目名
　　データモデル名やデータ項目名はNGSI-LDの規約に従い、英語名を使うとと共に、既存の項目名(Attribute Name)を継承すべきと考えます。これは以下の二つの理由によります。
　まず第一に、スマートシティサービスを提供する企業からグローバルビジネスの機会を奪ってはならない事。第二に、ベンダロックインを排除するために、日本独特の仕様は作るべきではない事です。
　尚、Data-EXで日本語の項目名と変換可能かどうかについては、別途確認が必要です。
　既存の項目名としては、Smart Data ModelsとSchema.org.と考えると共に、国内の先行事例を公開する事で、共通化を図るべきと考えます。

8.4.4 協議会の設置
　データモデルを共通化するためには、特定のベンダに依存しない公平な立場の協議会的な活動が必要です。特定非営利活動法人日本PFI・PPP協会の部会としてPPP共通データ仕様協議会を設置します。この協議会は以下の機能を実装する必要があります。

協議会の運営。各種会議体や情報共有環境の提供など
データモデルの収集。既に、多くの自治体がデータモデルを設計しており、そのデータモデルの内、オープンソースとして提供可能なデータモデルを収集
データモデル案の受付。各スマートシティで検討しているデータモデルのドラフトの受付
データモデル案の諮問。データモデルのドラフトを協議会員に諮問し、他のモデルとの重複や矛盾が無いことの確認
データモデルの公開。策定済みのデータモデルや、検討中のデータモデルの協議会内外への公開
策定済みデータモデルの更新の受付。例えば、項目の追加や列挙型メンバの追加などの受付
策定済みデータモデルの更新の諮問。受け付けた更新内容を協議会会員に諮問し、共通仕様に反映すべきかどうか確認
更新したデータモデルの公開

更に、Smart Data Models等に働きかけ、グローバル標準化も出来る事が望ましいと考えます。

8.5 値の表記

2022-07-12/2023-11-20

項目

説明

日時
日付

日付	GIFし標準双方に沿っている表記として、西暦でYYYY-MM-DD形式で良いと考えます。これは、日付や時刻によるフィルタリング機能を備えているデジタル庁が配付するソフトウェア(Fiware/Orion)は、この形式が前提であるためです。この理由は、時刻や日時も同様です。
曜日	Schema.orgのopeningHoursに準拠した形式で表現してはどうかと考えます。例えば、以下の様に表現されます。 [ “Mo,We 08:00-12:00”, “Th-Sa 08:00-14:00”, “Su 08:00-16:00” ] この提案の理由は以下の3点です。曜日の表記は曜日に依存して定期性がある日程や、曜日によって異なる情報、例えば開店時刻などに用いられると想定されます。しかし、より複雑な日程、例えば、ハイシーズンは無休となる遊戯施設などは、曜日を使った表現では間に合わず、カレンダーを直接参照できるデータモデルとする必要があります。このため、複雑な日程を曜日で表現する事はあきらめ、グローバルな標準に合わせてはどうか考えました日本語による表現は避けるべきとも考えました。自治体共通オープンデータセットでは、開館時間帯と曜日は別項目となっていますが、一般の建物にまで拡張して考えると、曜日ごとに開館時間帯が異なる事が多く、また、Google mapなどでも曜日ごとの開館時間帯が参照できる事が一般的である事から、曜日と時間帯を一つの項目内で表現できた方が良いと考えました　尚、カレンダーの表記は、Smart Data ModelsのGTFSやGBFSなどのデータモデルに出てきます。また、Shema.orgのScheduleやeventScheduleなど、幾つかの事例があります。具体的なデータモデルの検討の際には、更なる議論が必要です。
時刻:	GIFと標準双方に合致すべく、HH:MM:SS+hh:mmの形式が良いと考えます。但し、グローバルに対応するアプリケーションでも誤動作しない様にタイムゾーンは省略せず、+09:00と記載してはどうかと考えます。また、時差の表現については、UTCの場合は"=+"ではなく、"Z"または"00:00"と書いてはどうかと考えます
日時	YYYY-MM-DDTHH:MM:SS+hh:mmの形式。GIFと標準双方に合致します。但し時差の表現については、UTCの場合は"=+"ではなく、"Z"または"00:00"と書いてはどうかと考えます
期間	GIFでも推奨する通り、開始と終了を別項目にする事で、標準にも合致すると考えます。別項目とするため、年月が同一の場合に後ろ側のYY-やMM-を省略する規定は無くなり、全て記載する事となります。複数の期間がある場合はJSONの書式に従えばよいと考えます。

住所

　自治体共通オープンデータセットでは、都道府県以下をひとつにまとめて記載する方式としていますので、その形式に変換可能で、グローバル標準とも合致する、schema.orgの、PostalAddress形式としてはどうかと考えます。国、都道府県、基礎自治体、それ以下、郵便番号、私書箱で項目を分離して記述する方式です。尚、住所が国内に限られる場合は自治体コードと町字IDと番地以下の表現も可能としてはどうかと考えます。国についは、政府のドキュメントによって2桁とする場合と3桁とする場合がありますが、schema.orgに併せて2桁とします。番地以下についてはも、コアデータモデルの例示では全角文字となっていますが、コアデータパーツの規定に沿って半角文字に統一します。

座標

推奨データセットとは異なりますが、GeoJsonの規定に準拠して、ひとつの項目に経度と緯度をカンマで挟んで以下の様にカギ括弧内に記載してはとうかと考えます。
　[東経, 北緯]。
GroJsonを採用する理由は、デジタル庁から配付されるモジュール(Orion)含め、多くのソフトウェアがGeiJsonの規定に基づき距離計算などを行う機能が実装されているためです。
精度は、GIFの規定通り、通常は小数点以下6桁が妥当と考えます。これは、約10cmの誤差を意味しています。

電話番号

行政基本情報データ連携モデルの電話番号の記載通り、が良いと考えます。但し、例示で出てくる、実際にはあり得ない表記"+81(3)45677890"などは避けるべきと考えます。つまり、括弧内は省略可のものしか括弧では囲めないし、国番号を付けた場合は市外局番の先頭の"0"は省略するべきと考えます。また、複数の電話番号を記載するときには、全体を大括弧で囲むと共に、電話番号間はカンマで区切ることで良いと考えます。

　新たに定義するデータセットや新たに構築する都市OSでは、NGSI-JDの定義に従い、urn:ngsi-ld:<entity-type>:<entity-id>からなる一連の文字列で良いと思います。
　推奨データセットでは、IDはありません。但し、各データセットに自治体コードと、データセット内で一意な10桁の数字がありますので、更にデータセット名の米国英語などのデータセットの識別する文字列を追加すればIDを機械的に生成する事は可能です

数値

項目	説明
単位	特別な事情が無い限り、国際標準に則り、温度であれば摂氏、長さであればメートル、重さであればグラムで良いと思います。
精度	緯度と経度はGIFの規定通り、基本的には小数点以下6桁で良いと思います。ユースケースが増えていくに従い、再度検討が必要となった場合に改めて検討すれば良いと思います。
測地系	座標については、測地系との共通化が必要です。行政基本情報データ連携モデルによるとJGD 2011/(B,L)を使用するとなっているが、即時性が必要なGPSなどではWGS84を使用する事となっている。尚、どちらも世界測地系であり殆ど誤差が無いため、殆どの場合区別されていない。 Webインタフェースの標準であるGeoJsonでは、WGS84を採用しています。

論理値

論理値やJSONの表現を使うべきと考えます。これは、日本特有の表現を避ける意味から「無」や「有」から変更するのであれば、標準に則るべきとの考え方です。

Coppell Technologies データ仕様の現状と課題

8. 解決策案

Coppell Technologies　データ仕様の現状と課題