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

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

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