LISTSERV mailing list manager LISTSERV 16.0

Help for ZNG Archives


ZNG Archives

ZNG Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ZNG Home

ZNG Home

ZNG  December 2004

ZNG December 2004

Subject:

Re: Adlib Base profile

From:

Mike Taylor <[log in to unmask]>

Reply-To:

Z39.50 Next-Generation Initiative

Date:

Thu, 16 Dec 2004 00:02:41 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (68 lines)

> Date: Wed, 15 Dec 2004 23:15:31 +0000
> From: Dr Robert Sanderson <[log in to unmask]>
>
> >> I think that's exactly what cql.anywhere means.  Search all
> >> indexes that you know about, but you can't be expected to search
> >> indexes that you don't
> >
> > Well, I will leave it to the profile author to say whether that
> > was what he meant.  I read the Adlib-specific definition to mean
> > that they wanted "anywhere" to mean "in any of the Adlib access
> > points only".
>
> Then I would suggest:
>
> adlib.anywhere   Search in any of the indexes defined in the adlib context
>                   set.

Sounds right to me -- if that's what the writer did mean.

> > For Adlib, there _is_ an implementation difference between (the
> > putative) cql.record access point on cql.anywhere. in that the latter
> > makes use of all the indexes that are to hand, but the former makes a
> > physical scan of all records, so it can even find the term in fields
> > that are not indexed.  As I implied, not every server will implement
> > this (which is fine) but it does seem like a useful distinction for
> > those that do.
>
> cql.anyField ?  I don't like cql.record as a name, as to me that would
> imply that a string search should be matched against the entire record,
> rather than any subfield within the record.

Agreed -- your name is better,

> Also, if the text isn't indexed at all, how do you determine where to
> start matching and where to end?

I don't understand.  Whatever you might otherwise have done at
indexing time, you just do at search time instead.  Run-time
performance will suffer, but the pay-off is of course smaller index
files.

> >>> This is _not_ what "=" means in CQL.  It means that the term is
> >>> word-structured, irrespective of the index being searched, unless
> >>> overridden by a relation modifier.
> >>
> >> I disagree, Mike.  It means, currently, exact equality, but does not
> >> say how equality is to be determined.
> >
> > Au contraire.  This is precisely the difference between "=" and
> > "exact".
>
> =/cql.number  must surely mean exact numeric equality?

Er.

Oh, look!  A badger!

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "When you are young, you enjoy a sustained illusion that
         sooner or later something marvelous is going to happen [...]
         But it isn't like that at all.  But if it isn't, where did
         the idea come from?" -- Brian Aldiss, _Helliconia Summer_

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Error during command authentication.

Error - unable to initiate communication with LISTSERV (errno=111). The server is probably not started.

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager