[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Association Core Components - Represent withAssociations
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: >> >>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: I think that B.4 could be modeled as a Slot on Extrinsic Object - ACC "Person. Details" and that B.5 could be modeled as a Slot on Extrinsic Object - BCC "Person. Name. Text" thus making it only 3 objects instead of 5. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]