Re: [regrep-cc-review] Issue #4: 11179 Data Element Terms

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

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

I definitely see your point, Paul. Let's say for a second that the
registry simply stores/maintains these qualifiers, and does not indicate
any order; and that the assignment of order is the job of an Assembly
tool.

Having said that, suppose in the registry we have a BCC called called
"Telephone. Number", where "Telephone" is the Property Term (per our
example in the original e-mail below). Next, a user creates another BCC
from this one, by adding "Home" as a Property Term Qualifier (NOTE: This
is not a BBIE, because "Home" is not covered by one of the 8 context
categories). So now we have a BCC called "HomeTelephone. Number".

Next, a user (the same user as above or another user) wishes to create a
"US" version of the "HomeTelephone. Number" BCC - which would be a BBIE.
So, they classify the "HomeTelephone. Number" according to the
"Geopolitical" context category, thereby creating a BBIE called...what?

Therein lies our issue: Should this BBIE be called "US_HomeTelephone.
Number"? Or "HomeUS_Telephone. Number"? Are different semantics implied
in each case? i.e. does "US_HomeTelephone. Number" imply that the it is
a US home, but not a US telephone number? (think of a person in a US
home with a cell phone that has a non-US telephone number).

If the latter, the registry user would need to choose which term to
qualify (perhaps through a user interface prompt) - and this would need
to be done in an automatic manner as well (i.e. through a SubmitObjects
request for a BBIE). 

Is the above approach too complex? Should we leave the order to Assembly
tools? If so, how can an Assembly tool know what the proper order is? Is
there really a "proper" order?

[New thread coming for your P.S. regarding BIE Property]

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