Deploying Virtual Libraries

Z39.50 is becoming used increasingly to access multiple resources, for distributed (or cross-database) searching. This will be one of the focus topics for the next ZIG meeting.

Z39.50 offers a richer level service but requires a higher level of user-knowledge, in contrast to most web search interfaces, that are easy to use but not very useful. In the trade-off between simple-but-dumb vs. complex-but-useful, "simple" seems to be winning, which is unfortunate because users aren't getting very useful results, though apparently they think they are. Part of the problem Z39.50 faces is to simply make the world aware that meaningful search results are actually possible. Joe Zeeman observed: Z39.50 is usually a hard-sell, but customers usually end-up very surprised when they eventually understand its capabilities, for example, scan an index, sort a result set, retrieve a record according to a specified format and element set, export or order an item, etc.

But the people who are in a position to address this problem, for the most part, don't come to ZIG meeting, for example, Abstracting and Indexing people. So there is a question of what is the best forum for this sort of discussion, or, what can we do about the ZIG process to make these discussions more meaningful? More on this later in the meeting.

Information providers seem to be able, if they want, to come up with an excuse not to use Z39.50 - clients, in general, do not implement many of the Z39.50 features that are intended to support semantic interoperability.

A related issue (related to semantics): though Z39.50 provides the potential for wide semantic-interoperability, the opportunity isn't always exploited, perhaps because Z39.50 isn't an easy read, and neither are the profiles. (Later in the meeting the subject of re-writing the Z39.50 service definition is discussed.) On the other hand consider the two recent profiles, Bath and Holdings (actually, the latter is technically a schema, not a profile); both are inherently important in their own right, but both have perhaps gotten even more attention because of the high level of semantic exposition - both are very readable and informative documents that might be read even by people not necessarily planning to implement them. This is an important lesson for the Z39.50 community - we should be producing more readable and informative documents.

During the discussion of Interlibrary Loan, Barbara observed that much of the benefit of the ILL protocol is lost when you can't first locate the item via Z39.50. Joe observed that ILL today perhaps should be modeled as a business-to-business protocol for e-commerce; the ILL protocol models it for a manual world.

There was discussion of Explain (somewhat of a digression). Ole Husby expressed concern about "trust" - whether the information provided by Explain is reliable. Information changes all the time. In order for an Explain server to maintain reasonably current, comprehensive, and reliable information, it needs to deploy a robot to constantly access the servers that it is "explaining", trying all possible combinations. (Index has a robot that looks at Z39.50 servers.) Slavko raised the issue of directories; the result of that discussion was this: before we talk about how to provide directory services, we need to determine what problem we're trying to solve; what are the directory service requirements? More generally, we need to re-assess what is the information about a server that we really need, that should be supported by Explain. We're going to try to focus on this question at the next meeting.

Future of Z39.50

This session began with a continuation of the earlier discussion, as several points had been made that have a direct bearing on Z39.50's future.

Z39.50 can be viewed abstractly as three levels: model, semantics, and mechanics. Actually, there are two models: a topological model and data model. So perhaps four levels:

• Topological model: Z39.50 is modeled as a client/server protocol, but this model was developed before the importance of distributed searching was recognized. The question was raised whether the "intermediary" or "middleware" should be explicitly introduced into the model.
• Data model: Z39.50 is record-oriented - the basic unit of information is a database record. (This assertion needs some qualification: for searching, the basic unit of information is a record, and for retrieval, from the protocol viewpoint the basic unit of information is also the record, but it is possible to explicitly retrieve elements of records.) This model is compared to both the relational model and the directed graph model (e.g. for RDF, where the universe of information is a single XML document). Z39.50 is not well-suited for these latter two models, but does this mean that the data model should change? Or is the record model still important enough that Z39.50 can continue to limit itself to that model and remain useful?
• Semantics: The ZIG feels that however these other areas are resolved, the semantics of Z39.50 are its greatest strength and should be preserved. Semantics, in this contexts, essentially encompasses a service definition.
• Mechanics: This refers to abstract and concrete syntax as well as mappings.

