[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Association Core Components - Represent with Associations
Thanks Mark. I'd be genuinely interested to learn more about why you feel it would be confusing, and to who - Implementers? Users? Readers of a Technical Note describing technique #2? Joe "CRAWFORD, Mark" wrote: > > Joe, > > It might get rather confusing to try approach 2. Better to keep separate mechanisms - especially in light of the corresponding ASBIEs. > > Mark > > -----Original Message----- > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > Sent: Fri 7/11/2003 7:38 AM > To: CCRev > Cc: > Subject: [regrep-cc-review] Association Core Components - Represent with Associations > > > > 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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]