OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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