Notice to the reader: This document is no longer in effect. It has been archived online and is kept purely for historical purposes.

About the Profile

The Profile

The Maintenance Agency

• Amendment Procedures

• Defect Report Procedures

Resources

Bath Profile Meeting

September 24 -- 25, 2000
St. John's, Newfoundland

Minutes of the September 24--25 meeting

Chair:  Carrol Lunau, Library and Archives Canada
Recorders: Paul Miller and William E. Moen
Attendees:  See attached list.

Day One:

Carrol Lunau welcomed all participants to the meeting and suggested a way to revise and prioritize the agenda of items she had circulated.During the introductions, participants were asked to identify issues and concerns they wanted addressed.Through this process, the following was accepted as the work items for the two-day meeting:

• For discussion on Sunday:
  • Record Syntaxes in Functional Area A (XML, SUTRS)
  • Functional Area A SCAN - redundancy of terms
  • Functional Area C
    • XML DTD
    • Requesting a DC XML record
  • Functional Area A - including Additional Searches
    • Position and Completeness attributes & field/subfields
    • Structure attribute for Date Search
    • See Texas profile Level 3
    • Format
    • Publication Date
• For further development on Sunday night and discussion on Monday:
  • Functional Area B - Holdings Level 1, additional requirements
  • Normalization
    • What is the scope of the normalization problem
    • Normalizing search term
    • Normalized author search
  • Character Sets
    • Character sets and SUTRS
  • UNIMARC
• For discussion on Monday:
  • Scope of Profile
    • For consideration: ILL, NCIP, searching other resources (e.g., web resources, A&I databases) etc.
    • Collaborative digital reference
  • Stumbling blocks to adoption
  • Evolution, Changes, Stability of Profile
  • Directory Services/Explain Lite
  • Best Practices Guides - what is needed?
    • Indexing recommendations
    • Operational issues, timeout, etc.
    • Guidelines for SUTRS formatting

This meeting followed on the ACCESS Y2K Conference, and a number of participants from that conference attended the Bath Profile meeting.Given the various levels of knowledge about the profile in the group, Bill Moen provided the participants with a recap of the development of the Bath Profile and how it grew out of several previous and concurrent profiling efforts.He also addressed the relationship between various profiles such as Bath, Z Texas, and the NISO profiling effort that is beginning.

The following sections summarize the results of discussion and agreements reached on the agenda items.

1. Functional Area A: Record Syntaxes (XML, SUTRS)

The discussion concerned record syntaxes and the business case/application for deciding on specific syntaxes.The agreement was that XML is not necessary at Level 0.

Through this discussion, there were suggestions for tightening up the scope statement of the profile, especially in this functional area.Is this functional area for virtual union catalogs? For resources other than library catalogs? Functional Area A is defined for Basic Bibliographic Search & Retrieval, with Primary Focus on Library Catalogues.This implies that the searches defined for this area can be used for other "electronic resources."

One thing that needs to be done is to check on the genesis of the "and other electronic resources" statement for Functional Area A, and possibly tighten the language and focus by removing that.

Agreement: The requirements in Section 5.A.0, Functional Area A: Level 0 Basic Bibliographic Search and Retrieval, will be changed as follows:

Uses: The concept of VUC is not clearly defined in terms of service and policy.The Bath Profile specifications are intended to accommodate a diversity of VUCs.

• Level 0 implementations will support forms of virtual union catalogs (VUCs).Extent of robustness of VUCs will be determined by the syntax supported. For example, if a VUC includes a server that only supports UNIMARC and a server that only supports MARC21, a client may only have SUTRS records as a common syntax.In this case, robust VUC services such as de-duplication and the reporting of associated holdings are not possible. However, a more likely scenario is that a VUC will be based on certain homogeneity of implementations based on geographic, political, or other organizational jurisdictions.In these cases, all servers will be supporting a common MARC syntax that will enable deduplication services and reporting of associated holdings information
• When talking about VUCs, the model is that some organizational arrangement among libraries exists to form a VUC (e.g., on a province-wide basis, a consortium, a library system).A user should not expect to form a robust on-the-fly VUC by doing a broadcast search to any random selection of Bath-compliant Z39.50 servers.
• Level 0 specifications will allow a Bath-compliant client to interact with servers that support the same MARC record syntax as the client as well as to interchange data with a server that doesn't.In the latter case, SUTRS provides a way to provide the client data in a way that allows the user to at least view the record.
• Level 0 is intended for primarily recall-oriented searches across a set of library catalogs using a core set of basic searches useful to general end-users, reference and technical services librarians.

