Search (12 results, page 1 of 1)

0.024192145 = product of:
  0.036288217 = sum of:
    0.016003672 = weight(_text_:on in 3842) [ClassicSimilarity], result of:
      0.016003672 = score(doc=3842,freq=2.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.14580199 = fieldWeight in 3842, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.046875 = fieldNorm(doc=3842)
    0.020284547 = product of:
      0.040569093 = sum of:
        0.040569093 = weight(_text_:22 in 3842) [ClassicSimilarity], result of:
          0.040569093 = score(doc=3842,freq=2.0), product of:
            0.1747608 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.04990557 = queryNorm
            0.23214069 = fieldWeight in 3842, 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=3842)
      0.5 = coord(1/2)
  0.6666667 = coord(2/3)

Abstract

The Library of Congress Classification (LCC), originally designed for classifying the Library's own collection, is now used in a wide range of libraries, both in the United States and abroad. This entry recounts its history and development from its genesis to the present time, leading up to an explanation of LCC structure, tables, and notation. It then considers the system's potential for wider application in the online age, through speculation on using LCC as a tool for (a) partitioning large files; (b) generating domain-specific taxonomies; and (c) integrating classification and controlled subject terms for improved retrieval in the online public access catalog (OPAC) and the Internet. Finally, analyzing both its strong and relatively weak features, it addresses the question of whether in its current state LCC is in all respects ready for playing such roles

Date

27. 8.2011 14:22:42

0.01577687 = product of:
  0.04733061 = sum of:
    0.04733061 = product of:
      0.09466122 = sum of:
        0.09466122 = weight(_text_:22 in 3247) [ClassicSimilarity], result of:
          0.09466122 = score(doc=3247,freq=2.0), product of:
            0.1747608 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.04990557 = queryNorm
            0.5416616 = fieldWeight in 3247, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.109375 = fieldNorm(doc=3247)
      0.5 = coord(1/2)
  0.33333334 = coord(1/3)

Object

DDC-22

