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

[Diego Ballvé <diego.ballve@republica.fi>]

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

<Diego>
Sorry for not been clear. What I had in mind was that the top-most ABIE
in a form, which is not an ASBIE, maps to a top-most ACC. So, yes, it
does not get instantiated. Instead, one of its extensions does. This will
come back later when we move to BIEs.
</Diego>

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

<Diego>
I don't want to change Associations! I'm happy with them. :)
This comments were for the approach that there would be no RegistryObject
(ExtrinsicObject) specific for an ASCC. Just an Association between 2 ACCs.
That's not what you're talking about. Cleared.
</Diego>

> - 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>
Yep, makes sense. I'd like to point that the "conversion" is made by
a tool. We (or the Registry) just have to care about how to store the
results of the conversion, and how to offer proper ways to navigate
through it (ExtrinsicObjects for CCs and for BIEs, Associations and
Classifications -> the paths that you're describing).
</Diego>