Re: [emergency-msg] ICS 201 Object Model

[Art Botterell <acb@incident.com>]

At 3:28 AM -0400 8/14/03, Allen Wyke wrote:
>1. In the object model I can see where things, such as the Area
>Description is required for an area, but is an area required for
>incidentInfo?

Good point... I thought in conventional UML usage "*" was considered 
equivalent to "0..n", but the descriptive text doesn't make that 
clear.  ResourcesSummary and Organization are both mandatory elements 
of the paper ICS form, and the lack of the "*" in the object diagram 
suggests to me that they're singletons.

As we discussed on last week's call, I think it might be useful to 
compose Organization of a "0..n" set of Position items... preserving 
the model of the paper form while dealing with the (unhappy) case 
where there'd be no position information available.  By the same 
token I think we might want to compose ResourcesSummary of a 
collection of Asset elements.

And on that basis we might like to consider creating a mandatory 
singleton Location element which could comprise 0..n MapSketch and/or 
Area elements.

>3. In the Summary (7) section of the form, I feel the crystal ball is
>speaking. I can foresee the desire, or maybe even need, in the future to
>embed/reference other XML dialects (potentially external to the document
>itself - think about, but avoid the color conversation we had about
>attachments in CAP at the mini-F2F :) in order to more accurately define
>what is happening. Whether it is temperature or maybe the description of
>a resource that was deployed. Having said that, I think it is probably
>premature to allow it, BUT we should put some thought into not
>preventing it in the future.

Temperature is a good example.  The weather forecast is part of the 
ICS-202-et-seq Incident Action Plan.  For congruence with ICS (and 
presumably NIMS) practice we may want not to over-extend the 201, 
especially not to the point that it overlaps other forms.

>4. In the Current Organization (6) section of the form, the crystal ball
>is speaking again. Not of future needs, but of innovative opportunity.

I think we should be circumspect about trying to be too innovative 
here.  The basic premises of the ICS Forms project are that:  a) the 
paper ICS forms are the expression of three decades of practical 
experience, and b) the paper ICS forms are a familiar user interface 
to responders.

Anyway, we went down this road once already and wound up agreeing 
that non-core assets would not be included in the message format, but 
could be treated as an attachment by URI reference (either for Web 
retrieval or in an accompanying SOAP attachment.)  I think it would 
make sense to apply that principle consistently.

>5. And finally the Resource Summary (5) page - basically a combo of the
>Current Organization page and the Summary page. Need + Innovation = we
>should think about it.

Again, I think we'll want to be cautious about reengineering 
established business practices too aggressively... it can be risky to 
forge too far ahead of the flock.   Anyway, even if we treat 
individuals as resources, their casting into organizational roles 
forms a separate relation.

By the way... might it also make sense to describe discrete Objective 
and Action elements to be composed into an 
ObjectivesAndActionsSummary?  And maybe make that structure a child 
to the IncidentInfo along with Area, ResourcesSummary and 
Organization?  Thus:

		IncidentInfo
			Location
				MapSketch *
				Area *
			ObjectivesAndActionsSummary
				Objective *
				Action *
			ResourcesSummary
				Asset *
			Organization
				Position *

That seems like it stays pretty true to the source document.  Of 
course, we might want to roll the message-header elements of ICS201 
into the IncidentInfo, or vice-versa.  (And do we need some way to 
describe the timeframe... an Expires or ValidUntil element in the 
header, maybe?)

We might allow optional Resource elements (as in CAP) at various 
points in the document to enable the referencing/attachment of 
"exotic" assets like Visio or Project files, GIS files, photos or 
graphics.  (Heck, in the bandwidth-rich future, an IC might even want 
to attach a little audio or video commentary.)

- Art

PS - Just as an aside... even though the ICS-201 is normally created 
either by the ICS or his Plans Chief, it's interesting how the 
structure of the form actually parallels the ICS organizational 
paradigm:

		Incident ID / Location ... Plans (SitStat);
		Objectives and Actions ... Operations
		Resources Summary ... Logistics
		Organization ... Finance/Admin.

