The day began with coffee, pastry, and old American rock-n-roll music (for example, Twist and Shout, Under the Boardwalk, When a Man Loves a Woman).
The initial discussion about retrieving holdings occurred in the context of the National Library of Canada's work on a union catalog. The following options for retrieving holdings information were discussed at the April 1997 ZIG:
Discussion followed in an effort to focus the problem and analyze the alternative solutions:
Mogen: the DRA handout analyzes the problem and proposes a solution: two presents on one record. The DRA proposal will be presented at the satellite meeting this evening.
Stovel: the options Zeeman presented are not really alternatives, but rather show the progression or evolution in ZIG thinking. Have we reached the end of this line of thinking? Zeeman: the last option (two presents on one record) really addresses the problem of large holdings; the earlier options address not much more than the discovery issues.
D Lynch: it helps to separate what these things are about, for example, record syntax choices, big records, the location of holdings records. The first and last options address only record syntax issues, so neither of them are acceptable solutions. Sending MARC records that are guaranteed to be useless is not a good plan. The last option (all bib records have to be GRS) is not a good plan either. OPAC record was dismissed quickly, though we have no common understanding of how to use it. Maybe all we need is some disambiguation and profiling. Two searches of one database suggests that you know ahead of time how to do this. Does the client have to know a priori where to get holdings or does the server have to tell it? There really are not so many choices here.
Wibberley: if a reasonable approach is to beef-up the OPAC record, then we can define a new OPAC record as a schema, but carry it as a GRS-1 record. We can do similar things with other issues over time.
Denenberg: are we assuming v2 in this discussion? Zeeman: yes, we are addressing an immediate practical problem. Denenberg: but e-spec would help (it supports syntax within syntax) and that is v3. The installed base will have to do something to adopt whatever solution we come up with. Waldstein (a v3 implementor) doesn't know anyone who has done e-spec.
Hinnebusch: there was some discussion on the list about the need to generalize this. Denenberg: the discussion ended in May with two different lines of thinking, one of which was to generalize from simple linear range to arbitrary range searching. But we don't know what "general range" means and there are too many specific areas of application to try to sort this out. Hinnebusch: if we stick to a two point solution, what are the implications?
Denenberg: the new proposal consists of a new relation attribute in Bib-1 (Within) and the term itself would have to include two terms. Stovel: there are lots of restrictions in the proposal for the Within attribute that would prevent it from being used for geospatial information retrieval. Denenberg: we could have an implementors agreement to make linear range searching use two terms, but not require the relation attribute Within to use two terms. LeVan: we will need some way to modify relation attributes, for example, greater than 1990 or less than 1990. A term here is a sequence of terms, so you should be able to specify a relation. Multiple relation attributes are needed. If all you can do is inclusive range searches, not exclusive, then we have a bug or deficiency. Loy and Wibberley agree that we need greater flexibility than what is proposed. Wibberley: CAS solved the range problem by defining a Range attribute in the STAS attribute set; two terms in the linear range are linked by the Range attribute. Hinnebusch and Denenberg: this is getting dangerously close to using proximity; they don't want to use proximity to do this.
The defect in the proposal is great enough that Wibberley, LeVan, Loy (and perhaps others) will not support the proposal. Zeeman suggested that we add an external data structure. ZIG response: no. Hinnebusch: there are three possibilities here: solve the problem using a With attribute, solve it with proximity, or solve it by making Range an operator. Waldstein proposed defining a With attribute and specifying whether it includes one or both end points. Hinnebusch is concerned about the muddle of semantics and attributes. Zeeman: a With attribute also requires you to do a lot more error checking for attributes that do not make sense.
C Lynch pointed out that the attribute architecture group spent some time on this issue and made two recommendations: first, that future revisions of the type 1 and successor query replace term and operand with sequence of terms, and second, that in the interim we consider doing some kind of range operation as an external. Denenberg: the proposal under discussion is consistent with the new attribute architecture. C Lynch: in the current v3, the best you can do is an external to hold the multiple end points plus flags; put an operator in (range) that would take an external term. Hinnebusch: we have a type 101 with nothing in it. ZIG response: no!
Denenberg: we have here a proposal that is agreed upon if we do not introduce the end point problem, but we need to solve the semantics of the end points. Hinnebusch: we got caught in the past when we took the short term solution. We should solve the general problem here if we need a range operator. LeVan, Loy, Zeeman propose a sequence of terms plus flag (flag has a big number space). If we generalize this from two terms to an arbitrary number of terms, then the geospatial people can use it with a flag that indicates whether a line is open. Is a Boolean flag sufficient? There was some debate about whether or not the proposed solution will handle range searching related to polygons. Denenberg proposed going with sequence of terms plus Boolean flag. Wibberley suggested defining an external for this particular problem space; the geospatial community can propose an external for their problem space. Agreed.
Does this need a different OID? If it is a different beast, yes. But is it a different beast? Hinnebusch: we need an external that is just a sequence of terms (over and above ranging). Denenberg will modify the definition and later on, when this is stable, the ZIG will define a new OID if we decide we need to.
Denenberg provided brief background information from the discussion about mapping Dublin Core to Bib-1 and TagSet G. The focus of the current discussion is mapping to Bib-1. Stovel: the problem with the proposed mapping is that it dummies-down Bib-1, so this is a mapping of a mapping from RLG's perspective.
C Lynch observed that when we talk about mappings between Dublin Core and Bib-1, there are two distinct problems being solved. One problem is the case where someone wants to search a Bib-1 style database using Dublin Core access points as the lowest common denominator. The second case is where there is a Dublin Core indexed database; someone has built descriptive records using Dublin Core and someone wants to search this database using a Bib-1 search umbrella. We may want to use different mappings for the two cases. In the first case, you want to go from general Dublin Core to more specific Bib-1. In the second case, you want to go from more specific to less specific. These are different mappings.
Denenberg: if we were looking at this in terms of the future attribute architecture, then the second case would need a Dublin Core attribute set, and the first case would need a different attribute set. C Lynch: this is not an issue of the new attribute set architecture, but two different application scenarios that are mixed together in the proposal. Denenberg: but would we have two different mappings within the same attribute set? Give me an example where they would map differently in the two cases. Stovel: author is a case in point: Z39.50 distinguishes between author and corporate names, but Dublin Core lumps them together.
Selway suggested that the proposal be clarified to indicate the preferred mapping when there are options. Denenberg: the implication is that you search on both when there are options. Selway: the proposed mapping makes it impossible using Z39.50 to distinguish Author/Creator from Other Contributors in a Dublin Core database until the ZIG has a Dublin Core attribute set. The British museum community wants to use Dublin Core and create Dublin Core databases. Denenberg has no idea when the ZIG will have a Dublin Core attribute set.
Hinnebusch: the Dublin Core people have to work with the ZIG to create this attribute set. Do Dublin Core folks care about Z39.50? Disagreement. Denenberg: it is a big jump to go from defining 15 elements (Dublin Core) to a Z39.50 attribute set; creating a complete attribute set is beyond the scope of Dublin Core. Davison: it is not clear that spending effort on a mapping between Dublin Core and Bib-1 is preferable to spending effort on drafting a Dublin Core element set.
C Lynch attended the Dublin Core meeting in October and observed that their data element names and rough semantics are pretty stable; he would be surprised to see new data elements in Dublin Core. The group's focus is on definitions more than searching (access points). The underlying philosophical tension in the group is not the field-name side of what would become an attribute set, but the data-representation side. For example, how do you write a date? Do they need to specify structures? Some factions are talking about qualifiers to give more precision about the kind of date. We can do the Use attribute part of an attribute set at this point (no brainer, 15 elements); what would be harder at this point (what is not cooked in Dublin Core) is what other attributes are needed and how they are defined. They do not have an explicitly stated goal to define a Z39.50 attribute set, but once they straighten out the qualifiers, etc., it will be fairly mechanical to translate that into a Z39.50 attribute set. He suspects that by the end of the year we should be able to work with them on that.
Denenberg's perception is that Dublin Core does not even make the distinction between an element used for searching and an element used for retrieval. But the museum community wants to search using Dublin Core attributes! He is trying to facilitate this by providing a mapping to Bib-1. C Lynch: if all you want to do is provide Dublin Core access to Bib-1 databases, then create 15 new use attributes called Dublin-Core-whatever and let individual servers map them as they see fit.
Gatenby: mapping to Bib-1 is relevant; she does not favor adding 15 new attributes, though servers could handle them. There is also the problem of databases that have mixed records (some Bib-1, some Dublin Core). Denenberg: do your comments also apply to the proposal to create a different attribute set entirely for Dublin Core? Gatenby: yes. Denenberg's mapping proposed some new Bib-1 attributes to accommodate Dublin Core (like C Lynch's proposal). Wibberley: since Dublin Core is still evolving and the definition and semantics of these things will change, he prefers that they not be in Bib-1 and that the ZIG bite the bullet and create a new Dublin Core attribute set. If we put them in Bib-1, we're introducing more multiple ways to express the same attribute in the same attribute set. Adding new attributes to Bib-1 only further muddies the water.
Denenberg summarized the options:
C Lynch: the problem with a new Dublin Core attribute set is that you will have to make some decisions about other kinds of attributes (e.g., relation) to complete the Dublin Core set. If we stuff everything into Bib-1, we don't have to make those decisions. Denenberg suggested evaluating the Dublin Core attributes on a case-by-case basis (e.g., we already know there are problems with authors). C Lynch: that leaves you with arbitrary semantics about Dublin Core.
Hinnebusch: what problem are we trying to solve? LeVan proposed that CIMI should profile this, since they are the folks that want this. Denenberg: CIMI is not the only group interested in this. LeVan: let CIMI and Dublin Core decide if they want to use the proposed mapping, with ZIG clarifications about the deficiencies. Wibberley: this issue is a symptom of a longer range problem; he agrees with Denenberg's proposed mapping for the short term, but for the long term wants to develop an attribute set for Dublin Core that meets the criteria of the new attribute set architecture. Bib-2 is going to be enormous, but Dublin Core is small and may be a good exercise to work with. Denenberg has no problem with the long term suggestion, but wants to solve the short term problem because other topics at this ZIG meeting hinge on this decision.
Waldstein: Denenberg's proposal is no different from the MARC to Bib-1 semantic mapping from a few years ago that was offered as a guideline: it's OK to ignore the guideline because it's an implementor agreement, not part of the standard. Moen: CIMI has to address the issues that Dublin Core raised because they affect the CIMI interoperability testbed; he would like the ZIG to address the Dublin Core elements that don't fit Bib-1. Hinnebusch: since this is a guidance document for a particular group of implementors who may or may not care about it, what are we arguing about? Denenberg: we can put this doc in the category of commentary, but ZIG commentaries are approved by the ZIG. Dekkers: who or what is this doc for? The server side or client side?
Denenberg's problem with adding 15 new attributes to Bib-1 is the databases with mixed records. We need to select a solution just for the people who need this. Zeeman agrees with Denenberg; his concern is what is implicit in this discussion, specifically that it is appropriate to search Dublin Core with the Bib-1 attribute set. Davison requested clarification: are these recommendations to use Bib-1 to search Dublin Core records, or do we want to use Dublin Core access points to search non-Dublin Core records? Denenberg explained that there are three types of databases: one is Dublin Core, two is Bib-1, three is a mixture of both. Zeeman thinks the current proposal applies only to the first case where the database is Dublin Core.
Hinnebusch summarized ZIG consensus: we need to resolve a two-directional mapping. C Lynch: is language the problem here? Bib-1 refers to MARC records (what MARC fields you index into what access points). When we talk about Dublin Core, we're confusing Dublin Core access points and Dublin Core data elements. We need a document that guides the mapping of Dublin Core data elements with Bib-1 attribute searches. We need to be more precise about the context. Waldstein: maybe we should map Dublin Core to MARC. Hinnebusch: be quiet! Stovel: if we can map Dublin Core to MARC, why isn't that sufficient? Hinnebusch: where do we go from here? Stovel: Denenberg can say whatever he wants; there is no official ZIG document.
Zeeman asked for a clarification of the need this discussion is addressing. Moen: the CIMI requirement is a client using Dublin Core fields to map/search Dublin Core and MARC bibliographic records. Zeeman: this sounds like a user interface (label) problem. LeVan: a fixed translation table like this proposal is inappropriate for the client; interfaces need to be customized to every server mapping. Dekkers: if a user inputs Dublin Core things and at least part of the database is Dublin Core, it makes no sense to do this translation on the client side. Zeeman and Dekkers are opposed to adding 15 Dublin Core attributes to Bib-1. Denenberg is concerned that a new Dublin Core attribute set would preclude doing a better one down the line (if we do DC-1, when will we do DC-2)? He proposes a DC-0 attribute set because we don't have the resources to do DC-1.
Hinnebusch: we must settle this issue. It was brought forward for CIMI, so they should do a straw vote on the proposed options; the ZIG is not going to decide. Tibbetts: Other Contributors, Resource Type, Resource Identifier must be made unique to help CIMI and RLG, which means adding seven new use attributes instead of four. Hinnebusch called the discussion closed. The proposal will be revised as a result of the CIMI meeting at this ZIG. Denenberg agreed that the final decision would be made at the CIMI meeting. He will write this up as commentary pending until the next ZIG.
Field 720 is a new field: added entry - uncontrolled name. Stovel: where do we add it? To author (1003) and name (1002) seems reasonable, but the Bib-1 attribute group should decide and will do so on the ZIG list. Though 720 came about because of Dublin Core (not real authority cataloging), it has application outside of Dublin Core.
Propose not requiring DocId (1032) to be persistent (for example, it could be a URL). Waldstein: is this like 001 (local number)? Hinnebusch: it was originally added for WAIS, which needed it to be persistent for a while but not immutable. Selway: is this used for Z39.50 URL? Yes, sort of. You don't supply the whole URL. Wibberley: does it make sense to retain an attribute that is a persistent identifier, and add an attribute that is not persistent? Is this a significant distinction? D Lynch: this was invented specifically for URLs for WAIS retrieval, so this is a clarification of the original intention. The ZIG is happy with the clarification (except perhaps Wibberley).
The proposed new Use attributes plus three additional attributes suggested by Tibbetts were approved by the ZIG.
Issue of number space: Wibberley: multiple attribute sets early on defined Bib-1 as inherited and started numbering at 2000. For example, the STAS attribute set inherits Bib-1 and already uses these numbers. Importing the GILS attribute set into Bib-1 with these numbers creates problems. The ZIG cannot accept this proposal with this number space. (The LC web page on use attributes may be wrong, i.e., it may not include the Canadian attributes that were approved at the same ZIG meeting with the German attributes and SICI number). Denenberg withdraws the proposal if these numbers have already been assigned. The problem that the proposal addresses is that there are servers and clients that just stick Bib-1 into everything and don't look at attribute set IDs. Zeeman: this is not a problem that we should address.
Issue of bringing GILS attributes into Bib-1: Waldstein, Wibberley and others will approve the proposal if we assign a proper number space. Inheriting GILS into Bib-1 is an exception to usual ZIG behavior. We are not creating a universal number space. But inheriting GILS into Bib-1 will create a problem for anyone who inherits Bib-1 and begins numbering at 2000. Implementors must begin looking at the attribute set ID. (Editorial comment: discussion here turned to some complications based on whether you are using Z39.50 v2 or v3 that I did not understand.)
This extension is necessary because the existing diagnostics do not allow you to return an attribute set ID, numeric value of the attribute type, or the numeric value of the attribute. The ZIG approved the proposal.
The ZIG approved the proposal to add a fourth type in that class to be identified by an ISO object identifier (OID) for body part type. The ZIG also approved the proposal to return within a variant that the content is a pointer to the data, not the actual data.
After brief discussion of deprecating HTML v1, the ZIG agreed with the other things proposed. Stovel requested clarification or elaboration of record syntax id 109. LeVan responded: if XML has an iana type, we should add it; if there is no approved iana type for XML, then we don't create one.
Concern about being able to tell what kind of element set the embedded MARC is (brief or full). LeVan: this is too complicated to consider within GRS. Hinnebusch is concerned about the particular kind of MARC record it is (for example, holdings, authority); you have to look at the record to discern this because there is no way to do it externally. Denenberg: there will be a variant containing the OID on top of this any way, so we could add MARC record type as another variant. LeVan: no, if they can look at the record and tell, they should look at the record. Zeeman: otherwise we'll be carrying all sorts of things as variants that they can tell by looking at the record. The client recognizes the record syntax, so let it do that. Denenberg: the record syntax is GRS, but the element syntax within that is MARC. Zeeman: but you know that because it has an element set identifier. Why do we need this? Hinnebusch: having it as an external in the record makes the record self-identifying. Denenberg: the variant facility enables you to identify it by the MIME type. LeVan: why did we not embed this as an external initially? Denenberg: there is nothing normative that dictates how we should do this. Our intention was to do this as an octet string, rather than an external. LeVan: the fact that we have assigned OIDs indicates that we want an external. Denenberg: no, we assigned OIDs so that we could stick them in the variants.
The ZIG agreed to do this as an external. Denenberg: but then we don't need to apply the variant. Denenberg will write this up again and will keep it pending for further discussion.
The proposal is to add Record ID to the schema. At the last ZIG, we made two important resolutions about where to go with Update Extended Service. First, we reached consensus to have a record locking and unlocking mechanism. Second, we agreed that we need a Merge function incorporated in a way that would not require us to normatively define the semantics. We could do that by adding Merge as a function along with elementUpdate, mergeQualifier, etc. MergeQualifier would be one or more externals to qualify the merge.
If you took the database record that you wanted to lock (set and unset) and a lock expiry, one way to incorporate that without impacting on applications is to view it as a logical schema that would be created on the fly and not affect how the records are stored. A Time Stamp and Record ID were also suggested. The schema identifier would identify the schema that the record was in. The point is that we are superseding the uncanned schema with a canned RecordLock schema. This abstract record structure would go from client to server (the client identifies the record that it wants to lock and the expiry of lock) and from server to client. The client may retrieve a record (via a regular present) to see if the record is locked; if it is locked, it can find out when the lock expires.
Hinnebusch: this is complex; what about element update? Denenberg: you are updating the lock element. Hinnebusch: this is clearly metadata; why do you want to create a new element? Gatenby: the record locking portion of the union cataloging profile is not mandatory; record locking in this case will be done by version control. The server can decide what to accept. She does not want this to get too complicated below the record level. Hinnebusch: either your server supports locking or it doesn't. If it does support locking, then getting this as metadata is fine; if it does not support locking, then it doesn't matter. If someone in the future wants to lock record elements, we can't do it if we approve this proposal.
LeVan: we're talking about cataloging and MARC records. Elements of the MARC record are not visible in the GRS record, so you can't apply variants, etc., about elements of MARC records. What are the real requirements? The ZIG folks from Sweden appear to need a mechanism to support element level locking. Do they want to lock elements of MARC records? Wibberley: to address this kind of element level locking, you need a schema to refer to the element that you want to lock so that the client can refer to the element the same way that the server does. The immediate need of the Australian group is atomic record locking of MARC records. Hinnebusch: if the Swedish group want to do element-level update in a MARC record, they can break it into a GRS record so they can do element-level update. Denenberg: we never talked about what a GRS-style schema looks like for MARC. But that's not our problem. OCLC needs record-level locking for Extended Services Database Update; they have already done it.
??: can we store who or what updated the record? Denenberg: in that case you must retrieve a Task Package that may not exist any more. Hmm. Task Package will give a user ID, but otherwise no. Selway: maybe that information can be put in a comment or descriptive field. Denenberg: we could do that.
??: are we talking about using an external for the record syntax to retrieve records for Database Update? Yes. Then this is also a proposal for present. Gatenby: yes. It should be an option in present and .... Denenberg: if accepted, this proposal is an implementors agreement (for interoperability) about how to do record locking. It would not make it mandatory to do record locking this way.
Gatenby: is the solution to make the record element ID optional? Denenberg: if you are only setting one element, that is pretty trivial, but if you try to set many elements, what if one of the many fails? Hinnebusch wishes the SQL people were here for this discussion. LeVan: we do not have a way to specify record elements with information attached except in GRS. Do we have to support full e-spec to specify elements to be locked? Hinnebusch: either the server says these elements are the ones you are allowed to update, or the client must be able to specify the elements that it wants to update -- which is a different problem. Denenberg: in the second scenario, instead of a schema, one of the element flags for each element will be locked. LeVan: does the full record have to be returned or just the elements that are to be locked? Denenberg: in terms of locking, we either go with the simple record locking right now and something like the proposed schema, or alternatively we want to develop this into an element-level locking, in which case we need to end this discussion and go back and do some more work.
Zeeman is concerned about GEAC applications and what they did with locking. Denenberg doesn't think what GEAC did will work. Hinnebusch: if we pull back from locking, then GEAC can continue; he thinks we need more than atomic record locking, that we need element-level locking. The Australian solution (already implemented) is collision detection rather than collision prevention; the server will lock the record, but there is no exchange about it between client and server. Hinnebusch and the Swedish folks want element-level locking. OCLC needs only atomic record locking and has implemented their own private record locking like GEAC. All we are doing by ignoring (or tabling) the locking issue now is postponing the interoperability issue. Denenberg: should the current proposal be pressed now? People will talk at break.... For now, the lock part of the proposal is withdrawn.
The other parts of the proposal include:
Maybe instead of having Merge and GlobalUpdate we combine them into something more general. The ZIG approves the diagnostic part of the proposal and will revisit Merge after discussing GlobalUpdate.
This proposal derives from the observation that generalized time is broken and not flexible in Z39.50 (ISO standards withdrawn). How do we represent date and time? We can adopt or adapt what Dublin Core is doing. We could use ISO 8601 when they are done, or profile it further to be compatible with our needs. The retrieval aspect was generalized time. Searching was more complicated in that it had to be supplied as an octet string. The point is that searching for date and time does not work very well. If we need a date and time definition, it should be compatible with the new attribute architecture. Should we develop a string definition? Or should we develop an ASN.1 definition (aligned somewhat with 8601)? Or both? Internet folks, certainly metadata folks, think 8601 is the way to go.
Tibbetts: we need to be able to specify seasons, quarters, etc. LeVan and people in the museum community: we should be able to specify centuries, decades, etc. Selway and other museum folks also want a circa bit. What about different calendars? They could be enumerated lists. Denenberg: the ASN.1 definition we have right now is the Julian calendar. Wibberley, Denenberg: we need something more than 8601, but should not try to be comprehensive. Davison: we need year, then subdivision of year, which is a choice of month (required), day (optional) or season, etc.
C Lynch: we're going off the deep end here; we understand about 90% of the dates we have to handle. The irony is that we have a legitimate scholarly case for handling some complicated dates, for example, B.C. dates and dates from non-Julian calendars. We should partition the problem. Hinnebusch and Denenberg argue about whether we should keep it extensible now or come back and fix it (make it extensible) later. Loy agrees with C Lynch: we should go after as simple a definition as will serve our needs now. Denenberg: let's keep what we have in the proposal and add a circa flag. What is missing from the proposal that is a hard requirement? Wibberley: if we want this to be a long-standing definition and recognize that we can't cover everything now, what about an option of an external for those things that don't fit, where people could register their non-Julian (tough 10%) of dates? Waldstein: what are we trying to achieve here that strings or 8601 can not do? Denenberg: 8601 can't handle B.C. dates, for example.
Denenberg has a sense of where we are (including some additional requirements reported during break) and will write another draft of the proposal. He will post the draft to the list for a month or so and if no one objects will consider the definition approved. He is open to suggestions about how to represent week number and what to do about week 0. Dekkers pointed out that there is an international rule about week 0. Choice will be moved to the top level. Waldstein: every place that we now say generalized time will be replaced with the new definition and ASN.1. LeVan: the form of the term will be in the ASN.1. There will be a specialized type of term for this.
At the last ZIG meeting we discussed Internationally Registered Profiles (IRPs) and concluded that the ZIG cannot and should not be in a position to officially approve profiles for a number of reasons. For example, it could cause legal problems for the ZIG (although it would be difficult to sue a non-entity :-). "Endorse" is an informal term and we can do that.
A TC46/SC4/WG4 meeting was held after the last ZIG. These groups are responsible for ISO 23950 and ILL. Brief background: ISO has something called an ISP with lots of baggage and no one wants to do it. So the ZIG came up with the term IRP (Internationally Registered Profile). Could we define an IRP that did not need the formal approval of an ISP? The ZIG agreed that we could do this as guidelines that would apply to Z39.50 (ISO 23950) and ILL (ISO 1060 and 1061). IRPs are reviewed for technical conformance by the relevant standard group (e.g. TC46/WG4), profile group (e.g. EWOS, OIW -- though that no longer exists) or recognized group of users (like GILS or CIMI). The proposing group will prepare a draft IRP within their community and then run it by the ZIG for endorsement. It will be up to the proposing group to represent how they view the ZIG response. The Z39.50 Maintenance Agency web site will list the IRPs and who approved and maintains them.
Stovel: the proposal does not say that the ZIG is going to be involved. What will you do when there is a profile that does not pass through the ZIG? Hinnebusch: we are trying to avoid liability for anything, so we can't put it in the doc, but implicitly an IRP cannot be considered in conformance with Z39.50 if it has not been discussed and endorsed by the ZIG. People can profile things now without going through the ZIG.
What is the difference between an ISP and an IRP? Denenberg: an ISP is tantamount to a formal ISO standard; an IRP is like an implementors agreement. Davison: an IRP was invented inside of TC46 because that community was not prepared to take on the full review and balloting cycle required for an ISP. JTC1 would not recognize an IRP. ??: then why would you bother to register these profiles? Denenberg: because we want some process that alludes to some level of approval that is short of the full ISO standard cycle of approval, but more formal than our previous haphazard ZIG/Maintenance Agency procedure. Gatenby: an IRP bypasses the ISO publication procedure and copyright. ??: who will use IRPs? Davison: ISPs are the sound of one hand clapping. ??: we should encourage profiling and IRPs. ??: is there a mechanism for forwarding profiles to the ZIG? Send them or pointers to them to Denenberg to put up on the web. ??: is there an obligation to make changes recommended by the ZIG? Denenberg: not an obligation, but you may have to defend that to TC46. Hinnebusch: The ZIG has stated that they do not want approval rights, so they do not get any rights.
??: how far before the ZIG meeting should IRPs be submitted? Denenberg: depends on the size of the profile, but probably two months.
Denenberg provided some background: the topic was previously discussed in the context of Z39.50 v4, simplification, pruning and APIs. He does not see a new protocol version coming about for a long time because publishing a new version is expensive and we have not yet implemented v3 widely. If we did have v4 or changes to v3, he believes that they should simplify Z39.50. The ZIG looked at this at two levels. One level was to prune the standard; the pruning doc was discussed at the last ZIG meeting and repudiated as incompatible with the standard (and not interoperable with existing applications). The second level was to write a logical API that someone could read -- in effect hiding rather than eliminating complexity in the standard. There was lots of enthusiasm for the API approach.
Denenberg will continue to work on this or work with others on this if people think it's the right thing to do. The ZIG agreed that we should initiate efforts to help people understand the protocol. After a brief discussion of alternatives (like online tutorials), the ZIG agreed that an abstract API could clarified what the protocol is about and is therefore worth pursuing. The current doc (draft 2 API, July 3, 1997), needs some work but is a good start.
Needleman: the current doc is a good guideline doc for someone to write an API for Z39.50. Pedersen: have you considered any of the APIs in the toolkits? Denenberg: this is not meant to be a real API. Pedersen: what is it meant to be? Denenberg: a "service definition," though that term is loaded in the OSI context. Will a service definition be useful? Hinnebusch: we should not call it a service definition; let's call it "Z for dummies." Waldstein: what are we trying to achieve with this thing? To show implementors what is required (and throw away everything that is optional)? Hinnebusch: Denenberg does this in the draft; the optional stuff is put in subsections called mapping to Z39.50. Maybe this needs to be a subgroup effort? Clearly it is too much for one person to do. People who have implemented toolkits should get involved here.
Stovel: no one in this room is the audience for this document; we need to show it to people who are in the intended audience and ask them if they can make sense of it. The draft has enough content to test this. C Lynch is lost here, having trouble understanding the intended audience and intended purpose. This is not a standards document. It may be inspirational material. It has some characteristics of a tutorial and some characteristics of a subroutine library for Z39.50.
Denenberg: the API does constrain some of the actual operations of the protocol. Does this document require agreement since it does restrict functionality? Or is it simply an instructional document? Hinnebusch: we have not agreed that this doc should restrict functionality. C Lynch: are we doing a roundabout standard for a fictional API that someone may or may not write to someday in an unspecified language? LeVan: this doc explains to application-level users what you can do with Z39.50, then mixes in some of what implementors can do. Needleman: parts of it sound like a profile.
Denenberg: there are at least three potential roles for this doc. It is not clear which it best serves:
What is it? The service description seems to be a pressing need. We called it an API at the last meeting, but discussion suggests that service description fits the situation best.
Hinnebusch: the beginning history of this was that we needed an implementors manual. But we did not produce that. ZDSR would have bought an API written in C or C++, but he does not think they will buy a high level doc. LeVan: this group can agree on abstract stuff, but will never agree on a concrete API; maybe we need to take existing APIs and discuss what you can do with them. Wibberley agrees with the observation that vendors are scared by the existing standard and thinks a doc that gives a high level overview with a mapping included would be valuable and complimentary to the standard. Davison: this doc is a functional description or overview, not a service definition; it is PR. M Pierce: application level programmers do not know what to do with a formal standard doc; you need to present it to them in something that looks like C. It need not describe the entire protocol, but should enable a programmer to do basic stuff in an afternoon. Hammer: as a developer of a toolkit, he initially wanted to do a definitive API for Z39.50, but realized that was not possible. He likes the doc as a description of how to go about implementing a client, and thinks it's good to provide a tutorial, but does not think it should be made into anything further than that. Do not confuse a discussion or need for a good tutorial with the task of simplifying or profiling the protocol. There is nothing wrong with the protocol. Hinnebusch agrees somewhat with Hammer, but thinks that if we had had a cook book of API(s) years ago, it would have dispelled the mythology about complexity in Z39.50.
C Lynch commented on the situation with search engine vendors and made a point about the proposed API (or whatever it is): it is reasonably short and concise, but it does not deal at all with the mess that you get back in records. One of the things that people find confusing is that you do not just get a record back, but a mess of tagsets and GRS and what do you do with that? That discussion alone will double the length of the doc. That stuff scares people more than Search and Present. We have a schizophrenic protocol -- not just Search and Present, but complicated modeling of data structures. Which personality will be presented in a doc or API like this? Hinnebusch: initially there was only MARC (no schizophrenia). C Lynch: you really cannot talk much about Z39.50 without getting involved in the content you bring back. Zeeman: record syntaxes have to be visible above the API or you can't do anything with it.
Hinnebusch: it is 5:00 and time for the holdings meeting. People should discuss this API business tonight and report back tomorrow. Think about what would have made your initial implementation easier....