Search (7 results, page 1 of 1)

0.0130477995 = product of:
  0.026095599 = sum of:
    0.026095599 = product of:
      0.052191198 = sum of:
        0.052191198 = weight(_text_:p in 711) [ClassicSimilarity], result of:
          0.052191198 = score(doc=711,freq=2.0), product of:
            0.18768665 = queryWeight, product of:
              3.5955126 = idf(docFreq=3298, maxDocs=44218)
              0.052200247 = queryNorm
            0.27807623 = fieldWeight in 711, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5955126 = idf(docFreq=3298, maxDocs=44218)
              0.0546875 = fieldNorm(doc=711)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Source

Cataloging and classification quarterly. 59(2021) no.5, p.492-509

0.011183828 = product of:
  0.022367656 = sum of:
    0.022367656 = product of:
      0.044735312 = sum of:
        0.044735312 = weight(_text_:p in 3857) [ClassicSimilarity], result of:
          0.044735312 = score(doc=3857,freq=2.0), product of:
            0.18768665 = queryWeight, product of:
              3.5955126 = idf(docFreq=3298, maxDocs=44218)
              0.052200247 = queryNorm
            0.23835106 = fieldWeight in 3857, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5955126 = idf(docFreq=3298, maxDocs=44218)
              0.046875 = fieldNorm(doc=3857)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

0.010608619 = product of:
  0.021217238 = sum of:
    0.021217238 = product of:
      0.042434476 = sum of:
        0.042434476 = weight(_text_:22 in 2946) [ClassicSimilarity], result of:
          0.042434476 = score(doc=2946,freq=2.0), product of:
            0.18279637 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.052200247 = 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.008989646 = product of:
  0.017979292 = sum of:
    0.017979292 = product of:
      0.07191717 = sum of:
        0.07191717 = weight(_text_:authors in 2953) [ClassicSimilarity], result of:
          0.07191717 = score(doc=2953,freq=2.0), product of:
            0.23797122 = queryWeight, product of:
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.052200247 = queryNorm
            0.30220953 = fieldWeight in 2953, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.046875 = fieldNorm(doc=2953)
      0.25 = coord(1/4)
  0.5 = coord(1/2)

Abstract

This article presents the process adopted by the France to bring library catalogs to the Web of data and the RDA role in this general strategy. After analising RDA limits and inconsistencies, inherited from the tradition of AACR and MARC21 catalogues, the authors present the French approach to RDA and its positioning in correlation to international standards like ISBD and FRBR. The method adopted in France for FRBRising the catalogues go through a technical work of creating alignment beteween existing data, exploiting the technologies applied to the creation of data.bnf.fr and through a revision of the French cataloguing rules, allowing FRBRised metadata creation. This revision is based on RDA and it is setting up a French RDA application profile, keeping the analysis on the greater differences. RDA adoption, actually, is not a crucial issue in France and not a self standing purpose; it is just a tool for the transition of bibliographic data towards the Web of data.

0.007491372 = product of:
  0.014982744 = sum of:
    0.014982744 = product of:
      0.059930976 = sum of:
        0.059930976 = weight(_text_:authors in 2525) [ClassicSimilarity], result of:
          0.059930976 = score(doc=2525,freq=2.0), product of:
            0.23797122 = queryWeight, product of:
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.052200247 = 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.007491372 = product of:
  0.014982744 = sum of:
    0.014982744 = product of:
      0.059930976 = sum of:
        0.059930976 = weight(_text_:authors in 3373) [ClassicSimilarity], result of:
          0.059930976 = score(doc=3373,freq=2.0), product of:
            0.23797122 = queryWeight, product of:
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.052200247 = 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.

0.0074558854 = product of:
  0.014911771 = sum of:
    0.014911771 = product of:
      0.029823542 = sum of:
        0.029823542 = weight(_text_:p in 3818) [ClassicSimilarity], result of:
          0.029823542 = score(doc=3818,freq=2.0), product of:
            0.18768665 = queryWeight, product of:
              3.5955126 = idf(docFreq=3298, maxDocs=44218)
              0.052200247 = queryNorm
            0.15890071 = fieldWeight in 3818, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5955126 = idf(docFreq=3298, maxDocs=44218)
              0.03125 = fieldNorm(doc=3818)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

Equally fallacious is the statement that support for the "clustering bibliographic records to show relationships between works and their creators" is an "important new feature" of RDA. AACR2 bibliographic records and the systems housing them can, did, and do show such relationships. Finally, whether users want or care to be made "more aware of a work's different editions, translations, or physical formats" is debatable. As an aim, it sounds less like what a user wants and more like what a cataloging librarian thinks a user should want. As Amanda Cossham writes in her recently issued doctoral thesis: "The explicit focus on user needs in the FRBR model, the International Cataloguing Principles, and RDA: Resource Description and Access does not align well with the ways that users use, understand, and experience library catalogues nor with the ways that they understand and experience the wider information environment. User tasks, as constituted in the FRBR model and RDA, are insufficient to meet users' needs." (p. 11, emphasis in the original)