[Fwd: FW: [regrep-cc-review] Core Components Issue: Representation ofAggregate Core Components]

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Team,

This is the e-mail I referred to at the end of the previously forwarded
e-mail:

<Quote>
In the next e-mail that I will forward, I asked Alan and Mark to clarify
whether "ResidenceAddress. Details" is indeed an ABIE - or perhaps some
"intermediate" entity between an ACC and ABIE.
</Quote>

Joe

---

• From: Joseph Chiusano <Chiusano_Joseph@bah.com>
• To: Alan.Stitzer@marsh.com
• Date: Tue, 05 Aug 2003 11:11:00 -0400

Thanks Alan and Mark - that brings up an additional question (if I may
please):

Would "ResidenceAddress. Details" be an ABIE, or an ACC? In the example
on p.12 of CCTS spec it is unclear. If it is an ABIE, which of the 8
context categories would it be associated with?

The reason I ask is that I know that "US_ResidenceAddress. Details" is
an ABIE, as per p.16 of CCTS spec - it is clearly associated with the
Geopolitical context. But since "US_ResidenceAddress. Details" is an
ABIE, can "ResidenceAddress. Details" also be an ABIE? Or is it some
"intermediary" entity (perhaps a "Qualified Aggregate Core Component" -
QACC)?

Joe

Alan.Stitzer@marsh.com wrote:
> 
> It has been my impression that the base ACC, in this case Address. Details
> would remain as an ACC that contains numerous properties relating to an
> address, including things that you may not need for Residence Address.
> 
> Residence Address (or something like that) -- I don't want to worry about
> the names right now, would have to be ABIE's which would restrict the ACC
> Address. Details to the BCC's that you would like to see in Residence
> Address.  Since the ABIE is registered separately, it would, indeed have a
> unique identifer separate from the Address. Details ACC.
> 
> Since that is just my impression, I am hoping that someone else from the CC
> team will respond and correct my impression if it is wrong...
> 
> Regards,
> 
> ____________________
> Alan Stitzer
> AVP
> Marsh USA Inc.
> 1133 Avenue of the Americas
> New York, NY 10036-2774
> Phone: (561) 743-1938
> Fax: (561) 743-1993
> Internet: Alan.Stitzer@marsh.com
> ____________________
> 
> <<< Memo from MCRAWFORD@lmi.org@Internet on 05 August, 2003, 10:48 Tuesday
> >>>
> 
> MCRAWFORD@lmi.org@Internet on 5 Aug 2003, 10:48 Tuesday
> 
> Please respond to uncefact-tmg-ccwg@listman.disa.org@Internet
> 
> To:    uncefact-tmg-ccwg
> cc:    chiusano joseph  (bcc: Alan Stitzer)
> Subject:    FW: [regrep-cc-review] Core Components Issue: Representation of
>        Aggregate Core Components
> 
> CCTS Team,
> 
> See the discussion below.  We owe an answer to the OASIS Registry CC
> Subteam on this.
> 
> Mark
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Tuesday, August 05, 2003 10:37 AM
> To: CRAWFORD, Mark
> Cc: CCRev
> Subject: Re: [regrep-cc-review] Core Components Issue: Representation of
> Aggregate Core Components
> 
> Thanks Mark - Can you please forward to the UN/CEFACT Team?
> 
> Joe
> 
> "CRAWFORD, Mark" wrote:
> >
> > Joe,
> >
> > This seems a better question for the team responsible for the
> specification.
> >
> > Mark
> >
> > > -----Original Message-----
> > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > > Sent: Tuesday, August 05, 2003 10:05 AM
> > > To: CAM
> > > Cc: CCRev
> > > Subject: [regrep-cc-review] Core Components Issue: Representation of
> > > Aggregate Core Components
> > >
> > >
> > > CAM TC,
> > >
> > > For those who don't know me, I chair the "Core Components Review"
> > > subcommittee in the OASIS/Registry TC. We are in the midst of
> > > implementing the UN/CEFACT Core Components Technical Specification
> > > (CCTS) requirements in our registry architecture.
> > >
> > > We have a current issue that affects assembly of schemas from
> > > components
> > > that I would like to (on behalf of the subcommittee) run by you if I
> > > may. The bottom line issue is: If we derive an Aggregate Core
> > > Component
> > > (ACC) from another ("base") Aggregate Core Component, should
> > > the "base"
> > > and "derived" ACC each be a separate entity in the registry, with its
> > > own unique ID? Or should they be one entity with additional attributes
> > > added to it? If this isn't clear, the example below will clarify.
> > >
> > > Suppose we have an ACC called "Address. Details" - it
> > > contains the usual
> > > address information (street, city, etc.) We want to create
> > > several other
> > > "related" (derived) ACCs from this "base" ACC, and name them more
> > > specifically (i.e. with more semantic detail) - for example,
> > > "ResidenceAddress. Details", "OfficeAddress. Details", etc.
> > >
> > > Each of these "derived" ACCs would have the same properties
> > > and content
> > > as the "base" ACC - the only exception is their name.
> > >
> > > So the question is: If one wanted to assemble schemas using these
> > > derived ACCs, would it be more advantageous if they were
> > > represented as
> > > separate entities in the registry (i.e. separate from the "Address.
> > > Details" ACC) - thus with their own UUIDs? Or, would it be
> > > best to have
> > > a single "Address. Details" entity with each of its various "derived"
> > > names included as properties (these would be Slots according to the
> > > registry architecture).
> > >
> > > My viewpoint says it's best to represent them separately, so one could
> > > list the UUIDs for these entities in an "assembly template"
> > > (if that is
> > > the right term), and automatically "pick up" the right entity
> > > during the
> > > assembly process. The second approach would require some mechanism by
> > > which the proper Slot (name) could be identified in such a template.
> > >
> > > Please note also that with the first approach (separate entities), the
> > > "derived" ACCs would be associated with their "base" ACC
> > > through the use
> > > of registry associations.
> > >
> > > We appreciate your feedback very much. We want to ensure that our work
> > > takes into account all potential usage of the Registry down the road.
> > >
> > > Kind Regards,
> > > Joe Chiusano
> > >
> 
> ---
> You are currently subscribed to the uncefact-tmg-ccwg listserve.
> To unsubscribe send an email to lyris@listman.disa.org with the
> following subject: Unsubscribe uncefact-tmg-ccwg
> If you do not receive confirmation of your unsubscribe request
> please notify postmaster@disa.org to report the problem.
> 
> To:    uncefact-tmg-ccwg@listman.disa.org@Internet
> cc:    chiusano_joseph@bah.com@Internet (bcc: CN=Alan
>        Stitzer/OU=NYC-NY/OU=US/OU=Marsh/O=MMC)
> From:  MCRAWFORD@lmi.org@Internet

begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard

---

begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard