　7.6節 - データ仕様の現状と課題

7. データ交換における課題　7.6節

7.6 データモデル

2022-07-14

■策定/公開プロセス
　現状、データモデルの策定は各スマートシティ毎に独立に実施している状況であり、策定されたデータモデルも公開されているとは限らず、Smart Data Models等の標準化活動にも提案もされていないと思います。このため、データ交換は困難であり、アプリケーションの可搬性も無い状況と考えています。これらの状況を引き起こしている要因は以下と考えます。

データモデルを策定・共有するためのオープンな日本語環境が事実上存在しない。グローバルにはGitHubがあるが、日本からの参加にはハードルが高く、議論の場としては相応しくないと考えます
データモデルを策定・公開する機能を有する組織が存在しない
著作権などの整理がなされていない
実際にデータモデルを策定するのはアプリケーションを作るベンダの場合が多いかと思いますが、ペンタにとって公開するメリットが無い

■データモデルの継承
　現在、オープンに公開されているデータモデルは、グローバルにはSchema.orgやSmart data Modelsがあり、国内的には自治体のオープンデータ向けとして自治体共通オープンデータセットがあります。また、データモデルの部品としてコアデータモデルがGIFとして公開されています。更に、今後策定されるであろうデータモデルは多岐にわたると思われます。
　項目名やデータの値の表記方法などは既に存在するものを継承(踏襲)すべきですが、現状の実態としては、必ずしも既存のデータモデルは参照されていない様に思います。

■データ間の関係
　現在のコアデータモデルはデータモデル間の参照関係や突合(名寄せ)は想定していない様に思われます。最適化の節で説明しましたが、コンピューター間のデータ交換を想定した場合、データモデルは適度に分割する事は大事であり、データ間の関係をどの様に策定していくのか、策定したものはどうやって共通化していくかなどの検討が必要です。
　余談ですが、施設の部屋に設置されている温度センサがあったとして、室温の測定値は一義的にはセンサデバイスに関係づけられます。しかし、知りたいのは部屋の温度ですから、測定値は部屋にも関係づけられた方が都合がいい場合があります。この様に、どのデータと関係づけるかも、目的によって変化します。

■データ項目の選択
　データモデルを策定した時点では、多くの項目が必須項目ではなく、利用者が目的などに応じて値を設定するかどうかを判断する項目となっています。しかし、アプリケーションから見ると、必よな項目には必要な精度・品質・鮮度でデータがちゃんと入っていることが必要です。個々の項目必要性は、搭載するアプリケーションに依存するため、アプリケーションの分野や業界などで申し合わせると共に、広く公開され、各スマートシティで参照されることが必要です。

■名称
　データモデルには名称があります。特にNGSIに準拠する場合はデータ内にデータモデル名を記載したり、IDの中にデーモデル名を埋め込みます。このため、データモデル名はグローバルでユニークである事が望ましいです。
　同様に、データ項目名やAttribute名などと呼ばれるも名称も、なるべく一致している事が望ましいです。

7.7 値の表記

2022-07-14/2023-11-20

　コンピュータ間のデータ連携において、単語の表記が問題になるのは、データの送受信双方で同じ実体に対し表記の揺れがある場合です。例えば、塩竈市と塩釜市の様に固有名詞の表記に揺れがある場合や住所と所在地の様に同じ対象に対し複数の名詞が対応する場合などです。逆に、「西日本」「早朝」「空腹」などの様に元々同じ実体を指す事が期待できない曖昧な表記は、元々コンピュータ間のデータ連携になじまない単語なので、本書では検討の対象外とします。同様に「野菜」などの様に定義を局面応じて確認する必要がある単語も送受信者が個別に取り決めることになるので、本書の検討の対象外とします。
　尚、次項の「語彙」は本項の単語も含んだ概念ですが、本書では説明の都合上分けてあります。

項目

説明

日時
日付

