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

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

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