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

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

Thanks for your feedback and clarifications, Mark. Just one comment for
now - I'll respond to the rest either later today or tomorrow:

<Quote>
Concur.  However I hope that deviations are to support registry
functionality/capabilities, rather than alter the relationship of the
various entities defined in CCTS.
</Quote>

Absolutely. So far, the only deviation that we are looking at regarding
the relationship of the various entities defined in CCTS is the CCTS
definition of "Core Component Property". Up to now, we have not been
able to grasp the advantage of defining a Core Component Property entity
(and its related Property entities) in the registry - rather, we've been
considering taking the attributes of the Core Component Property entity
(Property Term, Cardinality) and moving them to other entities. For
example, Property Term seems very appropriate for a BCC (ex:
TelephoneNumber, where the Property Term "Telephone" is stored with the
BCC and the Representation Term "Number" is stored with the CCT). For
Cardinality, we're currently considering whether this should be placed
on a BCC, or on the Association the "joins" a BCC to an ACC (thereby
allowing a different minimum/maximum number of occurrences in each
BCC->ACC relation).

Any feedback you can provide on our current thinking would be very
valuable to us.

Thanks,
Joe
"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.
> 
> 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.
> 
> 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