0.010669115 = product of:
  0.032007344 = sum of:
    0.032007344 = weight(_text_:on in 507) [ClassicSimilarity], result of:
      0.032007344 = score(doc=507,freq=2.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.29160398 = fieldWeight in 507, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.09375 = fieldNorm(doc=507)
  0.33333334 = coord(1/3)

0.0075442037 = product of:
  0.02263261 = sum of:
    0.02263261 = weight(_text_:on in 2181) [ClassicSimilarity], result of:
      0.02263261 = score(doc=2181,freq=4.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.20619515 = fieldWeight in 2181, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.046875 = fieldNorm(doc=2181)
  0.33333334 = coord(1/3)

Abstract

Recent trends, driven to a large extent by the rapid proliferation of digital resources, are forcing changes in bibliographic control to make it easier to use, understand, and apply subject data. Subject headings are no exception. The enormous volume and rapid growth of digital libraries and repositories and the emergence of numerous metadata schemes have spurred a reexamination of the way subject data are to be provided for such resources efficiently and effectively. To address this need, OCLC in cooperation with the Library of Congress, has taken a new approach, called FAST (Faceted Application of Subject Terminology). FAST headings are based on the existing vocabulary in Library of Congress Subject Headings (LCSH), but are applied with a simpler syntax than required by Library of Congress application policies. Adapting the LCSH vocabulary in a simplified faceted syntax retains the rich vocabulary of LCSH while making it easier to understand, control, apply, and use.

Source

New pespectives on subject indexing and classification: essays in honour of Magda Heiner-Freiling. Red.: K. Knull-Schlomann, u.a

0.007112743 = product of:
  0.021338228 = sum of:
    0.021338228 = weight(_text_:on in 3738) [ClassicSimilarity], result of:
      0.021338228 = score(doc=3738,freq=2.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.19440265 = fieldWeight in 3738, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.0625 = fieldNorm(doc=3738)
  0.33333334 = coord(1/3)

Abstract

This entry discusses the importance of semantic interoperability in the networked environment, introduces various approaches contributing to semantic interoperability, and summarizes different methodologies used in current projects that are focused on achieving semantic interoperability. It is intended to inform readers about the fundamentals and mechanisms that have been experimented with, or implemented, that strive to ensure and achieve semantic interoperability in the current networked environment.

0.0067615155 = product of:
  0.020284547 = sum of:
    0.020284547 = product of:
      0.040569093 = sum of:
        0.040569093 = weight(_text_:22 in 5920) [ClassicSimilarity], result of:
          0.040569093 = score(doc=5920,freq=2.0), product of:
            0.1747608 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.04990557 = queryNorm
            0.23214069 = fieldWeight in 5920, 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=5920)
      0.5 = coord(1/2)
  0.33333334 = coord(1/3)

Date

27. 5.2001 16:22:21

0.0067615155 = product of:
  0.020284547 = sum of:
    0.020284547 = product of:
      0.040569093 = sum of:
        0.040569093 = weight(_text_:22 in 2205) [ClassicSimilarity], result of:
          0.040569093 = score(doc=2205,freq=2.0), product of:
            0.1747608 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.04990557 = queryNorm
            0.23214069 = fieldWeight in 2205, 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=2205)
      0.5 = coord(1/2)
  0.33333334 = coord(1/3)

Date

10. 9.2000 17:38:22

0.00622365 = product of:
  0.01867095 = sum of:
    0.01867095 = weight(_text_:on in 6109) [ClassicSimilarity], result of:
      0.01867095 = score(doc=6109,freq=2.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.17010231 = fieldWeight in 6109, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.0546875 = fieldNorm(doc=6109)
  0.33333334 = coord(1/3)

Abstract

This article describes FAST, the Faceted Application of Subject Terminology, a project at OCLC to make Library of Congress Subject Headings easier to use in Dublin Core metadata by breaking out facets of space, time, and form. Work on FAST can be watched at its web site, http://www.miskatonic.org/library/, which has recent presentations and reports. It is interesting to see facets and Dublin Core combined, though both LCSH and FAST subject headings are beyond what most people making a small faceted classification would want or need.

0.00622365 = product of:
  0.01867095 = sum of:
    0.01867095 = weight(_text_:on in 4698) [ClassicSimilarity], result of:
      0.01867095 = score(doc=4698,freq=2.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.17010231 = fieldWeight in 4698, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.0546875 = fieldNorm(doc=4698)
  0.33333334 = coord(1/3)

Abstract

After an introduction that addresses the means people use to search for information, this entry articulates the principles underlying various subject access options, including both controlled vocabulary systems and classification. It begins with a brief history of subject access provisions, including an account of the impact of automation, and goes on to discuss in some detail the principles underlying American library practice in respect to subject access. It then, briefly, describes selected subject-access schemes (including both subject heading lists and classification systems) in terms of how they reflect the principles presented, and how well they fulfill their stated functions.

0.006159817 = product of:
  0.01847945 = sum of:
    0.01847945 = weight(_text_:on in 1177) [ClassicSimilarity], result of:
      0.01847945 = score(doc=1177,freq=6.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.16835764 = fieldWeight in 1177, product of:
          2.4494898 = tf(freq=6.0), with freq of:
            6.0 = termFreq=6.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.03125 = fieldNorm(doc=1177)
  0.33333334 = coord(1/3)

Abstract

This is the second part of an analysis of the methods that have been used to achieve or improve interoperability among metadata schemas and their applications in order to facilitate the conversion and exchange of metadata and to enable cross-domain metadata harvesting and federated searches. From a methodological point of view, implementing interoperability may be considered at different levels of operation: schema level (discussed in Part I of the article), record level (discussed in Part II of the article), and repository level (also discussed in Part II). The results of efforts to improve interoperability may be observed from different perspectives as well, including element-based and value-based approaches. As discussed in Part I of this study, the results of efforts to improve interoperability can be observed at different levels: 1. Schema level - Efforts are focused on the elements of the schemas, being independent of any applications. The results usually appear as derived element sets or encoded schemas, crosswalks, application profiles, and element registries. 2. Record level - Efforts are intended to integrate the metadata records through the mapping of the elements according to the semantic meanings of these elements. Common results include converted records and new records resulting from combining values of existing records. 3. Repository level - With harvested or integrated records from varying sources, efforts at this level focus on mapping value strings associated with particular elements (e.g., terms associated with subject or format elements). The results enable cross-collection searching. In the following sections, we will continue to analyze interoperability efforts and methodologies, focusing on the record level and the repository level. It should be noted that the models to be discussed in this article are not always mutually exclusive. Sometimes, within a particular project, more than one method may be used.

0.006159817 = product of:
  0.01847945 = sum of:
    0.01847945 = weight(_text_:on in 3616) [ClassicSimilarity], result of:
      0.01847945 = score(doc=3616,freq=6.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.16835764 = fieldWeight in 3616, product of:
          2.4494898 = tf(freq=6.0), with freq of:
            6.0 = termFreq=6.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.03125 = fieldNorm(doc=3616)
  0.33333334 = coord(1/3)

Abstract

Purpose - The purpose of this paper is to investigate the linking of a folksonomy (user vocabulary) and LCSH (controlled vocabulary) on the basis of word matching, for the potential use of LCSH in bringing order to folksonomies. Design/methodology/approach - A selected sample of a folksonomy from a popular collaborative tagging system, Delicious, was word-matched with LCSH. LCSH was transformed into a tree structure called an LCSH tree for the matching. A close examination was conducted on the characteristics of folksonomies, the overlap of folksonomies with LCSH, and the distribution of folksonomies over the LCSH tree. Findings - The experimental results showed that the total proportion of tags being matched with LC subject headings constituted approximately two-thirds of all tags involved, with an additional 10 percent of the remaining tags having potential matches. A number of barriers for the linking as well as two areas in need of improving the matching are identified and described. Three important tag distribution patterns over the LCSH tree were identified and supported: skewedness, multifacet, and Zipfian-pattern. Research limitations/implications - The results of the study can be adopted for the development of innovative methods of mapping between folksonomy and LCSH, which directly contributes to effective access and retrieval of tagged web resources and to the integration of multiple information repositories based on the two vocabularies. Practical implications - The linking of controlled vocabularies can be applicable to enhance information retrieval capability within collaborative tagging systems as well as across various tagging system information depositories and bibliographic databases. Originality/value - This is among frontier works that examines the potential of linking a folksonomy, extracted from a collaborative tagging system, to an authority-maintained subject heading system. It provides exploratory data to support further advanced mapping methods for linking the two vocabularies.

0.0044454644 = product of:
  0.013336393 = sum of:
    0.013336393 = weight(_text_:on in 1176) [ClassicSimilarity], result of:
      0.013336393 = score(doc=1176,freq=2.0), product of:
        0.109763056 = queryWeight, product of:
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.04990557 = queryNorm
        0.121501654 = fieldWeight in 1176, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          2.199415 = idf(docFreq=13325, maxDocs=44218)
          0.0390625 = fieldNorm(doc=1176)
  0.33333334 = coord(1/3)

Abstract

The rapid growth of Internet resources and digital collections has been accompanied by a proliferation of metadata schemas, each of which has been designed based on the requirements of particular user communities, intended users, types of materials, subject domains, project needs, etc. Problems arise when building large digital libraries or repositories with metadata records that were prepared according to diverse schemas. This article (published in two parts) contains an analysis of the methods that have been used to achieve or improve interoperability among metadata schemas and applications, for the purposes of facilitating conversion and exchange of metadata and enabling cross-domain metadata harvesting and federated searches. From a methodological point of view, implementing interoperability may be considered at different levels of operation: schema level, record level, and repository level. Part I of the article intends to explain possible situations in which metadata schemas may be created or implemented, whether in individual projects or in integrated repositories. It also discusses approaches used at the schema level. Part II of the article will discuss metadata interoperability efforts at the record and repository levels.