Search (7 results, page 1 of 1)

0.024570452 = product of:
  0.049140904 = sum of:
    0.049140904 = product of:
      0.09828181 = sum of:
        0.09828181 = weight(_text_:i in 5411) [ClassicSimilarity], result of:
          0.09828181 = score(doc=5411,freq=2.0), product of:
            0.1965379 = queryWeight, product of:
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.05210816 = queryNorm
            0.50006545 = fieldWeight in 5411, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.09375 = fieldNorm(doc=5411)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

0.014478277 = product of:
  0.028956555 = sum of:
    0.028956555 = product of:
      0.05791311 = sum of:
        0.05791311 = weight(_text_:i in 5718) [ClassicSimilarity], result of:
          0.05791311 = score(doc=5718,freq=4.0), product of:
            0.1965379 = queryWeight, product of:
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.05210816 = queryNorm
            0.29466638 = fieldWeight in 5718, product of:
              2.0 = tf(freq=4.0), with freq of:
                4.0 = termFreq=4.0
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.0390625 = fieldNorm(doc=5718)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

Persistent identifiers (PID's) are essential for getting access and referring to library, archive and museum (LAM) collection objects in a sustainable and unambiguous way, both internally and externally. Heritage institutions need a universal policy for the use of PID's in order to have an efficient digital infrastructure at their disposal and to achieve optimal interoperability, leading to open data, open collections and efficient resource management. Here the discussion is limited to PID's that institutions can assign to objects they own or administer themselves. PID's for people, subjects etc. can be used by heritage institutions, but are generally managed by other parties. The first part of this article consists of a general theoretical description of persistent identifiers. First of all, I discuss the questions of what persistent identifiers are and what they are not, and what is needed to administer and use them. The most commonly used existing PID systems are briefly characterized. Then I discuss the types of objects PID's can be assigned to. This section concludes with an overview of the requirements that apply if PIDs should also be used for linked data. The second part examines current infrastructural practices, and existing PID systems and their advantages and shortcomings. Based on these practical issues and the pros and cons of existing PID systems a list of requirements for PID systems is presented which is used to address a number of practical considerations. This section concludes with a number of recommendations.

0.010589904 = product of:
  0.021179808 = sum of:
    0.021179808 = product of:
      0.042359617 = sum of:
        0.042359617 = weight(_text_:22 in 2946) [ClassicSimilarity], result of:
          0.042359617 = score(doc=2946,freq=2.0), product of:
            0.1824739 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.05210816 = 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.00819015 = product of:
  0.0163803 = sum of:
    0.0163803 = product of:
      0.0327606 = sum of:
        0.0327606 = weight(_text_:i in 4283) [ClassicSimilarity], result of:
          0.0327606 = score(doc=4283,freq=2.0), product of:
            0.1965379 = queryWeight, product of:
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.05210816 = queryNorm
            0.16668847 = fieldWeight in 4283, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.03125 = fieldNorm(doc=4283)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

Am 12. Dezember 2017 ist das neue Release des RDA Toolkits erschienen. Dabei gab es, aufgrund des 3R-Projekts (RDA Toolkit Restruction and Redesign Project), keine inhaltlichen Änderungen am RDA-Text. Es wurden ausschließlich die Übersetzungen in finnischer und französischer Sprache, ebenso wie die dazugehörigen Policy statements, aktualisiert. Für den deutschsprachigen Raum wurden in der Übersetzung zwei Beziehungskennzeichnungen geändert: Im Anhang I.2.2 wurde die Änderung von "Sponsor" zu "Träger" wieder rückgängig gemacht. In Anhang K.2.3 wurde "Sponsor" zu "Person als Sponsor" geändert. Außerdem wurde die Übersetzung der Anwendungsrichtlinien (D-A-CH AWR) ins Französische aktualisiert. Dies ist das vorletzte Release vor dem Rollout des neuen Toolkits. Das letzte Release im Januar/Februar 2018 wird die norwegische Übersetzung enthalten. Im Juni 2018 wird das RDA Toolkit ein Relaunch erfahren und mit einer neuen Oberfläche erscheinen. Dieser beinhaltet ein Redesign der Toolkit-Oberfläche und die inhaltliche Anpassung des Standards RDA an das Library Reference Model (IFLA LRM) sowie die künftige stärkere Ausrichtung auf die aktuellen technischen Möglichkeiten. Zunächst wird im Juni 2018 die englische Originalausgabe der RDA in der neuen Form erscheinen. Alle Übersetzungen werden in einer Übergangszeit angepasst. Hierfür wird die alte Version des RDA Toolkit für ein weiteres Jahr zur Verfügung gestellt. Der Stand Dezember 2017 der deutschen Ausgabe und die D-A-CH-Anwendungsrichtlinien bleiben bis zur Anpassung eingefroren. Nähere Information zum Rollout finden Sie unter dem folgenden Link<http://www.rdatoolkit.org/3Rproject/SR3>. [Inetbib vom 13.12.2017]

0.0074781566 = product of:
  0.014956313 = sum of:
    0.014956313 = product of:
      0.059825253 = sum of:
        0.059825253 = weight(_text_:authors in 2525) [ClassicSimilarity], result of:
          0.059825253 = score(doc=2525,freq=2.0), product of:
            0.23755142 = queryWeight, product of:
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.05210816 = 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.0074781566 = product of:
  0.014956313 = sum of:
    0.014956313 = product of:
      0.059825253 = sum of:
        0.059825253 = weight(_text_:authors in 3373) [ClassicSimilarity], result of:
          0.059825253 = score(doc=3373,freq=2.0), product of:
            0.23755142 = queryWeight, product of:
              4.558814 = idf(docFreq=1258, maxDocs=44218)
              0.05210816 = 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.004095075 = product of:
  0.00819015 = sum of:
    0.00819015 = product of:
      0.0163803 = sum of:
        0.0163803 = weight(_text_:i in 3401) [ClassicSimilarity], result of:
          0.0163803 = score(doc=3401,freq=2.0), product of:
            0.1965379 = queryWeight, product of:
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.05210816 = queryNorm
            0.083344236 = fieldWeight in 3401, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.015625 = fieldNorm(doc=3401)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Content

What are these two Beowulf translations "expressions" of? I used the term work above, an even more abstract concept in the FRBR model. In this case, the "work" is Beowulf , that ancient intellectual creation or effort that over time has been expressed in multiple ways, each manifested in several different ways itself, with one or more items in each manifestation. This is a pretty gross oversimplification of FRBR, which also details other relationships: among these entities; between these entities and various persons (such as creators, publishers, and owners); and between these entities and their subjects. It also specifies characteristics, or "attributes," of the different types of entities (such as title, physical media, date, availability, and more.). But it should be enough to grasp the possibilities. Now apply it Imagine that you have a patron who needs a copy of Heaney's translation of Beowulf . She doesn't care who published it or when, only that it's Heaney's translation. What if you (or your patron) could place an interlibrary loan call on that expression, instead of looking through multiple bibliographic records (as of March, OCLC's WorldCat had nine regular print editions) for multiple manifestations and then judging which record is the best bet on which to place a request? Combine that with functionality that lets you specify "not Braille, not large print," and it could save you time. Now imagine a patron in want of a copy, any copy, in English, of Romeo and Juliet. Saving staff time means saving money. Whether or not this actually happens depends upon what the library community decides to do with FRBR. It is not a set of cataloging rules or a system design, but it can influence both. Several library system vendors are working with FRBR ideas; VTLS's current integrated library system product Virtua incorporates FRBR concepts in its design. More vendors may follow. How the Joint Steering Committee for Revision of Anglo-American Cataloging Rules develops the Anglo-American Cataloging Rules (AACR) to incorporate FRBR will necessarily be a strong determinant of how records work in a "FRBR-ized" bibliographic database.