[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Nick names search extension
Ringer, Oded wrote:
>
> Great ! can you give more details. How you did configure the server with
> this list ?
We have a separate protocol for a bunch of Directory administration operations.
Operations to add and delete synonyms are part of that protocol. The list
itself is just another indexed file in the database. The list can be accessed
at query time to expand out the filter with the other possibilities.
Alternatively, approximate match indexes can be built which factor in the
synonyms. For example, the entry for "Bill" is indexed under both "Bill"
and "William" though it only explicitly contains the string "Bill".
We have been tending towards representing various configurable lists as
attributes in the root entry so that those lists can be manipulated using
ordinary DAP/LDAP operations. We've delayed doing this with the synonyms list
because of its size. The base list of givenName synonyms has 1800 records.
Steven Legg
Telstra Research Laboratories
>
> -----Original Message-----
> From: Steven Legg [mailto:s.legg@trl.telstra.com.au]
> Sent: Sunday, November 08, 1998 6:23 PM
> To: Ringer, Oded
> Cc: ietf-ldapext@netscape.com
> Subject: Re: Nick names search extension
>
>
>
> The way we dealt with this issue in Telstra's directory server was through
> the approximate match filter item. The server is configured with a list
> of whole value and/or keyword synonyms per attribute type. In the case
> of commonName or givenName "Bill=William" and "Bob=Robert" are typically
> registered. If a filter specifies an approximate match on "Bill" then the
> server will also try "William", and any other registered synonyms of "Bill".
> Similarly "William" in the filter will match "Bill" in an entry.
> If the filter specifies an equality match then only the entries matching
> "Bill" are returned.
>
> Since the issue of alternate names is handled during matching we don't need
> to add extra attributes or extra values to entries, people get to use their
> preferred name in their entry, and operators don't need to try all the
> variations on a name to get a match.
>
>
> Steven Legg
> Telstra Research Laboratories
>
>
> Ringer, Oded wrote:
> >
> > Think about a person that is known as Will and doesn't want to appear as
> > Bill as his nick name. We wouldn't want to force him to have this other
> name
> > as part of his entry.
> >
> > However, since it is a common knowledge that Bill=William, When 411
> > operators are asked to find a William they're making the extra step and
> > looking up Bill as well.
> >
> > Of course we could hard code this into the LDAP client application and
> make
> > it part of the matching rule. But the right place to store this knowledge
> is
> > centrally. (Otherwise, we would have to redeploy clients if we think of a
> > new nick-name.)
> >
> >
> > -Oded
> >
> > Oded Ringer 212-902-7939
> > Goldman, Sachs & Co.
> >
> >
> > -----Original Message-----
> > From: Erik Skovgaard [mailto:eskovgaard@geotrain.com]
> > Sent: Friday, November 06, 1998 12:40 PM
> > To: Ringer, Oded; ietf-ldapext@netscape.com
> > Subject: Re: Nick names search extension
> >
> >
> > Oded,
> >
> > I am not sure why you would want to use a control for that. Why not just
> > put the nicknames in the name attribute? The cn attribute is multi-valued
> > in the standard schema (I have to make this qualification given the many
> > different schemae that seem to be published). Only one of the values of
> > this attribute is distinguished, of course, but you can search on the
> rest.
> >
> > Cheers, ....Erik.
> >
> > ---------------------------------------
> > Erik Skovgaard
> > GeoTrain Corp.
> > Enterprise Directory Engineering Services
> > http://www.geotrain.com
> >
> > At 11:36 98/11/06 -0500, Ringer, Oded wrote:
> > >One server side control that can be very useful is the ability to search
> by
> > >nick names.
> > >That is, encapsulating the knowledge that:
> > >"William" = "Will" = "Bill" = "Billy" = "Wilberto" = "Willem"
> > >
> > >Than, applications looking for Billy will be able to leverage this
> > centrally
> > >stored functionality and find the person even if his name is actually
> > >William.
> > >
> > >This feature will be highly appreciated by enterprises looking to deploy
> a
> > >meta-directory.
> > >
> > >-Oded
> > >
> > >Oded Ringer 212-902-7939
> > >Goldman, Sachs & Co.
> > >
> > >
> > >
> >
> >
>