Search (9 results, page 1 of 1)

0.02659677 = product of:
  0.05319354 = sum of:
    0.05319354 = sum of:
      0.02856791 = weight(_text_:i in 1236) [ClassicSimilarity], result of:
        0.02856791 = score(doc=1236,freq=2.0), product of:
          0.17138503 = queryWeight, product of:
            3.7717297 = idf(docFreq=2765, maxDocs=44218)
            0.045439374 = queryNorm
          0.16668847 = fieldWeight in 1236, 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=1236)
      0.024625631 = weight(_text_:22 in 1236) [ClassicSimilarity], result of:
        0.024625631 = score(doc=1236,freq=2.0), product of:
          0.15912095 = queryWeight, product of:
            3.5018296 = idf(docFreq=3622, maxDocs=44218)
            0.045439374 = queryNorm
          0.15476047 = fieldWeight in 1236, product of:
            1.4142135 = tf(freq=2.0), with freq of:
              2.0 = termFreq=2.0
            3.5018296 = idf(docFreq=3622, maxDocs=44218)
            0.03125 = fieldNorm(doc=1236)
  0.5 = coord(1/2)

Abstract

Dublin Core is often presented as a modern form of catalog card -- a set of elements (and now qualifiers) that describe resources in a complete package. Sometimes it is proposed as an exchange format for sharing records among multiple collections. The founding principle that "every element is optional and repeatable" reinforces the notion that a Dublin Core description is to be taken as a whole. This paper, in contrast, is based on a much different premise: Dublin Core is a language. More precisely, it is a small language for making a particular class of statements about resources. Like natural languages, it has a vocabulary of word-like terms, the two classes of which -- elements and qualifiers -- function within statements like nouns and adjectives; and it has a syntax for arranging elements and qualifiers into statements according to a simple pattern. Whenever tourists order a meal or ask directions in an unfamiliar language, considerate native speakers will spontaneously limit themselves to basic words and simple sentence patterns along the lines of "I am so-and-so" or "This is such-and-such". Linguists call this pidginization. In such situations, a small phrase book or translated menu can be most helpful. By analogy, today's Web has been called an Internet Commons where users and information providers from a wide range of scientific, commercial, and social domains present their information in a variety of incompatible data models and description languages. In this context, Dublin Core presents itself as a metadata pidgin for digital tourists who must find their way in this linguistically diverse landscape. Its vocabulary is small enough to learn quickly, and its basic pattern is easily grasped. It is well-suited to serve as an auxiliary language for digital libraries. This grammar starts by defining terms. It then follows a 200-year-old tradition of English grammar teaching by focusing on the structure of single statements. It concludes by looking at the growing dictionary of Dublin Core vocabulary terms -- its registry, and at how statements can be used to build the metadata equivalent of paragraphs and compositions -- the application profile.

Date

26.12.2011 14:01:22

0.018469224 = product of:
  0.036938448 = sum of:
    0.036938448 = product of:
      0.073876895 = sum of:
        0.073876895 = weight(_text_:22 in 6048) [ClassicSimilarity], result of:
          0.073876895 = score(doc=6048,freq=2.0), product of:
            0.15912095 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.045439374 = queryNorm
            0.46428138 = fieldWeight in 6048, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.09375 = fieldNorm(doc=6048)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Date

22. 9.2007 15:41:14

0.017854942 = product of:
  0.035709884 = sum of:
    0.035709884 = product of:
      0.07141977 = sum of:
        0.07141977 = weight(_text_:i in 1187) [ClassicSimilarity], result of:
          0.07141977 = score(doc=1187,freq=8.0), product of:
            0.17138503 = queryWeight, product of:
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.045439374 = queryNorm
            0.41672117 = fieldWeight in 1187, product of:
              2.828427 = tf(freq=8.0), with freq of:
                8.0 = termFreq=8.0
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.0390625 = fieldNorm(doc=1187)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Abstract

