SC Call Tuesday

[Art Botterell <acb@incident.com>]

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
>
>
>-----Original Message-----
>From: Art Botterell [<mailto:acb@incident.com>mailto:acb@incident.com]
>Sent: Wednesday, October 01, 2003 6:58 PM
>To: emergency-msg@lists.oasis-open.org
>Subject: [emergency-msg] Minutes from 9/30/03 call
>
>
>NOTIFICATION METHODS AND MESSAGES SUBCOMMITTEE
>Conference Call - 30 September 2003 - 12:30 PM EDT
>
>Attending: David Hall, Rex Brooks, Gary Ham, Jerry Weltman, Carl
>Reed, Rob Torshon, Art Botterell
>
>- Rex recounted highlights of last week's TC meeting for the folks
>who were unable to participate.
>
>- Art and others reported on the successful CAP-based demo event in
>Washington last week.
>
>- David led a discussion of the status of the ICS-201 format.  He has
>incorporated various inputs (from Eliot and others) in version 2 of
>the Data Dictionary.  Rex volunteered to help David in casting the
>format as an XML Schema.  The group agreed that we would provide our
>comments on the data dictionary in time for next week's call.  (A
>copy of the v2 Dictionary is attached for reference.)
>
>- Cathy Subatch is on sabbatical for the immediate future.  We'll all
>miss her detailed minutes and general organizational skills.
>
>- Rex mentioned special populations, and Art suggested that we might
>want to consider how such groups might help champion CAP and other
>interoperability standards that improve accessibility.
>
>- That led to a brief discussion of PR.  Art reminded the group that
>any press mention of OASIS or its processes should be coordinated
>through the OASIS PR mechanism.
>
>   - The call adjourned at 1:00 PM EDT. << File: 
>ICS_201_Data_Dictionary_v_2.doc >>  << File: 
>ATT199327.txt >>