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

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

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