In June of this year, I performed my final official duties as part of the Dublin Core Metadata Initiative management team. It is a happy irony to affix a seal on that service in this journal, as both D-Lib Magazine and the Dublin Core celebrate their tenth anniversaries. This essay is a personal reflection on some of the achievements and lessons of that decade. The OCLC-NCSA Metadata Workshop took place in March of 1995, and as we tried to understand what it meant and who would care, D-Lib magazine came into being and offered a natural venue for sharing our work. I recall a certain skepticism when Bill Arms said "We want D-Lib to be the first place people look for the latest developments in digital library research." These were the early days in the evolution of electronic publishing, and the goal was ambitious. By any measure, a decade of high-quality electronic publishing is an auspicious accomplishment, and D-Lib (and its host, CNRI) deserve congratulations for having achieved their goal. I am grateful to have been a contributor. That first DC workshop led to further workshops, a community, a variety of standards in several countries, an ISO standard, a conference series, and an international consortium. Looking back on this evolution is both satisfying and wistful. While I am pleased that the achievements are substantial, the unmet challenges also provide a rich till in which to cultivate insights on the development of digital infrastructure.

0.012625352 = product of:
  0.025250703 = sum of:
    0.025250703 = product of:
      0.050501406 = sum of:
        0.050501406 = weight(_text_:i in 1176) [ClassicSimilarity], result of:
          0.050501406 = score(doc=1176,freq=4.0), product of:
            0.17138503 = queryWeight, product of:
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.045439374 = queryNorm
            0.29466638 = fieldWeight in 1176, 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=1176)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

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.

0.0123128155 = product of:
  0.024625631 = sum of:
    0.024625631 = product of:
      0.049251262 = sum of:
        0.049251262 = weight(_text_:22 in 2686) [ClassicSimilarity], result of:
          0.049251262 = score(doc=2686,freq=2.0), product of:
            0.15912095 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.045439374 = queryNorm
            0.30952093 = fieldWeight in 2686, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.0625 = fieldNorm(doc=2686)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Date

10. 9.2004 10:22:40

0.010712966 = product of:
  0.021425933 = sum of:
    0.021425933 = product of:
      0.042851865 = sum of:
        0.042851865 = weight(_text_:i in 3893) [ClassicSimilarity], result of:
          0.042851865 = score(doc=3893,freq=2.0), product of:
            0.17138503 = queryWeight, product of:
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.045439374 = queryNorm
            0.25003272 = fieldWeight in 3893, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.046875 = fieldNorm(doc=3893)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

0.010100282 = product of:
  0.020200564 = sum of:
    0.020200564 = product of:
      0.040401127 = sum of:
        0.040401127 = weight(_text_:i in 1177) [ClassicSimilarity], result of:
          0.040401127 = score(doc=1177,freq=4.0), product of:
            0.17138503 = queryWeight, product of:
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.045439374 = queryNorm
            0.2357331 = fieldWeight in 1177, product of:
              2.0 = tf(freq=4.0), with freq of:
                4.0 = termFreq=4.0
              3.7717297 = idf(docFreq=2765, maxDocs=44218)
              0.03125 = fieldNorm(doc=1177)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

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.009234612 = product of:
  0.018469224 = sum of:
    0.018469224 = product of:
      0.036938448 = sum of:
        0.036938448 = weight(_text_:22 in 266) [ClassicSimilarity], result of:
          0.036938448 = score(doc=266,freq=2.0), product of:
            0.15912095 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.045439374 = queryNorm
            0.23214069 = fieldWeight in 266, 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=266)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Date

22. 5.2021 12:43:05

0.00769551 = product of:
  0.01539102 = sum of:
    0.01539102 = product of:
      0.03078204 = sum of:
        0.03078204 = weight(_text_:22 in 4550) [ClassicSimilarity], result of:
          0.03078204 = score(doc=4550,freq=2.0), product of:
            0.15912095 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.045439374 = queryNorm
            0.19345059 = fieldWeight in 4550, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.0390625 = fieldNorm(doc=4550)
      0.5 = coord(1/2)
  0.5 = coord(1/2)

Date

10.11.2018 16:27:22