Re: [regrep-cc-review] Association Core Components - Represent withAssociations

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

Please see comments below marked with <JMC> (excellent thoughts
Farrukh!). 

Farrukh Najmi wrote:
> 
> Chiusano Joseph wrote:
> 
> >Sent on behalf of Diego.
> >
> >Diego Ballvé wrote:
> >
> >
> >>Joe and Farrukh,
> >>
> >>Comments inline, plus analysis/suggestion on ASBIE/BBIE.
> >>Comment that, please.
> >>
> >>Regards,
> >>Diego
> >>
> >>Chiusano Joseph wrote:
> >>
> >>
> >>><Quote1>
> >>>An instance of type ASCC can be seen as a CC since extends CC (it has
> >>>all CC fields).
> >>></Quote1>
> >>>AND
> >>><Quote2>
> >>>Sorry, but I still cant see the replication.
> >>></Quote2>
> >>>
> >>>Since ASCC extends CC (it has all the CC fields plus more): If an ASCC
> >>>were represented as a RegistryObject (rather than an Association with
> >>>Slots), wouldn't values for the fields that it has in common
> >>>with CC be
> >>>duplicated as well?
> >>>
> >>>
> >>Detail: CC is abstact. ASCC, ACC and BCC are concrete.
> >>ASCC extends CC, so it must have all the fields defined for CC.
> >>The same way, ACC extends CC, so it must have all the fields
> >>defined for CC. Now, ASCC references ACC. ASCC does not reference
> >>ACC in the sense of inheriting fields.
> >>
> >>Illustration:
> >>ACC "Address. Details" might have business term "Address",
> >>
> >>while ASCC "Person. Residence_ Address" might have business terms
> >>"Residence, Residence Address, Home Address",
> >>
> >>and ASCC "Person. Official_ Address" might have business terms
> >>"Official Address, Work Address, OfficeAddress".
> >>
> >>
> >>
> >>>If not, what values would the ASCC fields hold?
> >>>
> >>>
> >>According to Figure 7.1, the fields below (which have different values
> >>than the fields in the referenced ACC)
> >>    * from RegistryClass *
> >>  - Unique Identifier
> >>  - Version
> >>  - Dictionary Entry Name
> >>  - Definition
> >>  - Usage Rule
> >>    * from CoreComponent *
> >>  - Business Term
> >>    * from our merge with BIEProperty *
> >>  - Property Term
> >>  - Cardinality
> >>  - Reference to ACC
> >>
> >>Similarly BBC fields should be the same except for "Reference to ACC",
> >>which is replaced by "Reference to DataType".
> >>
> >>Finally, ACC fields are
> >>    * from RegistryClass *
> >>  - Unique Identifier
> >>  - Version
> >>  - Dictionary Entry Name
> >>  - Definition
> >>  - Usage Rule
> >>    * from CoreComponent *
> >>  - Business Term
> >>    * from AggregateCoreComponent *
> >>  - ObjectClassTerm
> >>  - References to aggregated ASCCs/BCCs.
> >>
> >>Most of the fields have the same name in ACC/ASCC/BCC and also
> >>the same type of information, but there's nothing saying the
> >>values are the same. In fact, some of them must be different
> >>(DictionaryEntryName and Definition).
> >>
> >>
> >>
> >>>[Keeping in mind that the fundamental question is still:
> >>>Should an ASCC
> >>>be represented as an Association that "connects" two ACCs in the
> >>>registry, with additional Slots to represent things such as
> >>>Cardinality
> >>>and Object Class Qualifier]
> >>>
> >>>
> >>Before answering this fundamental question, some comparison
> >>using data from example - page 12 CCTS. Slots not mentioned
> >>should correspond to the field lists above, with exceptions.
> >>
> >>A) ASCC as RIM Association that "connects" two ACCs:
> >>
> >>1. Extrinsic Object - ACC "Person. Details"
> >>2. Extrinsic Object - ACC "Address. Details"
> >>3. Association - ASCC "Person. Residence_ Address"
> >>   .sourceObject = Extrinsic Object - ACC "Person. Details"
> >>   .targetObject = Extrinsic Object - ACC "Address. Details"
> >>
> >>B) ASCC as RIM ExtrinsicObject "connected" to two ACCs:
> >>
> >>1. Extrinsic Object - ACC "Person. Details"
> >>2. Extrinsic Object - ASCC "Person. Residence_ Address"
> >>3. Extrinsic Object - ACC "Address. Details"
> >>4. Association - "ACC contains ASCC"
> >>   .sourceObject = Extrinsic Object - ACC "Person. Details"
> >>   .targetObject = Extrinsic Object - ASCC "Person. Residence_ Address"
> >>5. Association - "ASCC references ACC"
> >>   .sourceObject = Extrinsic Object - ASCC "Person. Residence_ Address"
> >>   .targetObject = Extrinsic Object - ACC Address. Details"
> >>
> >>Approach B has 2 extra objects (3 vs 5).
> >>Approach B (might) requires 2 steps to get from Aggregate to Aggregated.
> >>
> >>My opinion: make it more complex but optimized. Well documented,
> >>of course. Approach A.
> >>
> First my thanks to Diego for re-bootstrapping me on current state of CCRIM.
> 
> I feel very comfortable with above suggestion to go with:
> 
> A) ASCC as RIM Association that "connects" two ACCs:

