ZIG meeting - June 3, 1998 -- Day 3

5. Extensions Pending to Bib-1 Attribute Set

(LeVan, Christian, Hinnebusch for Evans) -- CONTINUED
• Authority attributes - The new bib group will look at these issues. Tabled for the time being at the ZIG (not "pending").
• Dublin Core attributes - Agreed to add all Dublin Core attributes to bib-1. Semantics come from Dublin Core group.

6. Attribute Sets and Attribute Architecture

CONTINUED

Hinnebusch: concern was expressed overnight about the new bib group being independently constituted. Europeans will have difficulty traveling to attend meetings of a group that doesn't really exist. There's also a question of working style. So WG4 (the ISO body for library activities) will convene the group. Anyone can still participate. Stovel is looking for a co-chair, preferably from the European community. Denenberg: since it is not a ZIG group, there is no need to discuss at the ZIG except to facilitate international participation. Pederson is pleased with having the group in WG4; this is the right way to do international standards. But Stovel is concerned about putting the group in WG4 because ISO moves so slowly; can the group even start working without ISO's approval of the constitution of the group? Sally McCallum: Z39.50 is now ISO 23950; WG4 is not as formal as some other ISO groups.

Stovel wants guidance on the duplication of attributes over attribute sets. We have Dublin Core as our Cross Domain attribute set. Should we use that in combination with Bib-2, or should we duplicate some DC things in Bib-2? Denenberg: we discussed this in the past and agreed to duplicate because the semantics will be different in the Bib-2 and Cross Domain attribute sets. Zeeman: this will make the Cross Domain set useless. D Lynch: no it doesn't. LeVan agrees with Lynch because profiles solve the problem of duplicated attributes. D Lynch: profiles may not even be required; the dominant attribute set is declared and defines the rules. Reich is uncomfortable with the idea of not being able to duplicate attributes; he wants to re-use attributes where he can. (Note: Van Lierop made a comment here that LeVan and Stovel thought raised an interesting problem, but I didn't understand it so couldn't record it.)

Gignac: what is the scope of "bibliographic"? Please expand it to include A&I databases because Bib-1 is inadequate. Stovel prefers a library catalog attribute set and a separate set for A&I, but it will depend on what the group decides to do. She will post a scope statement and Gignac and Waldstein can respond. Stovel made it clear that if we need a separate attribute set for A&I databases, we'll need another group to do it. The new bib group is doing Bib-2 for library catalogs.

Waldstein: is it really the case that people expect the Mechanical attribute set to be "dominant" (at the top level)? Denenberg is responsible for the development of the Mechanical set, and it is not his intention to make the Mechanical set dominant. Zeeman thinks the notion of a dominant attribute set doesn't buy us anything. D Lynch: a dominant attribute set buys us a parallel between schema and attributes. Denenberg: it's too late to bring this up.

8. Z39.50 Maintenance Agency Business

(Denenberg)

Denenberg: ISO 23950 is an approved ISO standard -- identical to Z39.50 -- but not yet published. Now ISO 23950 needs a maintenance agency or something like it. ISO operates a little differently from NISO. Denenberg wants the Z39.50 Maintenance Agency (and registration authority) to continue to serve the ZIG and to serve in the capacity that ISO requires. NLC is now the official Maintenance Agency and registration authority on interlibrary loan.

Denenberg provided a brief overview of Z39.50 Maintenance Agency activities and procedures, ISO procedures, and some suggestions or guidelines for how the Agency and ISO will interact:

