Re: Feedback Due 9/5: Updated Requirements Mapping

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

Forwarded on behalf of Diego. Please see comments marked with <JMC15>
(getting bored with predictable sequences).

Diego Ballvé wrote:
> 
> Chiusano Joseph wrote:
> >
> > <JMC3>
> > The case you cite does not involve layers - it is horizontal in nature
> > (extension), rather than vertical in nature (layers).
> > </JMC3>
> 
> True. I used the wrong word. Not "creating new layers" but
> "creating new entities", that is something we also don't
> want to do, unless required (your next comment gives a
> possible reason: reuse).
> 
> > <JMC3>
> > That is a perfectly acceptable (and common) occurrence. A Person may
> > have multiple addresses associated with them. Additionally,
> > creating/storing/maintaining an entity called "ResidenceAddress.
> > Details" allows it to be reused in multiple scenarios. I'm
> > not sure what
> > the issue is here.
> > </JMC3>
> 
> Is it really required to maintain a "ResidenceAddress. Details"
> if it only reuses what has been defined for "Address. Details"?

<JMC15>
Absolutely not. A user should only do so if the "derived" ACC
("ResidenceAddress. Details") is different than the "base" ACC
("Address. Details") - for example, if "ResidenceAddress. Details" has
an additional element. But we probably cannot enforce this in the
Registry architecture - that is, we cannot stop users from derving an
ACC from another ACC and simply providing a different name without
modifying it. This would be up to implementations to enforce. If you
think we should add a requirement in our Technical Note that states that
a derived ACC *must* be different than a base ACC, then it would be
worth considering.
</JMC15>

> I can see CCTS Association doing this trick. 

<JMC15>
Yes - the base and derived ACCs will be linked via an Association whose
assocationType is "derivedFrom".
</JMC15>

What you cannot
> reuse is the "thing" that the Object Class (Aggregate) uses to
> identify each of its contents: PropertyTerm+PropertyTermQualifier.

<JMC15>
Property Term is an attribute (Slot) of Basic Core Components. For
example, "Address. Street. Text" is a BCC (per CCTS p.12 example) whose
Property Term is "Street".
</JMC15>

