RE: [emergency-msg] RM elements - Ross/Jon Skeels

From
Aymond, Patti <>
Date
2006-08-28T14:55:59+00:00
ID
Thread
RE: [emergency-msg] RM elements - Ross/Jon Skeels
Title: Re: [emergency-msg] RM elements - Ross/Jon Skeels

I'm comfortable with 
ContactInfo structure as we have it now as long as we add an element that 
indicates what role the contact has in the resource procurement 
process.

 

I'm more interested in grouping elements 
together based on what role provides them. I think having resource producer 
elements grouped together, resource distributor elements grouped together, 
resource owner elements grouped together... etc. would clarify what elements are 
appropriate for what message type. For example, elements associated with 
resource owner would never be used for a "Request Resource" 
message.

 

Patti

From: Rex Brooks 
[mailto:]
Sent: Mon 8/28/2006 8:49 AM
To: 
Renato Iannella; Aymond, Patti; Tim Grapes
Cc: 
Emergency_Mgt_Msg_SC
Subject: Re: [emergency-msg] RM elements - 
Ross/Jon Skeels

Agreed.

Perhaps we should place ResourceConsumers, 
ResourceDistributors and
ResourceOwners into their own category: 
ResourceActors?

That way they are grouped together and the distinctions 
between and
amongst them such as that between Owner and Distributor can be 
made
clear in relation to the others.

Cheers,
Rex

At 2:57 PM 
+1000 8/28/06, Renato Iannella wrote:
>On 26 Aug 2006, at 02:24, Aymond, 
Patti wrote:
>
>>Looking at this I realize that we don't have 
elements that identify
>>the requestor and the provider. I think we 
need to add that
>>distinction. I see the general "ContactInfo" as 
contact information
>>relating to the sender of the message, which may 
not be the
>>requestor of the resource or the provider of the resource. 
One
>>thought is to add a "ContactType" element in "ContactInfo" that 
can
>>have the values "MessageSender", "Resource Requester", 
or
>>"ResourceProvider" - or something like 
that.
>>
>
>We should define two roles within the RM 
structures.
>
>1 - Resource Consumers - those that request and need 
resources
>
>2 - Resource Distributors - those that have resources, 
or have
>access to them, or manage them for others, and can 
provide/dispatch
>resources (to Resource Consumers)
>
>My 
assumption has been that the ContactInformation is always the
>sender of 
the resource message, and hence in some cases
>it is the RC and others the 
RD - those distinction simply depends on
>the message 
type.
>
>So the question is:  Do we need more roles than these 
two?
>
>For example, do we need a "Resource Owner" who maybe 
different than
>the RD - for example: 
Owning/HomeDispatch/HomeUnit
>If yes, then we need some Ref Model 
changes.
>If no, then we don't need this info - we assume that the RD 
is
>responsible for all aspects of the Resource management.
>(In 
this case, if the HomeDispatch is "Collins Dispatch Center" then
>this 
would only appear in one of the arrival/departure Locations
>elements, as 
this is the important bit of information...)
>
>I think the 
important design-philosophy is that we are not trying to
>replicate an 
entire back-end resource management/logistics system,
>but the 
interoperability between resource 
consumer/distributor.
>
>Cheers...  Renato 
Iannella
>National ICT Australia 
(NICTA)
>
>
>--------------------------------------------------------------------------
>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.

--
Rex Brooks
President, CEO
Starbourne 
Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 
94702
Tel: 510-849-2309

IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
http://www.ieminc.com/e_mail_confidentiality_notice.html