A Slight Adjustment (Was Re: [regrep-cc-review] Bringing It Home: BIEs, ASCCs, and Business Context)

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

I'd like to propose a slight adjustment on my original proposal (shown
below), regarding what we would consider entities such as
"ResidenceAddress. Details" and "OfficialAddress. Details" to be.

In my proposal below, I offered that we consider these entities to be
ABIEs, (and store them in the registry as such). I'd like to propose
that we consider these ACCs rather than ABIEs, for better conformance to
the CCTS spec. That means that ACCs can have Object Class Qualifier
Terms (i.e, "Residence", "Official"), in addition to Object Class Terms
(i.e. "Address").

The adjusted proposal would be as follows:

I propose then that:

(1) We consider "ResidenceAddress. Details" amd "OfficialAddress.
Details" to be ACCs

(2) We represent ASCCs as associations between these ACCs and the ACC
(per the p.12 example) in which they are contained

So #1 means that a registry user can create an ACC from an existing ACC
(i.e. "derive" an ACC from another ACC) by simply providing an Object
Class Qualifier in the ACC ("Residence" or "Official" in this case).

This means that in order to create an ABIE, one MUST classify an ACC
according to one of the 8 context categories - with no exceptions.

The same concepts would apply for the BCCs - consider a BCC of
"OfficeTelephoneNumber" which is derived from another BCC of
"TelephoneNumber". If one then classified these BCCs according to the
Geopolitical context category ("United States" node), they would become
BBIEs of "US_OfficeTelephoneNumber" and "US_TelephoneNumber".

How does that sound?

Joe

Chiusano Joseph wrote:
> 
> Team,
> 
> Thinking about the example on p.12 of the CCTS, and how we see ASCCs
> created through the "Residence" and "Official" links:
> 
> The CCTS spec does not explicitly acknowledge that one can have in a
> registry an entity named "ResidenceAddress. Details" or
> "OfficialAddress. Details" - rather, it descibes the ASCCs that are
> created with these "links" in between. I am not saying that this was an
> omission in the CCTS spec, but I believe that from a registry standpoint
> the reality is that there is a great advantage to being able to
> register/derive and maintain entities named "ResidenceAddress. Details"
> and "OfficialAddress. Details" - so that they may be used in multiple
> ACCs.
> 
> I propose then that:
> 
> (1) We consider "ResidenceAddress. Details" amd "OfficialAddress.
> Details" to be ABIEs, even though they are not (to my knowledge)
> associated with one of the 8 context categories
> 
> (2) We represent ASCCs as associations between these ABIEs and the ACC
> (per the p.12 example) in which they are contained
> 
> So #1 means that a registry user can create an ABIE from an ACC *with
> classifying the ACC according to one the 8 context categories* - that
> is, by simply providing an Object Class Qualifier in the ABIE
> ("Residence" or "Official"), in this case.
> 
> It would be very inefficient (I believe) to require a user to reference
> a classification scheme every time they create an ABIE from an ACC - in
> the p.12 example, they would have to create a classification scheme with
> only 2 nodes ("Residence" or "Official") and then classify the ABIE.
> Much more complicated than it needs to be - the user should simply be
> able to add the Object Class Qualifier.
> 
> The same concepts would apply for the BCC->BBIE transition - consider a
> case of "OfficeTelephoneNumber" (may include an extension) vs.
> "HomeTelephoneNumber" (would not include extension).
> 
> Please provide thoughts on this.
> 
> Thanks,
> 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