案件 (Complaint)

説明

2023-04-04

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

データモデル

2023-04-04/2024-06-22

Data Model				説明
Attribute name		回数	type	補足	①
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		0::n	Array (Relationship)	ひとつの不具合が複数の苦情から構成される場合などにこの項目で相互参照したり階層化したりします。
location		0::1	Point	不具合の発生個所を座標で示します。例えば、道路の陥没、河川の汚染、街角の異臭などを想定しています。今回のユースケースとは合わないと考えます
name		0::1	Text	案件の名称	〇
seeAlso		0::n	URL	追加情報のurlの列です
source		0::1	Text	この情報の提供元に関するurl等を格納します
status		0::1	Text	活動状況を登録します。”処置中”、”完了”など
timestamps		1::n	Array (StructuredValue)	受付から完了に至る一連の手順における日付、または日時を登録します。予定も含めて構いません。尚、12条点検で報告する不具合については少なくとも受付の日時を記入すると共に、作業未実施の場合は作業予定の日時も記入します。	必須
	step	1::1	Text	日付または日時に対する手順内のステップの名称。例え゛は、”受付”、”調査予定”、”調査実施”、”作業予定”、”作業実施”、”完了届出”、”完了承認”など。同じ名称のタイムスタンプが複数登録されても構いません	〇
	timestamp	1::1	DateTime	日付または日時です。時刻を省略する場合、00:00を指定します	〇
refFacility		1::1	Relationship	案件の対象となる施設(Facility)に対するリンクです。FacilityのEntity idを格納します。refFacilityかrefBuildingのどちらかを必ず登録します。施設からBuildingを辿ることができます。	〇
refBuilding		1::1	Relationship	案件の対象となる建物(Building)に対するリンクです。BuildingのEntity idを格納します。refFacilityかrefBuildingのどちらかを必ず登録します。	〇
zones		1::1	StructuredValue	不具合発生の場所を格納します。列挙型項目の列と自由記述文字列の組み合わせで格納します。列挙型メンバは施設のZonesから選択した文字列です>	必須
	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	0::1	Relationship	不具合を発生した部位(BuildingComponent)または設備(Device)に対するリンク。BuildingComponentが登録されていない場合は省略して構わない	〇
	remarks	0::1	Text	部位の補足です。例えば”基礎部分”、”蛍光管”などと記載します。	〇
cause		1::1	StructuredValue	不具合を発生させた原因。	必須
	abstracts	1::1	Text	原因を示す列挙型項目。用語定義はCauseを参照。例えば”車両事故”、”地震”など	必須
	remarks	0::1	Text	前項の補足	〇
severityMark		1::1	Text	不具合に対する緊急性を示すマークを登録する項目です。登録する用語はComplaintSeverityをご覧ください。	〇
severity		1::1	Text	不具合に対する処置の緊急性を示す項目です。sevirityMarkに対する補足の位置づけとなります。例えば”放置すると機能不全に至る可能性あり”、”施設運営に影響あり”など	〇
repairPlan		1::1	Text	処置の計画です。”部品交換”などと記載します。	〇

技術情報

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)」と分離して策定してあります。

影響度の4段階

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