Bath Profile – 4 years on

1. Bath Profile – 4 years on A perspective of Z39.50 and the Bath Profile from a commercial systems provider. 8th July 2003

2. Contents • Background and drivers • Technical factors • Development factors • Customer factors • Bath is a “good thing” • Profiles, Profiles everywhere • Stability • Conclusions

3. Background and drivers • UK public sector has more or less accomplished internet networking in the last 2 – 3 years. Examples: • People’s Network • local authority services going on line • central government going on line • UK government has established: • E-GIF – Government Interoperability Framework • eGMS – Government Metadata Standards • UK Government strongly promotes “join-up” of services • These are drivers behind public sector spending

4. Technical factors • There is a bombardment of standards and specifications in all areas: • Z39.50, ISO-ILL, XML, SIP2, NCIP, DC, OAI, EAD, ISAD(G), SPECTRUM, etc etc etc • Until recently Z39.50 has been more or less unknown to the public sector: • Few projects – eg, CoEast • Not easy to explain to non-technical staff • Not easy to explain to IT networking and security staff

5. Development factors • Z39.50 commands a relatively small percentage of corporate product scope. • More or less everything in the library has standards involved. Most have a higher exposure to staff and public than Z39.50: • Cataloguing, circulation, peripherals, barcodes, e-commerce, web, RFID, etc etc • Z39.50 receives a proportional degree of development effort in the corporate portfolio.

6. Customer factors • Z39.50 in the public sector is driven by: • Authorities/organisations who are undertaking cross-domain portal products to serve their communities • Often, Z39.50 is one of several protocols being used • Increased use of interlending models using virtual catalogues • Indirectly driven by increased demand for real-time information

7. Customer factors • Applying profiles often has logistic issues: • Public facing search systems are often simpler in design for users, but frequently include more complex functionality than provided by Z servers: • fewer search criteria, • sorted data, • term processing – synonyms, stemming, thesauri • The data can often be “awful” from a standards perspective with little scope for improvement • The data is sometimes created with a view that only staff would ever use it

8. Bath is a “good thing”… • Z39.50 is complex and needs initiatives like Bath to set a common basis • “Surely Z39.50 is Z39.50 is Z39.50…..” • Bath gives an opportunity for scope of specification in procurement exercises • Bath gives implementers a practical scope of implementation… • …. possibly too complicated.

9. All those profiles… • ONE profile (1997) • Models profile family (1997) • CENL profile (1998) • Z-texas profile rel.1, rel.2, (2000) • CCF profile (2000) • ONE-2 profile (2001)

10. … not to mention • Specialised profiles for extended services • Other national profiles (Norway, Denmark, Finland etc.) • Profiles for specific sectors: • Museums, digital collections, thesauri, cultural heritage, geospatial etc.

11. … and… • Bath Profile first draft (1999) • Second draft (2000) • Version 1.1 (2001) • Version 2 (2003) • In essence – way too many ?

12. Take-up and Stability • Take-up of the Bath profile is relatively disappointing • From my perspective: • Are implementers seeing the moving goalposts and waiting for stability ? • Currently waiting over 3 and a half years ! • Procurement exercises often just cite “Bath profile” and leave room for manoeuvre • Do suppliers lose business on grounds of lower specification Z39.50 support ?

13. Practicality example • A recent search of the library systems in the London boroughs exposed many issues where Bath compliance would be difficult: • Different cataloguing practice • Records inherited from previous systems • Indexes mapping to unexpected fields • Little scope for improvement without costs

14. Practicality – cross searching • Cross Domain searching (area c) potentially imposes difficulties to the type of data that is there: • Eg, many databases are provided in small relational databases where it is not possible to cite “do not truncate” as per the profile. • Some data does not have the relevant data elements to search on.

15. Practicality – issues • Profile could be improved in terms of practical application specific factors; eg: • Operators/operands • Record content • Recognition of XML schemas • Start with realistic specifications

16. Conclusions • Some parts of the profile may be beyond the practicalities of implementations – where the cost of conformance is difficult to justify • Customers often find it difficult to see what its all about ! • Quite often the fact that their data is on line at all is a major achievement

17. Conclusions • Stability is key to take up • Cross-search systems are increasingly searching Z39.50 and non-Z39.50 systems: • Introduction of new standards (eg OAI) • Proprietary Web services • Lower common denominators • The search and retrieval part is just a part of the application – other parts of products are equally as important • The Google factor