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

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

<Quote1>
We agreed on not to add Slots to RIM Association for clarity and I think
it makes sense. 
</Quote1>

Ah - I'm reconsidering here, in this context. :) I believe that this
approach was not good for Properties, but is good for ASCCs.

<Quote2>
ASCC would contain (as Slots):

- Object Class Qualifier 
- Property Term
- Cardinality
</Quote2>

Exactly.

Joe

Diego Ballvé wrote:
> 
> > That all makes sense Diego. Whether you realized it or not, you are
> > actually agreeing with my #2 approach which calls for no
> > replication of
> > objects, and an association between ACCs and BCCs that represents an
> > ASCC (i.e. we can represent ASCCs as Associations).
> 
> I am. Just cutting the name generation and transformation part. :)
> 
> > The only item left to clarify is: Do you and other team members agree
> > with our adding a slot to the "ASCC Association" to hold the Object
> > Class Qualifier?
> 
> No, not to the (RIM) Association. Use the ASCC ExtrinsicObject instead.
> (Is it what you mean??) We agreed on not to add Slots to RIM Association
> for clarity and I think it makes sense. And since we also agreed on
> unifying ASCC with AssociationCCProperty, ASCC would contain (as Slots):
> 
> - Object Class Qualifier
> - Property Term
> - Cardinality
> 
> Diego
> 
> > Joe
> >
> > Diego Ballvé wrote:
> > >
> > > Joe,
> > >
> > > I don't see the point for (1), though as Mark pointed out 2
> > > is rather complex. My question is, do we have to choose one
> > > of this approaches? IMO, you don't have to replicate BCCs.
> > > You don't have to worry about the "pre-transformation" as you
> > > said. ASCC are there so that you can reuse ACCs (and BCCs,
> > > through ACCs) but they (ASCCs) just reference other ACCs; they
> > > don't force you to replicate the referenced objects, do they?
> > >
> > > What I mean is that I don't think we have to change referenced
> > > ACCs or BCCs when inserting an ASCC. It's simply a reference.
> > > Does it make sense?
> > >
> > > Diego
> > >
> > > > -----Original Message-----
> > > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > > > Sent: Friday, July 11, 2003 2:43 PM
> > > > To: CCRev
> > > > Subject: Re: [regrep-cc-review] Association Core Components -
> > > > Represent
> > > > with Associations
> > > >
> > > >
> > > > Minor modification (sorry for any confusion):
> > > >
> > > > <Was>
> > > > (1) Create a new BCC in the Registry for each
> > "pre-transformation" BCC
> > > > that has the same metadata as the pre-transformation BCC
> > > > (except for its
> > > > name) - and give it a new name (i.e. "Person. Residence.
> > Address").
> > > >
> > > > That is, we would create a BCC called "Person. Residence.
> > > > Address" that
> > > > would essentially be a copy of the "Address. Street.
> > Text" BCC, with a
> > > > different name. Seems very redundant and inefficient, and
> > a waste of
> > > > Registry storage space.
> > > > </Was>
> > > >
> > > > <ShouldBe>
> > > > NOTE: New text is "Person. Residence. Address. Street. Text":
> > > >
> > > > (1) Create a new BCC in the Registry for each
> > "pre-transformation" BCC
> > > > that has the same metadata as the pre-transformation BCC
> > > > (except for its
> > > > name) - and give it a new name (i.e. "Person. Residence. Address.
> > > > Street. Text").
> > > >
> > > > That is, we would create a BCC called "Person. Residence. Address.
> > > > Street. Text" that would essentially be a copy of the
> > > > "Address. Street.
> > > > Text" BCC, with a different name. Seems very redundant and
> > > > inefficient,
> > > > and a waste of Registry storage space.
> > > > </ShouldBe>
> > > >
> > > > Chiusano Joseph wrote:
> > > > >
> > > > > Team,
> > > > >
> > > > > Over the weekend I'll send an updated summary on our
> > > > proposed handling
> > > > > of each of the CCTS requirements.
> > > > >
> > > > > I've been thinking more about Association Core Components -
> > > > particularly
> > > > > the example on CCTS p.12. In that example, we have:
> > > > >
> > > > > - An ACC called "Address. Details", with several BCCs
> > (ex: Address.
> > > > > Street. Text)
> > > > >
> > > > > - An ACC called "Person. Details", with several BCCs (ex:
> > > > Person. Name.
> > > > > Text)
> > > > >
> > > > > - 2 ASCCs, each of which associate the "Address. Details"
> > > > ACC with the
> > > > > "Person. Details" ACC - and each of which provide a
> > > > different "role" for
> > > > > the "Address. Details" ACC within the "Person. Details"
> > > > ACC. These are
> > > > > reprsented as "Residence" and "Official Address" in the example.
> > > > >
> > > > > - Also: When each ASCC is created, each BCC within the "Address.
> > > > > Details" ACC "takes on" the role signified by the ASCC
> > within the
> > > > > "parent" ACC. For example, the BCC of "Address. Street.
> > > > Text" becomes
> > > > > "Person. Residence. Address".
> > > > >
> > > > > Having said that: It seems to me that there are
> > generally 2 ways to
> > > > > handle the "transformation" described in the final point above:
> > > > >
> > > > > (1) Create a new BCC in the Registry for each
> > > > "pre-transformation" BCC
> > > > > that has the same metadata as the pre-transformation BCC
> > > > (except for its
> > > > > name) - and give it a new name (i.e. "Person.
> > Residence. Address").
> > > > >
> > > > > That is, we would create a BCC called "Person. Residence.
> > > > Address" that
> > > > > would essentially be a copy of the "Address. Street. Text"
> > > > BCC, with a
> > > > > different name. Seems very redundant and inefficient,
> > and a waste of
> > > > > Registry storage space.
> > > > >
> > > > > (2) Do not create a new BCC in the Registry, but use
> > the Association
> > > > > mechanism of the Registry to "point to" the
> > > > pre-transformation BCC and
> > > > > indicate the new name within the Association. This prevents
> > > > the need to
> > > > > duplicate BCCs in the Registry and keep them in sync if the
> > > > metadata for
> > > > > either of them changes.
> > > > >
> > > > > I would like to propose that we pursue (2) - and represent
> > > > the ASCC by
> > > > > an Association between the 2 ACCs. We can add a slot to the
> > > > Association
> > > > > to indicate the new Object Class for the ASCC - i.e. the
> > > > Object Class of
> > > > > "Address" for the "Address. Details" ACC would be
> > > > "qualified" by the new
> > > > > Object Class Qualifier of "Residence" for the ASCC (the
> > > > combination of
> > > > > Object Class Qualifier and Object Class would therefore be
> > > > > "ResidenceAddress"). When tools join the two ACCs through
> > > > the ASCC, they
> > > > > can ensure that they "construct" the name for the ASCC using:
> > > > >
> > > > > - The Object Class for the "master" ACC (i.e. "Person")
> > > > > - The Object Class Qualifier for the ASCC (i.e. "Residence")
> > > > > - The Object Class for the "joined" ACC (i.e. "Address")
> > > > >
> > > > > ...to yield "Person. Residence. Address". So a large part
> > > > of this would
> > > > > be up to the tools that ultimately utilize these entities,
> > > > and we can
> > > > > place some requirements in our Technical Note that instruct
> > > > the tools
> > > > > how to access the entities.
> > > > >
> > > > > Thoughts, comments?
> > > > >
> > > > > Joe
> > > > >
> > > > >
> > > > --------------------------------------------------------------
> > > > ----------
> > > > > 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
> >
> > 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