ZIG Meeting

  Notes provided primarily by Les Wibberley.

presentation by Bill Moen

Handout on "Moving Towards the Future of Z39.50"

• what is the question, the problem?
• is the a need for a standard networked information retrieval protocol
• what are the requirements
• can the current z protocol address the requirements
• if no, can the z protocol be revised to address the requirements
• what are options for the revision
• who will do the revision and how?
• options for changing z39.50
• revision and  reaffirmation of the standard for  niso five year review
• radical options
• rewrite the protocol from the ground up
• rewrite the protocol as an xml protocol
• somewhat less radical options
• separate the z protocol from its use of ber as a wire protocol
• simplify the protocol specs to focus on core features
• z as a protocol template
• First principles
• simple implementation
• rapid development and implementation
• addressing requirement - scoping
• applications requirements
• functional requirements
• application development requirements
• who does it? the ZIG or..?
• where is the mandate for change
• from whom does the mandate come
• who will carry out the mandate
• in what forums will the work get done
• need:
• decisions
• deadlines
• deliverables

Discussion
Led by Pat Stevens

• The first question is really two questions
• need for IR standard vs interoperable protocol
• First set of questions
• Is there a problem?
• Are we happy with the status quo?
• Should we prepare to fold our tents and wait for the next great thing?
• Mark: if we stay with status quo, will fall further behind.
• Yes, there is a huge problem.  We have some interoperability, not enough. We want international interoperability for several services, more than what the web can provide.
• Sebastian: yes there is a problem, but not one addressed by this discussion, not yet on this agenda.  Changing z39.50 into an xml protocol only addresses one aspect.  Different problems for the users.  Information providers guard their interfaces as well as their services.
• Poul Henrik - disagreed about guarding interfaces, and fully support interoperability
• Lennie - happy with status quo, continuing to use z more and more, but many resources not available via Z.  Lots of info providers that are interested in providing info.
• Joe - in past environment, search engines have seen us as irrelevant, but with rise of enterprise and corporate portals, the business rationale of search engines will change to provide corporate value added services.
• Mike: IR is not one community, and needs vary widely across companies.
• who are our users/customers/communities?
• who do we want to serve?
• who wants us to serve them?
• libraries is one of the major communities served by z39.50
• there has been an ongoing effort to broaden the scope
• who are the other communities of interest
• libraries
• archives
• museums
• online information search and retrieval companies (e.g., dialog, lexis-nexis, cas, etc.)
• corporate information centers (e.g., lucent)
• kevin: use it for distributed searching of metadata to find low level databases to get to in-depth searching
• scientific communities - producing scientific information for sharing
• matthew: people building online learning environments and tools
• the government - provide access to government information
• who are we not interested in serving?
• in the 90s, the attitude was to allow/encourage its use beyond just the library community.
• Ray: perhaps specifying that full-text is outside of the scope of the standard.
• Bill: more useful to define scope of applications.
• Then what applications is z39.50 not a good match for?
• maybe web search engines fall into that category
• Joe: the protocol to  date hasn't met their economic model, but this may be changing.
• Ralph: our strengths are in searching structured text
• Elliot: until recently search engines couldn't use what we do.  Not much trustable metadata.  search engines are sold as intranet search engines.  Are interested in getting there, tools must be made in good form. Changes are underway in this area, and opportunities are arising
• libraries need to support wide range of users; lots of users want to do dumb keyword searches across multiple databases.
• by putting the functionality in the right form (push down the complexity), the standard could be very widely applicable
• Bob: z39.50 has two reasons it developed as it did: (1) for internal use (lucent, cas, biological communities, within communities need to interoperate); (2) across communities
• who are we - the ZIG community
• we are both users and developers
• competing interests: offer products for sale, and consume those products; different interests
• what are our competencies as a community
• Bob: business issues are very different from technical issues
• the standard provides most of the functionality for most of those communities
• so what is the problem
• why isn't z39.50 achieving its potential
• Ray: Z is not a web-friendly protocol
• burden to new implementors is high, relative to competing technologies
• Ralph:  problem is that we are wedded to a single protocol on the wire, and requiring byte-compatibility
• Mark: up until now, economic models for using Z.39.50 haven't generally been there
• Are we trying to support a very broad range of searching across disciplines
• Ralph: there are lots of folks with info retrieval problems which we have solutions for.
• we have a framework for solving a wide range of problems
• Lennie: need to address all the Z issues to solve a general IR  problem
• we need to make our solution clear, straightforward
• and how to make the implementation reasonable
• Joe: protocol started out not being tied to the wire protocol, but implementors have stuck with that assumption
• this is an application protocol, and this is its value.
• note: ldap is BER-encoded over tcp/ip, and no one worries about that
• Difficulty of understanding and learning the protocol, as a new implementor
• modern programmers don't care about the protocols
• they use the API to get to the functionality they need
• Ralph: disagrees that a single API solves all needs.  Need multiple APIs
• KEvin: we've been saying this for years.  We have produced tools, so what is the problem?
• issue of how to do this within the relevant environments
• Joe: definition of functionality was not constrained by ease of implementation
• Sebastian: teaches z39.50 without ever mentioning BER, and they go right to programming
• It is misrepresented
• lack of APIs is an issues
• BER itself is pretty opaque, and hard to get the resources to use them
• If there had been the right interfaces available, and provided, this would not have been a problem
• Matthew has funding to develop a Z Java Bean
• But still need to capture the semantics for it, as well
• Two classes of problems: the standard itself is hard to understand, and hard to implement.
• need to create clear information about what z39.50 can provide - high level
• provide a protocol package in the right form  for implementation of applications and tools
• remaining complexity which makes up the standards strength still need to be addressed
• Bob: also, accommodate the environments of the customers/users
• including the desktop environments, the internet, the firewalls, the server environments, the security aspects, etc.
• e.g., opening a non-http port on the firewall for z39.50
• Also a PR problem: it does not have the right image
• Janifer: Another class of problem: content of the standard.  The functionality itself
• clearly identify the core vs advanced functionality
• another class of problem is interoperability
• profiles are a key tool to improve interoperability
• Dave Vieglais:  several levels of interoperability: within the community, across communities, across technologies
• Bill Moen: testbed project is mapping out these various aspects of interoperability- paper forthcoming
• How do we broaden usage? - Solutions
• by whom?
• for whom?
• how can we make it easier for application developers who don't want to worry about network protocols
• lets do a java bean for z39.50
• Ray: on solutions from LC perspective, as a user of z39.50
• please send reports to Ray; important to document all this discussion
• maintenance agency perspective - very valuable discussion, but maybe ZIG is not the body to solve these issues
• LC perspective
• perhaps form some sort of coalition as suggested yesterday
• not interested in junking the standard and starting over
• Ray prepared to gather folks to pursue that approach
• approach would be to pursue the Poul, Henrick, Matthew, Elliot, combined with John, Kevin approach
• need folks who can commit resources, more than just showing up at a meeting now and then; need to contribute
• Matthew approach
• try to use asn.1 as semantics
• and bind that to other protocols
• Ray:  use SOAP, XML, XER and RFC822 ideas, and get rid of ASN.1/BER completely
• Nature of this proposal is to separate what the standard does from how it is carried
• Elliot: establish a testbed to try things out, and see what works
• Ray: focus this at a particular approach
• We need to think about how to bring these experiences/experiments back together to reunify
• Other groups may be formed to pursue other approaches, and explore them
• How to resolve various approaches: Ray, Ralph: let the marketplace decide
• Summary
• major reorganization issues about how to do this
• what does it mean to bring this back to the ZIG?
• ZIG is no longer a coherent body, nor a natural authority to support protocol development
• Is there an authority within which to operate to result in approving the results
• Not clear whether any of this will result in a new version of Z39.50
• It is clear there is interest in working on separation of Z application functionality from the transport mechanism carrying it
• any groups going out and experimenting these approaches must be careful about implementing production and calling it Z39.50