[Date Prev][Date Next]
Re: approx match at CMU
Please note the X.500 requirement that
approximate(asserted,stored) MUST return TRUE
if equality(asserted,stored) is TRUE
That is, the set of values which successful match via the
appropriate matching rule must include all the values which
successful match per the equality matching rule.
As you've noted, there are numerous ways of applying phonetics.
In 1.2, the values where broken into words, translated to
normalized form. The match would return true if each asserted
normalized word appeared in the asserted value in the order
asserted. That is, "a b" would match "x a y b z" and "b a b"
but not "b a".
There are, of course, countless variants on this approach
as well as countless routines for generating "normalized"
I actually don't care too much which variant/routine is
chosen... but I suspect others might. Hence, I suggest
whatever be done be designed to allow for easy replacement.
Basically, if you have the time, I suggest a knob to flip
between variants and a knob to select the word normalization
approach. I'd be very happy if each knob would have two
positions initially... of course, if you (or someone else)
doesn't have time, we'll take what we can get.
PS: 1.2 actually could use soundex or phoentic (switchable