案件 (Complaint)

説明

2023-04-04

 不具合(故障・破損等)案件を表現するデータモデルです。①のカラムは包括施設管理において事業者から自治体への報告の際に必要と思われる項目を示しています

データモデル

2023-04-04/2023-11-13

赤字の部分は頂いたコメントにより追記した未確定のドラフトです。

Data Model説明
Attribute name回数type補足
id1::1TextNGSI-LDの仕様に合わせ、次の形式の識別子とする。”urn:ngsi-ld:Complaint”<.一意となる番号>。一意となる番号は事業者が交代しても一意となる様な運用が必要です。必須
type1::1Text必ず”Complaint”の文字列でなくてはならない必須
phenomenon1::1StructuredValue不具合現象です。必須
category1::nArray列挙型メンバ。Phenomenonを参照。[“破損”]、[“汚損”]など必須
remarks0::1Text前項の補足です。例えば、”コンクリートの割れ”など
dataProvider0::1Textデータのプロバイダのid。このWGが想定するシステムでは関係しないと考えます
description0::1Text説明を記載
isFiledTo0::1Text苦情をエスカレーションする先。例えば自治体の所管課など
isMadeBy0::1Textこの苦情を申し立てたユーザーの ID。個人情報にならない様に留意が必要。例えば、定期検査による検出はこの項目を記入するが、個人や利用者団体は記入しないなど。
isPartOf0::nArray
(Relationship)
ひとつの不具合が複数の苦情から構成される場合などにこの項目で相互参照したり階層化したりします。
location0::1Point不具合の発生個所を座標で示します。例えば、道路の陥没、河川の汚染、街角の異臭などを想定しています。今回のユースケースとは合わないと考えます
name0::1Text案件の名称
seeAlso0::nURL追加情報のurlの列です
source0::1Textこの情報の提供元に関するurl等を格納します
status0::1Text活動状況を登録します。”処置中”、”完了”など
timestamps1::nArray
(StructuredValue)
受付から完了に至る一連の手順における日付、または日時を登録します。予定も含めて構いません。尚、12条点検で報告する不具合については少なくとも受付の日時を記入すると共に、作業未実施の場合は作業予定の日時も記入します。必須
step1::1Text日付または日時に対する手順内のステップの名称。例え゛は、”受付”、”調査予定”、”調査実施”、”作業予定”、”作業実施”、”完了届出”、”完了承認”など。同じ名称のタイムスタンプが複数登録されても構いません
timestamp1::1DateTime日付または日時です。時刻を省略する場合、00:00を指定します
refFacility1::1Relationship案件の対象となる施設(Facility)に対するリンクです。FacilityのEntity idを格納します。refFacilityかrefBuildingのどちらかを必ず登録します。施設からBuildingを辿ることができます。
refBuilding1::1Relationship案件の対象となる建物(Building)に対するリンクです。BuildingのEntity idを格納します。refFacilityかrefBuildingのどちらかを必ず登録します。
zones1::1StructuredValue不具合発生の場所を格納します。列挙型項目の列と自由記述文字列の組み合わせで格納します。列挙型メンバは施設のZonesから選択した文字列です>
必須
abstracts1::3Array列挙メンバは建物(Building)または施設(Facility)のZonesから選択した文字列です。このArrayは順序に意味を持ち(順序付きリスト)、zoneName、subzoneNameの第一要素、subzoneNameの第二要素の順番に登録します。ま例えば、[“校舎”,”2F”,”1年A組”]となります
remarks0::1Text前項の補足です。例えば、”北側”など。
parts1::1StructuredValue不具合を発生したBuildingComponent(部位)やDevice(設備)を示す必須
abstracts0::1Text不具合を発生した部位や設備を示す列挙型項目。用語の定義はBuildingComponentを参照
refComponent0::1Relationship不具合を発生した部位(BuildingComponent)または設備(Device)に対するリンク。BuildingComponentが登録されていない場合は省略して構わない
remarks0::1Text部位の補足です。例えば”基礎部分”、”蛍光管”などと記載します。
cause1::1StructuredValue不具合を発生させた原因。必須
abstracts1::1Text原因を示す列挙型項目。用語定義はCauseを参照。例えば”車両事故”、”地震”など必須
remarks0::1Text前項の補足
severityMark1::1Text不具合の重要度を示すマークを登録する項目です。登録する用語はComplaintSeverityをご覧ください。
severity1::1Text不具合の重要度を示す項目です。例えば”放置すると機能不全”、”施設運営に影響あり”など
repairPlan1::1Text処置の計画です。”部品交換”などと記載します。

技術情報

2023-04-04

定義名Complaint
継承元データモデルSmart Data Models/Complaint
参照データモデルなし
URIhttps://ppp-database/spec/datamodel/Complaint
JSON SchemaこのJSON SchemaはNormalized形式に対応しています。必要に応じて、形式チェックの項目を追加するなどして利用する事ができます。本JSON Schemaはデータ仕様の変更や、JSON schemaに対する要望により、予告なく更新されます
補足コア・データモデルに「案件」に相当するデータモデルが無いため、Smart Data Modelsから継承しました。ひとつの不具合に対して複数回数の報告があり得るので、次の「報告(Report)」と分離して策定してあります。

影響度の4段階

 severityMarkに設定するマークの説明です。

更新情報

■コメントおよび更新の一覧

コメント日コメント内容対応更新日
2023-05-10・受付から完了までのタイムスタンプを登録する項目が欲しい・”timestamp”を構造化すると共に、複数登録可能とする2023-05-13
2023-06-27千葉県佐倉市
・重要度の記述も共通化して欲しい
新たにseverityMarkというAttributeを追加し、Severityのレベルを表現できる様にします
— 赤字で記述している箇所が仕様のドラフトです
2023-11-13
2023-06-27佐倉市
・昔の12条点検の報告書を読み返しても、実態を把握しにくい
以下の改善を行います。青字の部分が加筆分です。検討中であり、未確定の仕様です
・12条点検の報告書の項目も登録可能とする
・12条点検の報告書に対応する「報告(Report)」から検出した不具合の「案件(Complaint)」を辿れる様にする
本データモデルでは、timestampsの説明に追記しました
2023-11-13
2023-08-01事務局
・施設管理の管理単位を建物・棟・施設のいずれも可能とします
AttributeとしてrefBuildingを追加し、施設管理の管理単位に対応して、FacilityまたはBuildingのどちらでもリンクできる様にしました2023-11-13