MMG Special Meeting
Background Documents
Wednesday March 6, 2002
SML Room 409 at 9:00 a.m.


At our last meeting at the end of January the MMG decided that the + symbol used in LC call numbers before the cutter should be moved to the end of the call number. EXAMPLE: Q1 +S17 (LC) will become Q1 S17 (LC)+

Left undecided was the question of whether to also add a suffix (852 |m) to these call numbers with the word "Oversize." SML and CCL want to include the Oversize suffix in order to give the readers an additional warning that this material is shelved in a different place. EXAMPLE: Q1 +S17 (LC) would become Q1 S17 (LC)+ Oversize

Sue Crockford-Peters surveyed Orbis libraries to determine whether any other libraries want the oversize suffix added. The results of that survey are:

Add Oversize Suffix
Art, BAC,REF, BAC,PD, CCL, Classics, Medical, Ornithology, SML, SML,AOB, SML,MSS

Just +
Astronomy, BAC,RB, Chemistry, Divinity, Drama, Engineering, Forestry, Geology, KSL, Math, Mudd, Music, SSL, Stats, Film, EPH, BRBL

ADVANTAGE OF INCLUDING A SUFFIX: For those libraries who shelve oversize materials in a separate location, the suffix will help direct readers to the oversize shelves. The + is very subtle and readers frequently miss its significance. Moving it in Voyager but not on the spine label will add confusion to an already somewhat perplexing situation. The oversize suffix will help clarify the materials' physical location.

DISADVANTAGE: Technical services will experience a loss in productivity from the implementation of the oversize suffix. They will need to remember or refer to a list of locations that get the suffix whenever they catalog an oversize item. Errors are sure to be introduced which raises the possibility of record checking by another unit (more loss in productivity) in order to ensure the oversize suffix has been applied correctly.

Selectively adding the Oversize suffix will increase the cost of this customization. We do not have a quote yet (since we haven't told Endeavor what we want to do), but estimate a few thousand dollars to move the +. Double the cost if we are selectively adding the oversize suffix.

Note that the Oversize suffix is not appropriate for the entire database. In libraries that interfile their oversize materials with regular materials the oversize suffix would mislead readers.

Sue Crockford-Peters and Joan Swanekamp will review discuss the advantages and disadvantages of the oversize suffix in more detail at our meeting.

1) Move the + to the end of the LC call numbers and add an oversize suffix based on the individual libraries' request as indicated in the above list, or
2) Move the + to the end of the LC call numbers only.


We do not store our non-Roman script tags in our NOTIS records. In order to have this data available in Voyager, we need to order a snapshot file from RLIN and load these records into Voyager. The time to order the snapshot file is approaching. In reviewing the status of Endeavor's glyph server, we do not think we should request a snapshot of all of our JACKPHY records.

Although Endeavor's glyph server is not currently working correctly, based on the work I reviewed at the last Unicode Task Force meeting, I remain optimistic that for CJK records, the glyph server will be operational this Summer. I recommend we include all of our CTYO records in the RLIN snapshot request. In the event that the glyph server is not working correctly in July, we will suppress the display of CJK by keeping the glyph server down.

The glyph server will also be operational, I believe, for records with Hebrew tags, although these will be aligned along the wrong (left) margin. Our data in RLIN, however, is flawed.

Based on RLIN's instructions we entered all multi-digit numbers in a way that will make them display reversed in Voyager. Dates of publication will display backwards, e.g., 2001 will display as 1002. Birth and death dates will display backwards, e.g., 1929-2001 becomes 9291-1002. Multi-digit volume numbers will also be reversed, e.g., we will see v.1, 2, 3, 4, 5, 6, 7, 8, 9, 01, 11, 21.

Endeavor is committed to trying to flip these multi-digit numbers in Hebrew records during the conversion of the database from its current encoding to UTF-8, but that fix will not occur until sometime next Winter. Audrey Novak, Joan Swanekamp, Daniel Lovins and Nanette Stahl recommend that we exclude our CTYH records in the RLIN snapshot request.

Arabic records present a different problem. For those records the glyph server does a very poor job rendering the characters. Arabic characters appear as separate characters rather than linked characters. Endeavor might solve this problem within the timeframe of our dataload, but we can't be sure.

Our dilemma is that if we include our CTYN records in the RLIN snapshot, we have no way of excluding them from a load to Voyager. And if we load the records to Voyager, we have no way of suppressing the display of the Arabic script. It's an all-or-nothing situation. If the glyph server is down no non-Roman scripts will display. If the glyph server is up any non-Roman script in an 880 tag will display. Based on the uncertainty of fixes for the display of Arabic, I recommend that we exclude CTYN records form our RLIN snapshot request.

The content of the RLIN snapshot file.


I will be starting a group to address publicity about Orbis2. I would like to hear suggestions about:
- Group membership
- When should we start announcing Orbis2?
- How much publicity should we start with?
- Kinds of publicity (Nota Bene article, newspaper articles, through the Front Door, on the Orbis page, posters, information sheets)?
- What should we do about reader instruction? Reader "training" is not part of NELINET's training package, nor is it included w/in the OPAC implementation group's charge. Should the publicity group address this issues? Should the SQIC instruction group? Which group w/in the library now "owns" Orbis reader instruction/training?

Return to Orbis2 Implementation Site