[ISSUE CLOSED] Re: [regrep-cc-review] Properties (Was Re: [regrep-cc-review] Issue #4: 11179 Data Element Terms)

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

As per my last e-mail, this issue is now closed. However, if anyone
would like to comment on what I've written below, please feel welcome as
it may spark discussions on other aspects of our architecture.

Joe

Chiusano Joseph wrote:
> 
> Paul says:
> 
> <Quote1>
> I think a light bulb just went off for me on why the "BIE Property" is
> it's own storable entity in Figure 7-3.
> </Quote1>
> 
> This figure is on p.85 of CCTS spec.
> 
> <Quote2>
> Looking at the attributes of the entity in the figure it should probably
> have been named "BIE Property Qualifier".
> </Quote2>
> 
> The attributes for "BIE Property" are:
> 
> - Qualifier Term (for both Object Class and Property Term), 0..1
> - Cardinality, 1..1
> 
> The cardinality for the "BIE Property" entity itself is 1..*, BIE
> Property-to-ABIE (focusing only on ABIEs for this example, for
> simplicity).
> 
> <Quote3>
> By storing the property qualifiers the registry could construct ABIEs in
> an automated fashion by reusing standardized property term qualifiers.
> </Quote3>
> 
> Ah...very interesting. So for example, for Geopolitical context one
> could store "US" as the Qualifier Term that is used each time an ACC is
> classified according to Geopolitical context "United States".
> 
> But how is the connection between the Qualifier Term and the
> Classification Node "United States" made? This is a key piece that seems
> to me to be missing from this figure. In our discussions, we've decided
> (because I offered it and no one objected ;)) that the Qualifier Term
> "US" would be stored (i.e. tightly coupled) with the classification node
> "United States", and would automatically be used to populate the Object
> Class Qualifier term of any ACC that is qualified (or ABIE that is
> qualified multiple times) according to Geopolitical context of "United
> States". This allows one to maintain the value from a single, central
> location.
> 
> Stepping back from context categories, what if the Object Class
> Qualifier were not related to one of the 8 context categories - ex:
> "Temporary" for "Employee. Details" (i.e "TemporaryEmployee. Details").
> How can we "reuse" these qualifiers?
> 
> I would assert that we can leave this up to implementers, since the
> qualifiers are really stored as they are entered anyway. IOW, let's
> suppose that a user has entered 3 non-context-category-qualifiers up to
> now (since the registry came into use), and 2 of them are Object Class
> Qualifiers and 1 is a Property Term Qualifier. For example, we would
> have:
> 
> - Temporary
> - Home
> - Official
> 
> Now, a user wishes to assign a non-context-category Property Term
> Qualifier to a BCC. An implementation could simply present a list to the
> user of the 3 values above, and let them choose from one of them. The
> registry could add to the "list" with each new qualifier entered by a
> user. Of course, an implementer could do this multiple ways:
> 
> (1) Upon entry of a qualifier term, populate a "QUALIFIER_TERMS" table
> with the value entered
> 
> (2) Do not use a "QUALIFIER_TERMS" table, but rather query for all
> qualifier terms each time a user requests a list, and filter out
> duplicates in the query results prior to presenting them to the user
> (not as efficient as (1) above).
> 
> Now, let's compare with Figure 7-1 on p.75, which is at the Core
> Component level (rather than BIE).
> 
> The attributes for "CC Property" are:
> 
> - Property Term (not a Qualifier term as in the earlier figure!), 1..1
> - Cardinality, 1..1
> 
> The cardinality for the "CC Property" entity itself is 1..*, CC
> Property-to-ACC.
> 
> So there is a large inconsistency here, in that the CC Property entity
> has a "Property Term" attribute rather than a "Property Term Qualifier"
> attribute. Assuming this is not a typo (which it may be), we are
> planning to store the "Property Term" attribute along a BCC. The same
> concept as above would follow if a registry implementation wished to
> present the user with a list of all Property Terms assigned thus far,
> for their selection.
> 
> So in summary, I still don't see a need for us to represent these
> Property entities in the registry. Please enlighten me if you think my
> argument is off base.
> 
> <Quote4>
> And the rule that makes the resultant ABIE unique regardless of the
> qualifier order makes it easier on the developer to be certain that they
> are not duplicating another ABIE where the registry happened to place
> the property qualifiers in a different order.
> </Quote4>
> 
> Let's see: Suppose we have an ABIE called "BuyerParty. Details" (where
> Buyer = Object Class Qualifier), and then we further classify it
> according to the Geopolitical context category and it becomes
> "US_BuyerParty. Details". Then, a user comes along and takes the
> "BuyerParty. Details" ABIE (which still exists, BTW; the "US_BuyerParty.
> Details" ABIE was "derived" from it), and wishes to further classify -
> not the Buyer term - but the Party term.
> 
> Questions:
> 
> (1) Should this be allowed?
> (2) Is it a valid scenario?
> (3) If so, how could the registry maintain the order of Qualifiers?
> (remember that a Qualifier is a Slot, and we cannot have Slots for
> Slots!)
> (4) If the order of Qualifiers is different between 2 "derived" ABIEs,
> does that make them unique?
> (5) Other questions?
> 
> I believe the CCTS spec is silent on this issue (which means we'll need
> to create an approach for us) - does anyone have a different
> perspective?
> 
> Joe
> "MACIAS, Paul" wrote:
> >
> > I've lost an aspect of this discussion.  Why are we debating the order of two property term qualifiers.  I've gone back to look at the discussion thread and I'm missing the concept of why the registry mapping needs to be concerned with the order.  Is it to facilitate automated registry construction of a ABIE from an ACC?  Is it a matter of establishing a rule that if the registry (instead of an CC developer) is making the decision that the registry should attach additional property qualifiers to the front of any existing property qualifiers?
> >
> > I make the distinction, because in my view the overall issue of guiding developers on what term goes where is a job for the CCTS to do, not the registry spec.  Still, I see nothing wrong in including a best practice type recommendation for automating what according to the CCTS appears to be an arbitrary decision for a developer. In other word if relevant standards   don't think its important what qualifier proceeds another, then anything we do for the sake of making automation easier could be included as a recommendation.
> >
> > However, I don't think it is possible to guarantee the semantic order by any rule for registry automation.  Thinking more abstract than the current example, I think it is reasonable to assume that there will be situations where even a developer would have a hard time rationalizing one qualifier as being more relevant to the property term than another qualifier.  According to the CCTS you could have infinite property qualifiers for a single property term.
> >
> > Regards,
> >
> > Paul M.
> >
> > P.S. - I think a light bulb just went off for me on why the "BIE Property" is it's own storable entity in Figure 7-3.  Looking at the attributes of the entity in the figure it should probably have been named "BIE Property Qualifier".  By storing the property qualifiers the registry could construct ABIEs in an automated fashion by reusing standardized property term qualifiers.  And the rule that makes the resultant ABIE unique regardless of the qualifier order makes it easier on the developer to be certain that they are not duplicating another ABIE where the registry happened to place the property qualifiers in a different order.  Does anyone else see that, or am I off base?
> >
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: Tuesday, August 26, 2003 4:32 PM
> > To: Monica Martin
> > Cc: CCRev
> > Subject: Re: [regrep-cc-review] Issue #4: 11179 Data Element Terms
> >
> > <Quote1>
> > is this based on where the qualifier goes or how we interpret the
> > qualifier?
> > </Quote1>
> >
> > I would say it is based on where the qualifier goes. So in our case, we
> > are really talking about a format for a telephone number in the U.S. I
> > don't believe the CCTS spec speaks to this, so we'll need to brainstorm.
> > My preference would be to place the qualifier closest to where it
> > applies - i.e. before "Telephone" rather than before "Home" in this
> > case.
> >
> > Thoughts?
> >
> > Joe
> >
> > Monica Martin wrote:
> > >
> > > >Chiusano: <Quote>
> > > >The two expressions do have different semantics, but that does not make
> > > >them unique.
> > > ></Quote>
> > > >
> > > >Excellent - thanks for the reference Monica. I would assert that a
> > > >qualifier should be placed closest to the term that it is meant to
> > > >qualify. That is, if I were to choose between:
> > > >
> > > >US | Employee | US | Home | Telephone | Number
> > > >
> > > >or:
> > > >
> > > >US | Employee | Home | US | Telephone | Number
> > > >
> > > >I would choose the second one because I really mean a US telephone
> > > >number, more than I mean a US home.
> > > >
> > > mm1: I am really stumped here (which happens often) is this based on
> > > where the qualifier goes or how we interpret the qualifier?
> > > I think logically it falls with the former.  Do we apply some priority
> > > here to how they are qualified?
> 
>   ------------------------------------------------------------------------
> To unsubscribe from this list, go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review. Note:unsubscribing will result in your withdrawal from this OASIS Technical Committee.
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