[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] Draft schemas from the meeting
A quick answer for Karen, and a comment on structure in general, and the Contact Information Package in particular. We consolidated ContactInformation into its own package as a means to include wherever it is needed as named component of another element, e.g. in Resource we needed to add an element for whomever has responsibility for a resource at the time of a given message, so you find: ResponsibleParty: ContactInformation It is not specifically connected because it can be included as a package wherever it is needed and this eliminates intersecting association lines which would have required having a connector between ContactInformation and Resource and which will otherwise be confusing. We do need to explain this better. However, my suggestion is not to connect everything with association lines, but to package ScheduleInformation-ScheduleType-Location-Where into another package so that it can be used the same way. Otherwise we are going to have a rather confusing and more complex diagram for individual message types. This fits quite well with the consolidation of "types" in a schema. Cheers, Rex At 9:23 AM -0600 12/13/06, Aymond, Patti wrote: >I agree. We need to get the whole location thing straight. > >I really think getting the details of the >utility element types worked out is actually >more important than the data dictionary. Once >these are settled, schema and example >development can mostly finalized. > >According to the spec, we have four utility element types are > >DateTime >Currency >ContactInformation >Keyword >Location. > >Patti > >Patti Iles Aymond, PhD >Senior Scientist, Research & Development >Innovative Emergency Management, Inc. >Managing Risk in a Complex World >8555 United Plaza Blvd. Suite 100 >Baton Rouge, LA 70809 >(225) 952-8228 (phone) >(225) 952-8122 (fax) > >From: Karen Robinson [mailto:Karen.Robinson@nicta.com.au] >Sent: Wednesday, December 13, 2006 12:07 AM >To: Ham, Gary A >Cc: emergency-msg@lists.oasis-open.org >Subject: RE: [emergency-msg] Draft schemas from the meeting > > >Hi Gary (& others), > >The problem I see with treating Location as just >a container for GML information is that you lose >the ability to capture street addresses within >the ScheduleInformation - unless you embed them >in the free-text "Description" element, which is >not an optimal solution. For example, we can no >longer capture this sort of thing (from the >example in Section 3.3.1.4): > > <ScheduleInformation scheduleType="RequestedArrival"> > <DateTime>2006-03-24T09:00:00+10:00</DateTime> > <Location> > <Description>Innisfail Animal Refuge</Description> > <CIQInformation> > <xnal:Address> > <xnal:Country> > <xnal:Name>Australia</xnal:Name> > </xnal:Country> > <xnal:AdministrativeArea> > <xnal:Name>QLD</xnal:Name> > </xnal:AdministrativeArea> > <xnal:Locality> > <xnal:Name>Innisfail</xnal:Name> > </xnal:Locality> > <xnal:Thoroughfare> > <xnal:NameElement>Downing St</xnal:NameElement> > <xnal:Number>27</xnal:Number> > </xnal:Thoroughfare> > <xnal:PostCode> > <xnal:Identifier>4860</xnal:Identifier> > </xnal:PostCode> > </xnal:Address> > </CIQInformation> > </Location> > </ScheduleInformation> > >I suppose we could connect the >ScheduleInformation and CIQInformation objects >directly in the ERM (without hanging >CIQInformation off Location, as it was >previously) - but to my mind, grouping CIQ >addresses under Location makes sense, because an >address is one valid way of specifying a >Location (a GML Point is another, etcŠ). > >Unless I'm mistaken, the ContactInformation >captured at the ResourceMessage level captures >only address information for the resource >requester, owner, etc. - it doesn't specify >addresses for sending resources. > >By the way (a question for the whole group), is >it intentional that ContactInformation is now >sitting up in the corner of the ERM by itself, >not connected to anything? It is a bit >confusing, as it doesn't show where it fits into >the message structure. I noticed that the >sub-elements of ContactInformation have also >been removed from all of the message tables. > >The schema layout looks fine to me - however, I >would uncomment quite a few of the comments. J >Having worked through a lot of message examples, >I tend to think that most of the things that >have been removed are still needed. > >Thanks, >Karen. > > >From: Ham, Gary A [mailto:hamg@BATTELLE.ORG] >Sent: Wednesday, 13 December 2006 12:46 AM >To: Karen Robinson >Cc: emergency-msg@lists.oasis-open.org >Subject: RE: [emergency-msg] Draft schemas from the meeting > >Karen, > >I agree with you on the need for the committee >to address CIQ content item specifically. And >yes, I was just looking for a "straw man" CIQ >profile. But, "Party" and "Address" fill that >need for now. Are there others that the >committee wants? Should be a primary question >for Thursday. > >The difference between CIQInformation and >Location was that Location is (at least in my >mind) the container for the GML structure and >CIQ is the structure for addressing, party >naming, etc. following the OASIS spec for such >data. So, in my mind, CIQ was not part of >Location, nor was Location part of >CIQInformation. Rather both were potential >parts of ContactInformationType along with >Radio, and a generic Description. The objective >was to put a place in for both >standards, without having to directly mix them. >It was just my personal interpretation. I am >not hard over on it, though. If there is reason >to do differently, I think the committee would >be open to it. I certainly am. > >Can I take it from your comments that the rest >of the schema layout is OK with you? After the >"types" schema concept was your idea, and a good >one. Keep the input rolling!!!! > >Thanks, > >R/s > >Gary A. Ham >Senior Research Scientist >Battelle Memorial Institute >540-288-5611 (office) >703-869-6241 (cell) >"You would be surprised what you can accomplish >when you do not care who gets the credit." - >Harry S. Truman > > > >From: Karen Robinson [mailto:Karen.Robinson@nicta.com.au] >Sent: Monday, December 11, 2006 10:13 PM >To: Ham, Gary A >Subject: RE: [emergency-msg] Draft schemas from the meeting > >Hi Gary, > >Thanks for sending the schemas. I'm a bit >confused about what you want me to do with the >CIQ information. It looks like the >"CIQInformationType" type I added is still >there, just commented out. Could we just >uncomment it for now and use it "as is" until we >develop a CIQ profile consisting of an >appropriately restricted subset of CIQ? Or are >you asking me to actually develop the CIQ >profile? Unfortunately, I doubt that I could >work out all of the potential parts of CIQ we >might need by myself - I think this is probably >an activity for the group as a whole to tackle. >So far, I have identified "Party" and "Address" >as potentially useful parts of CIQ, but there >must be other elements as well. > >One thing that confuses me about the latest ERM >and schema is why CIQInformation has been taken >out of LocationType. Previously, CIQ Addresses >were the main way used to specify location (they >are used in most if not all of the message >examples). Was there some discussion at the >face-to-face surrounding this? > >Regards, >Karen. > > >From: Ham, Gary A [mailto:hamg@BATTELLE.ORG] >Sent: Tuesday, 12 December 2006 1:45 AM >To: emergency-msg@lists.oasis-open.org >Subject: [emergency-msg] Draft schemas from the meeting > >Folks, > >The attached schema files represent a completed >(with clearly defined placeholders for CIQ and >Location) reference schema for RM. Based on >Karen Robinson's input, I broke it into two >files. The Types schema represents all data >structures that are unchanged across the >spectrum of messages. They may be used or not >use by a message, but they are unchanged where >they are used. The only exception is >the likely further restriction of enumerated >types. The reference schema is the base schema >for all RM messages. It forms the least >restrictive schema from which each of the >messages will be derived. I am working on each >of the messages, but they will be a lot simpler >because of Karen's input. > >For Karen, If you would like to specifically add >the CIQ piece to the Types Schema (and tidy as >necessary) I would appreciate it. > >For all, If your mail server strips off the >attached files, just respond to my email ><mailto:hamg@battelle.org>hamg@battelle.org and >I will send access to a file download capability. > >Respectfully, >Gary A. Ham >Senior Research Scientist >Battelle Memorial Institute >540-288-5611 (office) >703-869-6241 (cell) >"You would be surprised what you can accomplish >when you do not care who gets the credit." - >Harry S. Truman > >-------------------------------------------------------------------------- >This email and any attachments may be confidential. They may contain legally >privileged information or copyright material. You should not read, copy, >use or disclose them without authorisation. If you are not an intended >recipient, please contact us at once by return email and then delete both >messages. We do not accept liability in connection with computer virus, >data corruption, delay, interruption, unauthorised access or unauthorised >amendment. This notice should not be removed. > >IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: ><http://www.iem.com/e_mail_confidentiality_notice.html>http://www..iem.com/e_mail_confidentiality_notice.html -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]