> Date: Thu, 10 Mar 2005 16:24:32 -0500
> From: "LeVan,Ralph" <[log in to unmask]>
>
> > zeerex.set exact "info:srw/context-set/1/dc-v1.1"
> > prox/distance=0/unit=element
> > zeerex.index exact "title"
>
> Ick.

How true.

> That is exactly the right way to do it.

Also true. Bad, isn't it? :-)


> The way I typically handle this is to create an artificial index that
> combines the two fields so you could do a search like:
> Ralph.setAndIndex exact "info:srw/context-set/1/dc-v1.1:title"

This is precisely the other approach that Rob and I discussed (except
that the hacky index would of course not be in an "ad-hoc" Ralph set
but profiled in the ZeeRex set.

Our feeling was the same as yours: that the proximity approach is
correct, but that the nasty approach is more likely to actually get
implemented. In fact, you'll see something very similar to this in my
own (unpublished) independent stab at a ZeeRex context set:
        http://explain.z3950.org/search/contextset/2.0/
in which the zeerex.attribute index is described as follows:

        Finds databases which have a map that supports searching with
        the specified attribute. ``Attributes'' in this sense may be
        either index names (for databases supporting SRW/U) or
        attributes in the classic sense (for databases supporting
        Z39.50).

        An attribute in the former, SRW/U sense, is specified by a
        combination of the identifying URL of the context set that
        provides it, and the index-name iself. These two elements are
        glued together into a single search term of the form
        context-set-URI:index-name. Since the context-set URI may
        contain a colon but the index name cannot, servers are advised
        to parse these search-terms backwards, starting at the
        end. For example, info:srw/cql-context-set/1/dc-v1.1:title
        searches for the Dublin Core context set's ``title'' index.

        Attributes in the latter, Z39.50, sense are specified by a
        combination of attribute set, attribute type and attribute
        value. These three elements are glued together into a single
        search term of the form attributeSet:type=value, where the
        attribute set is expressed as in the attributeSet attribute in
        the DTD, the type is a number and the value may be a number or
        a string. For example, BIB-1:1=21 searches for the BIB-1
        attribute set's ``subject'' access point.

I am (and I think Rob is) genuinely torn between the purity of the
proximity model and the pragmatism of the all-in-one-index model.

 _/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Documentation is worth it just to be able to answer all
         your mail with 'RTFM'" -- Alan Cox.

--
Listen to free demos of soundtrack music for film, TV and radio
        http://www.pipedreaming.org.uk/soundtrack/