Re: centroid propagation

Mark Prior <mrp@itd.adelaide.edu.au> Tue, 19 October 1993 03:13 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18677; 18 Oct 93 23:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18671; 18 Oct 93 23:13 EDT
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa25913; 18 Oct 93 23:13 EDT
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA13552; Mon, 18 Oct 93 18:57:41 PDT
X-Orig-Sender: ietf-wnils-request@ucdavis.edu
Received: from jarrah.itd.adelaide.edu.au by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA11943; Mon, 18 Oct 93 18:21:43 PDT
Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.28) id AA11032; Tue, 19 Oct 1993 09:25:04 +0930
Message-Id: <9310182355.AA11032@jarrah.itd.adelaide.edu.au>
To: kashima@csce.kyushu-u.ac.jp
Cc: ietf-wnils@ucdavis.edu
Subject: Re: centroid propagation
In-Reply-To: Your message of "Tue, 19 Oct 1993 00:40:55 +0900." <9310181540.AA00528@hakozaki.csce.kyushu-u.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Oct 1993 09:25:03 +0930
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Prior <mrp@itd.adelaide.edu.au>

     >  I don't support centroids since it is too difficult to do a complete
     >  implementation when you are constrained by another system that doesn't
     >  map into whois++ cleanly. I would attempt to do a partial

     What type of constraints can be there? I can't image concretely. For
     example?

Well I have another API to deal with and for all whois++ concepts I
must try to translate them into X.500 concepts. Whois++ is designed
with a WAIS style indexing facility in mind but X.500 doesn't provide
access in this way. I must issue typed searches against X.500 so there
is no easy way for me to get at all the possible values of items so
they may be provided to an index server. I also have a system that can
(and does) defend itself from people trying to "trawl" data from it,
so if you send it a whois query like "*" it will return nothing, even
though it has had thousands of matches. You must be must more specific.

As a concrete example here is a whois++ query and it's corresponding
LDAP query (LDAP is used to query the X.500 directory)

whois++:        prior

ldap:           (|
                  (sn=prior)
                  (userid=prior)
                  (l=prior)
                  (ou=prior)
                  (&
                    (cn=prior)
                    (!
                      (objectClass=person)
                    )
                  )
                )

I have reformatted the LDAP query to make it clearer. What this is
saying is find a entry in the X.500 directory that has a surname
component with value "prior" or has a userid with value "prior" or has
a locality with value "prior" or an organisational unit value of
"prior" or has a common name of "prior" as long as the object in
question doesn't have a objectclass that contains the person value.

     >  implementation but unless whois++ supported "maybe" style responses
     >  this would be too confusing for the user.

     Is "maybe style" {vague,fuzzy,...?} searching?

No, I can do fuzzy searching easily enough via a soundex match. What I
am trying to drive at is that I might be able to pseudo index some
parts of my data. This means that if I implemented this and my server
was asked if it supported indexing it would respond "maybe", if it was
asked does it support indexing of surnames it could say "yes" but if
it was asked did it support indexing of personal titles it would say
"no".

Mark.