Search (364 results, page 19 of 19)

0.0017165683 = product of:
  0.006866273 = sum of:
    0.006866273 = weight(_text_:information in 5732) [ClassicSimilarity], result of:
      0.006866273 = score(doc=5732,freq=2.0), product of:
        0.08850355 = queryWeight, product of:
          1.7554779 = idf(docFreq=20772, maxDocs=44218)
          0.050415643 = queryNorm
        0.0775819 = fieldWeight in 5732, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          1.7554779 = idf(docFreq=20772, maxDocs=44218)
          0.03125 = fieldNorm(doc=5732)
  0.25 = coord(1/4)

Abstract

The speed with change takes place is startling and has left the information community with little time to consider how the development of electronic resources and the metadata schemas created to describe them effect how we view a work and its components. In terms of the attribution of authorship in the context of electronic works, this is a salient point. How does one determine authorship of a complex electronic resource, which is the culmination of the work of a myriad of entities? How does one determine the authorship when the content of the electronic resource may change at any moment without warning? What is the semantic content of the element that denotes authorship or responsibility for an electronic resource and how does the term used determine the element's meaning? The conceptual difficulty in the definition of the Creator element is deciphering what exactly the metadata schema should be describing. We also need to establish what purpose the element is intended to serve. In essence, we are at a crossroads. It is clear that once a work is digitized it exists in a significantly different medium, but how do we provide access to it? It is necessary to critically assess the accuracy of digital surrogates and to note that webmasters have a significant amount of intellectual responsibility invested in the sites they create. The solution to the problem in the Creator element may lie in moving from the concept of "authorship" and "origination" to a concept of intellectual responsibility. Perhaps the problematic nature of the Creator element allows us to move forward in our assessment and treatment of knowledge. One solution may be to standardize the definitions within various element sets. As the semantic web continues to grow and librarians strive to catalog electronic resources, the establishment of standard definitions for elements is becoming more relevant and important.

0.0017165683 = product of:
  0.006866273 = sum of:
    0.006866273 = weight(_text_:information in 2320) [ClassicSimilarity], result of:
      0.006866273 = score(doc=2320,freq=2.0), product of:
        0.08850355 = queryWeight, product of:
          1.7554779 = idf(docFreq=20772, maxDocs=44218)
          0.050415643 = queryNorm
        0.0775819 = fieldWeight in 2320, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          1.7554779 = idf(docFreq=20772, maxDocs=44218)
          0.03125 = fieldNorm(doc=2320)
  0.25 = coord(1/4)

Abstract

Purpose - The purpose of this paper is to describe a new approach to a well-known problem for digital libraries, how to search across multiple unrelated libraries with a single query. Design/methodology/approach - The approach involves creating new Dewey Decimal Classification terms and numbers from existing Dublin Core records. In total, 263,550 records were harvested from three digital libraries. Weighted key terms were extracted from the title, description and subject fields of each record. Ranked DDC classes were automatically generated from these key terms by considering DDC hierarchies via a series of filtering and aggregation stages. A mean reciprocal ranking evaluation compared a sample of 49 generated classes against DDC classes created by a trained librarian for the same records. Findings - The best results combined weighted key terms from the title, description and subject fields. Performance declines with increased specificity of DDC level. The results compare favorably with similar studies. Research limitations/implications - The metadata harvest required manual intervention and the evaluation was resource intensive. Future research will look at evaluation methodologies that take account of issues of consistency and ecological validity. Practical implications - The method does not require training data and is easily scalable. The pipeline can be customized for individual use cases, for example, recall or precision enhancing. Social implications - The approach can provide centralized access to information from multiple domains currently provided by individual digital libraries. Originality/value - The approach addresses metadata normalization in the context of web resources. The automatic classification approach accounts for matches within hierarchies, aggregating lower level matches to broader parents and thus approximates the practices of a human cataloger.

0.0017165683 = product of:
  0.006866273 = sum of:
    0.006866273 = weight(_text_:information in 5046) [ClassicSimilarity], result of:
      0.006866273 = score(doc=5046,freq=2.0), product of:
        0.08850355 = queryWeight, product of:
          1.7554779 = idf(docFreq=20772, maxDocs=44218)
          0.050415643 = queryNorm
        0.0775819 = fieldWeight in 5046, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          1.7554779 = idf(docFreq=20772, maxDocs=44218)
          0.03125 = fieldNorm(doc=5046)
  0.25 = coord(1/4)

Source

Information processing and management. 54(2018) no.6, S.985-1001

0.0015019972 = product of:
  0.006007989 = sum of:
    0.006007989 = weight(_text_:information in 1257) [ClassicSimilarity], result of:
      0.006007989 = score(doc=1257,freq=2.0), product of:
        0.08850355 = queryWeight, product of:
          1.7554779 = idf(docFreq=20772, maxDocs=44218)
          0.050415643 = queryNorm
        0.06788416 = fieldWeight in 1257, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          1.7554779 = idf(docFreq=20772, maxDocs=44218)
          0.02734375 = fieldNorm(doc=1257)
  0.25 = coord(1/4)

Abstract

Over the past three years, the Dublin Core Metadata Initiative has achieved a broad international consensus on the semantics of a simple element set for describing electronic resources. Since the first workshop in March 1995, which was reported in the very first issue of D-Lib Magazine, Dublin Core has been the topic of perhaps a dozen articles here. Originally intended to be simple and intuitive enough for authors to tag Web pages without special training, Dublin Core is being adapted now for more specialized uses, from government information and legal deposit to museum informatics and electronic commerce. To meet such specialized requirements, Dublin Core can be customized with additional elements or qualifiers. However, these refinements can compromise interoperability across applications. There are tradeoffs between using specific terms that precisely meet local needs versus general terms that are understood more widely. We can better understand this inevitable tension between simplicity and complexity if we recognize that metadata is a form of human language. With Dublin Core, as with a natural language, people are inclined to stretch definitions, make general terms more specific, specific terms more general, misunderstand intended meanings, and coin new terms. One goal of this paper, therefore, will be to examine the experience of some related ways to seek semantic interoperability through simplicity: planned languages, interlingua constructs, and pidgins. The problem of semantic interoperability is compounded when we consider Dublin Core in translation. All of the workshops, documents, mailing lists, user guides, and working group outputs of the Dublin Core Initiative have been in English. But in many countries and for many applications, people need a metadata standard in their own language. In principle, the broad elements of Dublin Core can be defined equally well in Bulgarian or Hindi. Since Dublin Core is a controlled standard, however, any parallel definitions need to be kept in sync as the standard evolves. Another goal of the paper, then, will be to define the conceptual and organizational problem of maintaining a metadata standard in multiple languages. In addition to a name and definition, which are meant for human consumption, each Dublin Core element has a label, or indexing token, meant for harvesting by search engines. For practical reasons, these machine-readable tokens are English-looking strings such as Creator and Subject (just as HTML tags are called HEAD, BODY, or TITLE). These tokens, which are shared by Dublin Cores in every language, ensure that metadata fields created in any particular language are indexed together across repositories. As symbols of underlying universal semantics, these tokens form the basis of semantic interoperability among the multiple Dublin Cores. As long as we limit ourselves to sharing these indexing tokens among exact translations of a simple set of fifteen broad elements, the definitions of which fit easily onto two pages, the problem of Dublin Core in multiple languages is straightforward. But nothing having to do with human language is ever so simple. Just as speakers of various languages must learn the language of Dublin Core in their own tongues, we must find the right words to talk about a metadata language that is expressable in many discipline-specific jargons and natural languages and that inevitably will evolve and change over time.