2. Functional Area A SCAN: Redundancy of Term and DisplayTerm

The suggestion was to change the wording in the profile (Section 5.A.1SCAN. Functional Area A: Level 1 Use of SCAN) regarding client and server responsibilities for sending/displaying the term.

Agreement: Wording will be changed from:

Z-clients must support Term and DisplayTerm, and Z-servers should always send both Term and DisplayTerm (which may contain the same value), and Z-client should always display the DisplayTerm.

   to:

Z-clients must support Term and DisplayTerm and display the DisplayTerm if sent.

3.Functional Area C: Record Syntax Issues & XML DTD

Paul Miller summarized some of the problems with the XML DTD for Dublin Core in that it doesn't provide an extensibility mechanism for servers to add locally defined elements and send them in a record.This lack of extensibility in the DTD is not something the Profile can fix.

Agreement: Level 0 record syntax requirements will be changed from:

Z-clients to support SUTRS and XML

Z-servers to support SUTRS or XML

   to:

Z-clients to support SUTRS

Z-servers to support SUTRS

Level 1 record syntax requirement stays the same using the Dublin Core Schema and the current DTD with the recognition that it is not extensible and servers will not be able to return elements in addition to those designated in the DTD. Record syntax is XML.

Level 2 in Functional Area C will be specified to increase the flexibility of retrieval by providing an RDF schema mechanism that will allow extensibility. Record syntax will be XML.A Schema for DC in RDF will be specified.(Paul Miller will provide additional technical language for this specification and try to unbundle the three uses of schema (Z39.50, XML, and RDF)).

A request for appropriate OIDs for the DC DTD and the RDF schema will be submitted to the Z39.50 Maintenance Agency.

4.Functional Area A: Searching and Searches

A number of issues were covered in this discussion.

1.  Position and Completeness attributes & field/subfields.  The semantics of these attribute types, particularly the Completeness attribute, are not clear.

   Agreement: Clarify the semantics of "incomplete subfield" as meaning "incomplete access point" in profile text.This is necessary to get past the confusion in the semantics of these values for the Bib-1 Completion attribute.

2.  Should clients be allowed not to send all attribute types and values as defined for the searches?

   Agreement: No change.Clients conforming to the profile must send all attribute types and values specified for a search.However, wording in the profile should be included for guidance to servers.Since Bath conformant servers will receive queries from non-Bath clients, those servers should not fail a search simply because the query doesn't include all attribute types.

3.  Additional searches. A number of new searches were discussed and agreed to being added in Functional Area A, Level 2.

   Agreement: Four new types of searches are being recommended for inclusion in Level 2:
   

4. 1. Serials/Periodicals Title Searches
      • Four title searches based on the patterns used in Level 0 and Level 1 Title searches will be specified.
      • The Use Attribute value will be 33, Title Key
   2. Format/Material Type Search
      • Can only be used as a search delimiter
      • Two format/material type searches included, for phrase and keyword
        • Use = 1031 (material-type)
        • Relation = 3 (equal)
        • Position = 1 (first in field)
        • Structure = 1 (phrase) & 2 (word)
        • Truncation = 100 (do not truncate)
        • Completeness = 1 (incomplete subfield)
   3. Language Search
      • Intended for search related to language of the bibliographic item, not language of the record itself.
      • Can only be used as a search delimiter
        • Use = 54 (code-language)
        • Relation = 3 (equal)
        • Position = 3 (any position in field)
        • Structure = 1 (word)
        • Truncation = 100 (do not truncate)
        • Completeness = 1 (incomplete subfield)
   4. Date Range Search
      • Can only be used as a search delimiter
      • Based on the Z39.50 Implementors Agreement #1 for Linear Range Searching (see http://lcweb.loc.gov/z3950/agency/agree/range.html )
      • Uses the Relation Attribute 104, within
        • Use Attribute = 31 (date of publication)
        • Relation = 104 (within)
        • Position = 1 (first in field) ??
        • Structure = 4 (date)
        • Truncation = 100 (do not truncate)
        • Completeness = 1 (incomplete subfield)

