Search (1 results, page 1 of 1)

0.008167865 = product of:
  0.01633573 = sum of:
    0.01633573 = product of:
      0.03267146 = sum of:
        0.03267146 = weight(_text_:systems in 340) [ClassicSimilarity], result of:
          0.03267146 = score(doc=340,freq=2.0), product of:
            0.16037072 = queryWeight, product of:
              3.0731742 = idf(docFreq=5561, maxDocs=44218)
              0.052184064 = queryNorm
            0.2037246 = fieldWeight in 340, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.0731742 = idf(docFreq=5561, maxDocs=44218)
              0.046875 = fieldNorm(doc=340)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

For a variety of reasons, reclassification was a popular project in libraries in the 1960s. Although such projects have faded from the limelight, some of the reasons for doing them remain valid today, i.e., a need to cut processing costs, participation in cooperative ventures, the inconvenience caused by working with a collection split between two classification systems, and continuing changes in the Dewey schedules. This article compares the steps needed for reclassifying in a manual environment with those required when the library has an in-house computer system. The comparison shows how using the latter makes a reclassification project more feasible than it would be in a totally manual library. The article also discusses various issues associated with reclassification in an automated environment such as the problem posed by a frozen public catalog and the combining of reclassification and conversion projects.