[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] RM elements - Ross/Jon Skeels
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.
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.
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: