Search (8 results, page 1 of 1)

  • × author_ss:"Baker, T."
  1. Baker, T.; Rühle, S.: Übersetzung des Dublin Core Metadata Initiative Abstract Model (DCAM) (2009) 0.01
    0.011084656 = product of:
      0.08867725 = sum of:
        0.08867725 = weight(_text_:property in 3230) [ClassicSimilarity], result of:
          0.08867725 = score(doc=3230,freq=2.0), product of:
            0.25336683 = queryWeight, product of:
              6.335595 = idf(docFreq=212, maxDocs=44218)
              0.039991006 = queryNorm
            0.3499955 = fieldWeight in 3230, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              6.335595 = idf(docFreq=212, maxDocs=44218)
              0.0390625 = fieldNorm(doc=3230)
      0.125 = coord(1/8)
    
    Abstract
    Dieses Dokument beschreibt das Abstraktmodell für Dublin-Core-Metadaten. Ziel des Dokuments ist es vor allem, die Elemente und Strukturen, die in Dublin-Core-Metadaten verwendet werden, zu benennen. Das Dokument definiert die verwendeten Elemente und beschreibt, wie sie miteinander kombiniert werden, um Informationsstrukturen zu bilden. Es stellt ein von jeglicher besonderen Codierungssyntax unabhängiges Informationsmodell dar. Ein solches Informationsmodell macht es uns möglich, die Beschreibungen, die wir codieren wollen, besser zu verstehen und erleichtert die Entwicklung besserer Mappings und syntaxübergreifender Datenkonvertierungen. Dieses Dokument richtet sich in erster Linie an Entwickler von Softwareanwendungen, die Dublin-Core-Metadaten unterstützen, an Personen, die neue syntaktische Codierungsrichtlinien für Dublin-Core-Metadaten entwickeln und an Personen, die Metadatenprofile entwickeln, die auf DCMI- oder anderen kompatibelen Vokabularen basieren. Das DCMI-Abstraktmodell basiert auf der Arbeit des World Wide Web Consortium (W3C) am Resource Description Framework (RDF). Die Verwendung von Konzepten aus RDF wird unten im Abschnitt 5 zusammengefasst. Das DCMI-Abstraktmodell wird hier mit UML-Klassen-Diagrammen dargestellt. Für Leser, die solche UML-Klassen-Diagramme nicht kennen, eine kurze Anleitung: Linien, die in einem Maßpfeil enden, werden als 'ist' oder 'ist eine' gelesen (z.B. "value ist eine resource"). Linien, die mit einer Raute beginnen, werden als 'hat' oder 'hat eine' gelesen (z.B. "statement hat einen property URI"). Andere Beziehungen werden entsprechend gekennzeichnet. Die kursiv geschriebenen Wörter und Phrasen in diesem Dokument werden im Abschnitt 7 ("Terminologie") definiert. Wir danken Dan Brickley, Rachel Heery, Alistair Miles, Sarah Pulis, den Mitgliedern des DCMI Usage Board und den Mitgliedern der DCMI Architecture Community für ihr Feedback zu den vorangegangenen Versionen dieses Dokuments.
  2. Baker, T.: ¬A grammar of Dublin Core (2000) 0.01
    0.00687223 = product of:
      0.05497784 = sum of:
        0.05497784 = sum of:
          0.033304926 = weight(_text_:resources in 1236) [ClassicSimilarity], result of:
            0.033304926 = score(doc=1236,freq=4.0), product of:
              0.14598069 = queryWeight, product of:
                3.650338 = idf(docFreq=3122, maxDocs=44218)
                0.039991006 = queryNorm
              0.22814612 = fieldWeight in 1236, product of:
                2.0 = tf(freq=4.0), with freq of:
                  4.0 = termFreq=4.0
                3.650338 = idf(docFreq=3122, maxDocs=44218)
                0.03125 = fieldNorm(doc=1236)
          0.021672918 = weight(_text_:22 in 1236) [ClassicSimilarity], result of:
            0.021672918 = score(doc=1236,freq=2.0), product of:
              0.1400417 = queryWeight, product of:
                3.5018296 = idf(docFreq=3622, maxDocs=44218)
                0.039991006 = 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.125 = coord(1/8)
    
    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
  3. Baker, T.: ¬The concepts of knowledge organization systems as hubs in the Web of data (2011) 0.00
    0.003122337 = product of:
      0.024978695 = sum of:
        0.024978695 = product of:
          0.04995739 = sum of:
            0.04995739 = weight(_text_:resources in 4810) [ClassicSimilarity], result of:
              0.04995739 = score(doc=4810,freq=4.0), product of:
                0.14598069 = queryWeight, product of:
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.039991006 = queryNorm
                0.34221917 = fieldWeight in 4810, product of:
                  2.0 = tf(freq=4.0), with freq of:
                    4.0 = termFreq=4.0
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.046875 = fieldNorm(doc=4810)
          0.5 = coord(1/2)
      0.125 = coord(1/8)
    
    Abstract
    The domain name system of the World-Wide Web provides a managed space of globally unique identifiers resolvable to a globally distributed set of information resources. When the concepts of a knowledge organization system (KOS) are identified using URIs, the KOS functions as a "hub" for accessing resources tagged with its concepts. Resource Description Framework (RDF) triples, consisting of a subject, a predicate, and an object, joined on the basis of matched URIs, form the spokes of these hubs. New sources of metadata can be dynamically integrated into an infinitely "expandable" description. Term-to-term alignments with other KOSs increase the conceptual reach of a KOS, while concept labels in multiple languages increase its reach linguistically. This talk illustrates the mechanics of merging linked data triples with reference to KOSs that function as hubs.
  4. Baker, T.: ¬A multilingual registry for Dublin Core elements and qualifiers (2000) 0.00
    0.0025757966 = product of:
      0.020606373 = sum of:
        0.020606373 = product of:
          0.041212745 = sum of:
            0.041212745 = weight(_text_:resources in 4447) [ClassicSimilarity], result of:
              0.041212745 = score(doc=4447,freq=2.0), product of:
                0.14598069 = queryWeight, product of:
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.039991006 = queryNorm
                0.28231642 = fieldWeight in 4447, product of:
                  1.4142135 = tf(freq=2.0), with freq of:
                    2.0 = termFreq=2.0
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.0546875 = fieldNorm(doc=4447)
          0.5 = coord(1/2)
      0.125 = coord(1/8)
    
    Abstract
    The Dublin Core Metadata Element Set (DCMES) provides 15 high-level, generic concepts for describing a broad range of resources. In actual implementations, these generic concepts must often be made more precise to meet the needs of a specific discipline or application. To support this, the Dublin Core Metadata Initiative has defined standard ways to refine or contextualize an element with 'qualifiers' - for example, to distinguish between Author, Illustrator, and Editor as types of Creator. As other articles in this issue have discussed, the DCMI is currently focusing much of its attention on standardizing qualifiers that have been found to be useful to implementors
  5. Baker, T.; Bermès, E.; Coyle, K.; Dunsire, G.; Isaac, A.; Murray, P.; Panzer, M.; Schneider, J.; Singer, R.; Summers, E.; Waites, W.; Young, J.; Zeng, M.: Library Linked Data Incubator Group Final Report (2011) 0.00
    0.0020815579 = product of:
      0.016652463 = sum of:
        0.016652463 = product of:
          0.033304926 = sum of:
            0.033304926 = weight(_text_:resources in 4796) [ClassicSimilarity], result of:
              0.033304926 = score(doc=4796,freq=4.0), product of:
                0.14598069 = queryWeight, product of:
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.039991006 = queryNorm
                0.22814612 = fieldWeight in 4796, product of:
                  2.0 = tf(freq=4.0), with freq of:
                    4.0 = termFreq=4.0
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.03125 = fieldNorm(doc=4796)
          0.5 = coord(1/2)
      0.125 = coord(1/8)
    
    Abstract
    The mission of the W3C Library Linked Data Incubator Group, chartered from May 2010 through August 2011, has been "to help increase global interoperability of library data on the Web, by bringing together people involved in Semantic Web activities - focusing on Linked Data - in the library community and beyond, building on existing initiatives, and identifying collaboration tracks for the future." In Linked Data [LINKEDDATA], data is expressed using standards such as Resource Description Framework (RDF) [RDF], which specifies relationships between things, and Uniform Resource Identifiers (URIs, or "Web addresses") [URI]. This final report of the Incubator Group examines how Semantic Web standards and Linked Data principles can be used to make the valuable information assets that library create and curate - resources such as bibliographic data, authorities, and concept schemes - more visible and re-usable outside of their original library context on the wider Web. The Incubator Group began by eliciting reports on relevant activities from parties ranging from small, independent projects to national library initiatives (see the separate report, Library Linked Data Incubator Group: Use Cases) [USECASE]. These use cases provided the starting point for the work summarized in the report: an analysis of the benefits of library Linked Data, a discussion of current issues with regard to traditional library data, existing library Linked Data initiatives, and legal rights over library data; and recommendations for next steps. The report also summarizes the results of a survey of current Linked Data technologies and an inventory of library Linked Data resources available today (see also the more detailed report, Library Linked Data Incubator Group: Datasets, Value Vocabularies, and Metadata Element Sets) [VOCABDATASET].
  6. Baker, T.: Dublin Core Application Profiles : current approaches (2010) 0.00
    0.002031836 = product of:
      0.016254688 = sum of:
        0.016254688 = product of:
          0.032509375 = sum of:
            0.032509375 = weight(_text_:22 in 3737) [ClassicSimilarity], result of:
              0.032509375 = score(doc=3737,freq=2.0), product of:
                0.1400417 = queryWeight, product of:
                  3.5018296 = idf(docFreq=3622, maxDocs=44218)
                  0.039991006 = queryNorm
                0.23214069 = fieldWeight in 3737, 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=3737)
          0.5 = coord(1/2)
      0.125 = coord(1/8)
    
    Source
    Wissensspeicher in digitalen Räumen: Nachhaltigkeit - Verfügbarkeit - semantische Interoperabilität. Proceedings der 11. Tagung der Deutschen Sektion der Internationalen Gesellschaft für Wissensorganisation, Konstanz, 20. bis 22. Februar 2008. Hrsg.: J. Sieglerschmidt u. H.P.Ohly
  7. Baker, T.; Sutton, S.A.: Linked data and the charm of weak semantics : Introduction: the strengths of weak semantics (2015) 0.00
    0.0018398546 = product of:
      0.014718837 = sum of:
        0.014718837 = product of:
          0.029437674 = sum of:
            0.029437674 = weight(_text_:resources in 2022) [ClassicSimilarity], result of:
              0.029437674 = score(doc=2022,freq=2.0), product of:
                0.14598069 = queryWeight, product of:
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.039991006 = queryNorm
                0.20165458 = fieldWeight in 2022, product of:
                  1.4142135 = tf(freq=2.0), with freq of:
                    2.0 = termFreq=2.0
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.0390625 = fieldNorm(doc=2022)
          0.5 = coord(1/2)
      0.125 = coord(1/8)
    
    Abstract
    Logic and precision are fundamental to ontologies underlying the semantic web and, by extension, to linked data. This special section focuses on the interaction of semantics, ontologies and linked data. The discussion presents the Simple Knowledge Organization Scheme (SKOS) as a less formal strategy for expressing concept hierarchies and associations and questions the value of deep domain ontologies in favor of simpler vocabularies that are more open to reuse, albeit risking illogical outcomes. RDF ontologies harbor another unexpected drawback. While structurally sound, they leave validation gaps permitting illogical uses, a problem being addressed by a W3C Working Group. Data models based on RDF graphs and properties may replace traditional library catalog models geared to predefined entities, with relationships between RDF classes providing the semantic connections. The BIBFRAME Initiative takes a different and streamlined approach to linking data, building rich networks of information resources rather than relying on a strict underlying structure and vocabulary. Taken together, the articles illustrate the trend toward a pragmatic approach to a Semantic Web, sacrificing some specificity for greater flexibility and partial interoperability.
  8. Baker, T.: Languages for Dublin Core (1998) 0.00
    0.0012878983 = product of:
      0.010303186 = sum of:
        0.010303186 = product of:
          0.020606373 = sum of:
            0.020606373 = weight(_text_:resources in 1257) [ClassicSimilarity], result of:
              0.020606373 = score(doc=1257,freq=2.0), product of:
                0.14598069 = queryWeight, product of:
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.039991006 = queryNorm
                0.14115821 = fieldWeight in 1257, product of:
                  1.4142135 = tf(freq=2.0), with freq of:
                    2.0 = termFreq=2.0
                  3.650338 = idf(docFreq=3122, maxDocs=44218)
                  0.02734375 = fieldNorm(doc=1257)
          0.5 = coord(1/2)
      0.125 = coord(1/8)
    
    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.