There is growing sentiment within the ZIG that the models (topological and data models) together with the semantics/service definition -- should be de-coupled from mechanics - syntax and underlying protocol. Thus, open for discussion are the possibilities of rendering the Z39.50 protocol for instance into XML rather than ASN.1, and mapping, for instance, to the SOAP protocol rather than to TCP.

The challenge to the Z39.50 community is (as Pat expressed it) to keep what has made Z39.50 successful, while expanding it to the rest of the world.

One thing we need to do is to get the right people involved in these sort of discussions. Some of the key people who have participated in discussions over the ZIG list, during the past five+ months since the last meeting, aren't at this meeting. What can we do to make these meetings more productive, and more interesting so that critical participants will be more likely to attend? The first step is to begin to plan for the next meeting, as soon as possible after this meeting, rather than wait until two months before the meeting as we've done in the past. The next meeting should have a more concrete program. I'll begin serious planning sometime in the month or two following this meeting, including sending explicit invitations to potential key participants.

Maintenance Revision

See http://www.loc.gov/z3950/agency/zig/meetings/leuven/future.html. The proposed plan for the Mantenance revision was largely endorsed by the ZIG, with a few comments:

• Clarify why attribute sets EXP and EXT are to be retained in the published text.
• Sebastian suggested that the cross domain set should be included. This raised discussion of whether the Utility set should also be included (it's more stable than the cross domain set). The conclusion was that both should be lumped together with the attribute architecture, which is to be included as a non-normative appendix.
• An additional non-normative appendix would be useful, 10-20 pages that explains Z39.50.
• The Foreword should describe "what problem the standard tries to solve". Pat and Joe will help with this.
• (This item came out of the plenary discussion of one of the proposed clarifications.) Prose should added to clarify the relationship of Z39.50 and OSI, that is, that there is no longer any relationship. This clarification is necessary because Z39.50 was originally developed as an OSI protocol, and is still perceived as such by some people.

Plenary Meeting

The following are all approved:

• Proposed new dianostics.
• Proposed new record syntax for Hungarian Marc.
• Commentary about Sort.
• Commentary about Addinfo.
• Clarification about Attribute set in scan response.
• Clarification about Use attribute Any.
• Clarification about Result Count.
• Clarification about Record Syntax.
• Clarification about Presentation Context. However this clarification won't be incorporated into the revision, because the OSI language will be removed making this a moot point. Instead, the previous clarification (about Record Syntax) will be incorporated in lieu of "the standard does not prescribe target action".
• Proposed amendment to Unit definition. The was a question whether the new version includes the Euro.

Record Source Schema

This was essentially approved, however one fairly important change was agreed-upon. Instead of prescribing a Z39.50 url, the schema will prescribe "url", and will note that multiple occurences are allowed. Thus a server might not be able to provide a Z39.50 url but can provide a url of a different type, or might provide a Z39.50 url as well as one or more urls of a different type.

Also, in the "Limitation" section, where it says "This schema assumes that all source records have an identifier that may be used in the construction of the Z39.50r url", this will be re-worded, something like: "This schema assumes that it is possible to create a url that uniquely identifies a given record.....".

Cryptography

Poul Henrik will write up the ZIG understanding of the cryptograpy issue.

XML Query

There is still interest and curiosity over the relationship between Z39.50 and the XML Query. Specifically, would it make sense (and be useful) to incorporate it as a Z39.50 query type? There is some thinking that this could potentially both makes sense and be useful: there is no "protocol" to wrap around the XML Query, so Z39.50 could be useful to XQL, and having XQL as a Z39.50 query type could prove useful to the Z39.50 community. But in order for this to make sense, the data model for XQL has to be compatible with that of Z39.50. It's not at all clear what this implies, but at the least, the result set model has to be incorporated.

We will write a letter to the chair of the W3C XQL Working Group (Paul Cotton), perhaps inviting him to the next ZIG meeting.

W3C Liaison Activity

The XQL matter is one of perhaps several areas of interest to the ZIG, and it may be useful to establish liaison relationships. Until now, LC, DRA, OCLC, and CNI were the known organizations attending ZIG meetings that are W3C members. However it was noted that the following organizations (some of who also attend ZIG meetings, or have attended in the past)) are also members: Silverplatter, DBC, Fretwell Downing, CNRI, EBSCO, and Lucent (any others?). Ray will look into contacting these organizations.

