Search (94 results, page 1 of 5)

0.022235535 = product of:
  0.04447107 = sum of:
    0.04447107 = sum of:
      0.007030784 = weight(_text_:a in 2946) [ClassicSimilarity], result of:
        0.007030784 = score(doc=2946,freq=6.0), product of:
          0.053105544 = queryWeight, product of:
            1.153047 = idf(docFreq=37942, maxDocs=44218)
            0.046056706 = queryNorm
          0.13239266 = fieldWeight in 2946, product of:
            2.4494898 = tf(freq=6.0), with freq of:
              6.0 = termFreq=6.0
            1.153047 = idf(docFreq=37942, maxDocs=44218)
            0.046875 = fieldNorm(doc=2946)
      0.037440285 = weight(_text_:22 in 2946) [ClassicSimilarity], result of:
        0.037440285 = score(doc=2946,freq=2.0), product of:
          0.16128273 = queryWeight, product of:
            3.5018296 = idf(docFreq=3622, maxDocs=44218)
            0.046056706 = 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)

Abstract

The author revisits the development of RDA from its inception in 2005 through to its initial release in 2010. The development effort is set in the context of an evolving digital environment that was transforming both the production and dissemination of information resources and the technologies used to create, store, and access data describing those resources. The author examines the interplay between strategic commitments to align RDA with new conceptual models, emerging database structures, and metadata developments in allied communities, on the one hand, and compatibility with AACR2 legacy databases on the other. Aspects of the development effort examined include the structuring of RDA as a resource description language, organizing the new standard as a working tool, and refining guidelines and instructions for recording RDA data.

Date

17. 5.2016 19:22:40

Type

a