• maintenance - deals with defect reports, clarifications, and amendments (e.g., approving an additional option bit for concatenation). Defects will be corrected and clarifications and amendments will probably be incorporated (at least balloted) in Z39.50 version 4. Our procedure includes the status of "endorsed by the ZIG." Then things go through the ISO approval process. We will review items on a case-by-case basis to determine if something is normative (the basis for implementation) prior to moving it through the ISO approval process. The review procedure has been outlined for profiles (page 4 Denenberg's handout). Profiles are developed by some group, which may submit them to the ZIG for approval or comment; there is no OIW any more. The ISO approval process only assesses whether something conforms with the standard, not whether there is a need for it. The ZIG can endorse a profile, suggest revisions, or decline to endorse.
• registration -
• implementation - has no meaning in ISO, but continues to have meaning for the ZIG; includes ZIG Commentaries.

Then we conducted Maintenance Agency business:
• Defect reports. (See page 13 of Denenberg handout.) Defect reports not yet endorsed by the ZIG begin with number 7 on page 17 of the handout. Agreed: all defect reports were endorsed by the ZIG except number 10, which was reclassified as ZIG Commentary.
• Amendments. (See page 22 of Denenberg handout.) Considering encapsulation, adding a schema identifier to qualify tagType in eSpec, and the revised Update ES definition. LeVan was not pleased with encapsulation. Instead of the first PDU containing a list of other PDUs, it would be easier if the first PDU contained a PDU that might contain others. No one has implemented this yet except LeVan. He will post his request to the list for further discussion. Stovel was concerned about something in the amendment to add a schema identifier, which turned out to be a typo; Denenberg will correct the text. She doesn't know why amendment 3 is being proposed; she and Zeeman want to see the discursive text that Denenberg removed. He will put the text back for review and approval. The amendments were not ratified by the ZIG.
• Clarifications. (See page 28 of Denenberg handout.) Agreed: all clarifications were approved or endorsed with little or no discussion.
• Commentaries:
  • Merging result sets (merge or merge and sort result sets) - Waldstein cannot understand the distinction between a simple search and Boolean search (page 38 of Denenberg handout). Denenberg: on the one hand, a lot of people have said repeatedly that as a general principle a result set should not include degenerate duplicates; on the other hand, there is no way to compel a server to unilaterally remove degenerate duplicates. When we talk in detail about what we do when we merge result sets together on a sort operation, some people were offended that the resulting set would include duplicates; but there's no way to prevent it except with a Boolean ("or") or follow-on search of the result sets. If you do a simple search, there is a presumption that you will not end up with a result set with degenerate duplicates.

    Hinnebusch characterized the problem the opposite way: if you do a simple search you will end up with degenerate duplicates. Waldstein is offended by degenerate duplicates, but why does it matter how the search is done? Stovel doesn't think Hinnebusch and Denenberg really disagree; the result of merging more than one search result will probably contain degenerate duplicates when the merge is finished, though it would be nice if they could be removed before the result set was presented to the user. Denenberg agrees. The extended result set model has additional information besides database name and pointer; additional information indicates why that record qualified (and may qualify more than once in the result set). Hinnebusch: does it make sense to say that you should expect different results when you do a simple search or a Boolean "or."

    Do we need a separate commentary on degenerate duplicates or is it orthogonal to the discussion of merging result sets? Debate ensued about whether degenerate duplicates should be discussed at all in this commentary. LeVan and Hinnebusch say no; Denenberg says yes. Waldstein thinks this is a defect about sort, which can't return the number of items in merged and sorted result sets. LeVan and Hinnebusch want an amendment in this regard. Denenberg doesn't think we should try to fix sort at this ZIG. C Lynch: it is useful to highlight in this commentary that sort and result set merging operations are all ambiguously specified. What he's hearing is that people have reasonable but different assumptions about how sorting and merging behave.

    Denenberg: should we progress both an Amendment to sort and Commentary on merging result sets? There was great debate about this and whether we should fix sort. Take the discussion to the ZIG list.

  • Explain and term lists - Ratified without comment.
  • Explain attribute vs. term list information - Waldstein does not agree with the dichotomy. Denenberg: Explain is misunderstood. The intent of attributeSetInfo and attributeDetails is to provide information about the attribute set and how your server interprets the attributes. The Commentary should describe this. Again, much debate, this time about attributes and term lists and their relationship to databases. (I didn't understand it.) Tabled until the Madrid ZIG when Hammer is available (he wrote this Commentary).

9. Proposed Extended Services Diagnostics

(Gatenby)

See page 48 of Denenberg handout. Gatenby provided background on diagnostics to be added to Bib-1 diagnostics, all prefaced with "Extended Services." The ZIG agreed to add the ES diagnostics to Bib-1 diagnostics. (Following the last ZIG, Denenberg added the diagnostics for Update Extended Services to the diagnostics tree, rather than creating a separate set of diagnostics just for the Update ES.)

10. Negotiation of Profiles and OIDs

See Denenberg handout page 49, which attempts to define the negotiation of IDs during initialization. People want to exchange information about OIDs in the init, not in Explain. In the past we discouraged this kind of thing, but folks want it here. Zeeman: why does the server care what profiles the client supports? Denenberg: I don't know, but this is not just for exchanging profiles; it's about OIDs. D Lynch and Zeeman: that's negotiation, not just exchange of information. LeVan: no it's not. Yes it is. Some wrangling here.

Denenberg: The point is to have one specific, well-known format, such that if the server sends an OID within that well-known format that the client doesn't know, the client can ignore that oid. In general, the client may not otherwise simply discard information because it doesn't understand it. Thus in general the server can't send any format unless it ascertains that the client understands it. The only way the server can send any information in the init that is binding on the association is if the client has said that it supports that OID. More wrangling.

Denenberg tried to clarify the model of negotiation during initialization based on parameters associated with OIDs. Van Lierop thought the sequence in which these were presented was the order of preference. Denenberg is afraid that if we rush into an overly simplistic format for negotiating profiles and OIDs that we'll get into trouble. Maybe we haven't formulated the problem clearly enough. Hinnebusch and others think part of the negotiation model is superfluous.

Stovel is concerned because Denenberg's proposal does not reference profile OIDs, which is what this is about. Denenberg: but there is nothing in the protocol about profiles or profile OIDs. What we need to do is clarify that we are negotiating behavior, not profiles.

C Lynch did not understand what it means to negotiate profiles. Let's set aside the details for now and discuss what it means to negotiate behavior. What he's hearing is the exchange of behavior OIDs (e.g., levels of compliance in CIMI). It might be useful to refer to these as "behavior tokens" rather than "profile identifiers" or "negotiation."

Zeeman: would negotiating a profile, where the profile says you will support these sets of attribute combinations, mean the server would be expected to return an error if it receives a request outside of those sets -- even if the server can support it? Hinnebusch: we don't know. Denenberg: the proposal does not exclude behavior outside of the profile unless the profile explicitly excludes it. Hinnebusch: we don't understand the problem yet.

Waldstein: it sounds like OSI stuff. What were the issues they raised? Denenberg: OSI did negotiation in a manner similar to what we're discussing. LeVan: our concept of OIDs is more complicated than OSI OIDs. We need implementation experience. Graubert: our intellectual effort should be going into Explain rather than trying to pass through these negotiations. Other folks objected to this. We need to "negotiate profiles" anyway. Hinnebusch: until we know what we mean by "negotiate profiles" or "negotiate behavior," any discussion of the mechanics is premature. Explain doesn't help (much) with negotiating behavior. D Lynch: a lot of this is database dependent, so it doesn't make much sense to do this in the init which applies to the whole association. Hinnesbusch: let's move this to the list.

11. Keyword Searching and Free-Form Text Searching

(Turner, Waldstein) (See handout.)

Turner: there is no consistency among Z39.50 clients and servers in terms of the attributes used to specify a keyword search. She wants the ZIG to say there must be common semantics for simple searching. Zeeman: this sounds like a profile for library systems. Turner: yes, the focus is library systems; she can't speak for other domains. The purpose of the proposal is to reach an agreement to which subsequent profiles can refer to find the attribute combinations that they must support.

Waldstein: not sending the attributes is a bad idea. Stovel objected to the confusion of phrase and word searches in the proposal; you cannot force phrase searching into keyword searching of one or more words in any order. St Gelais interprets "Any" as any field. Turner interprets "Any" as keyword search. Stovel has problems with "Any" too. Zeeman: we should not be specifying behavior in the absence of attribute values. Waldstein is bothered by "Any" too; he thought it meant all the access points within the database. D Lynch: that's right.

Hinnebusch: the problem that Turner is trying to get around is that there is at least one vendor (Innovative) that needs a word structure and title attribute; they can't do keyword searches without Any. What's the goal here? To clarify the way to do standard keyword searches in ILS systems. Stovel: we can currently do a keyword search for author, title, or subject, but we cannot do a keyword search of anything else because there is no Use attribute specified. Turner wants to use "Any." D Lynch: the requirement that comes out of this is that servers will have to support this one combination of attributes.

Turner will clarify in the document that this is about the client requesting explicit behavior from the server. Hinnebusch: when this is rewritten, what is this document? Clarification? Commentary? Profile? Implementors agreement? The proposal only pertains to Bib-1.

Waldstein: clearly the user is entering stuff that the client is parsing into words to send to the server. This is fine, but not all clients interpret words the same way (e.g., hyphens, etc.) Hinnebusch: do we need text and normalized text in parallel with name and normalized name?

Denenberg: the proposal is based on a profile so it's an implementors agreement. Turner agrees. Hinnebusch: do the implementors in the room agree to do this? St Gelais wants a clarification of Any; is it any commonly used access point? When you get this combination of attributes, the server should do whatever it understands as a keyword search. Hinnebusch: this will enable broadcast searching. Agreed.

12. Future Meetings

• Madrid, Spain, October 19, 20 and 21, 1998. The space is already reserved for Monday, Tuesday, and Wednesday, so there is no opportunity (space) for a tutorial before the ZIG meeting, though we could possibly do one at the end of the meeting. Pedersen: if we do a tutorial, we should re-think the content because presentations on ASN.1 are no longer necessary. Presentations on implementations are preferable. Information on hotels will be posted ASAP.
• Hosted by RLG, Palo Alto, California, March 3, 4 and 5, 1999.
• Tentative: Sweden in August or Washington DC in September 1999.

Opac/Holdings Conclusion