- From: Ashley Sanders <zzaascs@irwell.mimas.ac.uk>
- Date: Tue, 8 Jul 2003 12:27:43 +0100
- To: ZIG <www-zig@w3.org>
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