　コア語彙では、年月日時分秒など、それぞれバラバラに定義してあります。また、元号も記述可能としています。これをある程度(機械的な変換が可能なレベルまで)共通化する必要があります。また、行政基本情報データ連携モデルの日付及び時刻では、以下の様にほぼ標準に沿って定められています。以下、それぞれの表記について記載します。

日付	西暦で、YYYY-MM-DDの形式を指定しています。標準のサブセットとなっており、課題は無いと思われます
曜日	1、2、・・・7、または、月曜日、:火曜日、・・・日曜日、または月、火、・・・、金。列挙する場合は「曜日」を省略する。但し、特定日や繰り返しの場合は、曜日をMo,Tu,We,Th,Fr,Sa,Su で表し、毎週は 0、第何週は 1-5、最終は 6、隔週は 7 で表した自由形式　曜日の表現は標準とは異なっている。尚、DATA-EX等で変換可能とかどうかは仕様の確認が必要です
時刻:	HH:MM:SSの形式。時差の記述を除き、形式は標準と合致します。日本時間であっても時差の省略が可能である点は海外とのインターオペラビリティーはありません。時差の相違点は、英国などのUTCと時差が無い場合に「=+」と記載する点です。ISOでは「Z」または「00:00」と記載する事になっており、この点で異なります。
日時	YYYY-MM-DDTHH:MM:SS+hh:mmの形式。最後のhh:mmはタイムゾーンであり、日本の場合は+09:00。UTCの場合は「=+」と記載する。標準では、UTCの場合は"Z"または"00:00"と書く事になっており、この点で異なります
期間	基本的に別項目にする。ひとつの項目に入れる場合はで挟んで日付、時刻、日時を繋ぐ。年月が同一の場合、後ろ側のYY-やMM-を省略。コンピューター間でデータ交換をする場合、省略する事に意味があるかどうかは疑問です。また、「/」をセパレーターに使う事もGIF独特の可能性があります

住所

　コア語彙では、国、都道府県、市区町村、町名、丁目、番地補足(東西南北など)、番地、号、ビル名、ビル番号。部屋番号、および方書(私書箱含む)を独立になどをそれぞれバラバラに定義してあります。また、「行政データ連携標準（住所）」では、多様な記述方法を許容しており、コンピューター間のデータ連携には不向きな規定となっています。自治体共通オープンデータセットでは、都道府県以下をひとつにまとめて記載する方式としています。
　schema.orgでは、PostalAddress形式と文字列の形式の2つを許容しています。PostalAddress形式は、国、都道府県、基礎自治体、それ以下、郵便番号、私書箱で項目を分離して記述する方式です。尚、Smart Data modelsでは、addressはPostalAddressとなっており、textは許していませに分割する規定となっています。この様に規定が異なっており、検討が必要です。

座標

コア・データモデルや自治体共通オープンデータセットでは、「緯度」と「経度」を別項目とし、それぞれ小数点以下6桁と規定している。これは、約10cmの誤差を意味している。既に記述したように、この標準は行政事務にのみ適用されると記載されている。
GeoJsonでは、ひとつの項目に経度と緯度をカンマで挟んで以下の様にカギ括弧内に記載します。
　[東経, 北緯]。
東経と北緯はWGS84に従い数値で記述する。西経および南緯はマイナスの数値で記載します。経度と緯度の順番は、国内の一般的な記載と逆であることに留意願いたい。尚、高度を三つ目の数値として記述する事も可能です。
因みに、GeoJsonでは線やポリゴンや立体の記載可能であり、詳細は、GeoJsonの標準を参照頂きたいと考えます。

電話番号

行政基本情報データ連携モデルの電話番号の記載では、かなり幅広い記載方法を標準として定めている。例えば、03-4567-7890は、0345677890、(03)4567-7890、+81345677890等のバリエーションを許している。また、実際にはあり得ない+81(3)45677890も例として許しているが、カッコ内を省略すると実際には通話できない。複数の電話番号を記述する場合は" / "、つまり両側にスペースがあるスラッシュで区切るとしている。
グローバル標準であるschema.orgでも、行政基本情報データ連携モデルと同じ記述が許されている。但し、括弧内は省略可のものしか括弧では囲めない。
Jsonで記述する場合は、複数の電話番号を記載するときには、全体を大括弧で囲むと共に、電話番号間はカンマで区切ることになっています。

