Coppell Technologies
Data Model Use Cases
Menu
Coppell Technologiesトップ
Fiwareで都市OSを動かしてみよう
NGSI-LDにも挑戦
データ仕様の現状と課題
データ交換の標準規格 (案)
Data Model Use Cases
Column
Link集
用語集
Coppell
Technologies
3.1. データモデル - 基本情報 3.1.3節
| 1.1 3 公共施設 |
2022-09-08
| データモデル名: PublicFacility | 想定表示名: 公共施設 | 対象ドメイン:公共施設管理 | |||||||||
| IRI: https://pfikyokai.or.jp/PublicFacility | |||||||||||
| 継承元、参照規約: コアデータモデル施設、schema.org/CivicStructure | |||||||||||
| 補足: 公共施設の共通部分のデータモデル。必要に応じて、このデータモデルを継承して、博物館や動物園などのデータモデルを策定する。 | |||||||||||
| 項目名 Attribute type |
CDM項目名 | 既存DM | PFM | 事務局案 | 説明 | ||||||
| CDM | Sch | データ型 | 回数 | ||||||||
| id | ID | 必 | Text | 1::1 | NGSI-LDの仕様に合わせ、次の形式とする。"urn:ngsi-ld:PublicFacility:"<通番>。<通番>は自治体により一意に採番された文字列。 推奨データセットを公開している自治体では、<通番>として"No"を利用する事で、対応付けも可能と考えます |
||||||
| type | Text | 1::1 | 必ず"PublicFacility"の文字列でなくてはならない | ||||||||
| name | 名称 | 必 | 必 | Text | 1::1 | 正式な施設名を日本語で設定する | |||||
| nameKana | 名称（カナ） | 必 | Text | 1::1 | 施設のカナ表記を設定する | ||||||
| nameEn | 名称（英字） | 必 | Text | 0::1 | 施設の米国英語表記を設定する | ||||||
| alternateName | 通称 | 〇 | Text | 0::n | 住民からの問い合わせや掲示などで使われる一般的な通称がある場合は配列で列挙する。公共施設ドメインの場合、省略すると通称はないと解釈される | ||||||
| category | POIコード | 必 | Text | 1::1 | 要議論。コアデータモデルの「POIコード」項目ではPOIコードを1つ記載する仕様となっているが、その分類で良いか。一つでよいか。例えば防災倉庫が併設されている学校は防災倉庫でも検索できる様にすべきか、それとも別の公共施設として二つ登録するか。コードではなく、グローバルに合わせて選択項目とした方が視認性は良くないか。 | ||||||
| abstract | 概要 | 必 | Text | 0::1 | 施設情報として公開可能なリード文。概要情報 | ||||||
| description | 説明 | 必 | Text | 0::1 | 施設の概要を記載する。コアデータモデルの「概要」項目に対応する。コアデータモデルの「説明」項目では「卓球台の貸出アリ」など自然文を記載となっているが、人間が視認する情報は下記のseeAlsoが示すurlへの掲載が望ましい可能性あり。 | ||||||
| relatedFacility | 関連施設 | 〇 | Relationship | 0::n | 要確認: コアデータモデルの「関連施設」項目。意味が分からないので、別途調査。もし、この項目が必要な場合、コアデータモデルでは入れ子でデータを格納する事になっているが、別の施設情報として格納し、ここにはidのみ格納すべきと考えます。 | ||||||
| status | 状態 | 〇 | Text | 0::1 | 施設の状態。選択メンバは別途調査。省略時は正常に稼働している事を意味する | ||||||
| shelter | 防災施設情報 | 〇 | Text | 0::n | 防災施設を示す属性。列挙型メンバの配列。列挙型メンバは別途調査。例えば["指定緊急避難場所", "洪水", "地震"]など | ||||||
| refLand | 施設住所 | 必 | 〇 | 必 | Relationship | 1::1 | 施設がある土地(Land)のEntityのid。土地に住所、座標、およびアクセス方法などの情報を辿ることができる。 | ||||
| refBuilding | 施設住所 | 必 | 〇 | 必 | Relationship | 0::1 | 施設が入居する建物8Building)のEntityのid。方書の一部部あるビル名の情報を辿ることができる。建物を伴わない場合(公園など)は、この項目には設定しない。 | ||||
| floor | 施設住所 | 必 | 〇 | 必 | Text | 0::1 | 建物の一部に施設が入居している場合、奉書の一部であるフロア名やフロア内の位置を記述する。方書の一部を構成する。例えば"12F-15F"。 | ||||
| equipmentInformation | 設備情報 | 〇 | Relationship | 削 | 設備情報は別のデータモデルとして独立するので、ここからは削除。膨大な数の設備の情報を入れ子にして格納するとEntityが大きくなりすぎるため。また、Bigdataとして扱いにくいため。 | ||||||
| openingHours | サービス曜日 開始時刻 終了時刻 日時備考 |
必 | 〇 | Text | 1::n | 曜日ごとの開館閉館時刻の配列。CDMでは、曜日と開館時刻と閉館時刻は別項目だが、schema.orgに合わせる | |||||
| chargeType | 料金種別 | 必 | Text | 0::n | 列挙型メンバの配列:「期間払い、年払い、初回価格、フラット、無料、最小、最大、月額、など。列挙型メンバは別途調査。CDMでは「有料」と「無料」の二択 | ||||||
| price | 料金 | 〇 | Integer | 0::1 | 施設利用に必要な各種料金を日本円で記載(1円単位) | ||||||
| feeRemarks | 料金備考 | 〇 | Text | 0::1 | 料金の備考。例: １グループ1000円など。項目名は最高必要 | ||||||
| paymentMethod | 決済種別 | 〇 | Text (Array) | 0::n | 料金の支払方法。列挙型項目。列挙型メンバは、http://schema.org/paymentMethodを参照 | ||||||
| peopleCapacity | 収容人数 | 〇 | Integer | 0::1 | 定員 | ||||||
| accessMethod | アクセス方法 | 〇 | Text | 0::1 | 公共交通や車でのアクセス方法を記載 | ||||||
| refOffStreetParking | 駐車場情報 駐車場料金 |
〇 | Relationship | 0::n | 駐車場情報のid。駐車可能な台数などの説明、料金、優先駐車場の有無などを辿れる。データモデルはSmart Data ModelsのOffStreetParkingを参照されたい | ||||||
| areaServed | サービス担当区域(都道府県コード、市区町村コード、町丁字、ポリゴン、備考) | 〇 | geo:json Polygon |
0::1 | 要議論: CDMでは町名などを示す方式とポリゴンを示す方式の二つを定義している。どちらが良いか。但し、CDMでは町名はひとつしか入れられないため、複数の町名に跨る場合や一つの町名の一部を担当する場合は表現できない。 | ||||||
| coordinates | Number (Array) | n::n | |||||||||
| refContacts | 連絡先情報 | 必 | 〇 | Relationship | 1::1 | 施設を管理する事業者の情報。 | |||||
| accessblity | アクセリビリティ情報 | 〇 | StructuredValue | 0::1 | アクセリビリティ情報は施設毎の情報であり、データモデル内に情報搭載。共通語彙にも記載 | ||||||
| wheelchairAccessible | 車椅子可 | 〇 | Boolean | 0::1 | 車椅子の使用可否 | ||||||
| wheelchairRental | 車椅子貸出 | 〇 | Boolean | 0::1 | 車椅子貸出の有無 | ||||||
| caneRental | ツエ貸出 | 〇 | Boolean | 0::1 | ツエ貸出の有無 | ||||||
| multipurposeToilet | 多目的トイレ | 〇 | Boolean | 0::1 | 多目的トイレの有無 | ||||||
| ramps_Elevators_Escalators | スロープ、エレベータ、エスカレータ | 〇 | Boolean | 0::1 | スロープ、エレベータ、エスカレーターの有無 | ||||||
| mobilitySupportForBrailleBlocks | 点字ブロック等の移動支援 | 〇 | Boolean | 0::1 | 点字ブロック等の移動支援の有無 | ||||||
| brailleAndReadingAssistance | 点字や読上による支援 | 〇 | Boolean | 0::1 | 点字や読上による支援の有無 | ||||||
| accompaniedByGuideDogsAndServiceDogs | 盲導犬・介助犬・聴導犬同伴 | 〇 | Boolean | 0::1 | 盲導犬・介助犬・聴導犬などの同伴の有無 -- 意味不明。盲導犬などの同伴を許さない公共施設は無いはず | ||||||
| subtitles | 字幕 | 〇 | Boolean | 0::1 | 字幕の有無 | ||||||
| writingSupport | 筆談対応 | 〇 | Boolean | 0::1 | 筆談対応の有無 | ||||||
| toiletForOstomates | オストメイト対応トイレ | 〇 | Boolean | 0::1 | オストメイト対応トイレの有無 | ||||||
| remarks | 備考 | 〇 | Text | 0::1 | アクセシビリティの補足 | ||||||
| childCare | 子育て支援情報 | 〇 | StructuredValue | 0::1 | 子育て支援情報は施設毎の情報であり、データモデル内に情報搭載。共通語彙にも記載 | ||||||
| childCareType | 子供預かり種別（無料/有料） | 〇 | Text | 0::1 | 料金の種別。ENUM: "有償"、"無償" -- 要検討。Booleanとすべきか。次項含めて検討必要 | ||||||
| childCareFee | 子供預かり（料金） | 〇 | StructuredValue | 0::1 | 有料の場合の料金 | ||||||
| type | 種別 | 〇 | Text | 1::1 | "一時間毎の料金"などと入れる。 -- 要検討。typeをキーに使うのはNGSI違反。文字列ではマシンリーダブルでもない。 | ||||||
| typeRelatedInformation | 種別関連情報 | 〇 | Text | 1::1 | "700円"などと入れる | ||||||
| childCareFeeRemarks | 子供預かり（料金備考） | 〇 | Boolean | 0::1 | 料金の備考 | ||||||
| minAge | 最少年齢 | 〇 | Integer | 0::1 | 参加可能年齢（下限） | ||||||
| minAgeInMonths | 最少月齢 | 〇 | Integer | 0::1 | 参加可能月齢 | ||||||
| maxAge | 最大年齢 | 〇 | Integer | 0::1 | 参加可能年齢（上限） | ||||||
| childCareOpeningHours | 子供預かり開所時間 | 〇 | Text array | 0::1 | 対応時間帯 | ||||||
| nursery | 授乳室 | 〇 | Boolean | 0::1 | 授乳室の有無 | ||||||
| diaperChangingCorner | おむつ替えコーナー | 〇 | Boolean | 0::1 | おむつ替えコーナーの有無 | ||||||
| foodAndDrinkAvailable | 飲食可否 | 〇 | Boolean | 0::1 | 飲食可否 | ||||||
| strollerRental | ベビーカー貸出 | 〇 | Boolean | 0::1 | ベビーカー貸出の有無 | ||||||
| strollerUse | ベビーカー利用 | 〇 | Boolean | 0::1 | ベビーカー利用の有無 | ||||||
| remarks | 備考 | 〇 | Text | 0::1 | 子育て支援情報の備考 | ||||||
| facilityNo | 〇 | Integer | 1::1 | 公共施設の場合、自治体内で振られた通番を設定する | |||||||
| zones | 〇 | Text | 1::n | 施設内外の大まかな場所の名称の列です。多次元の行列で表現されます。この情報は、不具合の通報者、コールセンタ、受託事業者、および自治体職員間の意思疎通のために使われを事を想定しています。この内容と同じものはFMシステム内にも存在すると想定されるので、、この項目が都市OS上にも存在する必要性は、事業者の交代時や将来のデータ分析時にも要性かどうかに依存します。議論が必要だと考えます。は、 例えば、ある小学校は以下の様に区分されます。 [ "建物外部", [ "", ["外壁-北面","外壁-東面", "外壁-南面", "外壁-西面"] ], "校舎", [ "1F", ["正面玄関", "職員室", "音楽室"], "2F", ["1年A組", "1年B組", "1年C組", "2年A組", "2年B組", "2年C組"], "3F", ["3年A組", "3年B組", "3年C組", "4年A組", "4年B組", "4年C組"], "4F", ["5年A組", "5年B組", "5年C組", "6年A組", "6年B組", "6年C組"] ], "校庭", [ "グランド", ["北側", "中央", "南側"], "裏庭", ["花壇", "ケージ"] ] ] |
|||||||
| dateCreated | DateTime | 1::1 | NGSI V2のBuiltin Attributes | ||||||||
| dateModified | DateTime | 1::1 | NGSI V2のBuiltin Attributes | ||||||||
例
|
|||||||||||
Sch: schema.org/CivicStructure
PFM: 公共施設管理の施設補修のレポートを想定して設定した内容(事実には基づいていません)