Day 2:

The first item on Day 2 was to review the agreements reached on Monday.Copies of the agreements were distributed and reviewed.

There was some concern expressed about the decision regarding Functional Area A Level 0 Record Syntax.As a result of additional discussion, the suggestion is to make XML optional at Level 0. For exchanging MARC records in XML, the suggestion was to use the Open Archives XML DTD for MARC Records (see http://www.dlib.vt.edu/projects/OpenArchives/oa_marc.html ).

The following are agenda items and agreements from Monday's discussion.

1. Normalization

One of the areas of the information retrieval system and Z39.50 that affect search results is the normalization routines run on the data and the queries.This topic was first raised in terms of how to do normalized name searching.

If we are going to discuss indexing recommendations for MARC records to support the Bath and Z Texas Profiles, it seems appropriate to discuss normalization rules and practices as well.The issue is that in the environment of library catalogs, we will be dealing with an installed base and trying to get interoperability with existing systems that may not likely change indexing and normalization practices. Although normalization is an important issue, it may be an impossible issue.

Agreement: 

The agreement was that the Profile will not prescribe indexing rules but point to a set of best practices or recommendations for indexing such as those being developed by the Texas Z39.50 Implementors Group (TZIG) ( http://www.unt.edu/wmoen/Z3950/ ). This topic should continue to be on a To-Do list of things to address.

2. Character Sets

In the discussion about character sets, it was clear there would be ongoing discussions about this.And it will be important to highlight how character set issues affect interoperability. But for now, the following agreements and understandings were reached.

Agreement: 

Remove the paragraph from Section 4.3.3. Retrieval: Record Syntaxes, "Interoperability requires use of standard character sets."

Level 0:       
For SUTRS records, Latin 1 for retrieval.8859-1.

Level 1:       
Stays as is.

3. UNIMARC

The profile required UNIMARC for record syntax in Functional Area A, and it will be important to continue to treat UNIMARC and MARC 21 equally.It's also important that those implementors and organizations who want UNIMARC in the profile be involved with discussions about UNIMARC.

4. Scope of Profile

This item was to discuss possible future additions to the profile by addressing what the scope of the profile is or should be.For example, the ONE-2 Profile will cover ILL, update, circulation, and document delivery.Other possible areas for profiling would be search and retrieval of non-catalog library resources such as A&I databases, etc.Potentially the BP could address the next steps after finding the bibliographic records - holdings, ILL, document delivery.The sense of the group was that we should consolidate areas specified in the current release of the profile and not take on any new functional areas.

5. Holdings

Rolande St-Gelais and Poul Henrik Jorgensen prepared a presentation for introducing the issues related to holdings and some recommendations.Through the course of their presentation, it was clear there are many different usage scenarios for holdings information.

There was a discussion on basic models underlying our ideas about holdings information and their retrieval.Model 1: a unified bibliographic and holdings database.Model 2: separate bibliographic and holdings database, with a need to search the holdings database

Ralph LeVan articulated an expanded view of the models:

1. Embedded holdings in bibliographic records - can ask for holdings info
   • Do a query for book and location
2. Separate unindexed holdings info and bibliographic information but in a unified logical database
   • Do a query and then present bibliographic and holdings
3. Separate bibliographic and familiar holdings
   • Use a local control number
4. Explicitly separated bibliographic and holdings info.
   • Magic key will be needed.
   • Client must be able to pull out a magic key to turn around a special key.
   • Use a configuration table for host info for bibliographic and holdings
   • Set up a hierarchy of keys for turning around the holdings search.
   • Use standard identifier search with values of various numbers/control number/isbn/issn
   • Is there a best standard number … maybe not….use local number, isbn/issn, LC Control Number, etc.

To make progress at this meeting, the group focused on the following minimal requirements scenario for holdings information.

• "I have found a record for an item I'm interested in from a known library. Now I would like to see holdings information about this item."

The group came to agreements on reporting levels and on the record syntax for interchanging holdings information as follows.

Agreement: 

For this, the following Holdings Schema reporting levels are required at the Functional Area B conformance levels:

• Level 1 -- B1 and B2
• Level 2 - C1 and C2
• Level 3 - B3, B4 and C3, C4

Agreement: 

There may be cases where XML is less powerful than GRS-1, but what we need for Holdings is handled well by XML.Holdings information will be interchanged in XML using a XML schema based on the current Holdings Schema that is presented for GRS-1.All requirements for GRS-1 in Functional Area B will be dropped.

Agreement: 

Assume a Model #4 above, where there is an associated key between the bibliographic database record and the holdings record/information for the item represented by the record.The client will use one of the standard identifiers from the bibliographic record to query the holdings database and retrieve the holdings information.

6.Evolution, Changes, Stability of Profile

The Library and Archives Canada is the maintenance agency for the Bath Profile.It needs to develop some policies and procedures to address how changes to the Profile can be made (e.g., based on a meeting, on discussion on the listserv, etc.) and when the changes to the Profile are significant enough that the entire Profile should be put through the IRP process again.

It is important to have the Profile be perceived as stable, with only minimal (if any) changes being made to specifications that have already been approved.Stakeholders in the Bath Profile need to be involved in a timely fashion to voice their comments on proposed specifications to ensure widest review and comment prior to adoption. However, there was a suggestion that the Maintenance Agency reserve some dictatorial power in its decisionmaking.

Agreement: 

Bath Profile Discussion List is the formal place for approval.Formal proposals will result from this meeting and be posted to the list as recommended changes to the Profile.Based on responses, the Maintenance Agency along with a group of advisors (e.g., the original Bath Profile Development Group) can decide on specific changes.

There is a need for procedures to protect stability. Possibly, the Dublin Core effort can inform some of the procedures for the Profile.

7.Normalized Name Search

At the end of Monday, the group discussed the issue of normalized name search.This is a search that is problematic because of the issue of normalization rules in effect at a particular system.LeVan suggested that the behavior we are trying for can be described as:

• a phrase search with truncation (and with the example in the profile - the phrase search includes left truncation, something that is not readily or cheaply available)
• a word list search with implicit adjacency operator.

Implementation experience with the Profile may help us understand how best to specify this search in the future.

8.Things To Do

Although the group agreed to consolidate the profile at this point and not add new functional areas, participants agreed that a number of things should be addressed in the future:

• Need to develop other usage scenarios for holdings information and searching holdings information to inform Functional Area B specifications.
• Discuss the appropriate XML DTD/Schema for MARC 21 in Functional Area A, Level 1.
• Continue the discussion on indexing and normalization and support the development of best practices documents covering each.

The Bath Profile Maintenance Agency will start to collect and post on its website information about who is implementing the Profile (end user organizations as well as integrated library system vendors and other Z39.50 implementors).

The website will also contain information about the Bath Profile and documents to assist in educational efforts about the Profile.

9. Future Meetings

It was agreed that the next meeting would be held in conjunction with the ZIG meeting scheduled for the spring/summer 2001 in England. The group will meet twice a year and one meeting will be held in conjunction with a major library conference in order to encourage continuing participation of librarians in the meetings.

10. Thanks

Carrol thanked Slavko Manojlovich and the staff at Memorial for arranging the meeting and providing refreshments for the coffee breaks.

Bath Profile Meeting Attendees