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

[Diego Ballvé <diego.ballve@republica.fi>]

> 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