Issue 2836: need to be able to get description of matching algorithm (pids-rtf2) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In order for a client to rightly interpret the results of a search using find_candidates or find_or_register_ids, it would be very helpful to have an operation to get a description of the matching algorithm employed Resolution: Revised Text: Actions taken: August 11, 1999: received issue Discussion: End of Annotations:===== Reply-To: "Jon Farmer" From: "Jon Farmer" To: "pids-rtf2" Subject: issue: need to be able to get description of matching algorithm Date: Tue, 10 Aug 1999 16:20:13 -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: d09dbba9ae817a3db91f3ab6f956141f In order for a client to rightly interpret the results of a search using find_candidates or find_or_register_ids, it would be very helpful to have an operation to get a description of the matching algorithm employed Reply-To: "Jon Farmer" From: "Jon Farmer" To: "pids-rtf2" Subject: Issue 2836: need to be able to get description of matching algorithm (pids-rtf2) Date: Wed, 18 Aug 1999 16:20:37 -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: 7a2e2f1adc34ae1f511a055912c926cc Dave suggested, and I agree, that we should consider utilizing the OMG property list interface(s) so that an Identification component can provide the client with a description of its matching alogorthm(s). Note that since: IdMgr:find_or_register_ids, CorrelationMgr: find_or_register_ids, and IdentifyPerson:find_candidates might all use different matching algorithms, and since each may even offer multiple algorithms with a default, we are not necessarily talking about a single-valued property. I propose that we solve this problem in a way that provides not only for "getting" but also for "setting/selecting" the algorithm to be used in a goven call. For getting the possible and default algorithm names and descriptions, we use property lists assoicated with each interface. To permit the client to select the algorithm to be used in a given call, we add an "Algorithm" or "MatchingPolicyName" argument to each of the three operation signatures above. (Offhand, can anybody tell me what the propertylist operations would be for this?) There is presently no way to define a new operation that a client can call to specify the algorithm for use in subsequent calls, without putting undue restrictions on implementation approach. It raises serious new responsibilites on both client and server to remember what algorithm is in effect for specific users or connections or instances. I realize that it is usually not popular to violate issued specs. However in this case I belive that enough of the industry at large would consider this a defect rather than a new-feature-opportunity that I recommend we "fix" it. If we do not add this argument, then I must make a PIDS that lacks a distinguishing feature of my prior product. Furthermore I now know of two user organizations that would reject the PIDS for this feature-shortage alone. We should not leave a spec intact that prohibits a functionality deemed important by a significant portion of the user community. Jon Date: Wed, 18 Aug 1999 15:17:36 -0600 Message-Id: <199908182117.PAA13618@hope.aclnet> From: David Forslund To: "Jon Farmer" Cc: "pids-rtf2" Subject: Re: Issue 2836: need to be able to get description of matching algorithm (pids-rtf2) In-Reply-To: <005801bee9b7$276092c0$0c1e85cd@JGFNT.toledolink.com> References: <005801bee9b7$276092c0$0c1e85cd@JGFNT.toledolink.com> Reply-To: "David W. Forslund" Content-Type: text X-UIDL: 470f721ef1851bd3be867d52a369e274 I think you can "fix" the find_candidates call by adding an additional find_candidates call with this semantics corrected. I think there is room for the simple call under some circumstances where one does not care about the matching algorithm and would allow for backward compatibility. The new call might become preferred as PIDS gets further deployment. formal/97-12-20.pdf has the spec on Property service with the appropriate method calls. (A Property looks just like a Trait, surprise, surprise) We may need to specify some specific algorithm "Name" and values. Dave Jon Farmer writes: > Dave suggested, and I agree, that we should consider utilizing the OMG > property list interface(s) so that an Identification component can provide > the client with a description of its matching alogorthm(s). > > Note that since: > > IdMgr:find_or_register_ids, > CorrelationMgr: find_or_register_ids, and > IdentifyPerson:find_candidates > > might all use different matching algorithms, and since each may even offer > multiple algorithms with a default, we are not necessarily talking about a > single-valued property. > > I propose that we solve this problem in a way that provides not only for > "getting" but also for "setting/selecting" the algorithm to be used in a > goven call. > > For getting the possible and default algorithm names and descriptions, we > use property lists assoicated with each interface. > > To permit the client to select the algorithm to be used in a given call, we > add an "Algorithm" or "MatchingPolicyName" argument to each of the three > operation signatures above. (Offhand, can anybody tell me what the > propertylist operations would be for this?) > > There is presently no way to define a new operation that a client can call > to specify the algorithm for use in subsequent calls, without putting undue > restrictions on implementation approach. It raises serious new > responsibilites on both client and server to remember what algorithm is in > effect for specific users or connections or instances. > > I realize that it is usually not popular to violate issued specs. However > in this case I belive that enough of the industry at large would consider > this a defect rather than a new-feature-opportunity that I recommend we > "fix" it. > > If we do not add this argument, then I must make a PIDS that lacks a > distinguishing feature of my prior product. Furthermore I now know of two > user organizations that would reject the PIDS for this feature-shortage > alone. We should not leave a spec intact that prohibits a functionality > deemed important by a significant portion of the user community. > > Jon > > X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 21 Oct 1999 14:12:59 -0600 To: pids-rtf2@omg.org From: David Forslund Subject: Re: 2670, 2836 In-Reply-To: <4.2.0.58.19990915214454.01bdfd60@cic-mail.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: Zchd9V"Ne9lYR!!W]%"! At 09:49 PM 9/15/99 -0600, David Forslund wrote: >Here is a suggested IDL change to deal with Issues 2670 and 2836 > >Basically, I've followed the style of the Party Management Facility to include >SearchType in a new query_candidates call and a method to get the Properties >associated with a TraitName > >Dave Some seem to have had a hard time reading what I sent as an attachment, so here it is in plaintext. This has both the SearchType and the Properties changes, but I'm becoming more convinced that the SearchType change is out of scope, but that the Properties change is something that is broken in the current spec. Dave *** PersonIdService.idl ---- newPersonIdService.idl *************** *** 5,15 **** #include #include #include #include - #include //#include "Notification.idl" #pragma prefix "omg.org" module PersonIdService --- 5,14 ---- *************** *** 144,154 **** }; typedef sequence< MultipleFailure > MultipleFailureSeq; interface Identity; typedef sequence< Identity > IdentitySeq; ! typedef sequence SearchType; // --------------------------------------------------------------- // Exceptions // --- 143,153 ---- }; typedef sequence< MultipleFailure > MultipleFailureSeq; interface Identity; typedef sequence< Identity > IdentitySeq; ! // --------------------------------------------------------------- // Exceptions // *************** *** 175,185 **** exception ProfilesExist { IndexSeq indices; }; exception DuplicateProfiles { IndexSeq indices; }; exception DomainsNotKnown { DomainNameSeq domain_names; }; exception IdsNotKnown { QualifiedPersonIdSeq ids; }; ! exception SearchTypeNotSupported {}; // --------------------------------------------------------------- // IdentificationComponent // interface ProfileAccess; --- 174,184 ---- exception ProfilesExist { IndexSeq indices; }; exception DuplicateProfiles { IndexSeq indices; }; exception DomainsNotKnown { DomainNameSeq domain_names; }; exception IdsNotKnown { QualifiedPersonIdSeq ids; }; ! // --------------------------------------------------------------- // IdentificationComponent // interface ProfileAccess; *************** *** 204,231 **** readonly attribute CorrelationMgr correlation_mgr; // readonly attribute Notification::EventComponent event_component; readonly attribute CosNaming::NamingContext naming_context; readonly attribute CosTrading::TraderComponents trader_components; ! void get_supported_properties( ! in TraitName name, ! out CosPropertyService::PropertyDefs trait_defs) ! raises ( ! UnknownTraits ! ); ! }; // --------------------------------------------------------------- // IdentifyPerson // interface IdentifyPerson : IdentificationComponent { - - SearchType get_supported_search_types(); - void find_candidates( in TraitSelectorSeq profile_selector, in IdStateSeq states_of_interest, in float confidence_threshold, in unsigned long sequence_max, --- 203,221 ---- readonly attribute CorrelationMgr correlation_mgr; // readonly attribute Notification::EventComponent event_component; readonly attribute CosNaming::NamingContext naming_context; readonly attribute CosTrading::TraderComponents trader_components; ! }; // --------------------------------------------------------------- // IdentifyPerson // interface IdentifyPerson : IdentificationComponent { void find_candidates( in TraitSelectorSeq profile_selector, in IdStateSeq states_of_interest, in float confidence_threshold, in unsigned long sequence_max, *************** *** 239,270 **** WrongTraitFormat, CannotSearchOn, DuplicateTraits, InvalidStates, InvalidWeight ); - - void query_candidates( - in TraitSelectorSeq profile_selector, - in IdStateSeq states_of_interest, - in float confidence_threshold, - in unsigned long sequence_max, - in unsigned long iterator_max, - in SpecifiedTraits traits_requested, - - out CandidateSeq returned_sequence, - out CandidateIterator returned_iterator ) - raises ( - TooMany, - UnknownTraits, - WrongTraitFormat, - CannotSearchOn, - DuplicateTraits, - InvalidStates, - InvalidWeight, - - }; // --------------------------------------------------------------- // ProfileAccess // interface ProfileAccess : --- 229,240 ---- WrongTraitFormat, CannotSearchOn, DuplicateTraits, InvalidStates, InvalidWeight ); }; + // --------------------------------------------------------------- // ProfileAccess // interface ProfileAccess :