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

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

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.

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)


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.


Mark C.