|
|
|
Finding consensus in order to improve interoperability; a tale of Z39.50 & profiles
September 20, 2005
Presentation to the GOL Metadata Working Group
Carrol Lunau
Strategic Office
Library and Archives Canada
Agenda
- Context (1995 - 2000)
- What is interoperability?
- Interoperability issues & solutions
- Developing an international profile
- Lessons learned developing an international profile
- Summary: key messages
Context (1995-2000)
ANSI/NISO Z39.50-1995 standard
- First proposed 1984 for use with bibliographic data; holdings not considered bibliographic data
- Versions in 1988, 1992 & 1995
- Developed by technical experts without a lot of input from librarians
- Open to interpretation and choice of options
- Did not originally anticipate simultaneous search of multiple catalogues
Regional networks & virtual catalogues
- Growing number of networks wanting to create "virtual" catalogues rather than traditional union catalogues
- Desire to find "free" MARC records for cataloguing & location information for ILL
Implementations of Z39.50
- Virtually all OPAC vendors claim to have or to be working on implementing Z39.50
- Standalone clients from companies like BookWhere and Endnote
- Gateway software began to appear
- Implementations selected different options & made different interpretations of the standard
User expectations
- RFP's asking for Z39.50
- Expected good interoperability with simultaneous searching of multiple catalogues
- Anticipated direct end-user use of interfaces
User experiences
- Easy to learn but hard to interpret results or figure out if a system was working
- Holdings information lacking or deficient
- Searching difficulties related to the characteristics of the client, the database or the interpretation of attributes
- Lack of confidence in search results resulted in dissatisfaction - result sets too big or did not retrieve records that were in the database
- Systems were not interoperable beyond the technical level
What is interoperability?
- Can be defined in a number of ways either according to the system or to the user
- Ideally should interoperate at the:
- Syntactic level (can exchange information according to the standard)
- Functional level (supports the services the user wants to perform)
- Semantic level (do the systems preserve the meaning of the tasks and carry them out)
- Political level (policies and agreements to support interoperability)
Interoperability issues & solutions
Issue: Technical and standards-related
- Vendors supported different attributes for the same search
- Vendors selected different options
- Vendors interpreted the standard differently
Solution: Profile
- A document that clearly defines a subset of specifications, options and interpretations from one or more standards in order to improve interoperability
- Specified attributes for each search
- Specified options and interpretations
- Removed "wiggle room"
Issue: Semantic differences
- Different indexing practices, different mapping from MARC record to Z39.50 search attributes, record syntaxes, different cataloguing standards and lack of authority files
- Conflict between local practice and requirements to achieve interoperability
Solution: Agreements
- Guidance documents created, such as one for indexing
- Partners may have to agree on desired level of interoperability
- May need to change practices, re-index databases, etc.
Issue: Policy-related
- Different practices re access
- Firewall issues
Solution: Common policies
- Policy changes may result in technical changes to support access
- Agreements related to access
Issue: Knowledge and understanding
- Users had unrealistic expectations
- Developers using same words but mean different things
Solution: Communicate, communicate, communicate
- Profile as communication tool
- Find a champion
- Use appropriate language for the audience
Developing an international profile
Issues
- Identifying experts
- Identifying correct balance
- Funding
- Process - teleconference, listserv discussion, meeting
- Developing consensus
- Ensuring that no national developments were incompatible with the profile
- Finding a responsible body
- Convincing vendors to modify their systems
Lessons learned developing an international profile
Participation
- Have to involve the right people - those who understand the user as well as those with the technical and/or subject expertise
- People writing the documents have to be able to speak for the people they represent
Timing
- Easier to develop the agreements before the systems than after an installed base exists
- Takes significant time to develop a standard or profile
- Can be a long time between developing a standard and have a critical mass of installed systems
Process
- Iterative process - agreements and profiles are living documents and will change
- Compromise is essential to get consensus
- Important to have the profile endorsed by a recognized standards body
- Funding is required for face-to-face meetings
- A respected organization needs to be responsible for the standard/profile
Communication
- Need one or more strong, knowledgeable and well-respected champions
- Have to control expectations of what can be accomplished
- Need common recognition of the problem
- Participants on development groups must all speak the same language, e.g., have the same understanding of interoperability, etc.
- Clear, appropriate communications are essential
General
- Users must understand why they want a standard in order to communicate with vendors - what do they want to accomplish by using this standard?
- The most difficult issues were the semantic and policy issues not the technical ones
Summary: key messages
- Think about interoperability before the fact not after
- Involve the right people
- You can never communicate too much
- In the end it is worth the time and effort
|
