OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


See comments in line.

> -----Original Message-----
> From: Art Botterell [mailto:acb@incident.com]
> Sent: Tuesday, August 19, 2003 1:32 AM
> To: Notifications Subcommittee
> 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?
This area is a little convoluted. The ICS form requires a mapSketch. However
there are 3 situations I wanted to allow for. The first would be when there
was no sketch available and a textual description of the area would be all
that was available. In that case, only areaDesc under area would be filled
in. Another situation would be, independent of whether there was a map
sketch, to give the ability to provide specific area data such as geocode,
altitude etc. However, in keeping with our thoughts of not requiring
anythning additional to what is already on the forms, this info was
optional. The third case was when there is an areasketch. I put this as a
seperate element, but it may be better to have it as subelements to area??
Art has commented on this below. This seems like a good topic for
discussion.
>
> 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.
ResourcesSummary is indeed mandatory. My intent was that while the
ResourcesSummary was a singleton, there could be multiple resources
described within the element. Let me know if I have not represented this
correctly or if the group agrees with this approach.
This was the same idea for Organization. I think this is what Art is saying
below.
>
> 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.
Keep in mind that the information requreed to describe resources and
personnel are very different
>
> 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?)
According to Art in last weeks call. It is implied that the time period is a
shift. I do not see the harm in an optional way to described time period
covered or expiration.
>
> 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.

This is an excellent thought and I thought I had done it using the same
guide as the CAP spec.
This must have dropped off of the verion I sent out.
> >
> >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
>
>
> ---------------------------------------------------------------------
> 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]