> I mean, you reuse "Address. Details" and identify it once as
> ResidenceAddress and once as OfficialAddress. ... I guess I'm
> getting repetitive..
> 
> > <JMC3>
> > Not sure what fields you mean - I was referring to the properties on
> > ASCCs/ASBIEs. Since we are not representing these as entities
> > (in the CC
> > sense) but rather as Associations, these properties are not
> > required for
> > ASCCs/ASBIEs.
> > </JMC3>
> 
> For instance ASCC.propertyTerm field and ASBIE.propertyTermQualifier,
> which can be used to generate XML element names according to HK's
> approach (see http://www.itsd.gov.hk/itsd/english/infra/eif.htm).

<JMC15>
Please cite a specific page/line in the URL above. Citing the CCTS p.12
example, there are the following ACCs:

Person. Details
Address. Details

In our work here, we would also create the following 2 ACCs (this is not
in the CCTS spec):

OfficialAddress. Details
ResidenceAddress. Details

We would then join each of these 2 ACCs to the "Person. Details" ACC
with an Association. If one wanted to instantiate these Association in
an XML document, they would call them:

Person. Official. Address
Person. Residence. Address

Dissecting the first name above ("Person. Official. Address") it would
be constructed as follows:

Person = Object Class of "Outer" ACC (Person. Details)  
Official = Object Class Qualifier of "Inner" ACC (OfficialAddress.
Details)  
Address = Object Class of of "Inner" ACC (OfficialAddress. Details)

The same concept would apply for "Person. Residence. Address". In an
earlier e-mail today (subject: "ASCC Names"), I posed the question of
whether or not the above names should be stored as Slots (or a single
Slot) on the Association that links the ACCs, or not.

According to the CCTS spec, the name ASCC "Person. Official. Address"
would have the following 11179 terms:

Object Class = Person
Property Term = Official
Representation Term = Address

So you see, there is no need for us to store/maintain the above terms,
because one can "derive" the name of the Association based on the data
element terms for the "outer" and "inner" ACCs. Why store information
more than once?
</JMC15>

> BTW, I'm saying we should worry about sintax binding.. just that we
> cannot cut things that CCTS defines and sintax binding
> implementers use. We (regrep+cc) are the bridge between this 2.

<JMC15>
As I've stated *multiple* times, the OASIS/ebXML Registry TC was not
brough into the process of creating the CCTS spec. Therefore, we have
the right - and we *will* usurp it - to interpret the CCTS spec in any
way in which we choose. I have raised up to Patrick Gannon and Karl Best
(through Kathryn) the legal issues of our not being 100% compliant with
the CCTS spec. That is the field that we're playing on, and that is the
field we will continue to play on. Feel free to jump off if you don't
like the grass.
</JMC15>
 
> Sorry I can't continue anymore for today.
> 
> Cheers,
> Diego
> 
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: Tuesday, September 02, 2003 8:53 PM
> > To: Diego Ballvé; CCRev
> > Subject: Re: Feedback Due 9/5: Updated Requirements Mapping
> >
> >
> > Forwarded on behalf of Diego. Please see comments marked with <JMC3>.
> >
> > Diego Ballvé wrote:
> > >
> > > Chiusano Josheph wrote:
> > > > <JMC2>
> > > > We won't need such fields, since we will not be
> > representing ASCCs as
> > > > entities but rather as Associations (so no dictionaryEntryName, no
> > > > propertyTerm, etc.). The CCTS spec is *much* too
> > heavyweight on their
> > > > representations here - on top of ASCCs being entities, it
> > > > also specifies
> > > > Association Core Component Properties (more entities!). Yikes!!!!
> > > >
> > > > So we're getting rid of layers that do not need to exist.
> > > > </JMC2>
> > >
> > > .. and creating new layers to substitute them - that
> > > "Address. Details" dicussion, where ACC extends ACC????
> >
> > <JMC3>
> > The case you cite does not involve layers - it is horizontal in nature
> > (extension), rather than vertical in nature (layers).
> > </JMC3>
> >
> > > I DO see the point for propertyTerm, propertyTermQualifier and
> > > cardinality for an ACC/ABIE's contained properties (from UML POW),
> > > regardless if the property is simple (Basic) or complex (Aggregate).
> >
> > <JMC3>
> > I concur.
> > </JMC3>
> >
> > > I can go through the page12 example again but the Address Object
> > > being used twice inside the Person Object is the perfect example:
> > > once it is the Residence Address, once it is the Official Address.
> >
> > <JMC3>
> > That is a perfectly acceptable (and common) occurrence. A Person may
> > have multiple addresses associated with them. Additionally,
> > creating/storing/maintaining an entity called "ResidenceAddress.
> > Details" allows it to be reused in multiple scenarios. I'm
> > not sure what
> > the issue is here.
> > </JMC3>
> >
> > > I'll shut up if outnumbered and use that approach only inside
> > > Republica, but IMHO we can't drop those fields.
> >
> > <JMC3>
> > Not sure what fields you mean - I was referring to the properties on
> > ASCCs/ASBIEs. Since we are not representing these as entities
> > (in the CC
> > sense) but rather as Associations, these properties are not
> > required for
> > ASCCs/ASBIEs.
> > </JMC3>
> >
> > Joe
> >
> > > Diego
> > >
> > > > -----Original Message-----
> > > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > > > Sent: Tuesday, September 02, 2003 7:46 PM
> > > > To: Diego Ballvé; CCRev
> > > > Subject: Re: Feedback Due 9/5: Updated Requirements Mapping
> > > >
> > > >
> > > > Forwarded on behalf of Diego. Please see comments marked
> > with <JMC2>.
> > > >
> > > > Diego Ballvé wrote:
> > > > >
> > > > > Chiusano Joseph wrote:
> > > > > > <JMC>
> > > > > > Not at all - reference [S2]: "Association Core
> > Components will be
> > > > > > represented as Associations between ACCs, and will not be
> > > > > > considered as
> > > > > > "first rate" Core Components".
> > > > > > </JMC>
> > > > > >
> > > > > > If I have ASCC and I want to store them in the registry
> > > > > > can I still choose our mapping approach?? I hope so. I though
> > > > > > the point was to use RIM Association to represent it.
> > > > > >
> > > > > > <JMC>
> > > > > > Yes - see above.
> > > > > > </JMC>
> > > > > >
> > > > > > I propose again (if that is not what we're doing already!)
> > > > > > that we store
> > > > > > ASCC as RIM Association, use Association.name/Association.
> > > > > > description/Association's Slots to store
> > CC/CCProperty details,
> > > > > > just like we do for BCC.
> > > > > >
> > > > > > <JMC>
> > > > > > Not sure what you mean by "to store CC/CCProperty
> > > > details". An ASCC
> > > > > > Association will serve to associate 2 ACCs, and
> > nothing more. CC
> > > > > > Properties will not be represented as entities in our
> > > > architecture.
> > > > > > </JMC>
> > > > >
> > > > > Great. No problems here then, I hope.
> > > > > I meant the fields that CCTS attributes to ASCC/ASCCProperty
> > > > > (i.e, ASCC.dictionaryEntryName, ASCCProperty.propertyTerm,..).
> > > >
> > > > <JMC2>
> > > > We won't need such fields, since we will not be
> > representing ASCCs as
> > > > entities but rather as Associations (so no dictionaryEntryName, no
> > > > propertyTerm, etc.). The CCTS spec is *much* too
> > heavyweight on their
> > > > representations here - on top of ASCCs being entities, it
> > > > also specifies
> > > > Association Core Component Properties (more entities!). Yikes!!!!
> > > >
> > > > So we're getting rid of layers that do not need to exist.
> > > > </JMC2>
> > > >
> > > > > Diego
> > > >
> > > > Joe
> > > >
> >
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