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

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

Please see comments below marked with <JMC> (sorry about the format, I'm
working on a better approach).

"CRAWFORD, Mark" wrote:
> 
> Joe wrote -
> > Please bear in mind that the CCTS spec was written without the
> > participation/representation of anyone from the Registry TC,
> > and that we
> > have the freedom to deviate from the CCTS spec if we feel it would be
> > necessary to do so in our registry architecture. I also
> > anticipate that
> > there will be cases where we will do so - and we will clearly document
> > in both our Technical Note and our feedback to the CCTS Team
> > where such
> > deviations occur.
> 
> Concur.  However I hope that deviations are to support registry functionality/capabilities, rather than alter the relationship of the various entities defined in CCTS.
> 
> Fred wrote
>  <Quote1>
> > The CCTS does not support derivations of one ACC from
> > another, like the
> > derivation of a real ACC from an abstract ACC
> > </Quote1>
> 
> and Joe Responded -
> > This is an example of something that we may feel is necessary in our
> > registry architecture - for example, our "Address. Details"
> > scenario in
> > which "Address. Details" may be considered an "abstract"
> > (base) ACC, and
> > "ResidenceAddress. Details" may be considered a "real" (derived) ACC
> > that can be re-used in multiple ACCs as needed.
> 
> I don't  agree with Fred, but would be careful with the concept of derivation.  In your example you indicate there would be a ResidenceAddress.Details.  I am not sure that would be the case.  More likely there would be a Person. Residence. Address ASCC.  Per rule [c24], Person. Residence. Address ASCC would have the properties of the Address. Details ACC.

<JMC>
I forsee the need to store in the registry an entity (an ABIE) called
"ResidenceAddress. Details" that can be used in multiple scenarios -
such as the "Person. Residence. Address" ASCC. Isn't it possible that
there are other ASCCs called "X. Residence. Address" where X may be
multiple values? (none come to mind right now - perhaps there aren't
any?)
</JMC>

> Fred Wrote -
> > <Quote3>
> > 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.
> > </Quote3>
> Joe responded -
> > From the registry perspective: BuyerParty ("BuyerParty.
> > Details") is an
> > ABIE that is derived from an ACC called "Party. Details". This
> > "derivation" is done by classifying the "Party. Details" ACC according
> > to one of the 8 Context Categories (in this case, Business
> > Process Role)
> > and adding the proper Object Class Qualifier ("Buyer") to the ABIE.
> >
> > Regardless of at what stage this operation is done (discovery and
> > harmonization, some other process stage, etc.), we will need to have
> > this capability in the registry.
> 
> Absolutely concur.
> 
> Fred Wrote -
> > <Quote4>
> > The registry should not take such derivation into account.
> > </Quote4>
> And Joe responded -
> > This is a case where we will deviate - the registry must have this
> > capability.
> 
> Concur.  The registry must absolutely indicate where an ABIE is a derivation of an ACC.  This is one of our basic concepts and is covered by the various storage rules in Section 7.3 and 7.4
> 
> Fred Wrote -
> > <Quote5>
> > 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.
> > </Quote5>
> 
> And Joe responded -
> > I agree with this completely - and I think it may contradict some
> > earlier comments. In any event, we will accomodate this by
> > the fact that
> > changes to the "Party" entity will automatically be reflected in the
> > "BuyerParty" entity.
> 
> Concure that Fred is contradictory and Quote 5 is more reflective.  However, I am somewhat concerned by the "will automatically be reflected in the "BuyerParty" entity statement. Since an ABIE of BuyerParty will be versioned, then how would one automatically create a new version? (from a business process and standards management perspective - not a technical perspective)

<JMC>
I see - if we have a "Party. Details" ACC, and we create a "BuyerParty.
Details" ABIE from it, that "BuyerParty. Details" ABIE should have its
own UUID in the registry (i.e. it should be its own separate entity,
separate from "Party. Details"). So if there are any updates to "Party.
Details", I think it should be up to an implementation whether or not
they propagate to "BuyerParty. Details", and we should simply specify
this in our Technical Note. This will allow "BuyerParty. Details" to be
versioned separately from "Party. Details".

Sounds good to me.
</JMC>
 
> Fred wrote -
> > <Quote6>
> > One BCC can never be the property of more than one ACC
> > </Quote6>
> 
> And Joe responded -
> > This is another case where we will need to deviate - what
> > good is a BCC
> > if it can be used once and only once?
> 
> Concur with Joe.  There is not agreement within CCTS on Fred's position.
> 
> Fred wrote -
> > <Quote7>
> > 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).
> > </Quote7>
> 
> Joe replied -
> > Focusing on the (U)uid's comment: Would it be advantageous for an ASCC
> > to have its own UUID in the registry? If we represent ASCCs with
> > Associations, is this possible?
> 
> My understanding is that each type of CC and BIE (such as BCC, ACC, ASCC, & CCT) MUST have its own UUID.

<JMC>
I absolutely agree. I think if we do anything other than this, we may be
headed for trouble in implementations.
</JMC>
 
> Mark C.
> 
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
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