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

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

Forwarded on behalf of Diego.

---

• From: Diego Ballvé <diego.ballve@republica.fi>
• To: "Chiusano Joseph" <chiusano_joseph@bah.com>
• Date: Wed, 23 Jul 2003 15:16:52 +0300

Joe,

Please follow the comments to your comments.

Diego

<JMC>
Please forgive my terminology. When I refer to a CC in this sense, I am
really referring to a Basic Core Component (the concrete
representation), not a Core Component (the abstract representation). I'm
used to doing this - and will probably do it quite often in the future -
so I hope it's ok to ask that you please keep this in mind.
</JMC>

Ok, I'll keep that in mind.
Just that when you say "ASCC extends CC" it can't be read as
"ASCC extends BCC" because that is not the case. Anyway, lets
move on.

> > 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?

<JMC>
That's an excellent point - ASCC's may (and probably will) have
different Busiess Terms than the ACC's that they are derived from. So
"Business Term" is one CC attribute that we would want to "carry over"
to ASCC (using a Slot), so that an ASCC-specific value can be
represented. Are there other such attributes? How about Usage Rule
(p.76):

"Usage Rule (optional, repetitive): A constraint that describes specific
conditions that are applicable to the Core Component."
</JMC>

Exactly. IMO, all the fields listed below, in the first list.
If you disaggre, please use example from page 12 to illustrate
your point.

> >
> > 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.

<JMC>
Yes - I have some curiosities regarding Figure 7-1, and will get to this
figure in the near future in our discussions. Our representation of Core
Components in the registry may not be 100% in line with this figure.
Please stay tuned for more detais in the future.
</JMC>

Good. Let's try to make it as clear as possible. I'll wait.

> >
> > 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. 

<JMC>
I don't believe it was the intent of the CCTS to get to this level of
detail - not to say that your observation is incorrect, of course.
</JMC>

I wonder if we're speaking about the same thing here. I believe
they (CCTS team) do want specify details about each field. I've
based my observation on the extension mechanism they've used,
presented for instance on Figure 7-1. What is incorrect on the
statement above?

In fact, some of them must be different
> > (DictionaryEntryName and Definition).

<JMC>
Agreed - so perhaps it may make more sense to represent ASCC as a
RegistryObject. What are your thoughts, given this new way (at least for
me) of looking at this issue? I know this may change your vote for
"Approach A" below.
</JMC>

The good thing is that Associations are RegistryObjects and thus
have Name and Description, and Slots (just like ExtrinsicObject).
What Associations don't have is objectType - but we can sacrifice
that. I'm still up for ASCC as RIM Association (actually Appoach A).

> >
> > > [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.
> >
> > 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.
> 
>   ------------------------------------------------------------------------
> 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