Thursday, January 22, 1998
Orlando, Florida
Denenberg briefly recapped the history of the attribute architecture working group, explaining how the working group's report (presented at the April 1997 ZIG) turned into the current draft document. He also discussed the need to apply this attribute architecture to the development of future attribute sets, including the replacement for Bib-1, which may or may not be called Bib-2. We need to decide whether the ZIG endorses this attribute architecture, what attribute sets need to be developed and by whom. All agreed that it is important that those who work on the development of attribute sets should include international ZIG participants as well as North Americans. Denenberg announced that a NISO workshop on the topic of attribute sets is scheduled for March.
As prelude to discussion, C Lynch reviewed the issues that motivated the working group on attribute architecture. The draft attribute architecture is the collective substantial intellectual effort of a group of people motivated by the following problems. The maintenance of attribute sets was becoming unmanagable. Attributes were being replicated in multiple attribute sets. It was difficult for people to take advantage of work done by others on different attribute sets. Since version 3 enables you to use attributes from multiple attribute sets in one query, how do you define the semantics of attributes that are intermixed from multiple attribute sets? The ZIG decided a while ago that we had to get out of the business of defining attribute sets for different disciplines (e.g., geospatial, museums); these attribute sets should be produced by experts in the field working within a framework provided by the ZIG. The new thinking is that the ZIG will only define generic attribute sets in the future. Bib-1 has problems that require a fresh start with a new attribute set for bibliographic attributes. The purpose of the NISO Attribute Set Workshop that Denenberg announced is not to define attribute sets, but to examine the domain and scope statements of existing bibliographic sets, frame the key questions (such as what do we do about Dublin Core), and map the terrain in which the issues fit. The current attribute architecture draft document suggests that the ZIG should define some basic attributes, but we need to be careful that we don't make some sets appear premiere or better than other sets (e.g., by incorporating the set into the standard). We also need to be careful that we don't unnecessarily introduce complexity. Strong datatyping would increase rigor and precision, but increase dependence on ASN.1 structures. Missing from the draft document is the notion of nesting Use attributes. There are in fact two variations: anchored and unanchored, and we need to reflect the ability to do both of those. Cliff thanked Ray for progressing this draft.
The proposed work addresses version 3.
Stovel: the draft does not discuss the relationship between attribute sets when multiple sets are used in a query. Denenberg: if you have within one attribute set definition a rule for how these attributes are used in combination with other sets which also have rules, what if the rules conflict? What takes precedence as far as the semantics are concerned? C Lynch: there are several ways this could happen, e.g., you can nest Use attributes out of multiple attribute sets, which means precedence would follow the nesting rules; there's also the dominant OID which establishes precedence and sets defaults for all types. We've done all we can with general rules about attribute interaction.
Wibberley: the draft introduces the concept of "attribute class," though it suggests only one class. C Lynch: the doc says only that if you combine attributes from multiple sets, the results are undefined. Denenberg: we don't currently see a second class of attributes, though that doesn't preclude the development of a second class. The draft does encourage people to re-engineer existing attribute sets according to the new architecture.
Stovel: why are structure attributes character valued instead of enumerated? C Lynch: it could be enumerated, but in many cases people want to give you a structured string like a date (rather than an ASN.1 structure) or normalized/unnormalized name. The problem with doing it enumerated is that it raises potential extensibility issues (both sides need to know the enumeration). When Levan did Dublin Core, he assumed that structure attributes were enumerated. M Taylor: why are structure attributes non-repeatable (e.g., in cases of indirection)? C Lynch: in that case it needs to be repeatable or break indirection out into a separate case. Denenberg will revise the draft to say "non-repeatable attribute" instead of "non-repeatable operand." The general character or rule of the draft is: don't allow for any repeatability unless you describe how it works. The semantics of repeating an attribute must be well defined to avoid ambiguity. When we see the need for an attribute to repeat, we should look carefully to see whether we folded multiple attribute concepts into the same attribute type. C Lynch: our philosophy about repeatability is don't use repeatability when there is another (better) way to do this, e.g., using Boolean operators. There is general concern that when you introduce repeatable attributes it becomes easier to make nonsense or contradictory queries, which will require additional rules for handling or interpreting.
Hinnebusch: indirection is not really a structure attribute anyway; it should be its own kind of attribute. Denenberg disagrees: he wants to keep indirection as a structure attribute with the exceptional quality of repeatability -- using semantic indicator values to define the semantics of repeating Use attributes; we don't want to make non-repeatability a general rule. C Lynch thinks Hinnebusch's proposal is good engineering. Either an attribute is non-repeatable or there should be detailed prose about appropriate cases for repeatable attributes. He agrees that we don't want non-repeatability as an iron-clad rule. Stovel: we should start with the rule that every attribute in the class has certain characteristics, then go from there. Denenberg: the general thinking is this is an attribute architecture for class 1 attributes, so everything in the draft applies to all attributes in the class; he suggests deleting the comment that this is unrepeatable. C Lynch's view is that everything in the doc applies to any attribute set that conforms to this class; however it is reasonable to think about defining an attribute set that does not populate every attribute type in the class. There is no obligation to have attributes of every type in an attribute set; some types could be taken from other attribute sets. He suggests adding a new type to class one: indirection, which is repeatable and enumerated.
Hinnebusch: Semantic indicators do not adequately cover the full nesting of Use attributes. The use of multiple attributes is because we have no structure in the query to carry this information (e.g., order of preference or nesting). There is a semantic indicator that says how to interpret multiple Use attributes, but we have situations where the client wants the server to chose the best alternative of nested attributes, and you can't do that with semantic indicators. Levan: semantic indicators only apply to the single attribute to which they are attached; they don't talk about how they interact, only how this particular one is to be interpreted. Hinnebusch: we're trying to squeeze things into the attribute architecture to avoid having to define a new query type to rigorously define and handle the structure of attribute relationships. Denenberg: using version 3 we can do what you want in a type one query; we can support nested attribute expressions by attaching semantic indicators to sequences of attributes.
C Lynch: the boundary conditions for the attribute architecture work are version 3 only, not backward compatibility with v2 or the evolution of a new version of the standard or the redefinition of the query structure or type. There are legitimate issues here, but we tried to stay within bounds. We did query type 101 to accommodate proximity. Denenberg: "but there was a screaming requirement for proximity. Is this a screaming requirement?" Hinnebusch is concerned that we are trying to accommodate a flaw in the query definition by squeezing it into the attribute architecture. He doesn't think the new attribute architecture adequately addresses the need for nested attributes.
C Lynch: it may be useful to look at the interactions. The construct of nesting is independent of what you embed it in; it transcends the structure of the query. Then there is the higher level construct of semantic indicators, which encode processing instructions in the query. If we push semantic indicators out of the attribute architecture and into the query structure, that may be more rational and the attribute architecture will hold. Ranges are another part of the problem with the query structure. Hinnebusch: when we invented semantic indicators, it was because this was going to be solved in a new query type, but then we didn't do a new query type. He wants prose in the doc that shows that this is a somewhat limited solution to the problem. C Lynch agrees; he suggested going even farther and including in the introductory comments how the type one query shaped this. One of the design constraints on the architecture was that this had to be applicable to the type one query. Denenberg agrees to put this prose at the top.
Waldstein wants to see a core set of utility attributes of all types (Any, serverChoice, creationDate, etc.). Denenberg urged caution regarding the term "core" to mean the basic minimalist set. Waldstein also asked about stop words. He considers any word that appears in half of the database to be a stop word; can this architecture accommodate this? (His stop words change depending on the relation attributes.) C Lynch: you turn this on if you want the server to search stop words, which may or may not work depending on the server; the idea is for the server to return what it used as stop words. The architecture can accommodate what Waldstein does.
Waldstein thinks the distinction between Database Fieldname and Use attributes is unclear. The issue is to be able to string multiple Use attributes attached to a single term to indicate a Boolean 'or.' C Lynch: there is a terrible mistake here. First issue: the question of using Fieldnames and Use attributes within the same query. Page 18 of the handout should specify mutual exclusivity "within a given term" (not per query); nesting has nebulous semantics, otherwise the semantics are clear. Stovel: why are the rules of mutual exclusivity different for Fieldname and Use attributes? She would like all references to mutual exclusivity to be dropped. Hinnebusch: Waldstein's model of use attributes as applying to a collection of fields (e.g., title information) is somewhat different from the traditional ZIG model that Use attributes are independent of database fields. Both models may be rational, but they are different. C Lynch: Fieldnames are concrete concepts; Use attributes are abstract concepts -- and there is enough question about the semantics of database Fieldname and Use attributes that combining them in the same operand only further confuses things. Hinnebusch: we have the concept of fieldname; can a fieldname actually be a collection of fields? If so, that would reflect Waldstein's model (e.g., of title as a collection of MARC tags). Do we need a way to specify groups of fields? C Lynch: the language in the draft defines "database fieldname" "in conjunction with a specific database schema," which can define shortcut names for some set of fieldnames. Levan: this is a slippery slope -- what are the semantics for excluding a field from a collection of fields? C Lynch agrees: we definitely don't want to go down that slippery slope. Levan suggests that the ZIG will not support exclusion.
Waldstein then asked about a way to optimize how we can do a query that excludes a particular subfield. Wibberley supports Waldstein's concern. Users can express multiple use attributes on a term, and in large databases that have lots of access points the query will be very lengthy. Hiding the complexity of the database with a few groupings helps users; behind the scenes having as many as 25 words with proximity expressions applied to many search points (attributes) it becomes a real mess expanding it to a full RPN Boolean query and then converting it into the actual query the database engine can handle. Waldstein's request is a practical consideration -- the 'or-ing' of use attributes on a term. Hinnebusch: in previous discussions there was quibbling about whether the semantic indicator should indicate an 'or' or an 'and.' Wibberley: one of the purposes of the semantic indicators was to disambiguate what multiple use attributes mean. Denenberg: Bib-1 provides three different semantic indicators, but none of them can handle the 'or' currently under discussion; what Waldstein and Wibberley want is against the definition in Bib-1, so he doesn't want to allow this. Levan doesn't care how this comes out; he sees it as an unnecessary simplification.
C Lynch: what we're really talking about here does not belong in an attribute architecture at all. What we want is a shortened syntax in the structure of the query for expressing multiple attributes per term, a structure that says "take this stuff and apply it to this list of attributes." In the same way, the semantic indicator does not belong in the architecture document; it's really a higher level thing dealing with the query. He would be happy seeing this discussed in the query structure rather than the attribute architecture. For the short run, there is a semantically equivalent way to do this with the type one query and the new attribute architecture -- though it is longer and suggests the need for query optimization. But at least that would de-couple query handling and attribute architecture of this class of attribute sets. Hinnebusch: if we're going to take on query restructuring, when do we do it? Zeeman: the semantic indicator is a parameter of the query, not the attribute set; but adding another value to that set (matchAny or matchAll) does no damage to the attribute set. Wibberley suggests using an External structure as a term to contain a complex query without defining a new query type.
Graubert: if you have multiple Use attributes with the same term and multiple Structure attributes, how do you handle it? M Taylor: if there are multiple uses and multiple occurrences, are they parallel lists? Denenberg: this was discussed on the list, but this is outside the scope of the current discussion. Levan: that's another example of mixing abstract and concrete subjects; you cannot combine occurrences of abstract concepts. Hinnebusch: if you use repeatable Use attributes to indicate nesting, then you can't use them to indicate processing. Wibberley: if we want to address the full-blown issue where the client truely has a detailed understanding of the database schema, and you want the third occurrence of something, the current query mechanism is inadequate; you need eSpec-1. Denenberg: you need nesting and occurrences, but not everything in eSpec-1. Disagreement about whether or not you need variants. (Hinnebusch says yes; Denenberg says no.) Waldstein: to solve the big problem you need to fix the query; all he wants is a semantic indicator for 'or.' Wibberley reality check: the Z39.50 RPN query type is totally inadequate, so they define a structure as an external and then indicate that this query is one of those things. Hinnebusch: we can do what we want by burying the query in an external without having to change the standard (dong a query within a query).
Denenberg raised a procedural or logistics issue. We've framed the Boolean issue. There are some questions here that we need to frame and then get opinions when we have the architecture workshop in a month or so. Waldstein: the reason this is coming up right now is because the new document says that you shouldn't use repeatability for Boolean expressions, but currently you have to do this to accommodate certain queries. Denenberg: we will revise the attribute architecture document for further discussion, but NISO's position is that the Attribute Architecture Workshop will not occur if the ZIG cannot reach concensus on the architecture. We don't have time to reach concensus here.
Finnegan and Wibberley raised issues about nesting. The ZIG agreed that the ordering should be top-down to be more intuitive and more in line with other aspects of the standard. Denenberg will change this in the doc. Zeeman wants nesting to be removed from the architecture document and defined by SemanticAction. Denenberg: the use of multiple Use attributes does not imply nesting, but the draft doc says that is does or at least can (page 18). Each attribute set needs to address the issue of nesting. The nesting model needs to allow for the combination of attribute sets.
C Lynch's view of the group's work and intent is that multiple attributes do imply nesting. This whole discussion illustrates that the semantic indicator should not be mixed up with attribute sets at all, that it's really a higher level concept for conditional processing of attributes applied to a term; the Boolean business is also in this category. Neither of them having anything to do with attribute architecture. Hinnebusch: would it be possible to modify the doc to say that there are things in here that are only appropriate for the type one query and that a future document will address the new query type (followed by a revision of the architecture doc)? Or maybe the doc should be silent on this topic. Waldstein can continue to violate the standard or use STAS where it is legal (via the external).
Denenberg thinks it's a big mistake for the document not to talk about nesting. And once you talk about nesting you've opened the can of worms. We do not have concensus on C Lynch's suggestion that the use of multiple attributes can or should only mean nesting. Zeeman: that was certainly the assumption of the architecture working group because we failed to keep a semanticAction in mind. Loy: is the idea of nesting more important than the issue of repeated attributes? More people appear to be using repeated attributes than are using nesting. Should we look for an architectural solution to nesting using eSpec? Levan: the whole idea of nesting Use attributes feels wrong to me; if we agree that use attributes are intended to be abstract, the idea of an abstract structure is an oxymoron because you don't know what the relationships are. You can nest fieldnames because they are concrete (tied to a database schema), but you can't nest Use attributes because they are abstract. The structure of the record should only be supported in the context of Fieldnames with an associated shared Schema. Wibberley and Finnegan agree with Levan; to talk about nested search points you need a schema, which indicates the structure of the record for retrieval. Graubert: could a lot of these problems be solved with a semantic attribute type that described the model of what was being used? Hinnebusch: how does that solve the problem of nesting non-fieldname attributes? The ZIG agreed that nesting will require a Schema and be expressed in Fieldnames. If that's the case, is Fieldname the right name for this access point?
C Lynch: you're on a slippery slope. Reality check -- you're starting to re-engineering the fundamentals of Z39.50 on the fly. If you want to re-engineer Z39.50, it shouldn't be done as part of straightening out the attribute architecture. You need a new data model with implied hierarchy, which should start with a whole new set of assumptions about the understanding of the data structure shared between client and server. We've introduced some enormously complex query issues that go way beyond the scope of attribute architecture. Denenberg: fine, but what do we put in the doc? Hinnebusch: say in the doc that this is based on the type one query structure and that there are limitations.
Topic tabled. To be discussed at a future meeting.
The original intent of Dublin Core was to define a small set of standard elements. There is a reasonably vocal community in favor of using this small set, which turned out to be 15 elements. There are others who want more semantic specificity, such as qualifiers 15 elements, so a group is working on this. There are still others "cunningly reinventing MARC semantics."
The ZIG needs a way to cope with the original 15 Dublin Core attributes and the qualifiers that they are coming up with. Nine of the 15 attributes are already in Bib-1. Levan proposed adding the other six to solve the version 2 problem. The GILS and CIMI communities need these. For version 3, he recommends adding semantically rich attributes for Dublin Core, incuding Use and FieldName attribtues. Dublin Core qualifiers must also be addressed in some way.
Wibberley agrees with Levan's proposal. Others disagree: since GILS inherits Bib-1, adding six attributes to Bib-1 to accommodate Dublin Core will give GILS double attributes for the same semantics. C Lynch: the GILS folks assert that they have already accommodated all 15 Dublin Core attributes and don't like the idea of a separate Dublin Core attribute set or the idea of embedding Dublin Core in Bib-1. Denenberg: prior to the Copenhagen ZIG, GILS folks recommended adding all 15 Dublin Core elements to Bib-1. Hammer doesn't feel stronly about it one way or another. Stovel initially objected to adding Dublin Core to Bib-1, but now accepts Levan's proposal. Finnegan's colleagues did similar work to Levan and with the same results (proposal). Waldstein thinks it's the wrong path because of table overhead and the proliferation of logical access points. Tibbetts isn't sure that we can look at Dublin Core as setting precedent for Bib-1. Levan: handling Dublin Core requires the new attribute architecture to handle Dublin Core schemas, qualifiers, etc. Wibberley: how will the work that's going on in Dublin Core and the work in the attribute architeture keep in sync? We don't want to end up with constructs and concepts in our attribute architecture that don't map to Dublin Core. Levan and others will coordinate the work between Dublin Core and the Attribute Architecture group.
Denenberg: at the Copenhagen ZIG, we accepted C Lynch's proposal for handling Dublin Core, which was to add all 15 attributes so that we don't have to disambiguate. C Lynch: we decided that we want to get out of the business of defining semantics for various attribute sets. Dublin Core will provide the semantics; the ZIG is only doing the encoding. The focus of Dublin Core is the web and RDF contexts; they do not see Z39.50 searchin as a high priority and therefore will probably not make a lot of changes to conform with the ZIG's attribute architecture. Levan's proposal is useful, but we need to realize that Dublin Core is unstable about everything beyond the 15 attribute names. C Lynch's view is that there will be Dublin Core with 15 usage attributes that correspond with 15 elements.
Hammer is concerned, perhaps objecting, to dumping all 15 Dublin Core attributes into Bib-1 because this will create problems for GILS. (??): we have to face the fact that Bib-1 is going to be ambiguous and must be disambiguated with profiles.
Wibberley: Levan's proposal addresses Dublin Core elements used as attributes; they were not distinguishing between access points for searching vs retrieval points for presenting. Have we addressed how the ZIG will handle this? See the last paragraph of the proposal about elements for record retrieval (tagset-G). Stovel objects to the last paragraph. Wibberley: are we making vague semantic mappings to other elements in tagset-G or are we adding all new elements with semantics from Dublin Core? Levan: no mapping. Hammer likes the last paragraph, but he disagrees that "the solution is simple and non-controversial." Levan agrees that he ignored the whole issue of more complex records than GRS-1 and will address the more general topic of retrieval beyond just GRS-1 in the future.
Denenberg is concerned about inflammatory language in the proposal. He and Levan will discuss this offline.
There was disagreement about whether the ZIG needs to discuss the content of the Dublin Core attribute set. Finnegan: are the Dublin Core elements Use attributes or Fieldnames? That's up to the Dublin Core folks to decide. Wibberley: are defining attributes that map to the Dublin Core elements? C Lynch: assuming there is a direct relationship is dangerous; we cannot assume that Dublin Core elements will only be used with databases indexed according to the Dublin Core.
Two positions: Lynch versus Hammer (add Dublin Core elements to Bib-1 versus don't add them). Levan initially opposed dumping this stuff into Bib-1; now he's proposing it. He changed his position philosophically because of the new attribute architecture, which implicitly seems to deprecate Bib-1.
With the understanding that Bib-1 will eventually be deprecated and replaced by a next-generation Bib-2 attribute set, the ZIG tentatively agreed to add all 15 Dublin Core elements to Bib-1 with explicit Dublin Core semantics and an explanation for handling in v3. (There will be no mapping to already existing Z39.50 attributes in Bib-1.) Denenberg thinks we need a brief comment period on this, but that leads to scheduling problems and CIMI needs this now. Some disagreement about whether the ZIG can approve this now, or whether we need a period for people not at the meeting to comment. Levan will revise the proposed based on this discussion and post it for a two-week comment period. Denenberg will inform the GILS folks and assign the Bib-1 attribute numbers so developers can move forward.
Stovel: should the ZIG define Utility attributes for stuff that is independent of the database, e.g., Any? Denenberg: should there be a Utility attribute set? If so, there needs to be close coordination of this and the developent of a Bib-2 attribute set. Who should own the Utility set? This issue will be taken to the Attribute Architecture Workshop.
St-Gelais explained her proposal. Holdings items are typically physical items. The 852 or 863 field defines the bib unit (e.g., whether it's a single or multi-part thing). She described the general structure of the OPAC schema. Zeeman is uncomfortable with a one-to-one equivalence of circulating item and serial part; he wants to be able to model the whole such that the whole (containing parts) can be a single circulating item. He wants to be able to nest holdings items so that something with holdings can contain other things with holdings that contain other things with holdings. How can he describe volumes and the issues that comprise them and circulate items separately? Stovel: the diagram looks hierarchical, but the schema does not appear to be hierarchical. Hinnebusch: the diagram illustrates the general structre of the GRS-1 encoding of the OPACRecord schema; there will be a holdings subtree for each circulating piece; you would have a HoldingsAndCircData for each piece. St-Gelais: circulation is a property of the item; either it either circulates or it doesn't. Circulation information is not part of summary holdings. When you view summary holdings, you can then ask for detailed holdings or holdings and circulation information on a particular item. That's exactly the model Zeeman wants.
HoldingsData is repeatable; HoldingsAndCircData is not. Each HoldingsData subtree has its own enumeration and chronology.
Tibbetts: are we modeling holdings as a list of locations with items, or are we modeling a list of items that have locations? The latter. Why do we need additionalInfo in OpacRecord? The Univ of CA may need it, plus it's just good to have the option to add additionalInfo. Hinnebusch added the capability to handle electronicHoldings based on an email comment from Waldstein; electronicHoldings items allow the return of the electronic document itself. Stovel: for clarity, rename electronicHoldings "electronicObject." HoldingsPointer was added for union catalogs to point to the actual item, e.g., to a holdings URL. St-Gelais: why not use additionalHoldingsInfo for this pointer?
Levan: what's the intent of this data; why transmit it? Hinnebusch: to show users what the holdings are for a particular item; union catalogs may return information to search other locations for holdings. Maybe electronicObject needs some structure to indicate whether it is a pointer to the object or the actual object. Is there a difference in modeling electronic holdings versus physical holdings? Is this the right place to discuss this? Levan thinks this topic -- at this level of detail -- should be discussed in a library setting, not the ZIG. We don't discuss application specific details for GILS, for example, at the ZIG. Why do we deem OPAC applications central to Z39.50? Do we? Yes. Levan over-ruled because some folks came to the ZIG specifically to discuss this topic.
Hallen: HoldingsPointer should be reserved to reference holdings that can be retrieved as described here. Align the vocabulary. Counter to the Zeeman/Turner profile, he wants to discourage (rather than encourage) the delivery of location and holdings information within MARC records.
Waldstein is not sure if this schema can do what he needs. Hinnebusch thinks he can do what he wants using additionalHoldingsInfo to carry price information, for example.
Roby thinks we need multiple copies of (?). We need some way to deal with tables of contents and individual articles available for electronic delivery. Stovel: that's outside of the scope of bibliographic holdings in the OPAC environment, which is what this proposal addresses. OPAC is not an A&I database (title-level, not article-level). The issue here is the level of bibliographic description; OPACs do not describe individual articles within bound works. Yes, but it would be nice to be able to deal with tables of contents and individual articles....
Tibbetts needs to be able to link objects at the location level (several levels below where the proposal places it). She really needs this modeled as locations that have copies, not copies that have locations. Zeeman suggested a recursive model that would allow holdings to point to other holdings records. ??: a simple working model is one holdings record, one physical object. Zeeman strongly objects. ?? strongly objects to the recursive model. Hinnebusch: does the proposed schema meet traditional needs for holdings of physical items? Perhaps we can look at t he electronic requirements later. Tibbetts: no; she needs four levels to reflect multiple locations per holding, multiple levels per organization, and multiple holdings record per item: region, institution, location and location-within-location. If we add four levels for Tibbetts, do we need more? Should it be recursive? Tedious debate. ??: does this information really belong in HoldingsInformation, which is designed to specify which building and which shelf? Roby: this is the right place for it.
Do people need time to digest this? Should we take this discussion to the list? Stovel wants a description of the data elements, e.g., what is an electronicObject? Has anyone looked at the proposal to merge monograph and serial holdings (Z39.80?)? That was not designed to be machine readable. Turner wants to see this forwarded very soon; she would like more details (currently many things are unclear), then she'll distribute it to her staff for review. The ZIG needs examples. Randall is unclear on the relationship between the physical piece level and the serial itself. The electronic representation of these items does not map to the physical counterpart. Hinnebusch: do we want to have a place in here for electronic pointers to the electronic articles within the item? Yes. Hinnebusch will re-do the drawing to make it clearer.
Denenberg reviewed where we were, where we're going, and the serious urgency of having this completed within weeks of the August 1997 ZIG in Copenhagen. Is that urgency gone? If we take this to the list, it could be a long time until we settle it. Hinnebusch and Zeeman disagree: we have details now that we didn't have before; we have done some work on OPACRecord, which wasn't done in Copenhagen. Turner: the urgency to have standardized delivery of detailed holdings is still there, but we have advanced. Who has the resources to do this work? Denenberg wants the ZIG to formulate a plan for the next few months. Hinnebusch and St-Gelais will revise the schema docs and drawings based on this ZIG discussion, and post them to the list in a month. This is a profile; we'll do it as quickly as possible. Levan: remember that the ZIG does not approve profiles.
Wibberley: will support for electronic holdings, down to the article level, be included in the revision? Will this be an adequate mechanism for retrieving holdings information for today, when holdings are a mix of physical and electronic? Hinnebusch: yes, that's within the scope of the revisions; what is out of scope is handling A&I databases.
Turner: the draft profile incorporates the discussion from numerous ZIG meetings, Denenberg's email and other sources. Can the ZIG endorse this profile so that vendors will have the confidence to implement it? Stovel: are the element set names, e.g., summary holdings, meant to be tied to the OPAC schema? Zeeman: they were not formulated with the OPAC schema. Denenberg: when we nail down the schema, we'll tie the element set names to the schema. St-Gelais doesn't think they should be tied together. Zeeman: but a system that does USMARC needs to be able to address this info in different MARC formats. As a service provider, if you don't specifically ask for holdings you will not get holdings for MARC; you're going to have to have a standard way of retrieving holdings. Hinnebusch: if someone has holdings data in their bibliographic record, this profile does not require them to take it out. St-Gelais wants the sentence about "encouraging" use of MARC holdings deleted. Turner agrees to delete the sentence; the profile is not intended to suggest that you can't do what you have been doing.
Waldstein is concerned that the schema we're discussing will not enable us to handle a full-blown search on the end of a URL; we should solve this problem in Z39.50r. Levan: there is no grammar for Booleans. Hinnebusch agrees that the profile is not adequate for all situations. We'll discuss this again after finishing the schema. Zeeman: assuming that the elements in the profile are not the final set, tieing these element set names to a schema is to disambiguate things.
??: will there be a way to sort by location? Zeeman: there is no way to express sorting within the holdings record. But you can sort a bunch of holdings records using standard sort.
If approved, this would be a Z39.50 implementors agreement. Wibberley opposes the proposed agreement because it deprecates current practice. Denenberg disagrees, though perhaps item 3 suggests deprecation: "clients are encouraged not to use the merge feature of Sort." Is it acceptable if we remove item 3. Levan: the typical way to merge result sets is to 'or' them, which is a statement of fact. Hinnebusch: many sort packages use merge. M Taylor: what if we say, if the client uses the merge feature of sort, the size of the resulting set is unpredictable. Denenberg wants to keep some version of item 3 in the doc.
Some disagreement about how discussion of this topic initially started. Wibberley suggests that we address the problem identified by finding a clear way to convey the resulting number of records in sort. Waldstein disagrees; he would be upset if he gave a result set to the server to be sorted and got back a different number of records -- don't automatically de-dup. How many implementors have the problem of sorting a result set and ending up with a different number of records if they haven't asked the server explicitly to de-dup?
Denenberg: two alternatives: an implementors agreement or changing the standard. Stovel: there's a different alternative implementors agreement: merging result sets should have the sum total number of records of all result sets in the merged set. Denenberg: that won't work; if it doesn't have the sum total, what then? Hinnebusch says the result set model currently says only that there is a pointer in the result set to a record. We're opening another can of worms if we mess with the result set model.