Issue 2835:  need find_candidates operation on CorrelationMgr (pids-rtf2)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: We need a version of find_candiate that returns candidates (each with
 qualified id and profile) from multiple domains - not just the correlating
 domain.
 

Resolution: 
Revised Text: 
Actions taken:
August 11, 1999: received issue
Discussion: 

End of Annotations:=====
Reply-To: "Jon Farmer" <jfarmer@ic.net>
From: "Jon Farmer" <jfarmer@ic.net>
To: "pids-rtf2" <pids-rtf2@emerald.omg.org>
Subject: issue: need find_candidates operation on CorrelationMgr
Date: Tue, 10 Aug 1999 16:18:33 -0400
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: fcaa08d8d990f0958f8dbe739b324e7f

We need a version of find_candiate that returns candidates (each with
qualified id and profile) from multiple domains - not just the
correlating
domain.


Reply-To: "Jon Farmer" <jfarmer@ic.net>
From: "Jon Farmer" <jfarmer@ic.net>
To: "pids-rtf2" <pids-rtf2@emerald.omg.org>
Subject: Issue 2835: need find_candidates operation on CorrelationMgr
(pids-rtf
Date: Wed, 18 Aug 1999 15:54:50 -0400
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: d2926ec0570ba8c8dca7d226be0ee3ee

the existing operation for find_candidates returns a "candidateSeq
returned_sequence" which is a sequence of candidate, wherein each
candidate
has a PersonID, a confidence, and its associated profile.  Because the
PersonId is not qualified with its ID domains, this operation is not
satisfactory for use in a situation where the server delegates the
search
back to multiple IdentifyPerson interfaces, each on its own ID domain.

It is possible for an implementation of the existing find_candidates
operation to support a delegated search as follows.  It could take the
supplied selector traits and invoke the find_candidates operation on
all its
source domains and then for each candidate it could find_or_register
those
candidates into its own domain, and then search itself and present
results -
all under the auspices of its own correalting domain.

This type of implementation could indeed produce a meaningful
candidate set,
but its candidate set would be vulnerable to the following semantic
ambiguities:

1. Even if the client (end user or application ) knows that the final
candidate set was materialized from several source domains, it cannot
know
which candidate came from which domain.
2. The client may have knowledge of and confidence in the matching
algorithm
employed by the correlating domain, but it has no way of determining
the
reliability of the candidate sets retrieved from the source domains -
because the candidates do no identifiy their domains.

Two possible solutions
=========================
One solution is to define a new operation (and I think it fits
logically in
the Correlation Mgr interface) expressly for the purpose of supporting
a
multiple-domains search.

In "Basic Types" we would define:

struct IDDomainQualifiedCandidate {
  QualifiedPersonId id;
  float confidence;
  Profile profile_requested;
 };

Then in CorrelationMgr we define:

void find_candidates(
    in TraitSelectorSeq profile_selector,
    in IdStateSeq states_of_interest,
    in unsigned long sequence_max,
    in unsigned long iterator_max,
    in SpecifiedTraits traits_requested,
    out IDDomainQualifiedCandidateSeq returned_sequence,
    out CandidateIterator returned_iterator )
   raises (
    TooMany,
    UnknownTraits,
    WrongTraitFormat,
    CannotSearchOn,
    DuplicateTraits,
    InvalidStates,
    InvalidWeight );
    };

An alternative solution is to use a QualifiedPersonID (rather than
PersonID)
in the candidate struct , so that for each candidate the client can
tell
from which ID Domin the candidate had been retrieved:

struct Candidate {
  QualifiedPersonId id;
  float confidence;
  Profile profile_requested;
 };

In my opinion an identifer value should never travel without its
domain ID.
Therefore I prefer this resolution, even though it breaks the spec.