Deploying Virtual LibrariesPat Stevens (OCLC) chaired the session "Deploying virtual libraries: Z39.50, Circulation, and ILL protocols -- Their interaction and their future". Following summarizes the observations and discussions from that session.
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:
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.
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:
The following are all approved:
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.....".
Poul Henrik will write up the ZIG understanding of the cryptograpy issue.
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.
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:
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
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:
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.)