Re: The imprecision of Z39.50

Alan Kent wrote:

> Is "book-case" one word or two?

Tricky. Words joined by a hyphen(s) can have various meanings

o) The term "1-2-3" is a single word with hyphens
   and is the name of a once popular spreedsheet.

o) Generally, two words joined by a hyphen can have three
   meanings. In your example they would be: book-case, book case,
   and bookcase. A user searching for one of those might reasonably
   (or unreasonably, depending on your view) expect to find all three.

I think there is definately room for someone to write profiles
on how the above might be handled -- along with stop words (of which
nowadays there is no need for IMHO :-) and leading articles.

> Rather than only be critical (I am certainly not trying to offend those
> have put lots of time and effort into it), I guess I should present
> something constructive. If I was to design the ideal solution for myself,
> ignoring all other people's requirements, I would start from a definition
> of the basics of how I (and I think most vendors) implement Z39.50.

Why not start by considering what the users want to do? Lets
assume that the Bath Profile defines the sorts of searches that
users actually want to do (whether it does or it doesn't.)

Taking Functional area A level 0 and level 1 from Bath Profile
2.0, we have the follwing types of search:

  1) Keyword
  2) Keyword with right truncation
  3) Exact match
  4) First words in field (also used for standard identifier search)
  5) First characters in field
  X) Date search -- which breaks down into five searches, namely:
     6) Date less than
     7) Date less than or equal
     8) Date equal
     9) Date greater than or equal
     10) Date grater than
    
In all I make that 10 different types of search. Expanding out
into the other functional areas doesn't sem to include many more
types of search. In fact, a quick glance through the profile only
reveals a search called unachored phrase; so I'll have that as
number 11.

So, for my new attribute set and architecture, we'll
just have two types of attribute:

   Type 1: Use or access point. As I'm lazy we'll just import
           all the Bib-1 Use attributes into this.

   Type 2: Search type. Just 11 values defined in this -- the
           search types numbered 1 to 11 above.
           I might also define a twelfth search type: date range.
           In this case the search term will contain a string like:
           1914-1918, or -1400, or 1999-.

There's no need for any other attributes types and such an
attribute set takes nothing away from the Profile as it currently
stands. A z39.50 client designer stands a better chance of
designing a useable user interface around such a set -- far more
so than for Bib-1 and probably infinitely more so than with the
Attribute Architecture.  If the Bath Profile was to define itself
such an attribute set then a target would never be in any confusion
as to what Profile an origin was using.

And while I'm about it, I might want to specify that any search
term that comes with a Use attribute from the above proposed
attribute set must be encoded as UTF-8.

That's not to say there is no place for Bib-1 or the Attribute
Architecture. Some people will always want to do searches not
covered by the above and so they can use Bib-1 or the A. A. or
define their own attribute set.

Hey ho!

Ashley.
-- 
Ashley Sanders                                a.sanders@mcc.ac.uk
COPAC: A public bibliographic database from MIMAS, funded by JISC
             http://copac.ac.uk/ - copac@mimas.ac.uk

Received on Tuesday, 8 July 2003 07:27:44 UTC