[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
IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
http://www.ieminc.com/e_mail_confidentiality_notice.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]