emergency-msg — archive

Fwd: Re: ICS 201 Location Issues

From: Art Botterell
To: [email protected]
Date: Wed, 10 Sep 2003 17:42:00 -0000

 MHonArc v2.5.0b2 -->
















emergency-msg message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Fwd: Re: ICS 201 Location Issues




From: Art Botterell <[email protected]>
To: [email protected]
Date: Wed, 10 Sep 2003 11:02:52 -0700






Friends -

Carl and I had a little offline exchange, quoted below, on a point I 
think we should probably consider as a group.

- Art


>Date: Wed, 10 Sep 2003 10:54:47 -0700
>To: "Carl Reed" <[email protected]>
>From: Art Botterell <[email protected]>
>Subject: Re: ICS 201 Location Issues
>Cc:
>Bcc:
>X-Attachments:
>
>Carl -
>
>My sense is that what we're defining is a message, an event, rather 
>than a data structure per se, so we haven't really engaged issues of 
>persistence.  While some applications might want to implement an 
>internal data structure that matches that of the message, others 
>might (indeed, some already have) implement different structures to 
>hold the same and other information.
>
>In CAP we provide a field that allows the sender to indicate that a 
>particular message is an update to some earlier one.  But in CAP we 
>couldn't assume the persistence of an "incident" entity.  In the ICS 
>context, messages might be bound by the  incident they refer to, as 
>well as by the identity of the sender.
>
>Actually this ICS form is used to communicate from the field 
>Incident Command to some operating center or shared info system more 
>than in the other direction.  Although it also could be used by a 
>center to depict the state of an incident, the operating center 
>typically has no direct knowledge of the information in this form 
>until its reported by the IC.
>
>Anyway, each ICS201 message is designed to be a complete 
>representation of reality at its particular point in time.  So if it 
>refers to an incident that's new to a recipient, the recipient might 
>want to create a new incident object (on whatever model that 
>recipient uses) and post the information to it... and if it refers 
>to an existing incident then it might be used to update the existing 
>incident's state.
>
>All this is off the top of my head... we haven't really had this 
>conversation in the subcommittee yet.  Am I making any sense?
>
>- Art
>
>
>>Art -
>>
>>A quick question. In this document, it appears (from the use cases) that the
>>group is only considering content push to the field. Are they considering
>>field capture of new content and then the subsequent communication of that
>>new content back to the EM Response Center?
>>
>>Carl
>>
>>