[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: ACC or ABIE? (Was Re: [regrep-cc-review] Association Core Components - Represent withAssociations)
Forwarded on behalf of Diego. Please see comments marked with <JMC>. Diego Ballvé wrote: > > Good. The missing 1%: > > My "Address. Details" ABIE does have business context: ALL. <JMC> It's still an ACC according to the CCTS spec. If you think that we should propose to the CCTS Team that they remove the notion of "ACC" from the CCTS spec altogether, then please let me know. <JMC> > Diego > > Chiusano Joseph wrote: > > > > Forwarded on behalf of Diego. Please see comments marked with <JMC>. > > > > Diego Ballvé wrote: > > > > > > Joe, > > > > > > > for this point). Now let's say that we have an ABIE > > called "Address. > > > > Details" - but wait! - "Address. Details" is not an ABIE, > > it's an ACC. > > > > > Why? Why can't you have an ABIE "Address. Details" as well?? That is > > my starting point. > > > > <JMC> > > Oh - "Address. Details" cannot be an ABIE according to the CCTS spec > > because it lacks specific business context. On p.12, it is clarified > > that "Address. Details" is an ACC, not an ABIE. But that > > doesn't negate > > any of your points below. > > </JMC> > > > > > > > > > What happens now? If the "Address. Details" ACC is not classified > > > > according to at least one of the 8 context categories, it > > cannot be > > > > considered an ABIE (according to our current understanding). > > > > > I obviously missed the CC to BIE thread. In my point of view CCs and > > BIEs are different RegistryObjects. > > > > <JMC> > > Yes - they are different RegistryObjects. > > </JMC> > > > > Again, in my POV if you have a CC and need a BIE for it you > > follow these > > steps (talking RIM): > > 1. Create a NEW ExtrinsicObject of type xBIE > > > > <JMC> > > Yes. > > </JMC> > > > > 2. Associate it to you original CC > > > > <JMC> > > Yes. > > </JMC> > > > > 3. Optionally classify it for as many contexts as you want. > > > > <JMC> > > Yes. > > </JMC> > > > > 4. Optionally add QualifierTerm slot. > > > > <JMC> > > That is where I think we need to adjust - if both #3 and #4 are > > optional, you're still left with a Core Component (i.e. no business > > context, no Qualifier Term). I believe that #4 should be a > > requirement - > > the minimum requirement for an xBIE. > > </JMC> > > > > (5. Optionally further restrict datatypes.) > > > > <JMC> > > Yes. > > </JMC> > > > > > It does not invalidate your proposed process since it is in a > > > different abstraction layer. But maybe in my view you'd end up > > > with a lot more ExtrinsicObjects than you're expecting. > > > > <JMC> > > Since we're in sync regarding the creation of > > ExtrinsicObjects, I think > > there's no issue here. > > </JMC> > > > > Are we 'synchronized' about this?? > > > > <JMC> > > 99% - see step #4 above. > > </JMC> > > > > Joe > > > > > Diego > > > > > > > > > > > Forwarded on behalf of Diego. Please see my comments below. > > > > > > > > <Quote1> > > > > Probably amend is needed, though we have to specify what happens > > > > if the BIE has no classification for a context categories. I'd > > > > say that it should not be restricted for that category and fit > > > > any. Example: geopolitical classification missing -> BIE can be > > > > used all over the world. > > > > </Quote1> > > > > > > > > Ah, this is tricky - you make a great point here. In other > > > > words, let's > > > > say we have an ABIE called "US_Address. Details". We know > > > > this ABIE has > > > > a Geopolitical context of "US", because it is classified > > according to > > > > the Geopolitical context classification schema and is > > associated with > > > > the "US" node (leaving out the "_" for now, because it > > doesn't matter > > > > for this point). Now let's say that we have an ABIE > > called "Address. > > > > Details" - but wait! - "Address. Details" is not an ABIE, > > it's an ACC. > > > > > > > > What happens now? If the "Address. Details" ACC is not classified > > > > according to at least one of the 8 context categories, it > > cannot be > > > > considered an ABIE (according to our current understanding). > > > > If it were > > > > classified according to Business Process Role, it could be called > > > > "BuyerAddress. Details" - and since it is not classified > > according to > > > > Geopolitical context, it would mean (as you point out > > above) that it > > > > would be valid in all Geopolitical contexts (which I agree with). > > > > > > > > So this means: In order for an entity to make the "leap" > > from ACC to > > > > ABIE, it must be classified according to at least one context > > > > category. > > > > > > > > But is this realistic? How can we create an ABIE and have it > > > > be valid in > > > > ALL context categories? > > > > > > > > Here's what I propose: Knowing that "Address. Details" is > > an ACC, I > > > > propose that: > > > > > > > > - "ResidenceAddress. Details" is an ABIE, and > > > > - It is not classified according to any context category > > > > > > > > This means that "ResidenceAddress. Details" is valid in > > ALL context > > > > categories. Otherwise, if we require that an ABIE be > > classified by at > > > > least one of the 8 context categories, how would we allow an > > > > ABIE to be > > > > valid in context categories? (at least one context category > > > > would not be > > > > "ALL"). > > > > > > > > Another approach is to require an "ALL" node to exist in > > each context > > > > category classification scheme, and require that an ABIE > > be classified > > > > according to each "ALL" node as necessary - but I think > > this is very > > > > inefficient, because it requires more work by the registry. I > > > > think it's > > > > better if we consider "ALL" to be a default (as Diego points > > > > out above). > > > > > > > > So, what is an ABIE for our purposes? > > > > > > > > I believe it is an ACC that contains an Object Class > > Qualifier (ex: > > > > "Residence"). Additionally (not required), it may be classified > > > > according to one or more of the 8 context categories - if > > it is not > > > > classified according to a category, it is assumed (by > > default) that it > > > > is valid for all possible values (nodes) of that category. > > > > > > > > <Quote2> > > > > The alternative would be to add ALL the classif to that BIE, > > > > which would > > > > probably mean unnecessary overhead. > > > > </Quote2> > > > > > > > > Yes - excellent point (in line with the points above). > > > > > > > > <Quote3> > > > > Btw, you can have a combination of contexts, like a BIE > > is good for > > > > "this" business process under "that" geopolitical region. > > > > </Quote3> > > > > > > > > Yes - and let's think about that for a second. Let's suppose > > > > we have an > > > > "Address. Details" ACC, and we classify it according to > > > > Business Process > > > > Role (Buyer) and Geopolitical Region (US). Let's also > > suppose that we > > > > want to specify that this is the Buyer's "Residence > > Address" (not a > > > > normal case, but hang in with me for a sec). I believe we > > would stack > > > > Object Class Qualifiers in front of each other, as > > described below. > > > > > > > > The steps would be as follows (order could be different > > than below): > > > > > > > > (1) "Address. Details" -> "ResidenceAddress. Details" > > > > (ACC) (ABIE) > > > > > > > > - This is done by adding an Object Class Qualifier of "Residence"; > > > > > > > > (2) "ResidenceAddress. Details" -> > > "BuyerResidenceAddress. Details" > > > > (ABIE) (ABIE) > > > > > > > > - This is done by classifying the ABIE according to the > > > > Business Process > > > > Role context category, and (automatically) adding another > > Object Class > > > > Qualifier of "Buyer" in front; > > > > > > > > (3) "BuyerResidenceAddress. Details" -> "US_BuyerResidenceAddress. > > > > Details" > > > > (ABIE) (ABIE) > > > > > > > > - This is done by classifying the ABIE according to the > > Geopolitical > > > > context category, and (automatically) adding another Object Class > > > > Qualifier of "US_" in front; > > > > > > > > Thoughts? > > > > > > > > Joe > > > > > > > > Diego Ballvé wrote: > > > > > > > > > > Probably amend is needed, though we have to specify what happens > > > > > if the BIE has no classification for a context categories. I'd > > > > > say that it should not be restricted for that category and fit > > > > > any. Example: geopolitical classification missing -> BIE can be > > > > > used all over the world. If no classification is given for any > > > > > category, like in (b), then the resulting ABIE has can be used > > > > > in any context. The alternative would be to add ALL the classif > > > > > to that BIE, which would probably mean unnecessary overhead. > > > > > > > > > > Btw, you can have a combination of contexts, like a BIE is good > > > > > for "this" business process under "that" geopolitical region. > > > > > > > > > > Diego > > > > > > > > > > Chiusano Joseph wrote: > > > > > > <Quote> > > > > > > I would say that "ResidenceAddress. Details" fits the 2nd > > > > > > option. > > > > > > </Quote> > > > > > > > > > > > > Thanks Diego - let's say for the moment that > > "ResidenceAddress. > > > > > > Details" is an ABIE. We can create an ABIE from an ACC > > > > by classifying > > > > > > it according to one of the 8 context categories (and > > > > adding the Object > > > > > > Class Qualifier). Would the addition of "Residence" fall > > > > under one of > > > > > > the 8 context categories? Or do we need to amend our > > > > handling of the > > > > > > ACC->ABIE transition to state that it can occur from: > > > > > > > > > > > > (a) Classification according to one of the 8 context > > > > categories (plus > > > > > > addition of Object Class Qualifier), or > > > > > > (b) Simply the addition of an Object Class Qualifier (in > > > > which case no > > > > > > classification would be involved) > > > > > > > > > > > > Joe > > > > > > > > > > > > Diego Ballvé wrote: > > > > > > > > > > > > > > Chiusano Joseph wrote: > > > > > > > > > > > > > > > > Thanks to Monica for her feedback - please see > > comments below. > > > > > > > > > > > > > > > > <Quote1> > > > > > > > > >With this in mind, do folks agree that it would > > be valuable > > > > > > > > to create >an entity (a type of an ACC) in the > > registry called > > > > > > > > >"ResidenceAddress. Details", that can be > > re-usable in many > > > > > > > > cases, >thereby alleviating the > > > > > > > > >need to constantly re-create it on-the-fly? > > > > > > > > > > > > > > > > > mm1: One impact you have to think about, and has > > been raised > > > > > > > > by CCSD, is > > > > > > > > if the ResidenceAddress. Details has the same attributes > > > > > > > > which supports > > > > > > > > the later discussion if it could also be an ABIE. > > > > > > > > </Quote1> > > > > > > > > > > > > > > > > That's a great point, which I also brought up to Alan > > > > > > Stitzer of the > > > > > > > > CCTS Team. Is "ResidenceAddress. Details" an ACC or > > > > an ABIE? (or > > > > > > > > something in-between?) In the p.16 CCTS example it lists > > > > > > > > "US_ResidenceAddress. Details" as an ABIE, so could > > > > > > "ResidenceAddress. > > > > > > > > Details" really be an ABIE? If yes, then what context > > > > > > category does it > > > > > > > > fall under? > > > > > > > > > > > > > > There might be an "ResidenceAddress. Details" ACC and > > > > > > > a and a "ResidenceAddress. Details" ABIE, and the ABIE could > > > > > > > be the realization/contextualization of the idea (ACC). In > > > > > > > practice we (@Republica) assumed that some BIEs would be > > > > > > > context specific and some would probably fit all contexts. > > > > > > > I would say that "ResidenceAddress. Details" fits the 2nd > > > > > > > opion. > > > > > > > > > > > > > > Despite we can have ACC and ABIE with same name and actually > > > > > > > related (InstanceOf?), using the same > > RegistryObject for both > > > > > > > might not be possible, the main reason being the > > fact that we > > > > > > > can have multiple BIEs for the same CC. > > > > > > > > > > > > > > Diego > > > > > > > > > > > >
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]