Re: [regrep-cc-review] [ADDITIONAL THOUGHT]Re: [regrep-cc-review] ASCCs/ASBIEs Revisited

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

Please see comments below marked <JMC>.

Diego Ballvé wrote:
> 
> Joe,
> 
> > Regarding CCTS spec p.12, example: Another way to view the "Address.
> > Details" ACC is as an abstract class which cannot be instantiated, but
> > which can be used to derive sub-classes. More specifically, "Address.
> > Details" would never appear in an XML document, but "Person. Residence.
> > Address" (for which "Residence" can be considered a sub-class derived
> > from "Address. Details") would appear.
> 
> Nice way to see it. I agree with all but the fact that an ACC cannot be
> instantiated at all. If you assemble a form, the form itself can be
> viewed as an ACC, composed by ASCCs and BCCs.

<JMC>
Both our perspectives here are superceded by Mark Crawford's
clarification earlier today: "CCs (BCC, ACC, ASCC) will NEVER be used to
create an instance document.  Only BIEs."
</JMC>

> 
> > So we could potentially have many ASCCs in a registry derived from the
> > "Address. Details" ACC.
> 
> Definitely.
> 
> > It appears that the transition from ACC to ABIE occurs when business
> > context is added, and that business context is one of the 8 predefined
> > context categories (Business Process, Product Classification, etc.).
> >
> > It appears that the transition from ACC to ASCC occurs when business
> > context is added, but that business context is NOT one of the 8
> > predefined context categories. The same holds true for the transition
> > from ABIE to ASBIE - except that an ASBIE already incorporates one of
> > the 8 predefined context categories (by virtue of the fact that we are
> > starting with an ABIE).
> 
> Agree on both.
> 
> > I think we can represent ASCCs (created from ACCs) and ASBIEs (created
> > from ABIEs) with registry associations,
> 
> I was voting for this approach but I have some doubts now.
> - First, Association is a RegistryObject but not a RegistryEntry. So you
> loose status and version control capabilities from RIM.

<JMC>
True - but I'm not sure what that is undesirable - i.e. why an
Association should be that "heavyweight". Taking the RegistryEntry
attributes one-by-one, and considering them in light of Associations:

expiration:
	- Is there value in having an expirationDate for an 			Association?
majorVersion:
	- Is there value in having multiple versions of an Association? 		To
me, it seems that either an Association exists, or it 		doesn't.
minorVersion:
	- See "majorVersion"
stability:
	- Relates to content; do Associations really have "content"?
userVersion
	- See "majorVersion"
</JMC>

> - Second, since you don't have an ExtrinsicObject you can't set your own
> objectType attribute (ASCC/ASBIE in this case, although you can set
> associationType).

<JMC>
I think your last point regarding associationType is 100% correct - we
could have an associationType of (for example) "Derives From".
</JMC>

> - Third, in the attached document you've made the following note:
> "*Note that the relationship between the "Person. Details" ACC and the
> "Residence" ASCC can also be represented with a registry association.
> So there are really 2 associations here."
> 
> How are you seeing this 2 Associations??? Like this?
> Person. Details ACC (Contains) Residence ASCC (Extends) Address. Details

<JMC>
Exactly. I should have stated that in the document - will update.
</JMC>

> But since an Association needs a source and a target, Residence ASCC
> must be a RegistryObject. would we have an Association as source/target
> of another??

<JMC>
Exactly. Residence ASCC would be a RegistryObject, with an Association
to the "Address. Details" ACC, and another Association to the "Person.
Details" ACC (I'm not being specific about the Association direction
here - just talking high-level). 

If we feel the registry is becoming "heavy" with all these
RegistryObjects, there is an alternative for the Residence ASCC - for
example, it could be represented with a Slot on the "Address. Details"
ACC RegistryObject. However, this approach hits a brick wall when we
have to "join" the Residence ACC (represented as a Slot on the "Address.
Details" ACC RegistryObject) to the "Person. Details" ACC. With multiple
Slots on the "Address. Details" ACC - each representing an ASCC - how
would we indicate which Slot is participating in the Association? So
there may be no better way than representing these ACCs and ASCC as
RegistryObjects.
</JMC>

> 
> > while the transition from ACCs
> > to ABIEs can be represented by classifications (per the 8 context
> > categories). The path from ACC to ASBIE will therefore use both
> > associations and classifications - the order of which depends on whether
> > the path was:
> >
> > ACC --> ABIE (classification) --> ASBIE (association)
> >
> > OR
> >
> > ACC --> ASCC (association) --> ASBIE (classification)
> 
> Classification can (only) be made based on a ClassificationScheme.
> I see it so that if you have 8 predefined context categories, then you
> have 8 ClassificationSchemes (containing all the posible classification
> nodes!). 

<JMC>
Yes.
</JMC>

Having all that, you can classify the BIEs (RegistryObjects).

<JMC>
Yes.
</JMC>

> But you still need 2 RegistryObjects (1 CC and 1 BIE) and 1 Association
> between them.
> 
> Said that, I didn't get the point for the 2 paths.

<JMC> 
What, you mean you can't read my mind? ;) I should have been clearer: 

I believe there are 4 possible "transitions" involving ACCs, ASCCs,
ABIEs, and ASBIEs:

(1) ACC  --> ABIE 
(2) ABIE --> ASBIE 
(3) ACC  --> ASCC 
(4) ASCC --> ASBIE 

That is, a Registry user should be able to "convert" an ACC to an ABIE
(case #1), an ABIE to an ASBIE (case #2), etc.

I obtained this list by considering all 12 possibilities (assuming X -->
X was not valid - such as ACC --> ACC), and negating the ones that did
not make sense. For example, the following did not make sense:

ASCC  --> ABIE
ASBIE --> ACC
etc.

Having said that, the path from an ACC (the most generic entity) to an
ASBIE (the least generic entity) could be gotten two ways:

Join (1) and (2): ACC --> ABIE --> ASBIE 
Join (3) and (4): ACC --> ASCC --> ASBIE 

Lastly, we can use classification and association as follows:

ACC --> ABIE (classification) --> ASBIE (association)
ACC --> ASCC (association) --> ASBIE (classification)

Please let me know if you think this makes sense. 
</JMC>
> Diego
> 
> 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