It is often said in Computing circles that the Web changes everything and although a truism it is true. It has affected computing profoundly, in all aspects of software, in the languages we use, in user interface and even in hardware, by making some devices mass-market consumer items and altering their cost so dramatically. Because of this it has affected OPACs and OPAC design issues. And I'd be happy to admit that not all the changes may be positive ones but we have to live with those changes we can't ignore them.

It's certainly changed the OPAC work we have been doing in Bradford. As a sort of historical aside I'd like to show an input screen or user form from part of our original BOPAC project.

This was a small PC based demo that consciously used the look and feel of Windows applications. Hence we had a fill in form that would look like that of many applications and would also reflect how the final records were presented. Moving to a Web based application we lost a lot of that control in favour of a 'standard' Web form look.

The Web also changed the emphasis given by library systems suppliers in favour of developing Web front ends as opposed to Z39.50 development. The rise of one de facto standard meant the fall of a real one.

The Web meant the increase in general purpose software. It vastly increased the audience for computer systems of all sorts and with this came the rise of the search engine as a query system. Hence referring back to the clip art of the previous lecture. The computer of the OPAC is the same as the computer of the writing system, is the computer of the game player…. The days of the specialised system have gone; it often costs more to get dumb terminals than to get cheap PCs to display your OPAC

BOPAC was a project funded by the British Library, work continues in a small way on it, and we are looking for more development in the future. Because of the limited resources at our disposal it doesn’t do everything we want, and there are certainly areas of the guidelines that I agree with that I have to admit we don’t implement. An example is the material covered in Principle 30 on Diacritics; Non -Roman scripts etc although one of our reasons for using Java was the potential for such support.

At present record display is in two versions the normal tagged one and a MARC display, (not ISBD) although we want to add a number of display options, including the ability to produce displays in standard reference formats, this would enable cutting and pasting directly into bibliographies.

We were also limited in being forced to concentrate on the display of records retrieved via Z39.50. We used the excellent existing Z39.50 toolkit from the Europagate Project (from Index Data). This meant that for example the query forms are based on that toolkit and are standard web ones. We would hope to be able to replace these with something more on the lines of the previous BOPAC system. This would give us back more control over the look and feel and the break between the parts of the system was an area that user feedback suggested needed improvement.

What we wanted to do was create a system that exploited the undoubted wealth of information that is present in catalogue records. The system is based on organising displays around manifestations of a work. And here there is a debt to the work of Martha Yee, Barbara Tillett and Sherry Velluchi. The work on bibliographic relationships, pioneered by Tillett and taken up by Velluchi and used in part in the Guidelines by Yee also remains an area for development of BOPAC particularly because that relationship information is not always present. Or not present in a uniform or usable way in MARC records. One aim would be to avoid the non-informative sort of display that can be seen in this screenshot of Chemical Engineering titles.

I'd like to illustrate a number of points of the work we have been doing in particular and in general what you can do on the web by using BOPAC. BOPAC isn't the only system doing something innovative and I wanted to point to another innovative use of Java in the Willow project at Washington but I discovered in checking on that before coming to Oslo that work there seems to have been abandoned in favour of a plain Web interface. BOPAC can be tried by anyone with a Java enabled web browser at http://www.comp.brad.ac.uk/research/database/bopac2.html. (At the talk I did an author contains 'Kipling' query on a number of UK University libraries. A fairly random example since I didn’t know which servers would be reachable.) I hope BOPAC illustrates a number of features such as

• The ability to group retrievals into manifestations of a work.
• The usefulness of displaying what was matched in a search
• The ability to sort and select those retrievals by a number of criteria including format, subject, author, title.
• The ease with which records can be selected for detailed examination.
• The power of a free text search through the records.
• The ease of moving between display formats.

What we don't as yet do (and is an area untouched by the OPAC Guidelines) is deal with moving on, from a record of an item, to the item itself.

Back to the Guidelines, the 8^th of the recommendations say that displays should look the same no matter how the user accesses the system. This seems to me to miss one of the fundamental points about the web. The look of systems is not controllable in the way that other computer systems are, cascading style sheets or not. Even Java, which we use, is implemented using the AWT, an abstract notion that is instantiated by the native controls of each machine. Users can set preferences you can't override or you do so at your peril. The look of a system is more a function of the browser. This leads to the importance of the search engine. We now have a 'standard' interface to a query system that is known by a very large number of users who will probably bring their expectations of it to any other query system such as an OPAC on the Web. The pernicious influence of the search engine can be seen on Web OPACs that retrieve 11 hits and insist on showing them as a page of 10 and then a page of one. Why follow the split that search engines use especially when the search engine interface is usually driven by the desire to show adverts and keep users on their 'portal', the 'dwell time' or 'holding eyeballs' as it is known.

One thing I haven't covered but may be very important is wireless application. Not only may users be reaching OPACs via the Web but also via devices like mobile phones where screen space is more restricted that on a dumb terminal and the temptation to truncation (referring back to the previous discussion of headings) may be even stronger.

What future is there for MARC itself, might it be replaced by XML? If XML is to become a standard data interchange format with specialised Markup Languages (and some heavyweight players believe this is the case) such as ChemML and MathML then why not BibML that can accept an XML record. It may display it in one of many different formats depending on the user's preferences. This might be as ISBD, as Harvard style reference, Amer. Psych. Assoc. style. This is not to say that we need abandon AACR or any other cataloging rules, the structure of the XML record may still be given by that set of rules but the record does not need to be carried in the form of a MARC record. The cataloging function can be freed from the MARC format.