GRX and eSpec-x

We will look into developing a general XML schema that parallels GRS-1, and a complementary element specification definition, eSpec-x.

Future Meetings

The next meeting will be December 6-8 (Wednesday through Friday) in Washington DC (at LC). The meeting following DC will be May 2001, in the UK, hosted by UKOLN, tentatively at Bath (though possibly in London, instead). The meeting following that is tentatively planned for Rome (Fall 2001) but this is not confirmed, and if we don't confirm this soon, we will schedule a US meeting for Fall 2001, and see about Rome for Spring 2002.

Planning for December 2000 Meeting

For the next meeting (December 2000, DC) we're going to start planning soon, and not wait until two months before the meeting. There will be special "focus" sessions, and invitations will be sent to specific targeted individuals, some of who have come to ZIG meetings before but haven't come to recent meeting, and others who may not have come to any ZIG meetings yet but whose presence could be useful. Tentative "focus" sessions will be:

• Distributed Searching (or "broadcast" or "cross database" searching) and specifically, integrating results. Perhaps demos may be set up. Chair: Sebastian.
• Explain. Sebastian suggests that there needs to be face-to-face discussion of what information Explain really needs to provide. Pat suggests that we need to discuss, up front, what problem Explain is intended to solve. (Note: the "server list" project will be deferred until we have results from this discussion.) Chair: ?
• Digital Libraries and Z39.50. Chairs: Mark Needleman and Mathew Dovey.
• Virtual Libraries (virtual union catalogues, circulation, ILL, etc.). Chair: Pat Stevens.
• XML Query Language. Chair: Mark N.
• Z39.50 url. Does it need to be revised/re-defined? What function should it serve? Chair: ?

Planning for the Bath Meeting

For the Bath meeting, we should think about a focus session on Extended Services.

More about Z39.50 Future

There was discussion about re-writing the Z39.50 Service Definition. Though the possible benefits are potentially significant, this is a serious step; it would require substantial effort and should not be undertaken without careful planning.

One big problem with the current definition is that the separation of Search and Retrieval (abstract access points vs. elements), though a good thing and one of the strengths of Z39.50, simply isn't adequately exposed in the text. This isn't likely something that can simply be "fixed". It would likely require a complete rewrite.

Another problem is the "record orientation". Though it isn't necessarily suggested that this change (this is discussed above) a more flexible approach to record structure would help. One suggestion (from Joe Zeeman) is to talk about "documents" not "records".

Possibly a "reference model" should be developed.

Bib-2 Attribute Set

Report from Barbara Shuh

Much of the meeting concerned editorial suggestions for the re-working of the bib-2 document. And several tasks were assigned during the meeting: The following ZIG participants volunteered to co-ordinate the review of the Bib-2 Content Authorities lists within their organization or country or area of expertise:

• British Library (Kevin Gladwell)
• Nordic Libraries (Ole Hussey)
• OCLC (Pat Stephens)
• DRA (Mark)
• Music requirements (Matthew Dovey)

Mark Needleman agreed to review the attribute sets in relationship to the Utility Attribute Set and Cross Domain Set to determine what needs to be pruned from Bib-2 set. Joe Zeeman is to review the division between semantic and functional qualifiers.

Some participants in the Bib-2 discussion found that the information in the current draft was fractured and suggested that all information on each attribute be brought together in one place. It was agreed that the coverage for each attribute begins on a new page, and include an example of the term as well as identify the semantic qualifiers and functional qualifiers appropriate for use with the attribute. Listings for attributes which are referenced from another attribute set should be separated from those that are defined in the Bib-2 attribute set.

It was also suggested that to help clarify the function of this document, it should include examples of how the attribute set works.

A discussion on how to support an Authorities Search is still pending. Work done on the Thesaurus Profile is to be considered in this discussion.

Some in the group felt that, although an interesting intellectual exercise, it was questionable whether this aspect of the "new" attribute architecture would ever be implemented. It was agreed that this question should be explored further in a broader forum (through the ZIG list or at the next ZIG meeting.)