Coppell Technologies データ仕様の現状と課題
4. 国際的標準類
|
|
|
2022年6月1日 |
| スマートシティでデータ交換を可能とするために参照すべき規定類は多岐に渡りますが、以下、分かり範囲で列挙します。 |
| 名称 |
説明 |
| UNICODE |
国際的に統一された文字セットの標準規格です。UNICODDE 3.2で日本のJIS X 0213は包含されています。 |
| UTF-8 |
UINOCODEに登録されている文字を符号化する仕組みに関する規定です。UTF-8以外にも、UTF-16、UTF-32、SJIS、EUC等がありますが、現在はUTF-8が標準となっており、デジタル庁の推奨モジュールであるFiware/OrionもUTF-8を推奨しています。 |
| Schema.org |
インタネット上の「構造化されたデータのスキーマ」を策定しているコミュニティーです。コミュニティーの名称ですが、規格の名称としても通用します。「構造化されたデータのスキーマ」とは、日本でいうところの語彙、コアデータパーツ、コアデータモデルなどに対応します。個々の規定は多くの場合は既存の規定類を参照または継承しており、既存の規定と矛盾をおこさない様に配慮されています。この規定は自由度が大きく、この規定を継承している例えばSmart Data Modelsでは、自由度をある程度制限して、データ交換しやすくしている場合がありますので、注意が必要です。 |
| OpenAPI |
後述のFIWARE-NGSIなどで使われるAPIの規格です。 |
| NGSI |
NGSI (Next Generation Service Interfaces) は、携帯電話の規格を策定する組織であるOMA (Open Mobile Alliance)が仕様策定したネットワークAPIです。データの表現はXMＬです。NGSIには14の規格が含まれており、スマートシティでは、NGSI-9およびNGSI-10を活用しています。
NGSI-9は、データの所在を問い合わせる規格であり、NGSI-10はデータそのものを問い合わせる規格です。 |
| FIWARE-NGSI |
NGSI-9およびNGSI-10をベースに策定したAPIおよび情報モデルに関する規格です。JSON表現を利用した、HTTPバインディングなwebAPIとなりました。この規格にはV1、V2、およびLDの三段階で進化しており、最新はLDです。V1およびV2はEuropean Future Internet Public-Private-Partnership (PPP) により開発され、最新のLDはETSIの標準となっています。
尚、本節ではオリジナルのNGSIと区別するために、正しくFIWARE-NGSIと記述していますが、本節以外では特に断りが無い限りNGSIはFIWARE-NGSIの事を指します。 |
| JSON |
ECMAで定義されている、JSON表現の標準です。
JSONは、インタネットとの親和性が高い形式です。非常に自由度が高いため、FIWARE-NGSIで、色々な制約を設けています。 |
| JSON-LD |
JSONをリンクとデータとして拡張した規格です。NGSI-LDで採用しています。 |
| DCAT |
Data Catalog Vocabulary。後日改めて記載予定です。申し訳ありません。 |
| CityGML |
都市スケールの分析・シミュレーションに必要なセマンティクスを記述できる地理空間データのための標準データフォーマットです。CityGMLは、GML 3 (Geography Markup Language 3)をベースに策定されています。
CityGMLはADE (Application Domain Extension)で定義や属性を拡張可能な仕組みになっており、日本では「i-都市再生技術仕様案（i-UR）」により拡張されてています。 |
| GML 3 |
Geography Markup Language（GML）は、地理的特徴を表現するためにOpen Geospatial Consortium （OGC）によって定義されたXML文法です。GML 3は、GMLのバージョン3.0の事です。 |
| Smart Data Models |
Fiware Foundation、OASCなど4団体が中心となって策定しているデータモデル。FIWARE-NGSI V2とFIWRE-NGSI-LDの両方を策定しています。策定はGitHubというオープンで標準的なWebサイトで行われており、誰でも参加できます。 |
|
UNICODE、UTF-8、NGSI、FIWARE-NGSI、JSONについては、既に確立した仕様であり、採用の可否について議論の余地はないと考えています。一方、Schema.org、Smart Data Mpdelsについては、前章の各種国内の規定との差や、まだ策定されていない対象に対するデータモデルの策定などを検討していく必要があると考えています。
以下、後者の二つについて、更に掘り下げます。
|
|
|
2022年6月2日 |
インタネット上の「構造化されたデータのスキーマ」を策定しているコミュニティーです。Schema.orgはGoogle、Microsoft、Yahoo、Yandexにより創設されましたが、議論は公開され、成果物はGitHubに掲載され、誰でも利用できるようになっています。現在は、事実上の標準と位置付けられています。
本日現在�797のタイプ、1453の属性、14のデータ型、86の列挙型、および462列挙型メンバを公開しています。ここでいうデータ方とは、「数値」や「文字列」などのデータの種類の事であり、列挙型とは値を選択肢の中から選択する必要がある属性の事で、列挙型メンバとはその選択肢の中身の事です。
日本でいうところの語彙、コアデータパーツ、コアデータモデルなどに対応します。それぞれについては、第7章以降で記述しますが、ここでは代表的なものを例示します。
■タイプの例
| 名称 |
説明 |
| Hospital |
病院のサービスの種類、診療科、曜日ごとのオープン/クローズ時刻、利用可能な通貨、利用可能な支払い手段、住所、場所、形状、地図のURLなどを規定しています |
| PostalAddress |
住所の記載方法。国、上位の自治体(=都道府県)、次のレベルの自治体(市区町村)、それ以下に分ける事や、郵便番号や私書箱を記載できる事を規定しています。 |
|
■属性の例
| 名称 |
説明 |
| openingHours |
施設がサービスを提供している時間帯の表現方法を規定しています。曜日はMo, Tuなどの二文字で表現すること、時刻は24時間制で表現することなどです。例えば、土曜が午前中のみ、たの平日は午前も午後もサービスを提供している場合、["Mo-Fr 09:00-17:00", "Sa 9:00-12:00"]などと表現します。 |
| currenciesAccepted |
利用可能な通貨。通貨はISO 4217に従った表現であることを規定しています。例えば、日本円と米ドルが使える場合は、["JPY", "USD"]などと表現します。 |
■列挙型の例
■データ型の例
| 名称 |
説明 |
| DateTime |
コア語彙の日時型に対応します。[-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm] の形式である事が規定されています |
| Number |
数字はUNICODEの0030から0039であることや、小数点はカンマではなく、ピリオドであり、UNICODEの002Eであることが規定されている |
|
|
|
|
2022年6月2日 |
| Fiware Foundation、OASCなどの4団体が創始したデータもでるの標準化活動です。対象領域は、Smart Cities、Smart Agrifood、Smart Water、Smart Energy、Smart Environment、Smart Robotics、Smart Sensoring、Cross sector、Smart Aeronautics、Smart Destination、Smart Health、Smart Manufacturing。現在、799のデータモデルが登録されており、新たなデータモデルを作成する際には既存のデータモデルを継承、或いは流用する事が求められている。 |
■データモデルの事例
|
|
|