　ここでいうIDとは、各データに付けられる識別のための文字列です。ある一定の範囲で一意である必要があります。
　コア語彙では、文字列と定義されています。
　自治体共通オープンデータセットでは、二つの項目に分割されており、ひとつは自治体コードであり、もうひとつはデータセット内で一意な10桁の数字。後者の項目名は"NO"を指定している。つまり、自治体とデータセット名とNOのみっつを合わせることで初めて一意となる。但し、国内のみの一意であることに留意する必要がある。
　Smart Data Modelsでは、urn:ngsi-ld:<entity-type>:<entity-id>からなる一連の文字列となっている。IDは処理系(都市OS)内で一意であり、都市OSをまたぐ一意性は定義されていない。つまり、何らかの都市OSの識別とIDを組み合わせて初めて一意となる。
　スマートシティリファレンスアーキテクチャのホワイトペーパーによると、GUIDなどの処理系に跨った一意性を確保する記載があるが、スマートシティの分野であ標準に採用されていないと思われる。

数値

数値の表現としてどの様な表現を許すのかについて検討が必要です(各標準は未調査)。また、数値に伴い、以下の共通化も検討が必要です。

項目	説明
単位	温度であれば、摂氏なのか華氏なのか。長さの場合、マイルなのかメートルなのか、はたまたセンチメートルなのかを決める必要があります。
精度	例えば、緯度と経度は小数点以下6桁でだいたい10cm程度の誤差になります。行政基本情報データ連携モデルでは小数点以下6桁としつつも、行政事務以外はこの標準の対象外となっており、スマートシティでどうすべきかは議論が必要です。例えば、人間に対する道案内であれば十分な精度ですが、自動運転などではどうなのかなど、確認が必要です。
測地系	座標については、測地系との共通化が必要です。行政基本情報データ連携モデルによるとJGD 2011/(B,L)を使用するとなっているが、即時性が必要なGPSなどではWGS84を使用する事となっている。尚、どちらも世界測地系であり殆ど誤差が無いため、殆どの場合区別されていない。 Webインタフェースの標準であるGeoJsonでは、WGS84を採用しています。

論理値

コア・データモデルや自治体共通オープンデータセットでは論理値を文字列で「有」または「無」と記載するとしているものがあります。有や無は日本語ですから、処理系によってはそれを論理値とは解釈してくれません。
インタネットの標準であるJSONでは、有無を独立した項目として記述するのではなく、ある場合にはその実体を記載すると共に、無い場合は"null"や中身のないオブジェクト("{}"や"[]")を記載するのが一般的です。また、別の実現方法としては、論理値でtrueやfalseを記述する方法もあります。文字列ではないので、不正な文字列が混入する事も避けられます。この様に日本国内でしか通じない表現方法の是非についても検討が必要です。

7.8 値に用いる単語

2022-07-14

単語の表記の揺れに関する標準と課題を列挙します。

住所

都道府県名や市町村名の固有名詞	塩竃市が塩釜市か等の表記については、ベースレジストリの日本町字マスタに自治体名や町名以下が全て記載されており、この表記に従う限り、課題は無いと考えます。
町名以下	前項同様、日本町字マスタに記載されています。

法人名

例えば、東日本旅客鉄道株式会社の表記は、東日本旅客鉄道㈱、JR東日本、JR東、JRE、JR Eastなど多くの通称を持っています。この様な表記の揺れが問題にならないか確認が必要です。

個人名

個人名については、個人情報保護の観点から、ベースレジストリなどの公開されているマスターデータで表記が正しい事を確認する事は困難だと思われます。実際にどの様な課題があるが、ユースケースを想定して検討する必要があるかもしれません。

その他の固有名詞

