[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
<Quote> I believe there are 2 aspects to this transition: (1) Classification of an ACC according to one of the 8 Context Categories (in this case, it was "Geopolitical" Context) (2) Adoption/modification of name of ACC to become name of ABIE - i.e. "Person. Details" --> "US_Person. Details" </Quote> I'm going to write here in terms of tbe "basic" entities - i.e. a transition from a BCC to a BBIE. Suppose we are dealing with a BCC called "PostalCode", and want to create a BBIE called "US_PostalCode". DATA ELEMENT TERMS: ------------------ Regarding the Data Element Terms, we have: Object Class: None - We introduce ObjectClass at the aggregate level, not the basic level; Property Term: Postal - Would be stored as an attribute of the BCC; Representation Term: Code - Would be stored as an attribute of the CCT; When BBIE (US_PostalCode) is created from a BCC (PostalCode), the difference in name is from the addition of a "Property Term Qualifier" (in this case US_) to the front of the Property Term. According to the CCTS, this Property Term Qualifier is an attribute of the Data Type. [NOTE: I am starting to think that the Property Term Qualifier belongs as an attribute of a *BBIE*, not a Data Type - more below] CLASSIFICATION: -------------- Additionally, the PostalCode BCC is classified according to one of the 8 Context Categories in the CCTS - in this case, Geopolitical Context. TRANSITION: ---------- SO: how do we get from "PostalCode" to "US_PostalCode"? I propose the following: (1) We store the "Property Term Qualifier" in a Slot that is attached to the pertinent node of the "Geopolitical Context" classification scheme - So in this case, we would store the value "US_" in the "Property Term Qualifier" Slot that is attached to the "United States" node of the "Geopolitical Context" classification scheme (2) When a user creates a BBIE from an existing BCC, they simply classify the BCC and the registry automatically does the following: (a) Creates the BBIE (b) Copies the Property Term Qualifier from the classification node to the "Property Term Qualifier" attribute of the BBIE (not the Data Type) How does this sound? PLACEMENT OF PROPERTY TERM QUALIFIER: ------------------------------------ The reason I'm thinking of BBIE rather than Data Type for the "Property Term Qualifier" attribute is that since we've just created a new entity (BBIE), why not "associate" this new value with the entity that was just created? How does this sound? Also: The placement of the Property Term Qualifier in a "central" location (the classification node) will enable all BBIEs created by classifying according to that node to have the same Property Term Qualifier (i.e. not "US" on some and "US_" on others). Thanks, Joe Chiusano Joseph wrote: > > Boy, did I mix up my acronyms on that last one! Here's a better version > - sorry for the inconvenience! :P > > Team, > > The topic of this e-mail is "How To Create an ABIE from a ACC". > Consider CCTS p.12, where we have an ACC (top left) called "Person. > Details" (I'm ignoring the other ACC at bottom right, for simplicity). > > On p.16, this ACC has become "US_Person. Details". > > So the question is: how could this happen in the registry? > > (Please note: The actions described below would be performed by tools > that utilize the registry, but it is important for us to understand > these potential transitions) > > I believe there are 2 aspects to this transition: > > (1) Classification of an ACC according to one of the 8 Context > Categories (in this case, it was "Geopolitical" Context) > > (2) Adoption/modification of name of ACC to become name of ABIE - i.e. > "Person. Details" --> "US_Person. Details" > > My thoughts are: > > - An ACC should remain as is, rather than being "transformed" into an > ABIE. This will allow the ACC to participate in other "scenarios" (i.e. > be joined to other ACCs through ASCCs) as well. In other words, we > should not take an ACC and classify it to create an ABIE. > > - Rather: One should *copy an ACC* to produce an ABIE, and then classify > the new object (ABIE) according to one of the 8 Context Categories. > > - Regarding (2) above - here's an open question whose answer I am not > certain of: Is the name "US_Person. Details" really the name "Person. > Details" with > > (a) An Object Class Qualifier (US_) in front of it? > OR > (b) An entirely new Object Class (US_Person insteand of Person)? > > Another aspect is at the BCC/BBIE level. On p.12, the "Person. Details" > ACC contains the following BCCs: > > - Person. Name. Text > - Person. Birth. Date > > For the p.16 example, these are represented as BBIEs: > > - US_Person. Name. Text > - US_Person. Birth Date > > Should the [BCC -> BBIE] transition be handled the same way as I propose > the [ACC -> ABIE] transition be handled? That is, in going from a BCC to > a BBIE, should all BCCs that the ACC comprises be "copied, classified, > and name-modified" as well? > > Joe > > Chiusano Joseph wrote: > > > > Team, > > > > The topic of this e-mail is "How To Create an BBIE from a BCC?". > > Consider CCTS p.12, where we have an ACC (top left) called "Person. > > Details" (I'm ignoring the other ACC at bottom right, for simplicity). > > > > On p.16, this ACC has become "US_Person. Details". > > > > So the question is: how could this happen in the registry? > > > > (Please note: The actions described below would be performed by tools > > that utilize the registry, but it is important for us to understand > > these potential transitions) > > > > I believe there are 2 aspects to this transition: > > > > (1) Classification of an ACC according to one of the 8 Context > > Categories (in this case, it was "Geopolitical" Context) > > > > (2) Adoption/modification of name of ACC to become name of ABIE - i.e. > > "Person. Details" --> "US_Person. Details" > > > > My thoughts are: > > > > - An ACC should remain as is, rather than being "transformed" into an > > ABIE. This will allow the ACC to participate in other "scenarios" (i.e. > > be joined to other ACCs through ASCCs) as well. In other words, we > > should not take an ACC and classify it to create an ABIE. > > > > - Rather: One should *copy an ACC* to produce an ABIE, and then classify > > the new object (ABIE) according to one of the 8 Context Categories. > > > > - Regarding (2) above - here's an open question whose answer I am not > > certain of: Is the name "US_Person. Details" really the name "Person. > > Details" with > > > > (a) An Object Class Qualifier (US_) in front of it? > > OR > > (b) An entirely new Object Class (US_Person insteand of Person)? > > > > Another aspect is at the BCCs/ABIE level. On p.12, the "Person. Details" > > ACC contains the following BCCs: > > > > - Person. Name. Text > > - Person. Birth. Date > > > > For the p.16 example, these are represented as: > > > > - US_Person. Name. Text > > - US_Person. Birth Date > > > > Should the BCC -> ABIE transition be handled the same way as I propose > > the ACC -> ABIE transition be handled? That is, in going from an ACC to > > an ABIE, should all BCCs that the ACC comprises be "copied, classified, > > and name-modified" as well? > > > > 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 --------------7121DA44CA42AC94BF701F3B Content-Type: text/x-vcard; charset=us-ascii; name="Chiusano_Joseph.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Joseph Chiusano Content-Disposition: attachment; filename="Chiusano_Joseph.vcf" 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 --------------7121DA44CA42AC94BF701F3B--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]