<JMC>
I was also very comfortable with this, until recently where I realized
the need to potentially represent ASCCs as RegistryObjects. One quick
example is the "Version" attribute of Core Components - i.e. one may
want to version an ASCC as its own entity. There are several other
attributes of Core Components that follow in this vein, which I listed
in a (this past) Friday e-mail.

In my mind, this one is still open.
</JMC>

> >>
> >>The interesting fact that comes from this analysis is that
> >>BCC has a similar behaviour, as I wrote in the other mail..
> >>that day I was just brain-storming, but today I'm serious
> >>about it. BCC as Association has advantages!! See this:
> >>
> >>A) BCC as RIM Association that "connects" ACC to DataType:
> >>
> >>1. Extrinsic Object - ACC "Person. Details"
> >>2. Extrinsic Object - DataType "Text DataType"
> >>3. Association - BCC "Person. Name. Text"
> >>   .sourceObject = Extrinsic Object - ACC "Person. Details"
> >>   .targetObject = Extrinsic Object - DataType "Text DataType"
> >>
> >>B) ASCC as RIM ExtrinsicObject "connected" to ACC and to DataType:
> >>
> >>1. Extrinsic Object - ACC "Person. Details"
> >>2. Extrinsic Object - BCC "Person. Name. Text"
> >>3. Extrinsic Object - DataType "Text DataType"
> >>4. Association - "ACC contains BCC"
> >>   .sourceObject = Extrinsic Object - ACC "Person. Details"
> >>   .targetObject = Extrinsic Object - BCC "Person. Name. Text"
> >>5. Association - "BCC is of type DataType"
> >>   .sourceObject = Extrinsic Object - BCC "Person. Name. Text"
> >>   .targetObject = Extrinsic Object - DataType "Text DataType"
> >>
> >>C) ASCC as RIM ExtrinsicObject "connected" to ACC referencing DataType with slot:
> >>1. Extrinsic Object - ACC "Person. Details"
> >>2. Extrinsic Object - BCC "Person. Name. Text"
> >>3. Extrinsic Object - DataType "Text DataType"
> >>
> >>Again, Approach B has 2 extra objects (3 vs 5).
> >>Approach B (might) requires 2 steps to get from Aggregate to Aggregated.
> >>C does not make use of Association..
> >>
> >>My opinion: Same as before, make it more complex but optimized.
> >>Approach A.
> >>
> After a lengthy discussion with Diego I am still a litle unsure about:
> 
> A) BCC as RIM Association that "connects" ACC to DataType:

<JMC>
I agree with Farrukh - I believe that BCC should be viewed as an entity,
the most "basic" entity that we deal with in the Core Components
methdology. IMO, if anything should be a RegistryObject, BCC should.
</JMC>
 
> I think that B.4 could be modeled as a Slot on
> 
> Extrinsic Object - ACC "Person. Details"

<JMC>
Great thought - here's an alternate viewpoint: I see an ASBIE
(Association Business Information Entity) modeled as an ASCC
(Association Core Component) which is classified according to one of the
8 Context Categories listed in the CCTS. 
</JMC>
 
> and that B.5 could be modeled as a Slot on
> 
> Extrinsic Object - BCC "Person. Name. Text"

<JMC>
Great thought - Keeping in mind that an ABIE is an ACC viewed in light
of one of the 8 Context Categories listed in the CCTS, couldn't we
simply represent an ABIE using our Classification mechanism?
</JMC>
 
> thus making it only 3 objects instead of 5.

<JMC>
A general comment, having nothing to do with Farrukh's comment above: I
don't believe we should place as much emphasis on "conserving objects"
as we have been, because I think we are sacrificing clarity of
representation for implementation-specific reasons. Perhaps we can
consider "swinging the pendulum" a bit back into the "clarity of
representation" realm.

[End of Joe's comments]
</JMC>
 
> So I ask should we consider a modified B where B.4 and B.5 are replaced with Slots on the sourceObject proposed in Diego's mapping?
> 
> However, take anything I say with a grain of salt as I am quite behind
> in CCRIM mapping work. I will defer to whatever Diego and Joe find is
> the right approach. Thanks.
> 
> --
> Farrukh
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