ZIG Meeting

Wednesday, August 20, 1997, 2:00 p.m.
Copenhagen, Denmark

A. ADMINISTRATION

A1. Nomination of Minutes Taker

Denise Troll

A2. Introductions and Implementor Status Reports

Will be sent in a separate message.

A3. Revision of Agenda (Hinnebusch)

Added updates on the holdings and ZSQL satellite meetings to the meeting on Friday.

A4. Future Meetings (Hinnebusch)

At the last ZIG people requested a meeting in Orlando, Florida, January 21-23, 1998, but Hinnebusch is having problems scheduling it in Orlando because the ZIG is not large enough. After some discussion Hinnebusch agreed to keep trying to schedule Orlando, but if that fails, the first alternative for January is Tampa (one hour away from Orlando), the second is Gainsville.

After the January meeting, the ZIG will meet again June 1-3, 1998, at the Library of Congress in Washington D.C. Denenberg invited financial support from commercial companies anywhere in the world to buy doughnuts or microphones.

Dekkers is working on the next meeting in Europe in late October or early November. (By the end of the ZIG meeting, the next European ZIG was tentatively scheduled -- with the help of Pierce -- for Barcelona, Spain, in early November.)

A5. Register of Implementors Update (Denenberg)

Denenberg announced that he has discontinued the print version of the Register of Implementors and is only maintaining the web version now, which is not organized alphabetically. Then he circulated a printed Register (!) and asked people to please initial or update their registry entry. If an entry has not been updated or verified in more than a year, Denenberg will try to contact you via email. If that does not work, your name is dropped from the list.

A6. Clarifications (Denenberg)

Denenberg described the procedure: items are raised for clarification; following discussion, the text is revised; the new text is considered to be pending approval at the next ZIG.

The ZIG moved quickly through Denenberg's list of clarifications pending approval. All were approved without discussion except one item that had to be deferred: embedding MARC in GRS-1 records.

A7. ZIG Commentaries (Denenberg)

If you have Denenberg's handout from the August ZIG meeting, see page 26.

At the April ZIG meeting, people pointed out that some of the so-called "clarifications" are more than simple clarifications, so we created a new category called "ZIG commentaries" for those items.

ZIG commentary at the August meeting included discussion of:

• Non-scanable term lists. Waldstein mentioned social security numbers as an example of a non-scanable term list; Denenberg will add that example. But Dekkers said that term list only makes sense in context of scan....
• Discussion of why the ZIG did not include REAL in GRS-1. Wibberley and others said that there are multiple ways to encode REAL in ASN.1. Denenberg responded that if that is the case, then the issue is not interoperability. Wibberley: the issue is the encoding in ASN.1, not the machine encoding. Denenberg: we can finesse this. Donnelly: it may be just a historical note now.
• Should tags be considered commentary or an issue for clarification? Denenberg suggested that the ZIG raise this topic (are tags clear enough?) from commentary to an issue of clarification. The ZIG agreed.
• Discussion of using nested schemas for cross-domain searching and semantic interoperability. Moen: people want to be able to change schemas in GRS records.

  Denenberg: when TagSet M was conceived, it was not clear that you could stick them in the middle of a record; this is more than clarification. Needleman: the comment at the bottom of page 35 of the handout reverses the two cases under consideration. Hinnebusch assumed that you had to get the whole GRS record before you could process it. LeVan: are we confusing a discovery problem with a schema problem? Is it left to right traversal or vice versa; what is the precedence of the elements? D Lynch: things in a sequence are in a particular order, and we request things based on this (e.g., the third occurrence). Wibberley: the example in the handout suggests that you do not discover another schema element until you drop down a level in the tree, so the order of the elements does not matter here. Hinnebusch: schemas change when going down, not going across the tree. Discussion and disagreement. Do profiles specify the sequence? Waldstein: this is too complicated. Denenberg: this tells you what you can and cannot ignore, and it allows you to ignore elements that you would be precluded from ignoring if you did not recognize that schema. What CIMI is trying to accomplish is several levels of semantic interoperability.

  Wibberley: when we defined GRS originally, we required it to deliver records within records within records; schemas were introduced after GRS-1. This proposal is consistent with the original goal, so it makes sense when you have nested records to be able to include the schema at each level. Denenberg: this proposal has nothing to do with nested records; we discarded the nested record mechanism.

  Zeeman: what did the client ask for that it got back a record with a schema that it didn't know? LeVan: the client said give me an F record; it can understand some of the record, but not all of it. Selway: we didn't want everyone to have to know about CIMI. D Lynch: I may have missed some of the premise here, but I don't think you can just throw this stuff together; the only way you can do that is with new tag types. Tag types don't have inheritance. Do we have a slot in which to put the new schema identifier? Quibbling about the significance or insignificance of the length of the tag path with nested records.

  Denenberg: the issue to CIMI is not performance but apparent complexity. The point is an abstract record structure for CIMI, not for the CIMI schema, but designed by the CIMI profile. This general abstract record structure (TagSet G) occurs before you discover a schema. Lots of discussion and disagreement. Denenberg convinced D Lynch, and no one wants to argue with D Lynch so Denenberg won.

  Moen: this is an interoperability testbed and we just want to know if we're off track. CIMI is not trying to cast this in stone; they just want to implement it and see how it works. Hmm. More arguing about what Denenberg's commentary text says and actually means.