emergency-msg — archive

Re: [emergency-msg] SC Call Tuesday

From: Rex Brooks
To: [email protected]
Date: Tue, 07 Oct 2003 12:21:00 -0000

 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] SC Call Tuesday




From: Rex Brooks <[email protected]>
To: Art Botterell <[email protected]>, <[email protected]>
Date: Tue, 7 Oct 2003 06:23:48 -0700






Me, too. See my comment on TC agenda items 7 & 8.

Ciao,
Rex

At 11:55 PM -0700 10/6/03, Art Botterell wrote:
>Sounds like another pass through the ICS-201 
>object model may be in order... looking forward 
>to our call at 12:30 Eastern 9:30 Pacific... 
>800-453-7412 passcode: 604776!
>
>- Art
>
>
>At 2:15 PM -0400 10/6/03, Walid Ramadan wrote:
>>I am no expert on ICS or UML, but her are my 
>>comments on version2 of ICS201 Data Dictionary
>>
>>resourceId: why are we limiting the format for 
>>this one?  ICS instructions suggest a resource 
>>ID may vary from a license plate or a vendor 
>>name plus anything in between.
>>
>>I may be mis-reading this, but how can the 
>>"resources" element be optional and the "asset" 
>>element be required
>>
>>The ICS201 is a 4-page document, and therefore, 
>>it must be maintained as such with all its 
>>elements regardless of whether information is 
>>available to go on all 4 pages.  For example, 
>>in a paper environment, you do not just take 
>>out the resource page of the ICS201 just 
>>because you do not need or have any resources, 
>>but rather you include it blanc. I would like 
>>for our object model to reflect that.  In other 
>>word, the recipient of the ICS201 should be 
>>able to recognize that there were no resources 
>>needed. Same applies to "location" and 
>>"position" in the object model.
>>
>>The multiplicity for "organization", 
>>"resources", "location" and "summary" in the 
>>object model cannot all be "0�n" 
>>simultaneously. We need to capture that 
>>constraint., otherwise, what is the point of 
>>filling the ICS201?
>>
>>In the data dictionary, the "objective" is 
>>designated as "optional", but in the object 
>>model, it is showing "1..n" multiplicity.  Are 
>>these two inconsistent?
>>
>>A time/date data element is missing under "action" under "summary"
>>
>>I am not sure I understand the "0�n" 
>>multiplicity between ics201 and incident data 
>>elements.  Is that implying that the same 
>>ICS201 is used for multiple incidents?  The 
>>purpose of ICS201 is to provide a limited 
>>number of users with information on the initial 
>>incident response until the first operational 
>>period begins
>>
>>We made some of the elements that we listed in 
>>the data dictionary under "ics201" "Elements 
>>and Sub-elements" mandatory, such as msgType, 
>>and status.  I believe that we agreed to reuse 
>>particular set of elements from CAP that 
>>provide for identification of the incident to 
>>which this ICS is related.  Are we trying to 
>>translate ICS201 into a CAP message?
>>
>>Although designated as optional, the "contact" 
>>element under "incident" Elements and 
>>Sub-elements" is not necessary because that 
>>information is already captured by other 
>>mandatory data elements such as preparedName, 
>>preparedPosition, and preparedAgency.
>>
>>I am not sure I understand under what 
>>circumstances the incident element under 
>>"incident" Elements and Sub-elements can have 
>>more than one <organization> block.
>>
>>When it comes to the data element 
>>"positionReports", the high level positions 
>>such as those making up the Unified Command, 
>>Officers, and Section Chiefs are pre-defined in 
>>ICS201, although not necessarily deployed in 
>>every incident.  I think the data model should 
>>capitalize on the fact that those positions are 
>>well-defined. We can also extend that to all 
>>ICS positions including task forces groups, etc.
>>
>>Walid
>>
>>
>>