Washington DC
St-Gelais provided an overview of the proposal, which was based on two major observations from previous discussions: first, that the proposal should be aligned with the existing vocabulary and standards (a combination of ISO 10324 and NISO Z39.71); second, that it should establish a model of how different organizations handle holdings. The current proposal does NOT discuss electronic holdings (where the items themselves are electronic), but instead focuses on physical holdings. Plans for handling electronic holdings is future work, to be conducted after the current issues related to physical holdings are settled.
The proposal defines important bibliographic item terms used in the document, different views of holdings (bibliographical- or item-level holdings and piece-level holdings for items grouped together), and the elements of the schema, with mapping to US MARC fields and subfields (extracted from the US MARC for holdings document, though not an identical replica). Section 4 of the proposal includes examples of the different reporting levels.
The first section of the proposal covers the model of a bibliographic item, including definitions. A bibliographic item may have one or more units. Each bib unit can be a single- or multi-part unit. The bibliographic-level view of holdings is the view of the publisher, the original or intellectual view of the holdings. The piece-level view of holdings is the institution's physical reorganization or regrouping of original holdings (the circulation view).
Clarification of the model (Hinnebusch and Zeeman): Hinnebusch wondered why there are two views of holdings. He gave an example of two novels bound together: two bib items in one physical piece, in which case the circulation software must know that the two items are bound and circulate together. St-Gelais on piece-level holdings: 90% of the time the item is the piece, but when you bind things together you need an extra level. Agreed. But is the extra level subordinate to the bibliographic item? St-Gelais: yes. Zeeman: it doesn't matter whether it's bound with another item. Hinnebusch: is a "piece" a physical thing? Stovel: these are cataloging decisions made at the local institution level; this discussion is not relevant here. Agreed to add a comment to the discussion of the model in the proposal to clarify bib-level and piece-level holdings.
The second section of the proposal discusses reporting levels existing in ISO 10324 and NISO Z39.71 holdings standards. St-Gelais: if you don't have the level of detail requested, always provide as much as you have, but do NOT exceed the level of what is requested. Hinnebusch: this point may require further discussion in cases where reducing the level of detail is lots of work. Van Lierop: are bib-level holdings for cataloging and acquisitions and piece-level holdings for circulation? St-Gelais: yes. It is up to the client application to determine at which level to start. (Probably P1, as referenced in the document.)
Zeeman: a level of abstraction is missing in the model, which is a way to distinguish between "just return institution code" and "return institution code and call number." St-Gelais: yes, where is location within institution or location on the shelf? She does not object to adding another level especially since ISO and NISO treat call number as optional. It could help us to have another level in location in the record schema -- split location into physical site (institution) and physical location within the site. Return one thing for all copies at an institution, not one thing for each copy at an institution.
Appendices A and B indicate the structure of each holding statement. These will be revised if we add another level of abstraction.
There was a question of whether lending and reproduction policies apply to bibliographical units or physical pieces (Randall, Stovel). Most of the time it is at the piece level, but sometimes it is not. For example, bound journals circulate but unbound issues do not. Someone recommended keeping lending and reproduction policies at least optional at the bib level, but maybe making them mandatory at the piece level. Stovel was not sure of the relationship between circulation status and lending policy. According to Randall, the MARC holdings record was not designed for circulation information.
Randall was also concerned about the call number being optional. Sometimes holdings don't have a call number, but can we require the call number if it's available? St-Gelais: we can address this when we add the new level of abstraction about location at the site.
Van Lierop: what is an item? Is a gramophone (if it circulates) an item? Hinnebusch, no, it's a piece, but it doesn't matter. Zeeman: the example where the distinction between item and piece matters is if you get a record for more than one item contained in the piece. For example, two novels (bib items) bound in one piece would require only one ILL request to get (both novels in) the piece. Tibbetts: isn't this information available in the piece record? Van Lierop and D Lynch: it is useful for the client (and user) to know that the piece is part of a multi-piece item. The ZIG will ponder this further and decide whether we have the right model by the end of the meeting.
Section 3 of the proposal describes the elements of the schema. Hinnebusch: why is it not mandatory to provide a specific statement for each institution? ZIG discussed it and agreed to make it mandatory (changing the second sentence in the opening paragraph of section 3.3).
Location data codes issues:
Sundstrum: additionalHoldingsInfo should be added to section 3.4 (location report). When there are no holdings, we need a redirect to provide pointers to location. St Gelais will clarify the information that is being modeled. Sundstrum: when you know nothing about holdings, the holdingsFormat parameter choice must be optional.
Hinnebusch surveyed vendors: they support MARC but are using OPAC record for holdings information. Tibbetts: if you prefer MARC holdings, does this belong in the schema or the profile? St Gelais: vendors may use MARC holdings, though she was tempted to remove this from the proposal. Before, holdings could be a mixture of MARC records or circulation records (?). Hinnebusch: vendors were pressured to bring MARC holdings into their systems, but they didn't. Should we remove it from the proposal? Denenberg: it's a profile issue, not a schema issue. Hinnebusch: why write it in and then profile it out? Denenberg: what if the schema is used for other purposes? The issue is whether to even speak of using MARC holdings records as an alternative to the GRS structure. Maybe we should take it out and see who complains. No. Brolin: include the preference for OPAC record but don't take out the MARC holdings. Stovel: elaborate the options in the proposal and explain that the holdings statement schema provides more information than MARC holdings records.
Propose to add a unit identifier. Agreed.
Hinnebusch would like enumeration and chronology to be separated (page 43 in the document). This is done philosophically, but is not reflected in the Table in the proposal document. He proposed that enumeration be a sequence of international string and chronology be a sequence of international string with a rule of moving from highest to lowest level of enumeration and chronology. Agreed.
Sundstrum asked a question about the number of people who have "reserved" or placed a hold on an item -- this information would be useful for ILL purposes.
St Gelais asked us to confirm that the examples included at the end of the proposal are accurate.
Stovel: what's the relationship between the ASN.1 section and the schema? St Gelais drafted the ASN.1 to help her think about the schema, but we can remove the ASN.1 if the schema is intelligible without it. Stovel: the ASN.1 is better at showing the structure of the fields, but it is misleading. She prefers that we don't include the ASN.1, but instead figure out how to show the structure better in the schema. Denenberg suggested not including the ASN.1, but since the schema may be full of errors (there was little review after drafting) it needs to be compared to the ASN.1. He prefers focusing on the logic of the proposal. Everyone agreed that the schema was easier to read than the ASN.1: we'll use GRS and the schema. Denenberg: maybe we should include the data type in the schema rather than referencing the tagset. We'll refine our techniques as we write more schema.
For the last ZIG, Hinnebusch prepared a tree view, but not this time. Would that be easier to read? Stovel: the examples could be presented as a tree. Agreed: we will take the ASN.1 out, make the schema show the hierarchy better, and put the examples in a tree.
Stovel asked for clarification of sublocationId; the server must know that the locations are a hierarchy with an order.
Denenberg: this version of the schema does not include the tagset, which is typically where we put the elements. Perhaps we should add another column to the Table for data Type. We will do that in the next draft.
Van Lierop: is there a browse mechanism? What if we want only the holdings of a particular location? Denenberg: the "next chunk" of HoldingsData was put in so that implementors can do this with v2 (see Appendix D). There was some discussion here of getting holdings from just one location. Agreed that eSpec does not do the job.
Hinnebusch: have we agreed that there are at least four element set names for specifying retrieval (what's to come back, e.g., B3, B4, P3, P4))? You ask the server for the element set you want, then when you ask for the "next chunk" it will be the next chunk of that set. Agreed.
Denenberg wants to solve the problem of additionalHoldingsInfo. Hinnebusch: this field was initially created for union catalogs. LeVan: if the functional requirement is to restrict holdings to a particular location, why not include Z39.50 sURL to run a subsequent query?
Graubert suggested adopting rules for automatically generating names. LeVan: we didn't do that to protect the Type-1 query. Stovel: Turner wrote a profile document for searching for holdings; the next step is to coordinate that document with the current schema once the element set names are settled. Hinnebusch: this is not a holdings-specific problem, but could exist in satellite data. Whatever we craft as a solution here should be general enough to stand in other subject domains. We really are talking about a query. Denenberg is against the idea of using element set names to search within the record; he doesn't think we should search within records. Graubert wants to take a single record and explode it into many. For example, you search a holdings database and get holdings records, then search a bib database and get bib records -- now you need some way for the client (or client-server) to combine these results. (Wibberly in the past wanted to collapse many records into one.)
Denenberg: Z39.50 sURL was intended to convey a variety of things, including database name. Zeeman: to retrieve holdings for library X, we need a result set with holdings data. Hinnebusch: if a record from a union database has inadequate information, you must query a separate database to get the holdings information.
Summary:
Someone tried to summarize the problem: You retrieve an OPAC record (containing bib and holdings information) with a bib-level search. In some cases, many institutions' holdings are in the OPAC record, so we need a way to ask for just the holdings from one or selected institutions. We need an attribute set on holdings information. Waldstein saw two problems:
Summary after break:
Graubert: query type 102 dealt with some of this. Can we put some of the dynamic element names in eSpec? Denenberg: the Z39.50 model assumes information units ("database records") to which a search is applied. To put the type 1 query in eSpec would require your server to do the same thing as if it modeled holdings as a separate logical database, so what's the point of using eSpec? Hinnebusch: you already know the results of the previous search and the selection the user has made (before requesting detailed holdings on particular location); if holdings are on a different server, how do you construct this? Denenberg: if we're talking about holdings on a separate server, that's a different problem. Hinnebusch: the server should return an attribute or cookie that could be used with the follow-on search of holdings on the same server (using the logical database name of the holdings database).
Waldstein: eSpec is a different view of the same record, not a different view of the same database. You're trying to get either all of the holdings at a particular location or all of the holdings for a particular piece (e.g., specific volume and issue). Denenberg disagrees. There was much quibbling about whether to specify a second database name (even if only the name of the logical holdings database) or whether to incorporate the type 1 query into eSpec.
Why not explore further the idea of solving this in the client? How big will the client have to be? Davidson: why can't I search for journal name, volume X, issue Y, at specified locations and "available"? Because we don't have the attributes in bib-1 to do this. And to do this in a union catalog would require the server to do multiple queries (in multiple holdings databases).
Denenberg: eSpec has no query mechanism to do this. LeVan: we modeled this result as a single record from which stuff has been selected by a server. Denenberg: what kind of mechanism do we need? Do we create eSpec-2 with attribute, operand, term mechanism or just another specifier? LeVan: we want a type 1 query. C Lynch: before you start coding this, think at the basic architectural level. What does putting a query in eSpec mean? LeVan: in eSpec now we can ask for author, title and subject or only the 4th subject heading; it's only a small leap to say only return those with the term "dog" in field X. C Lynch: if query language deals only with field names in ordinal positions, this could work; if, however, you want to deal with repeating field groups, etc., you'll have to back off unless you constrain this. Query is the absolutely wrong way to do this. Hinnebusch: type 1 query and ZSQL query won't work with this record structure. D Lynch: the model here is not type 1 or ZSQL, but DSSSL (which is something like XML but with query support).
LeVan: we're far from convergence on what we're discussing. Denenberg: we've discussed several alternatives:
Stovel: we need to write this down. D Lynch: this is the same discussion we've had for three meetings. Denenberg: the selection mechanism is new. Zeeman: the selection mechanism was expressed as a requirement a year ago. Hinnebusch: St Gelais' work enabled us to put record structure aside and get into this quagmire with new enthusiasm.
Hinnebusch: we agree that if the holdings data is on a different server, the server presents the URL of where the data is and the client goes and gets it. We get into trouble when we create selection criteria (e.g., volume X, issue Y, locations a, b, or c). Vendors are waiting for us to produce something by the end of this ZIG. Can we give them enough guidance for them to get started? If we decide on a logical database, let's give them a place to do that in the OPAC record. St Gelais: if we don't have a solid model, we can't go forward.
Denenberg thinks Hinnebusch is right. Only one of the three alternatives affects the schema (i.e., the different database view would require the database name), so can we create a placeholder? If we do eSpec we don't need to change the schema. D Lynch: the schema is not the issue; implementation is and a "placeholder" is inadequate. Vendors are implementing OPAC record and they know we are deprecating the current OPAC record syntax.
Pedersen wants guidelines for the content of the Explain database (attribute list) and the minimal requirements. Hinnebusch: aren't there canonical searches in the standard? Is it a question of what's being used? Pedersen: what does the content of the Explain database mean and how should it be presented to the user? What should the user interface look like? Hinnebusch: servers don't have an exhaustive list of attribute combinations. Do we declare defeat and give up? Pedersen: no, someone needs to create an exhaustive database that should be the defacto standard. Some elements must be mandatory. The Danish Library Centre is working on this.
Hinnebusch: do we need an Explain profile and if so, what is it? Denenberg: we don't want a profile for Explain, but strategically we can designate subsets or functional units so that implementors can determine interoperability. For example, some Explain information (e.g., library hours) is for the end user; other information is not (e.g., attributes, term lists). Waldstein: a lot of this is philosophical. Z39.50 does well in some areas but not in others (e.g., philosophically different search engines). Now that there is an Explain toolkit, things may get easier and we can see what's missing.
LeVan wants to see progress made on this. A useful next step would be for client developers to document what they want to get from a server and why this information is useful. This could be used to designate the subsets or functional units that Denenberg suggested. LeVan was drafted to push the client people to tell him what to put in an Explain server. Maybe the Madrid ZIG will have a central focus on Explain.
Segue to invitation-only workshop on thesaurus and structured authority files at the Digital Libraries '98 Conference in Pittsburgh in late June.