MHonArc v2.5.0b2 -->
emergency-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency-msg] ICS 201 Object Model
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]