0.0030444188 = product of:
  0.0060888375 = sum of:
    0.0060888375 = product of:
      0.012177675 = sum of:
        0.012177675 = weight(_text_:a in 2884) [ClassicSimilarity], result of:
          0.012177675 = score(doc=2884,freq=18.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.22931081 = fieldWeight in 2884, product of:
              4.2426405 = tf(freq=18.0), with freq of:
                18.0 = termFreq=18.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046875 = fieldNorm(doc=2884)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

OpenRefine is described as a tool for working with 'messy' data - but what does this mean? It is probably easiest to describe the kinds of data OpenRefine is good at working with and the sorts of problems it can help you solve. OpenRefine is most useful where you have data in a simple tabular format but with internal inconsistencies either in data formats, or where data appears, or in terminology used. It can help you: Get an overview of a data set Resolve inconsistencies in a data set Help you split data up into more granular parts Match local data up to other data sets Enhance a data set with data from other sources Some common scenarios might be: 1. Where you want to know how many times a particular value appears in a column in your data. 2. Where you want to know how values are distributed across your whole data set. 3. Where you have a list of dates which are formatted in different ways, and want to change all the dates in the list to a single common date format.

0.0029294936 = product of:
  0.005858987 = sum of:
    0.005858987 = product of:
      0.011717974 = sum of:
        0.011717974 = weight(_text_:a in 8920) [ClassicSimilarity], result of:
          0.011717974 = score(doc=8920,freq=6.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.22065444 = fieldWeight in 8920, product of:
              2.4494898 = tf(freq=6.0), with freq of:
                6.0 = termFreq=6.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.078125 = fieldNorm(doc=8920)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

A BIBFRAME Relationship is a relationship between a BIBFRAME Work or Instance and another BIBFRAME Work or Instance. Thus there are four types of relationships: Work to Work - Work to Instance - Instance to Work - Instance to Instance

0.0029000505 = product of:
  0.005800101 = sum of:
    0.005800101 = product of:
      0.011600202 = sum of:
        0.011600202 = weight(_text_:a in 2430) [ClassicSimilarity], result of:
          0.011600202 = score(doc=2430,freq=12.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.21843673 = fieldWeight in 2430, product of:
              3.4641016 = tf(freq=12.0), with freq of:
                12.0 = termFreq=12.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.0546875 = fieldNorm(doc=2430)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

This paper explores a technique to improve searcher access to library collections by providing a faceted search interface built on a data model based on the Functional Requirements for Bibliographic Records (FRBR). The prototype provides a Workcentric view of a moving image collection that is integrated with bibliographic and holdings data. Two sets of facets address important user needs: "what do you want?" and "how/where do you want it?" enabling patrons to narrow, broaden and pivot across facet values instead of limiting them to the tree-structured hierarchy common with existing FRBR applications. The data model illustrates how FRBR is being adapted and applied beyond the traditional library catalog.

Type

a

0.0028703054 = product of:
  0.005740611 = sum of:
    0.005740611 = product of:
      0.011481222 = sum of:
        0.011481222 = weight(_text_:a in 2950) [ClassicSimilarity], result of:
          0.011481222 = score(doc=2950,freq=16.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.2161963 = fieldWeight in 2950, product of:
              4.0 = tf(freq=16.0), with freq of:
                16.0 = termFreq=16.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046875 = fieldNorm(doc=2950)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

RDA appears to be an hybrid standard: a list containing a high number of bibliographic elements and a rewrite - more formal than substantial - of cataloguing practices established with AACR2. In this document, RDA guidelines are analysed trying to compare them to the requirements of good cataloguing rules. Cataloguing rules in general shold not be an abstract and self-referential model but an effective tool to analyse and represent cultural phenomena, useful to qualified staff and helpful in learning about users need. From this point of view, RDA is quite disappointing: many relevant and frequent cataloguing issues are not mentioned at all, and cataloguing itself is left without real guidelines. A certain number of omissions, mistakes and individual flawness in the text should be modified by RDA board with a deep analysis of real cataloguing activities.

Type

a

0.0028703054 = product of:
  0.005740611 = sum of:
    0.005740611 = product of:
      0.011481222 = sum of:
        0.011481222 = weight(_text_:a in 2953) [ClassicSimilarity], result of:
          0.011481222 = score(doc=2953,freq=16.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.2161963 = fieldWeight in 2953, product of:
              4.0 = tf(freq=16.0), with freq of:
                16.0 = termFreq=16.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046875 = fieldNorm(doc=2953)
      0.5 = coord(1/2)
  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.

Type

a

0.00270615 = product of:
  0.0054123 = sum of:
    0.0054123 = product of:
      0.0108246 = sum of:
        0.0108246 = weight(_text_:a in 5903) [ClassicSimilarity], result of:
          0.0108246 = score(doc=5903,freq=2.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.20383182 = fieldWeight in 5903, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.125 = fieldNorm(doc=5903)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

0.00270615 = product of:
  0.0054123 = sum of:
    0.0054123 = product of:
      0.0108246 = sum of:
        0.0108246 = weight(_text_:a in 3759) [ClassicSimilarity], result of:
          0.0108246 = score(doc=3759,freq=2.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.20383182 = fieldWeight in 3759, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.125 = fieldNorm(doc=3759)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Type

a

0.00270615 = product of:
  0.0054123 = sum of:
    0.0054123 = product of:
      0.0108246 = sum of:
        0.0108246 = weight(_text_:a in 1183) [ClassicSimilarity], result of:
          0.0108246 = score(doc=1183,freq=32.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.20383182 = fieldWeight in 1183, product of:
              5.656854 = tf(freq=32.0), with freq of:
                32.0 = termFreq=32.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.03125 = fieldNorm(doc=1183)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

IFLA's Functional Requirements for Bibliographic Records (FRBR) lay the foundation for a new generation of cataloging systems that recognize the difference between a particular work (e.g., Moby Dick), diverse expressions of that work (e.g., translations into German, Japanese and other languages), different versions of the same basic text (e.g., the Modern Library Classics vs. Penguin editions), and particular items (a copy of Moby Dick on the shelf). Much work has gone into finding ways to infer FRBR relationships between existing catalog records and modifying catalog interfaces to display those relationships. Relatively little work, however, has gone into exploring the creation of catalog records that are inherently based on the FRBR hierarchy of works, expressions, manifestations, and items. The Perseus Digital Library has created a new catalog that implements such a system for a small collection that includes many works with multiple versions. We have used this catalog to explore some of the implications of hierarchical catalog records for searching and browsing. Current online library catalog interfaces present many problems for searching. One commonly cited failure is the inability to find and collocate all versions of a distinct intellectual work that exist in a collection and the inability to take into account known variations in titles and personal names (Yee 2005). The IFLA Functional Requirements for Bibliographic Records (FRBR) attempts to address some of these failings by introducing the concept of multiple interrelated bibliographic entities (IFLA 1998). In particular, relationships between abstract intellectual works and the various published instances of those works are divided into a four-level hierarchy of works (such as the Aeneid), expressions (Robert Fitzgerald's translation of the Aeneid), manifestations (a particular paperback edition of Robert Fitzgerald's translation of the Aeneid), and items (my copy of a particular paperback edition of Robert Fitzgerald's translation of the Aeneid). In this formulation, each level in the hierarchy "inherits" information from the preceding level. Much of the work on FRBRized catalogs so far has focused on organizing existing records that describe individual physical books. Relatively little work has gone into rethinking what information should be in catalog records, or how the records should relate to each other. It is clear, however, that a more "native" FRBR catalog would include separate records for works, expressions, manifestations, and items. In this way, all information about a work would be centralized in one record. Records for subsequent expressions of that work would add only the information specific to each expression: Samuel Butler's translation of the Iliad does not need to repeat the fact that the work was written by Homer. This approach has certain inherent advantages for collections with many versions of the same works: new publications can be cataloged more quickly, and records can be stored and updated more efficiently.

Type

a

0.0026849252 = product of:
  0.0053698504 = sum of:
    0.0053698504 = product of:
      0.010739701 = sum of:
        0.010739701 = weight(_text_:a in 2882) [ClassicSimilarity], result of:
          0.010739701 = score(doc=2882,freq=14.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.20223314 = fieldWeight in 2882, product of:
              3.7416575 = tf(freq=14.0), with freq of:
                14.0 = termFreq=14.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046875 = fieldNorm(doc=2882)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

This short publication was made for two reasons. First, to provide a simple way to help people understand a bit more precisely what is defined by RDA, AACR2, MARC format, and so on. In this way, when someone says that MARC, or AARC2, or ISBD should change, they will have a better idea of what each term does and does not pertain to. One record has been chosen at random and analysed in various ways. This publication is far from complete and does not pretend to teach anything, it only demonstrates. When someone talks about, e.g. MARC, all the reader needs to do is look at the colored areas to get an idea of what that means.

Source

http://blog.jweinheimer.net/wp-content/Ebooks/A%20visual%20explanation%20of%20the%20are%20-%20James%20Weinheimer.pdf

0.0026849252 = product of:
  0.0053698504 = sum of:
    0.0053698504 = product of:
      0.010739701 = sum of:
        0.010739701 = weight(_text_:a in 3523) [ClassicSimilarity], result of:
          0.010739701 = score(doc=3523,freq=14.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.20223314 = fieldWeight in 3523, product of:
              3.7416575 = tf(freq=14.0), with freq of:
                14.0 = termFreq=14.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046875 = fieldNorm(doc=3523)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

On December 12, 2016, Carl Stahmer and MacKenzie Smith presented at the CNI Members Fall Meeting about the BIBFLOW project, self-described on Twitter as "a two-year project of the UC Davis University Library and Zepheira investigating the future of library technical services." In her opening remarks, Ms. Smith, University Librarian at UC Davis, stated that one of the goals of the project was to devise a roadmap "to get from where we are today, which is kind of the 1970s with a little lipstick on it, to 2020, which is where we're going to be very soon." The notion that where libraries are today is somehow behind the times is one of the commonly heard rationales behind a move to linked data. Stated more precisely: - Libraries devote considerable time and resources to producing high-quality bibliographic metadata - This metadata is stored in unconnected silos - This metadata is in a format (MARC) that is incompatible with technologies of the emerging Semantic Web - The visibility of library metadata is diminished as a result of the two points above Are these assertions true? If yes, is linked data the solution?

Type

a

0.0026742492 = product of:
  0.0053484985 = sum of:
    0.0053484985 = product of:
      0.010696997 = sum of:
        0.010696997 = weight(_text_:a in 2952) [ClassicSimilarity], result of:
          0.010696997 = score(doc=2952,freq=20.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.20142901 = fieldWeight in 2952, product of:
              4.472136 = tf(freq=20.0), with freq of:
                20.0 = termFreq=20.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.0390625 = fieldNorm(doc=2952)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

The Toolkit designed by the RDA Steering Committee makes Resource Description and Access available on the web, together with other useful documents (workflows, mappings, etc.). Reading, learning and memorizing are interconnected, and a working tool should make these activities faster and easier to perform. Some issues arise while verifying the real easiness of use and learning of the tool. The practical and formal requirements for a cataloguing code include plain language, ease of memorisation, clarity of instructions, familiarity for users, predictability and reproducibility of solutions, and general usability. From a formal point of view, the RDA text does not appear to be conceived for an uninterrupted reading, but just for reading of few paragraphs for temporary catalographic needs. From a content point of view, having a syndetic view of the description of a resource is rather difficult: catalographic details are scattered and their re-organization is not easy. The visualisation and logical organisation in the Toolkit could be improved: the table of contents occupies a sizable portion of the screen and resizing or hiding it is not easy; the indentation leaves little space to the words; inhomogeneous font styles (italic and bold) and poor contrast between background and text colours make reading not easy; simultaneous visualization of two or more parts of the text is not allowed; and Toolkit's icons are less intuitive than expected. In the conclusion, some suggestions on how to improve the Toolkit's aspects and usability are provided.

Type

a

0.0026202186 = product of:
  0.005240437 = sum of:
    0.005240437 = product of:
      0.010480874 = sum of:
        0.010480874 = weight(_text_:a in 2429) [ClassicSimilarity], result of:
          0.010480874 = score(doc=2429,freq=30.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.19735932 = fieldWeight in 2429, product of:
              5.477226 = tf(freq=30.0), with freq of:
                30.0 = termFreq=30.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.03125 = fieldNorm(doc=2429)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

If one follows any of the major cataloging or library blogs these days, it is obvious that the topic of FRBR (Functional Requirements for Bibliographic Records) has increasingly become one of major significance for the library community. What began as a proposed conceptual entity-relationship model for improving the structure of bibliographic records has become a hotly debated topic with many tangled threads that have implications not just for cataloging but for many aspects of libraries and librarianship. In the fall of 2005, the Perseus Project experimented with creating a FRBRized catalog for its current online classics collection, a collection that consists of several hundred classical texts in Greek and Latin as well as reference works and scholarly commentaries regarding these works. In the last two years, with funding from the Mellon Foundation, Perseus has amassed and digitized a growing collection of classical texts (some as image books on our own servers that will eventually be made available through Fedora), and some available through the Open Content Alliance (OCA)2, and created FRBRized cataloging data for these texts. This work was done largely as an experiment to see the potential of the FRBR model for creating a specialized catalog for classics.
Our catalog should not be called a FRBR catalog perhaps, but instead a "FRBR Inspired catalog." As such our main goal has been "practical findability," we are seeking to support the four identified user tasks of the FRBR model, or to "Search, Identify, Select, and Obtain," rather than to create a FRBR catalog, per se. By encoding as much information as possible in the MODS and MADS records we have created, we believe that useful searching will be supported, that by using unique identifiers for works and authors users will be able to identify that the entity they have located is the desired one, that by encoding expression level information (such as the language of the work, the translator, etc) users will be able to select which expression of a work they are interested in, and that by supplying links to different online manifestations that users will be able to obtain access to a digital copy of a work. This white paper will discuss previous and current efforts by the Perseus Project in creating a FRBRized catalog, including the cataloging workflow, lessons learned during the process and will also seek to place this work in the larger context of research regarding FRBR, cataloging, Library 2.0 and the Semantic Web, and the growing importance of the FRBR model in the face of growing million book digital libraries.

0.0024857575 = product of:
  0.004971515 = sum of:
    0.004971515 = product of:
      0.00994303 = sum of:
        0.00994303 = weight(_text_:a in 2433) [ClassicSimilarity], result of:
          0.00994303 = score(doc=2433,freq=12.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.18723148 = fieldWeight in 2433, product of:
              3.4641016 = tf(freq=12.0), with freq of:
                12.0 = termFreq=12.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046875 = fieldNorm(doc=2433)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

The goal of OCLC's FRBR projects is to examine issues associated with the conversion of a set of bibliographic records to conform to FRBR requirements (a process referred to as "FRBRization"). The goals of this FRBR project were to: - examine issues associated with creating an entity-relationship model for (i.e., "FRBRizing") a non-trivial work - better understand the relationship between the bibliographic records and the bibliographic objects they represent - determine if the information available in the bibliographic record is sufficient to reliably identify the FRBR entities - to develop a data set that could be used to evaluate FRBRization algorithms. Using an exemplary work as a case study, lead scientist Ed O'Neill sought to: - better understand the relationship between bibliographic records and the bibliographic objects they represent - determine if the information available in the bibliographic records is sufficient to reliably identify FRBR entities.

0.0023919214 = product of:
  0.0047838427 = sum of:
    0.0047838427 = product of:
      0.009567685 = sum of:
        0.009567685 = weight(_text_:a in 3225) [ClassicSimilarity], result of:
          0.009567685 = score(doc=3225,freq=16.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.18016359 = fieldWeight in 3225, product of:
              4.0 = tf(freq=16.0), with freq of:
                16.0 = termFreq=16.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.0390625 = fieldNorm(doc=3225)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

This is a report by a group "charged to identify current trends that will have a direct impact on cataloging operations and to define possible new roles for the online catalog and cataloging staff at Indiana University." Their one general conclusion after nine months of work is that "The need for cataloging expertise within the I.U. Libraries will not be diminished in the coming years. Rather, catalogers of the future will work in the evolving environment of publishing, scholarly communication, and information technology in new expanded roles. Catalogers will need to be key players in addressing the many challenges facing the libraries and the overall management and organization of information at Indiana University." The report also identifies five strategic directions. The report is an interesting read, and taken with the explosion of related reports (e.g., Calhoun's report to the Library of Congress cited in this issue, the UC Bibliographic Services TF Report), adds yet another perspective to the kinds of changes we must foster to create better library services in a vastly changed environment.

0.0023678814 = product of:
  0.0047357627 = sum of:
    0.0047357627 = product of:
      0.009471525 = sum of:
        0.009471525 = weight(_text_:a in 5412) [ClassicSimilarity], result of:
          0.009471525 = score(doc=5412,freq=2.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.17835285 = fieldWeight in 5412, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.109375 = fieldNorm(doc=5412)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

0.0023678814 = product of:
  0.0047357627 = sum of:
    0.0047357627 = product of:
      0.009471525 = sum of:
        0.009471525 = weight(_text_:a in 2408) [ClassicSimilarity], result of:
          0.009471525 = score(doc=2408,freq=2.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.17835285 = fieldWeight in 2408, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.109375 = fieldNorm(doc=2408)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

0.0023678814 = product of:
  0.0047357627 = sum of:
    0.0047357627 = product of:
      0.009471525 = sum of:
        0.009471525 = weight(_text_:a in 2432) [ClassicSimilarity], result of:
          0.009471525 = score(doc=2432,freq=8.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.17835285 = fieldWeight in 2432, product of:
              2.828427 = tf(freq=8.0), with freq of:
                8.0 = termFreq=8.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.0546875 = fieldNorm(doc=2432)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

FictionFinder is a FRBR-based prototype that provides access to over 2.9 million bibliographic records for fiction books, eBooks, and audio materials described in OCLC WorldCat. This project applies principles of the FRBR model to aggregate bibliographic information above the manifestation level. Records are clustered into works using the OCLC FRBR Work-Set Algorithm. The algorithm collects bibliographic records into groups based on author and title information from bibliographic and authority records. Author names and titles are normalized to construct a key. All records with the same key are grouped together in a work set.

0.0023678814 = product of:
  0.0047357627 = sum of:
    0.0047357627 = product of:
      0.009471525 = sum of:
        0.009471525 = weight(_text_:a in 5441) [ClassicSimilarity], result of:
          0.009471525 = score(doc=5441,freq=8.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.17835285 = fieldWeight in 5441, product of:
              2.828427 = tf(freq=8.0), with freq of:
                8.0 = termFreq=8.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.0546875 = fieldNorm(doc=5441)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

Ability to collect time-specific lists of faculty publications has become increasingly important for academic departments. At OHSU publication lists had been retrieved manually by a librarian who conducted literature searches in bibliographic databases. These searches were complicated and time consuming, and the results were large and difficult to assess for accuracy. The OHSU library has built an open web page that allows novices to make very sophisticated institution-specific queries. The tool frees up library staff, provides users with an easy way of retrieving reliable local publication information from PubMed, and gives an opportunity for more sophisticated users to modify the algorithm or dive into the data to better understand nuances from a strong jumping off point.

Type

a

0.0023435948 = product of:
  0.0046871896 = sum of:
    0.0046871896 = product of:
      0.009374379 = sum of:
        0.009374379 = weight(_text_:a in 5137) [ClassicSimilarity], result of:
          0.009374379 = score(doc=5137,freq=6.0), product of:
            0.053105544 = queryWeight, product of:
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.046056706 = queryNorm
            0.17652355 = fieldWeight in 5137, product of:
              2.4494898 = tf(freq=6.0), with freq of:
                6.0 = termFreq=6.0
              1.153047 = idf(docFreq=37942, maxDocs=44218)
              0.0625 = fieldNorm(doc=5137)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

This paper provides an overview of plans to implement RDA: Resource Description & Access in Europe to replace existing cataloguing rules. It is based on survey information gathered by EURIG and CILIP CIG. It includes background on the development of RDA as a replacement for AACR2.

Type

a