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

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

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