Legacy Issue Number: 3789
Source: Level Seven Visualizations ( Jon Farmer)
he "RequiredTraits" exception returns a sequence of traits. But
make_ids_permenant takes an ARRAY
of input ids. So this exception if thrown won't provide any usefull
information as to which id
had the problem.
Our implementation, rather than throwing the exception, just creates the ID
in a temporary state. However, as we recently considered supporting the
exception in conjunction with a probabilistic matching algorithm, we found
the following ambiguity:
The RequiredTraits exception inlcudes a list of required traits, but the
spec doesn't clarify that this is the complete list of required traits -
assuming that its the same set for any input profile - so that the client
can figure out which IDs need for traits.
The problem with that semantic is as follows. Some probabilisitc matching
algorithms can only determine the adequacy of the incoming trait set by
inspecting the VALUES of the trait types supplied. for example, if the
incoming request tries to register two ids, one with first=John ,
Last=Smith, and the second with First=Mergetroid Last=Pepperdyne, a
probabilisitc algorithm will likely accept the second but reject the first;
YET BOTH supplied the same traits. Hwo could the client figure out what's
missing? How the server even figure out what's missing? Neither can. ONLY
THE ALGORITHM KNOWS....... AND IT ONLY KNOWS ONCE IT HAS SEEN THE INPUTS.
Therefore we need to define clearly what the exception semantics are, and in
a way that doesn't preclude the use of probabilistic matchers that cannot
assess adequacy in a "one trait list fits all" manner.
One possible solution is to have the exception return a SEQUENCE OF
offending ids - so the client can know which are offensive. Instead of also
including for each the set of traits needed, the return structure could show
the confidence deficit for each.
Reported: PIDS 1.0 — Thu, 10 Aug 2000 04:00 GMT
Disposition: Resolved — PIDS 1.1
Updated: Fri, 6 Mar 2015 20:50 GMT