[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-msg] SC Call Tuesday
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 >> >> >>-----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 >> > > >To unsubscribe from this mailing list (and be >removed from the roster of the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/emergency-msg/members/leave_workgroup.php. -- Rex Brooks GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth W3Address: http://www.starbourne.com Email: rexb@starbourne.com Tel: 510-849-2309 Fax: By Request
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]