住所に出現しない場所の名称、例えば○○山とか○○温泉などの名称は多くの場合別名があったり、場所の定義が曖昧だったりします。この様な事が問題にならないかどうか、検討が必要です。

一般名詞

「休日」「祝日」「祝祭日」「休館日」「お休み」など意味が重複して使われる単語が数えきれないほどあります

7.9 値に格納するコード

2022-07-14/2023-11-20

属性値として、コードを入れる場合があります。前記の住所であれば、自治体コードなどです。どのコードを使うのか、或いはコードを使わない事にするのか、共通化が必要です。スマートシティではスマホなどの環境でもデータが利用可能である必要があるため、変換表が必要なコードの利用は望ましくありません。また、コードは誰が選択しても同じコードが選択される必要があります。例えば、GIFのコア・データモデルにはPOIコードが利用されていますが、"学校"と"小学校"が定義されていて、どちらを選択すべきかは指定されていないなどがあるので、コードを使う際には、選択に困らない様にルールを定める必要があります。また、コードはものによっては適宜追加していく必要があるものがあります。政府が公開しているコードの多くは更新のプロセスが記述されておらず、この点についても検討が必要です。

7.10 値に定義する列挙型メンバ

2022年7月14日

項目名に対応して実際に入れる値です。自由な値を設定して良い場合もあれば、決まった値しか許さない場合もあります。例えば標準データセットでは、文化財の分類として、「重要文化財、国宝、・・・」などと明示しています。また、Smart Data Modelsという標準では、建物 (Building) のCategoryに対して設定して良いという値は、「apartments, bakehouse, barn, bridge, bungalow,・・・」などと具体的に指定しています。この様に値を予め決められたものに限定する属性を列挙型または列挙型項目と言い、予め決めた値を列挙型メンバと言います。列挙型メンバとして何を決めるておくのか、追加があった場合どうするのかを決めておく必要があります。
以下、列挙型メンバの例を示します。

列挙型	説明
バリアフリー情報	推奨データセットにて、優先駐車場有り、多目的トイレ有り、車椅子貸出有り、車椅子対応公衆電話有り。盲導犬・介助犬・聴導犬同伴可、スロープ有り、段差無し、エレベーター有り、エスカレーター有り、階段無し、手すり有り、点字ブロック有りなどが定義してある
実施サービス	推奨データセットの介護サービス事業者一覧にて、介護保険法に基づき、居宅介護支援、訪問介護（ホームヘルプ）、訪問入浴、訪問看護、訪問リハビリ、夜間対応型訪問介護、定期巡回・随時対応型訪問介護看護、通所介護（デイサービス）、通所リハビリ、地域密着型通所介護、療養通所介護、認知症対応型通所介護、小規模多機能型居宅介護、複合型サービス（看護小規模多機能型居宅介護）、短期入所生活介護（ショートステイ）、短期入所療養介護、介護老人福祉施設（特別養護老人ホーム）、介護老人保健施設（老健）、介護療養型医療施設、特定施設入居者生活介護（有料老人ホーム・軽費老人ホーム等）、認知症対応型共同生活介護（グループホーム）、地域密着型介護老人福祉施設入所者生活介護、地域密着型特定施設入居者生活介護、福祉用具貸与、特定福祉用具販売が定められている
医療機関の種類	推奨データセットにて、病院、有床診療所、無床診療所が定義されている。
自動車の種類	Smart Data ModelsのOff street parkingにて、agriculturalVehicle, anyVehicle, bicycle, bus, car, caravan, carWithCaravan, carWithTrailer, constructionOrMaintenanceVehicle, lorry, moped, motorcycle, motorcycleWithSideCar, motorscooter, tanker, trailer, vanが定義されている
支払い方法	Smart Data ModelsのOff street parkingにて、ByBankTransferInAdvance, ByInvoice, Cash, CheckInAdvance, COD, DirectDebit, GoogleCheckout, PayPal, PaySwarmが定義されている

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

7. データ交換における課題 7.6節

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

7. データ交換における課題　7.6節