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