Don't want to make too much of that, but it does strike me as 
handy... especially for divvy'ing up the work of preparing this 
report.  The sort of subtle refinement one expects to find in a 
mature system. - ACB


At 3:28 AM -0400 8/14/03, Allen Wyke wrote:
>David, looks good - you guys DEFINITELY have a great start off on this
>effort. Couple of comments, that probably need nothing more than
>clarification.
>
>1. In the object model I can see where things, such as the Area
>Description is required for an area, but is an area required for
>incidentInfo? Same for incidentInfo to ics201 (I definitely assume that
>is required), resourcesSummary to incidentInfo, organization to
>incidentInfo, and mapSketch to area.
>
>2. Something that would be beneficial in the first page of the example
>document, which would also resolve my questions for #1, is to mark what
>is option, required, and repeatable. Just a thought.
>
>3. In the Summary (7) section of the form, I feel the crystal ball is
>speaking. I can foresee the desire, or maybe even need, in the future to
>embed/reference other XML dialects (potentially external to the document
>itself - think about, but avoid the color conversation we had about
>attachments in CAP at the mini-F2F :) in order to more accurately define
>what is happening. Whether it is temperature or maybe the description of
>a resource that was deployed. Having said that, I think it is probably
>premature to allow it, BUT we should put some thought into not
>preventing it in the future.
>
>4. In the Current Organization (6) section of the form, the crystal ball
>is speaking again. Not of future needs, but of innovative opportunity.
>This is one of those times that having a Microsoft representative on the
>TC would be helpful. Imagine, and I am completely making this up by the
>way, the part of Microsoft's future solutions for Public Safety involve
>an application that allows responders to quickly map out a process for
>responding to an emergency. This could involve anything from an org
>(Visio) chart of people/agencies involved, conveniently linked to a task
>tracking application (MS Project), to mapping out the work flow and/or
>business processes that have been put in place to ensure guidelines are
>adhered to and followed (think BizTalk's Orchestration Designer - aka
>Visio for building/linking/creating Business Process). Now imagine
>exporting this information into a format that can be included in the ICS
>201 form not unlike embedding a spreadsheet or video in a PowerPoint
>presentation. Anyway, my point is that from a software innovation
>perspective this section has a lot of opportunity, so we should think
>about that.
>
>5. And finally the Resource Summary (5) page - basically a combo of the
>Current Organization page and the Summary page. Need + Innovation = we
>should think about it.
>
>I know a lot of this may sound pie in the sky, but from a software
>vendor's perspective in this space, have #3 - #5 become a reality is not
>as complex as you might think. Additionally, and this is really the
>important reason, having our ICS work empowered to dramatically improve
>the current paper solution makes for a compelling business case to
>adopt. Our ability to turn this part of an ICS form into a living,
>breathing, document that extremely more powerful, because of its
>actionability, than its paper ancestor can really get things moving
>fast.
>
>Again, I certainly am not implying we have or should do all of this.
>Just that we should consider it, because it may put a longer term
>perspective in our minds as we move forward.
>
>Allen
>
>On Tue, 2003-08-12 at 11:28, David Hall wrote:
>>  Please find attached a first cut at the object model diagram for ICS
>>  Form 201 - Incident Briefing.
>> 
>>  I have also included an example of a filled out Form 201. Note that I
>  > could not find a completed example of the Map portion.
>> 
>>  Assume this is too late to discuss today, but if I could get
>>  feedback/questions before next weeks mtg, that would be appreciated.
>> 
>>  Thanks,
>> 
>>  David
>> 
>>  ******************************
>>  David Hall
>>  Federal Support Systems
>>  703-627-0215
>>  703-832-5664 fax
>>  -----------------------------
>>  System Engineering
>>  Information Security
>>  Internet Software Systems
>>  Project Management
>>  ******************************
>> 
>>
>>  ______________________________________________________________________
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
>>  For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org
>--
>R. Allen Wyke
>Chair, Emergency Management TC
>emtc@nc.rr.com
>http://www.oasis-open.org/committees/emergency
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org