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

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

Forwarded on behalf of Diego, with comments below marked with <JMC>.
Taking a step back and re-examining the notion of ASCCs, and considering
introducing a new type of entity (QACC) not represented in the CCTS.

Diego Ballvé wrote:
> 
> Important! Friday's deadline is here and we have to decide this:
> 
> > > 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>
> 
> I can't give you strong arguments why ASCC should be represented as
> Association. IMHO it's just the natural way to see it considering
> its (ASCC's) function in the specs. 
> What about other team members??

<JMC>
I completely agree - that is how it struck me as well. Maybe we should
take a step back here, and rethink this from scratch using the CCTS p.12
example. Let's say we already have an ACC in the registry called
"Address. Details". Let's then say we want to create another entity
(whose type is yet to be named for this example) from that ACC, and this
entity represents "ResidenceAddress. Details" (i.e. we have given it an
Object Class Qualifier of "Residence"). 

BUT: We do not yet have any notion of "joining" this entity with an ACC
(such as Person. Details) - we want it to exist in the registry as
"ResidenceAddress. Details", so that we can join it (include it in) in
the future to whatever ACCs we choose.

My question is: What type of an entity is "ResidenceAddress. Details" at
the point at which it is created, and before it is included in any ACC? 

- It can't be an ASCC, because it has not (yet) performed the function
that an ACC performs.

- It can't be an ABIE, because it does not have context per the 8
Context Categories (i.e. it is not "US_ResidenceAddress. Details) -
although it does have the context of "Residence".

- Can it be another ACC? (more below)

- Can it have a different Cardinality than that specified in the
"Address. Details" ACC? Absolutely - a "Residence Address" may have
multiple occurrences within another entity, while an "Address" may have
only a single occurrence.

BUT WAIT: Why would we want to specify Cardinality on "Address", when it
is really meant to be an "abstract class" from which various types of
Addresses are derived (and so it would never appear in an XML instance)?

Perhaps we should not specify Cardinality on an ACC? (would apply to a
BCC as well)

But what is "ResidenceAddress. Details" if it is not an ABIE or an ASCC? 
Is it an ACC?

Or do we need an entirely new entity that is not specified in the CCTS -
perhaps "QACC" (Qualified Aggregate Core Component -  pronounced
"Quack")?

Back to ASCC's: In light of this, I can see an ASCC being represented as
an Association. Also, perhaps the Cardinality should be specified as a
Slot on the Association that represents an ASCC.

Thoughts?
</JMC>

> Otherwise, we're specifying ASCC as ExtrinsicObject
> 
> > > 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>
> 
> Ok, that thought was flying to high and compromises clarity. Drop it.
> We keep it simple and clear. BCC as ExtrinsicObject.
> 
> Diego
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