[Fwd: [regrep-cc-review] Core Components Issue: Representation of Aggregate Core Components]

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

Forwarding from the CCTS Team, with my comments (with all due respect to
the poster of the e-mail below):

<Quote1>
There will likely be no Buyer Address ACC but Order. Buyer Address.
Address ASCC 
</Quote1>

I disagree - we will need to have a "BuyerAddress" ACC in the registry,
so that it can be used by multiple ASCCs. It's all about layers here.

<Quote2>
I think there is at least a strong reason to store all CCs and BIEs as
separate entries with unique (U)UIDs for harmonization among industry
standards.
</Quote2>

<Quote3>
I completely concur - for reasons additional to harmonization.
I am not sure though how the registry will store the model
(meaning provide connection among ACC, ASCC, BCC, ABIE, ASBIE, and BIE).
I think that the Dictionary entry name can do the job (if there is no
truncation).
</Quote3>

The Dictionary entry name is not intended to serve this purpose - of
course, we'll use Associations.

Joe

---

• From: "Boonserm \(Serm\) Kulvatunyou" <serm@nist.gov>
• To: "UN/CEFACT Core Component WG" <uncefact-tmg-ccwg@listman.disa.org>
• Date: Wed, 6 Aug 2003 23:48:14 -0400

I also agree with Fred. There will likely be no Buyer Address ACC but Order.
Buyer Address. Address ASCC - Buyer Address being a property term. So as our
old friend examples Penguine. Summer Address. Address and Penguine. Winter
Address. Address ASCCs :).

I think there is at least a strong reason to store all CCs and BIEs as
separate entries with unique (U)UIDs for harmonization among industry
standards. I am not sure though how the registry will store the model
(meaning provide connection among ACC, ASCC, BCC, ABIE, ASBIE, and BIE). I
think that the Dictionary entry name can do the job (if there is no
truncation).

My other two cents,
Serm

----- Original Message -----
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: "UN/CEFACT Core Component WG" <uncefact-tmg-ccwg@listman.disa.org>
Cc: <chiusano_joseph@bah.com>; <kramer@ean-int.org>; <MCRAWFORD@lmi.org>
Sent: Tuesday, August 05, 2003 2:42 PM
Subject: RE: [regrep-cc-review] Core Components Issue: Representation of
Aggregate Core Components


Joe, Mark, Regenald,

My personal opinion on this subject:

1. The CCTS does not support derivations of one ACC from another, like the
derivation of a real ACC from an abstract ACC. The Address example is not
that fortunate as such "derivation" can and probably will be solved by means
of ASCC's. Another example is a "Buyer Party" that may be derived from a
more generic "Party". Though it is tempting to define a "Buyer Party" as a
special case of "Party", this can only be done "off-line", in the discovery
and harmonisation process. The registry should not take such derivation into
account. Suppose later one adds some property to the "Buyer Party" and not
to the "Party", or deletes a property. That would be allowed according to
CCTS and consequently should be supported by the registry.

2. The UBL document Mark distributed states that the registry would not
store "properties", but would store BCC's apart from ACC's and data types. A
BCC is merely an association between an ACC and a data type, and has some
attributes like Property Name and Cardinality. One BCC can never be the
property of more than one ACC. Much like an ASCC, which is the association
between two ACC's, again with attributes like Property Name and Cardinality.
So BCC's and ASCC's are completely symmetrical. The registry should consider
both as properties of an ACC (with their own (U)uid's of course).

My two Eurocents.

Fred


-----Original Message-----
From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
Sent: Tue 8/5/2003 4:45 PM
To: UN/CEFACT Core Component WG
Cc: chiusano_joseph@bah.com
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
> >



-------------
Dit e-mailbericht en enige bijlage is vertrouwelijk en
uitsluitend bestemd voor de geadresseerde(n). Indien u niet
de geadresseerde bent, mag u deze e-mail of enige bijlage niet
kopieren of aan derden ter inzage geven of verspreiden.
Indien u deze e-mail per vergissing heeft ontvangen
verzoeken wij u de afzender ervan onmiddellijk op de hoogte te
stellen per e-mail en de betreffende e-mail te vernietigen.

This e-mail and any attachment is confidential and may
contain legally privileged information. If you are not the
intended recipient, please note that this e-mail or any
attachment may not be copied or disclosed or distributed to
others. If you have received this e-mail by error, please notify
the sender immediately by return e-mail, and delete this message.
--------------




----------------------------------------------------------------------------
----


> ---
> 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.
>

---

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