説明
2023-04-04/2024-09-20
不具合(故障・破損等)案件を表現するデータモデルです。このデータモデルの名称はComplaintですが、説明文などで用いる呼称は「案件」です。①のカラムは包括施設管理において事業者から自治体への報告の際に必要と思われる項目を示しています
データモデル
2023-04-04/2024-09-27
下表の「呼称」の列は、説明文やケーススタディで用いる項目の名称です。仕様としては意味を持たない情報ですが、本来の項目名であるAttribute nameは日本語話者にとっては感覚的に理解しにくいため、便宜上定義してあります。
青字の部分はレビュー中の箇所です。
| Data Model | 説明 | |||||
| Attribute name | 回数 | type | 補足 | ① | ||
| id | 案件ID | 1::1 | Text | NGSI-LDの仕様に合わせ、次の形式の識別子とする。”urn:ngsi-ld:Complaint:”<一意となる番号>。一意となる番号は事業者が交代しても一意となる様な運用が必要です。 | 必須 | |
| type | 1::1 | Text | 必ず”Complaint”の文字列でなくてはならない | 必須 | ||
| phenomenon | 現象 | 1::1 | StructuredValue | 不具合現象です。 | 必須 | |
| category | 現象概要 | 1::n | Array | 列挙型メンバ。Phenomenonを参照。[“破損”]、[“汚損”]など | 必須 | |
| remarks | 現象補足 | 0::1 | Text | 前項の補足です。例えば、”コンクリートの割れ”など | ||
| dataProvider | 0::1 | Text | データのプロバイダのid。このWGが想定するシステムでは関係しないと考えます | |||
| description | 説明 | 0::1 | Text | 説明を記載 | ||
| isFiledTo | 0::1 | Text | 苦情をエスカレーションする先。例えば自治体の所管課など | |||
| isMadeBy | 依頼者 | 0::1 | Text | この苦情を申し立てたユーザーの ID。個人情報にならない様に留意が必要。例えば、定期検査による検出はこの項目を記入するが、個人や利用者団体は記入しないなど。 | ||
| isPartOf | 関連案件ID | 0::n | Array (Relationship) | ひとつの不具合が複数の「案件」から構成される場合などにこの項目で相互参照したり階層化したりします。各「案件」は基本的に「報告」からリンクされますが、「報告」登録後に追加で「案件」を追加登録されるケースも想定されます。その場合は追加登録した「案件」からこの「関連案件ID」で元の「案件」をリンクする事で、間接的に「報告」と結びつけます。 | ||
| location | 座標 | 0::1 | Point | 不具合の発生個所を座標で示します。例えば、道路の陥没、河川の汚染、街角の異臭などを想定しています。今回のユースケースとは合わないと考えます | ||
| name | 案件名 | 0::1 | Text | 案件の名称 | 〇 | |
| seeAlso | 追加情報 | 0::n | URL | 追加情報のurlの列です | ||
| source | 0::1 | Text | この情報の提供元に関するurl等を格納します | |||
| status | ステータス | 0::1 | Text | 活動状況を登録します。”処置中”、”完了”など。用語について「案件ステータス(ComplaintStatus)」を参照してください | ||
| timestamps | 経緯 | 1::n | Array (StructuredValue) | 受付から完了に至る一連の手順における日付、または日時を登録します。予定も含めて構いません。尚、12条点検で報告する不具合については少なくとも受付の日時を記入すると共に、作業未実施の場合は作業予定の日時も記入します。 | 必須 | |
| step | ステップ | 1::1 | Text | 日付または日時に対する手順内のステップの名称。例え゛は、”発生”、”調査予定”、”調査実施”、”作業予定”、”作業実施”、”完了届出”、”完了承認”など。同じ名称のタイムスタンプが複数登録されても構いません。用語については「案件ステップ(ComplaintStep)」を参照してください | 〇 | |
| timestamp | 日時 | 1::1 | DateTime | 日付または日時です。時刻を省略する場合、00:00を指定します | 〇 | |
| refFacility | 1::1 | Relationship | 案件の対象となる施設(Facility)に対するリンクです。FacilityのEntity idを格納します。refFacilityかrefBuildingのどちらかを必ず登録します。施設からBuildingを辿ることができます。 | 〇 | ||
| refBuilding | 建物ID | 1::1 | Relationship | 案件の対象となる建物(Building)に対するリンクです。BuildingのEntity idを格納します。refFacilityかrefBuildingのどちらかを必ず登録します。 | 〇 | |
| zones | 場所 | 1::1 | StructuredValue | 不具合発生の場所を格納します。列挙型項目の列と自由記述文字列の組み合わせで格納します。場所大分類・場所中分類・場所小分類は「建物」または「施設」のZonesから選択した文字列です。この項目は不具合の現象を検出した場所であり、修繕した場所と異なる可能性があります。修繕した場所は「修繕計画(repairPlan)」に登録します。 | 必須 | |
| abstracts | 場所大分類 場所中分類 場所小分類 | 1::3 | Array | 列挙メンバは建物(Building)または施設(Facility)のZonesから選択した文字列です。このArrayは順序に意味を持ち(順序付きリスト)、zoneName、subzoneNameの第一要素、subzoneNameの第二要素の順番に登録します。例えば、[“校舎”,”2F”,”1年A組”]となります | 〇 | |
| remarks | 場所補足 | 0::1 | Text | 前項の補足です。例えば、”北側”など。 | 〇 | |
| parts | 1::1 | StructuredValue | 不具合を発生したBuildingComponent(部位)やDevice(設備)を示す | 必須 | ||
| abstracts | 部位概要 | 0::1 | Text | 不具合を発生した部位や設備を示す列挙型項目。用語の定義はBuildingComponentを参照 | 〇 | |
| refComponent | 部位ID | 0::1 | Relationship | 不具合を発生した部位(BuildingComponent)または設備(Device)に対するリンク。BuildingComponentが登録されていない場合は省略して構わない | 〇 | |
| remarks | 部位補足 | 0::1 | Text | 部位の補足です。例えば”基礎部分”、”蛍光管”などと記載します。 | 〇 | |
| cause | 原因 | 1::1 | StructuredValue | 不具合を発生させた原因。原因は「処置計画(repairPlan)」に記載する修繕の内容に対応したものである必要がある。修繕が完了し承認を得た後に現象が再発した場合は新たに「報告」や「案件」の登録を検討します。尚、「報告」や「案件」の登録例については包括施設管理における使い方 (6/7)もご覧ください。 | 必須 | |
| abstracts | 原因概要 | 1::1 | Text | 原因を示す列挙型項目。用語定義はCauseを参照。例えば”車両事故”、”地震”など | 必須 | |
| remarks | 原因補足 | 0::1 | Text | 前項の補足 | 〇 | |
| severityMark | 緊急度マーク | 1::1 | Text | 不具合に対する緊急性を示すマークを登録する項目です。登録する用語はComplaintSeverityをご覧ください。 | 〇 | |
| severity | 緊急度補足 | 1::1 | Text | 不具合に対する処置の緊急性を示す項目です。sevirityMarkに対する補足の位置づけとなります。例えば”放置すると機能不全に至る可能性あり”、”施設運営に影響あり”など | 〇 | |
| repairPlan | 修繕計画 | 1::1 | Text | 処置の計画です。”部品交換”などと記載します。修繕する場所が「場所(zones)」と異なる場合は修繕した場所も記載します。また、修繕が複数の工程や複数の箇所に及ぶ場合は、出来る限りそれぞれの箇所や修繕内容が分かる様に記述します。 | 〇 | |
技術情報
2023-04-04
| 定義名 | Complaint |
| Smart Data Models/Complaint | |
| 参照データモデル | なし |
| URI | https://ppp-database/spec/datamodel/Complaint |
| JSON Schema | このJSON SchemaはNormalized形式に対応しています。必要に応じて、形式チェックの項目を追加するなどして利用する事ができます。本JSON Schemaはデータ仕様の変更や、JSON schemaに対する要望により、予告なく更新されます |
| 補足 | コア・データモデルに「案件」に相当するデータモデルが無いため、Smart Data Modelsから継承しました。ひとつの不具合に対して複数回数の報告があり得るので、次の「報告(Report)」と分離して策定してあります。 |
更新情報
■コメントおよび更新の一覧
| コメント日 | コメント内容 | 対応 | 更新日 |
|---|---|---|---|
| ・受付から完了までのタイムスタンプを登録する項目が欲しい | ・”timestamp”を構造化すると共に、複数登録可能とする | ||
| 2023-06-27 | 千葉県佐倉市 ・重要度の記述も共通化して欲しい | 新たにseverityMarkというAttributeを追加し、Severityのレベルを表現できる様にしました | 2024-06-22 |
| 2023-06-27 | 佐倉市 ・昔の12条点検の報告書を読み返しても、実態を把握しにくい | 以下の改善を行いました ・12条点検の報告書の項目も登録可能とする ・12条点検の報告書に対応する「報告(Report)」から検出した不具合の「案件(Complaint)」を辿れる様にする 本データモデルでは、timestampsの説明に追記しました | 2023-11-13 |
| 2023-08-01 | 事務局 ・施設管理の管理単位を建物・棟・施設のいずれも可能とします | AttributeとしてrefBuildingを追加し、施設管理の管理単位に対応して、FacilityまたはBuildingのどちらでもリンクできる様にしました | 2023-11-13 |
| 2024-09-07 | 事務局 ・JSON SchemaのAttributeのisPartOfがArray構造になっていない | Arrayに修正しました | 2024-09-07 |
| 2024-09-20 | 事務局 ・各種説明やケーススタディに項目名を記載する際、Attribute nameでは理解しにくい | 日本語話者向けに「呼称」の列を追加しました。仕様としては意味はなく、説明文やケーススタディの理解が容易になる様に付けた便宜上の名称です | 2024-09-20 |
| 2024-09-27 | 事務局 事業者交替時の事業者間における修繕履歴の引継ぎの議論において、以下の課題が示された ・不具合が発生した場所と修繕した場所をどこにどの様に記述するのかが明確でない ・原因について、初期に推定したれ原因と、修繕に至った際の推定原因が異なる場合の記述が明確でない ・報告後に「案件」が追加登録された場合の登録方法が明確ではない ・修繕履歴と資料とするために、不具合の修繕内容を後で読んでわかる様に記述するすべき ・「ステータス」と「経緯(timestamps)」の「ステップ」は、引継ぎ上用語の定義が必要な場合がある | 「場所」「原因」および「修繕計画」の説明に記述を追加します。 「関連案件ID」に「案件」を後から追加登録する場合の考え方を追記します。 「ステータス」については用語として”完了”を定義し、「経緯」の「ステップ」については用語として”発生”と”完了”の用語を定義します 青字で記述しており、現在レビュー中です。 | 2024-09-27 |