Ray,
This may be too late for your discussions. However my comments are :
CQL. 1. While I recognise that many SRU/W applications will be
generating the query by software, my principal interest is with queries
entered directly by the user. A main issue is that CQL does not allow
queries to comprise more than one term without the terms being enclosed
in quotes. Using quotes in this way is not familiar to most users. The
manner in which CQL query is parsed should reflect this.
CQL 2. The use of commonly occurring terms "all", "any" etc. to define
operations and indexes is again confusing to most users. Google and MSN
set an example in tokenising the functions by adding a colon at the end
of the word, e.g. site: . I think it would be better is we followed this
example in CQL. I realise that index names are set in Explain so this
can be achieved at present, but I suggest we make it a recommendation.
CQL 3. We have started to create records that contain structure or
contain links to related records, for example a bound volume of
manuscripts containing a manuscript containing an illustration. It is
not clear to me if CQL contains functions which would allow a search to
match attributes in all three objects, for example "bound volume of
manuscripts with provenance x, manuscripts created in the y, with
illustrations containing z". I wonder if implementations of FRBR will
require similar queries against works, expressions and manifestations
and make this a more pressing requirement.
[In general terms I think this means a search must be expressed as
record type X with attribute Y has relation of type Z to record type A
with attribute B.]
CQL 4. I am not sure about the purpose of "level". If some search
services require a simpler language then I think it better to define
that language separate for CQL and offer it as a parameter in the
Explain response. Perhaps this is a way of dealing with my request in
CQL 1.
SORT - OK.
Record Identifier. - OK
NextRecordPosition - No, because it is tedious to find this number using
XSLT and it is easy for the server to add it to the response. (But I
wouldn't die for it :-))
Client and server identifiers. Not sure what this means, but if it means
that a response should include the URL of the server I am strongly for
this as otherwise if copies of a response are moved or processed outside
the context in which they were obtained, there is no way of knowing
where the response came from.
RecordXPath. I am not aware of the proposal.
XCQL Parameter. OK.
---
I hope the Forum is a success. I am sorry I cannot join in this time.
Bill
-----Original Message-----
From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]] On Behalf
Of Ray Denenberg, Library of Congress
Sent: 15 June 2005 18:36
To: [log in to unmask]
Subject: Proposals for next version
Please note that there are proposals on the table for the next version
of
SRW/U/CQL (either 1.2 or 2.0). See
http://www.loc.gov/z3950/agency/zing/srw/next-version.html
These are on the agenda for discussion at the ZING Forum next week in
Chicago.
--Ray
**************************************************************************
Experience the British Library online at www.bl.uk
Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook
**************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the [log in to unmask] : The contents of this e-mail must not be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author.
**************************************************************************
|