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  May 2002

ZNG May 2002

Subject:

Re: Betr.: revised Bath/CQL searches

From:

Theo van Veen <[log in to unmask]>

Reply-To:

Z39.50 Next-Generation Initiative

Date:

Wed, 22 May 2002 11:36:10 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (94 lines)

Let me put it completely differently.

First - correct my when I'm wrong - the use of a Bath profile was in my opinion to get clients and servers  supporting the same queries to establish interoperability. In my personal view the need for such a profile  comes from the lack of Z39.50 to deal with differences in general between servers and/or clients. With SRU/SRW we now have an opprtunity to get this right

Second. In the SRU/SRW discussions Z39.50 and what SOAP toolkits can or cannot do play a role. In my personal view this shouldn't be the case. It is the implementors responsibility to map SRW against existing Z39.50 implementations, but existing Z39.50 implementations should not influence (better) choices for SRW/SRU. In the "new situation" in which SRU/SRW is an accepted potocol there is no need to have a Z39.50 step between SRW/SRU and the server, because SRU/SRW use the native interface to newly developed servers.

Now I come to my prefered approach.
I have a CQL query that is the function f(a,b, ...) on a number of terms. This function may be boolean with proximity etc. Each term is a function g(x) on a single string x. This may be a phrase or a word with truncation and wildcards and other operators to indicate some attributes including the index name. The index name is generally (not always) only related to field in the originating record and does not specify how the field is indexed (although in somes cases it is trivial how a field is indexed). Now there can be an inifinite number of combinations and of course not all servers support all combinations. 
The question is how to deal with the differences in implementations in such a way that it does have a minimal effect on interoperability.  Getting error messages is something I consider the result of a lack of interoperability.

The answer is quite simple: The server decides whether it can handle the query and if not, it provides a response with additional information, that can be used by the client e.g. to improve the query. If we are able in SRU/SRW to come up with a good proposal for how such a response should look like then we can increase interoperability without the need profiles while leaving a lot of flexibilty and freedom at the server. 
The minimum what a server can do is say " no hits I do not support this query". A "better" server would say "no hits I do not support this query but the query that comes most close to what you want is: 'new_query'".  A client that is even more friendly will say I do not support your query but here are the results of the a query that I do support and which will most likely be good enough. 

My proposal sounds silly and  illustrates the big gap between my preferred approach and other approaches but I just give it a try as there might be people that also like this approach.

Theo

>>> [log in to unmask] 22-05-02 03:41 >>>
On Tue, May 21, 2002 at 12:39:49PM +0200, Theo van Veen wrote:
> I am still confused.
> - I remember discussions on the use of quotes but I do not remember
>   decisions  to move CQL towards CCL.

I cannot remember if a "decision" was officially reached or not (to me,
Ray's web pages are the master copy), but I think it was Ralph that
suggested it and I certainly agreed with the idea of "if we have
exactly the same semantics as CCL, and the CCL syntax is fine, why
not use the CCL syntax instead." If there is a good reason not to
use the CCL syntax, I agree completely we should use a different syntax.

> - In CCL I think we have the same problems with respect to  word like
>   "and" and "or".

Yes, absolutely. Ignoring CCL, my point was if "and" and "or" are
reserved words in CQL, then they need to be released somehow. Using
quotes seems a logical solution. Feel free to propose other semantics
for what different punctuation should mean in a CQL query. In fact
I would encourage it! It saves time however if the proposal can be
fairly encompassing. For example 'double-quotes should mean string-attribute'
is not enough. Are "and" and "or" reserved words? If so, how to release
the meaning of reserved words? If its also to use double-quotes, then
I dislike it because it means I can only search for "and" with the
string-attribute specified. (I am using this just as an example.)

> We have the opportunity to make a nice clean start with CQL. Let's
> make use of that. I think that "making things different from CCL" is
> not an issue or an argument in itself, but when we try combine the best
> of all worlds in CQL, there might be arguments to use things from CCL.

I agree completely. I don't want to take CCL verbatim. But if there
are good bits, I agree with Ralph (I think it was Ralph!!) who said
'why not steal CCL syntax where appropriate rather than argue over
whether ':' or '~' or '-' is better to separate the index name from
the term'. I agree with this. Most of the CCL syntax is not horrible,
so to reduce time arguing over which punctuation symbol to use, I am
in favor of stealing syntax from CCL when we like the semantics.
Its also more famililar to people (YAZ has something, OCLC has something,
Z39.58 was noised around a bit, ISO8777 is (was?) a standard, we support
it, etc).

But I agree 100% if we need to do something that CCL does not do, or
if CCL does not do it the way we want, then we don't use that bit of CCL.

> I had hoped on a generic approach with standard index names and
> operations (like truncation, completeness etc.) where all the
> "attribute" variants can be constructed in a logical way instead of
> agreeing on names for each individual "attribute" variant. I favour the
> approach in which the server tries to find the best match between how a
> field is indexed and what variant is asked for.

If you have have a concrete proposal, please make it! Your intensions
sound good, but I have no idea how to implement it. I want a concrete
computer algorithm to turn a CQL query into a RPN query with attribute
lists for sending to a Z39.50 target. If you want a proposal where the
CQL->RPN convertion uses 'best match' rules, then can you please propose
a formal model of the data structures the convertion process needs
and the algorithms for converting a CQL input string into a RPN query
with Z39.50 attribute lists etc using that formal model. Without concrete
proposals we are not going to get anywhere.

I am completely against any proposal that says 'here is the legal
syntax of CQL - a CQL->RPN converter should do whatever is best
to satisfy the users need, where the best way to achive this is up
to the implementor'. Any thing left to a specific implementation is
(in my view) completely counter-productive to any standardisation effort.

Alan
--
Alan Kent (mailto:[log in to unmask], http://www.mds.rmit.edu.au/~ajk/)
Project: TeraText Technical Director, InQuirion Pty Ltd (www.inquirion.com)
Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001.
Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC Australia.
Phone: +61 3 9925 4114  Reception: +61 3 9925 4099  Fax: +61 3 9925 4098

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

July 2017
October 2016
July 2016
August 2014
February 2014
December 2013
November 2013
October 2013
February 2013
January 2013
October 2012
August 2012
April 2012
January 2012
October 2011
May 2011
April 2011
November 2010
October 2010
September 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
October 2009
September 2009
August 2009
July 2009
May 2009
April 2009
March 2009
February 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager