Search (4 results, page 1 of 1)

0.018607289 = product of:
  0.037214577 = sum of:
    0.037214577 = product of:
      0.074429154 = sum of:
        0.074429154 = weight(_text_:u in 2428) [ClassicSimilarity], result of:
          0.074429154 = score(doc=2428,freq=2.0), product of:
            0.17144279 = queryWeight, product of:
              3.2744443 = idf(docFreq=4547, maxDocs=44218)
              0.052357826 = queryNorm
            0.43413407 = fieldWeight in 2428, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.2744443 = idf(docFreq=4547, maxDocs=44218)
              0.09375 = fieldNorm(doc=2428)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Issue

Übers. u. Kommentar: B. Eversberg.

0.0106406445 = product of:
  0.021281289 = sum of:
    0.021281289 = product of:
      0.042562578 = sum of:
        0.042562578 = weight(_text_:22 in 2946) [ClassicSimilarity], result of:
          0.042562578 = score(doc=2946,freq=2.0), product of:
            0.1833482 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.052357826 = queryNorm
            0.23214069 = fieldWeight in 2946, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.046875 = fieldNorm(doc=2946)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Date

17. 5.2016 19:22:40

0.007513987 = product of:
  0.015027974 = sum of:
    0.015027974 = product of:
      0.060111895 = sum of:
        0.060111895 = weight(_text_:authors in 2525) [ClassicSimilarity], result of:
          0.060111895 = score(doc=2525,freq=2.0), product of:
            0.2386896 = queryWeight, product of:
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.052357826 = queryNorm
            0.25184128 = fieldWeight in 2525, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.0390625 = fieldNorm(doc=2525)
      0.25 = coord(1/4)
  0.5 = coord(1/2)

Abstract

There is evidence that many individuals and organizations in the library world do not support the work taking place to develop a next generation of the library cataloging rules. The authors describe the tensions existing between those advocating an incremental change to cataloging process and others who desire a bolder library entry into the digital era. Libraries have lost their place as primary information providers, surpassed by more agile (and in many cases wealthier) purveyors of digital information delivery services. Although libraries still manage materials that are not available elsewhere, the library's approach to user service and the user interface is not competing successfully against services like Amazon or Google. If libraries are to avoid further marginalization, they need to make a fundamental change in their approach to user services. The library's signature service, its catalog, uses rules for cataloging that are remnants of a long departed technology: the card catalog. Modifications to the rules, such as those proposed by the Resource Description and Access (RDA) development effort, can only keep us rooted firmly in the 20th, if not the 19th century. A more radical change is required that will contribute to the library of the future, re-imagined and integrated with the chosen workflow of its users.

0.007513987 = product of:
  0.015027974 = sum of:
    0.015027974 = product of:
      0.060111895 = sum of:
        0.060111895 = weight(_text_:authors in 3373) [ClassicSimilarity], result of:
          0.060111895 = score(doc=3373,freq=2.0), product of:
            0.2386896 = queryWeight, product of:
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.052357826 = queryNorm
            0.25184128 = fieldWeight in 3373, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.0390625 = fieldNorm(doc=3373)
      0.25 = coord(1/4)
  0.5 = coord(1/2)

Abstract

A band of archivists and IT professionals at Harvard took on a project to convert nearly two million descriptions of archival collection components from marked-up text into the ArchivesSpace archival metadata management system. Starting in the mid-1990s, Harvard was an alpha implementer of EAD, an SGML (later XML) text markup language for electronic inventories, indexes, and finding aids that archivists use to wend their way through the sometimes quirky filing systems that bureaucracies establish for their records or the utter chaos in which some individuals keep their personal archives. These pathfinder documents, designed to cope with messy reality, can themselves be difficult to classify. Portions of them are rigorously structured, while other parts are narrative. Early documents predate the establishment of the standard; many feature idiosyncratic encoding that had been through several machine conversions, while others were freshly encoded and fairly consistent. In this paper, we will cover the practical and technical challenges involved in preparing a large (900MiB) corpus of XML for ingest into an open-source archival information system (ArchivesSpace). This case study will give an overview of the project, discuss problem discovery and problem solving, and address the technical challenges, analysis, solutions, and decisions and provide information on the tools produced and lessons learned. The authors of this piece are Kate Bowers, Collections Services Archivist for Metadata, Systems, and Standards at the Harvard University Archive, and Dave Mayo, a Digital Library Software Engineer for Harvard's Library and Technology Services. Kate was heavily involved in both metadata analysis and later problem solving, while Dave was the sole full-time developer assigned to the migration project.