[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]