Search (39 results, page 2 of 2)

0.008641209 = product of:
  0.051847253 = sum of:
    0.051847253 = weight(_text_:web in 4437) [ClassicSimilarity], result of:
      0.051847253 = score(doc=4437,freq=6.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.37471575 = fieldWeight in 4437, product of:
          2.4494898 = tf(freq=6.0), with freq of:
            6.0 = termFreq=6.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.046875 = fieldNorm(doc=4437)
  0.16666667 = coord(1/6)

Abstract

This site provides a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google and Yahoo! rely on this markup to improve the display of search results, making it easier for people to find the right web pages. Many sites are generated from structured data, which is often stored in databases. When this data is formatted into HTML, it becomes very difficult to recover the original structured data. Many applications, especially search engines, can benefit greatly from direct access to this structured data. On-page markup enables search engines to understand the information on web pages and provide richer search results in order to make it easier for users to find relevant information on the web. Markup can also enable new tools and applications that make use of the structure. A shared markup vocabulary makes easier for webmasters to decide on a markup schema and get the maximum benefit for their efforts. So, in the spirit of sitemaps.org, Bing, Google and Yahoo! have come together to provide a shared collection of schemas that webmasters can use.

0.008315007 = product of:
  0.04989004 = sum of:
    0.04989004 = weight(_text_:web in 1281) [ClassicSimilarity], result of:
      0.04989004 = score(doc=1281,freq=2.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.36057037 = fieldWeight in 1281, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.078125 = fieldNorm(doc=1281)
  0.16666667 = coord(1/6)

0.008231437 = product of:
  0.04938862 = sum of:
    0.04938862 = weight(_text_:web in 5896) [ClassicSimilarity], result of:
      0.04938862 = score(doc=5896,freq=4.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.35694647 = fieldWeight in 5896, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.0546875 = fieldNorm(doc=5896)
  0.16666667 = coord(1/6)

Abstract

This paper proposes the use of the Unified Modeling Language (UML) as a language for modelling ontologies for Web resources and the knowledge contained within them. To provide a mechanism for serialising and processing object diagrams representing knowledge, a pair of XSI-T stylesheets have been developed to map from XML Metadata Interchange (XMI) encodings of class diagrams to corresponding RDF schemas and to Java classes representing the concepts in the ontologies. The Java code includes methods for marshalling and unmarshalling object-oriented information between in-memory data structures and RDF serialisations of that information. This provides a convenient mechanism for Java applications to share knowledge on the Web

0.008231437 = product of:
  0.04938862 = sum of:
    0.04938862 = weight(_text_:web in 3229) [ClassicSimilarity], result of:
      0.04938862 = score(doc=3229,freq=4.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.35694647 = fieldWeight in 3229, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.0546875 = fieldNorm(doc=3229)
  0.16666667 = coord(1/6)

Abstract

Das Singapore Framework für Dublin-Core-Anwendungsprofile nennt die Rahmenbedingungen um Metadatenanwendungen möglichst interoperabel zu gestalten und so zu dokumentieren, dass sie nachnutzbar sind. Es definiert die Komponenten, die erforderlich und hilfreich sind, um ein Anwendungsprofil zu dokumentieren und es beschreibt, wie sich diese dokumentarischen Standards gegenüber Standard-Domain-Modellen und den Semantic-Web-Standards verhalten. Das Singapore Framework ist die Grundlage für die Beurteilung von Anwendungsprofilen in Hinblick auf Vollständigkeit der Dokumentation und auf Übereinstimmung mit den Prinzipien der Web-Architektur. Dieses Dokument bietet eine kurze Übersicht über das Singapore Framework. Weitere Dokumente, die als Anleitung für die Erstellung der erforderlichen Dokumentation dienen, sind in Planung.

0.0074371686 = product of:
  0.04462301 = sum of:
    0.04462301 = weight(_text_:web in 4439) [ClassicSimilarity], result of:
      0.04462301 = score(doc=4439,freq=10.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.32250395 = fieldWeight in 4439, product of:
          3.1622777 = tf(freq=10.0), with freq of:
            10.0 = termFreq=10.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.03125 = fieldNorm(doc=4439)
  0.16666667 = coord(1/6)

Abstract

Mit Schema.org und dem semantischen Web sollen Suchmaschinen verstehen lernen

Content

"Wörter haben oft mehrere Bedeutungen. Einige kennen den "Kanal" als künstliche Wasserstraße, andere vom Fernsehen. Die Waage kann zum Erfassen des Gewichts nützlich sein oder zur Orientierung auf der Horoskopseite. Casablanca ist eine Stadt und ein Film zugleich. Wo Menschen mit der Zeit Bedeutungen unterscheiden und verarbeiten lernen, können dies Suchmaschinen von selbst nicht. Stets listen sie dumpf hintereinander weg alles auf, was sie zu einem Thema finden. Damit das nicht so bleibt, haben sich nun Google, Yahoo und die zu Microsoft gehörende Suchmaschine Bing zusammengetan, um der Suche im Netz mehr Verständnis zu verpassen. Man spricht dabei auch von einer "semantischen Suche". Das Ergebnis heißt Schema.org. Wer die Webseite einmal besucht, sich ein wenig in die Unterstrukturen hereinklickt und weder Vorkenntnisse im Programmieren noch im Bereich des semantischen Webs hat, wird sich überfordert und gelangweilt wieder abwenden. Doch was hier entstehen könnte, hat das Zeug dazu, Teile des Netzes und speziell die Funktionen von Suchmaschinen mittel- oder langfristig zu verändern. "Große Player sind dabei, sich auf Standards zu einigen", sagt Daniel Bahls, Spezialist für Semantische Technologien beim ZBW Leibniz-Informationszentrum Wirtschaft in Hamburg. "Die semantischen Technologien stehen schon seit Jahren im Raum und wurden bisher nur im kleineren Kontext verwendet." Denn Schema.org lädt Entwickler, Forscher, die Semantic-Web-Community und am Ende auch alle Betreiber von Websites dazu ein, an der Umgestaltung der Suche im Netz mitzuwirken. Inhalte von Websites sollen mit einem speziellen, aber einheitlichen Vokabular für die Crawler - die Analyseprogramme der Suchmaschinen - gekennzeichnet und aufbereitet werden.
Indem Schlagworte, sogenannte Tags, in den für Normal-User nicht sichtbaren Teil des Codes von Websites eingebettet werden, sind Suchmachinen nicht mehr so sehr auf die Analyse der natürlichen Sprache angewiesen, um Texte inhaltlich zu erfassen. Im Blog ZBW Mediatalk wird dies als "Semantic Web light" bezeichnet - ein semantisches Web auf niedrigster Ebene. Aber selbst das werde "schon viel bewirken", meint Bahls. "Das semantische Web wird sich über die nächsten Jahrzehnte evolutionär weiterentwickeln." Einen "Abschluss" werde es nie geben, "da eine einheitliche Formalisierung von Begrifflichkeiten auf feiner Stufe kaum möglich ist". Die Ergebnisse aus Schema.org würden "zeitnah" in die Suchmaschine integriert, "denn einen Zeitplan" gebe es nicht, so Stefan Keuchel, Pressesprecher von Google Deutschland. Bis das so weit ist, hilft der Verweis von Daniel Bahns auf die bereits existierende semantische Suchmaschine Sig.ma. Geschwindigkeit und Menge der Ergebnisse nach einer Suchanfrage spielen hier keine Rolle. Sig.ma sammelt seine Informationen allein im Bereich des semantischen Webs und listet nach einer Anfrage alles Bekannte strukturiert auf.

0.006652005 = product of:
  0.03991203 = sum of:
    0.03991203 = weight(_text_:web in 4183) [ClassicSimilarity], result of:
      0.03991203 = score(doc=4183,freq=2.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.2884563 = fieldWeight in 4183, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.0625 = fieldNorm(doc=4183)
  0.16666667 = coord(1/6)

Abstract

A status of cataloging in Thailand shows a movement toward the use of information technology. The international standards for cataloging are being used and modified to effectively organize the information resources. An expanded scope of resources needed cataloging now covers cataloging the Web resources. The paper mentions Thailand's participation in the international working group on the use of metadata for libraries

0.0058795977 = product of:
  0.035277586 = sum of:
    0.035277586 = weight(_text_:web in 3337) [ClassicSimilarity], result of:
      0.035277586 = score(doc=3337,freq=4.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.25496176 = fieldWeight in 3337, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.0390625 = fieldNorm(doc=3337)
  0.16666667 = coord(1/6)

Abstract

Das Semantic Web ist schon seit über 10 Jahren viel beachtet und hat mit der Verfügbarkeit von Resource Description Framework (RDF) und den entsprechenden Ontologien einen großen Sprung in die Praxis gemacht. Vertreter kleiner Bibliotheken und Bibliothekare mit geringer Technik-Affinität stehen aber im Alltag vor großen Hürden, z.B. bei der Frage, wie man diese Technik konkret in den eigenen Webauftritt einbinden kann: man kommt sich vor wie Don Quijote, der versucht die Windmühlen zu bezwingen. RDF mit seinen Ontologien ist fast unverständlich komplex für Nicht-Informatiker und somit für den praktischen Einsatz auf Bibliotheksseiten in der Breite nicht direkt zu gebrauchen. Mit Schema.org wurde ursprünglich von den drei größten Suchmaschinen der Welt Google, Bing und Yahoo eine einfach und effektive semantische Beschreibung von Entitäten entwickelt. Aktuell wird Schema.org durch Google, Microsoft, Yahoo und Yandex weiter gesponsert und von vielen weiteren Suchmaschinen verstanden. Vor diesem Hintergrund hat die Bibliothek der Medizinischen Fakultät Mannheim auf ihrer Homepage (http://www.umm.uni-heidelberg.de/bibl/) verschiedene maschinenlesbare semantische Metadaten eingebettet. Sehr interessant und zukunftsweisend ist die neueste Entwicklung von Schema.org, bei der man eine 'Library' (https://schema.org/Library) mit Öffnungszeiten und vielem mehr modellieren kann. Ferner haben wir noch semantische Metadaten im Open Graph- und Dublin Core-Format eingebettet, um alte Standards und Facebook-konforme Informationen maschinenlesbar zur Verfügung zu stellen.

Theme

Semantic Web

0.0058795977 = product of:
  0.035277586 = sum of:
    0.035277586 = weight(_text_:web in 3372) [ClassicSimilarity], result of:
      0.035277586 = score(doc=3372,freq=4.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.25496176 = fieldWeight in 3372, product of:
          2.0 = tf(freq=4.0), with freq of:
            4.0 = termFreq=4.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.0390625 = fieldNorm(doc=3372)
  0.16666667 = coord(1/6)

Abstract

Europeana provides access to more than 54 million cultural heritage objects through its portal Europeana Collections. It is crucial for Europeana to be recognized by search engines as a trusted authoritative repository of cultural heritage objects. Indeed, even though its portal is the main entry point, most Europeana users come to it via search engines. Europeana Collections is fuelled by metadata describing cultural objects, represented in the Europeana Data Model (EDM). This paper presents the research and consequent recommendations for publishing Europeana metadata using the Schema.org vocabulary and best practices. Schema.org html embedded metadata to be consumed by search engines to power rich services (such as Google Knowledge Graph). Schema.org is an open and widely adopted initiative (used by over 12 million domains) backed by Google, Bing, Yahoo!, and Yandex, for sharing metadata across the web It underpins the emergence of new web techniques, such as so called Semantic SEO. Our research addressed the representation of the embedded metadata as part of the Europeana HTML pages and sitemaps so that the re-use of this data can be optimized. The practical objective of our work is to produce a Schema.org representation of Europeana resources described in EDM, being the richest as possible and tailored to Europeana's realities and user needs as well the search engines and their users.

0.005820505 = product of:
  0.03492303 = sum of:
    0.03492303 = weight(_text_:web in 4440) [ClassicSimilarity], result of:
      0.03492303 = score(doc=4440,freq=8.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.25239927 = fieldWeight in 4440, product of:
          2.828427 = tf(freq=8.0), with freq of:
            8.0 = termFreq=8.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.02734375 = fieldNorm(doc=4440)
  0.16666667 = coord(1/6)

Content

- Neue Standards Doch was hier entstehen könnte, hat das Zeug dazu, Teile des Netzes und speziell die Funktionen von Suchmaschinen mittel- oder langfristig zu verändern. "Große Player sind dabei, sich auf Standards zu einigen", sagt Daniel Bahls, Spezialist für Semantische Technologien beim ZBW Leibniz-Informationszentrum Wirtschaft in Hamburg. "Die semantischen Technologien stehen schon seit Jahren im Raum und wurden bisher nur im kleineren Kontext verwendet." Denn Schema.org lädt Entwickler, Forscher, die Semantic-Web-Community und am Ende auch alle Betreiber von Websites dazu ein, an der Umgestaltung der Suche im Netz mitzuwirken. "Damit wollen Google, Bing und Yahoo! dem Info-Chaos im WWW den Garaus machen", schreibt André Vatter im Blog ZBW Mediatalk. Inhalte von Websites sollen mit einem speziellen, aber einheitlichen Vokabular für die Crawler der Suchmaschinen gekennzeichnet und aufbereitet werden. Indem Schlagworte, so genannte Tags, in den Code von Websites eingebettet werden, sind Suchmachinen nicht mehr so sehr auf die Analyse der natürlichen Sprache angewiesen, um Texte inhaltlich zu erfassen. Im Blog wird dies als "Semantic Web light" bezeichnet - ein semantisches Web auf niedrigster Ebene. Aber selbst das werde "schon viel bewirken", meint Bahls. "Das semantische Web wird sich über die nächsten Jahrzehnte evolutionär weiterentwickeln." Einen "Abschluss" werde es nie geben, "da eine einheitliche Formalisierung von Begrifflichkeiten auf feiner Stufe kaum möglich ist."

0.005000541 = product of:
  0.030003246 = sum of:
    0.030003246 = weight(_text_:retrieval in 2294) [ClassicSimilarity], result of:
      0.030003246 = score(doc=2294,freq=2.0), product of:
        0.12824841 = queryWeight, product of:
          3.024915 = idf(docFreq=5836, maxDocs=44218)
          0.042397358 = queryNorm
        0.23394634 = fieldWeight in 2294, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          3.024915 = idf(docFreq=5836, maxDocs=44218)
          0.0546875 = fieldNorm(doc=2294)
  0.16666667 = coord(1/6)

Abstract

Purpose: Investigate the combination of controlled and folksonomy approaches to support resource discovery in repositories and digital collections. Aim: Investigate whether use of an established controlled vocabulary can help improve social tagging for better resource discovery. Objectives: (1) Investigate indexing aspects when using only social tagging versus when using social tagging with suggestions from a controlled vocabulary; (2) Investigate above in two different contexts: tagging by readers and tagging by authors; (3) Investigate influence of only social tagging versus social tagging with a controlled vocabulary on retrieval. - Vgl.: http://www.ukoln.ac.uk/projects/enhanced-tagging/.

0.0049890038 = product of:
  0.029934023 = sum of:
    0.029934023 = weight(_text_:web in 3523) [ClassicSimilarity], result of:
      0.029934023 = score(doc=3523,freq=2.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.21634221 = fieldWeight in 3523, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.046875 = fieldNorm(doc=3523)
  0.16666667 = coord(1/6)

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?

0.0041575036 = product of:
  0.02494502 = sum of:
    0.02494502 = weight(_text_:web in 1237) [ClassicSimilarity], result of:
      0.02494502 = score(doc=1237,freq=2.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.18028519 = fieldWeight in 1237, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.0390625 = fieldNorm(doc=1237)
  0.16666667 = coord(1/6)

Abstract

Metadata is a keystone component for a broad spectrum of applications that are emerging on the Web to help stitch together content and services and make them more visible to users. The Dublin Core Metadata Initiative (DCMI) has led the development of structured metadata to support resource discovery. This international community has, over a period of 6 years and 8 workshops, brought forth: * A core standard that enhances cross-disciplinary discovery and has been translated into 25 languages to date; * A conceptual framework that supports the modular development of auxiliary metadata components; * An open consensus building process that has brought to fruition Australian, European and North American standards with promise as a global standard for resource discovery; * An open community of hundreds of practitioners and theorists who have found a common ground of principles, procedures, core semantics, and a framework to support interoperable metadata. The 8th Dublin Core Metadata Workshop capped an active year of progress that included standardization of the 15-element core foundation and approval of an initial array of Dublin Core Qualifiers. While there is important work to be done to promote stability and increased adoption of the Dublin Core, the time has come to look beyond the core elements towards a broader metadata agenda. This report describes the new mission statement of the Dublin Core Metadata Initiative (DCMI) that supports the agenda, recapitulates the important milestones of the year 2000, outlines activities of the 8th DCMI workshop in Ottawa, and summarizes the 2001 workplan.

0.0029102524 = product of:
  0.017461514 = sum of:
    0.017461514 = weight(_text_:web in 1257) [ClassicSimilarity], result of:
      0.017461514 = score(doc=1257,freq=2.0), product of:
        0.13836423 = queryWeight, product of:
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.042397358 = queryNorm
        0.12619963 = fieldWeight in 1257, product of:
          1.4142135 = tf(freq=2.0), with freq of:
            2.0 = termFreq=2.0
          3.2635105 = idf(docFreq=4597, maxDocs=44218)
          0.02734375 = fieldNorm(doc=1257)
  0.16666667 = coord(1/6)

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.

0.002553003 = product of:
  0.015318017 = sum of:
    0.015318017 = product of:
      0.045954052 = sum of:
        0.045954052 = weight(_text_:22 in 2686) [ClassicSimilarity], result of:
          0.045954052 = score(doc=2686,freq=2.0), product of:
            0.14846832 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.042397358 = 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.33333334 = coord(1/3)
  0.16666667 = coord(1/6)

Date

10. 9.2004 10:22:40

0.0019147521 = product of:
  0.011488512 = sum of:
    0.011488512 = product of:
      0.034465536 = sum of:
        0.034465536 = weight(_text_:22 in 266) [ClassicSimilarity], result of:
          0.034465536 = score(doc=266,freq=2.0), product of:
            0.14846832 = queryWeight, product of:
              3.5018296 = idf(docFreq=3622, maxDocs=44218)
              0.042397358 = 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.33333334 = coord(1/3)
  0.16666667 = coord(1/6)

Date

22. 5.2021 12:43:05

0.0018070375 = product of:
  0.010842225 = sum of:
    0.010842225 = product of:
      0.032526672 = sum of:
        0.032526672 = weight(_text_:system in 1228) [ClassicSimilarity], result of:
          0.032526672 = score(doc=1228,freq=2.0), product of:
            0.13353272 = queryWeight, product of:
              3.1495528 = idf(docFreq=5152, maxDocs=44218)
              0.042397358 = queryNorm
            0.2435858 = fieldWeight in 1228, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.1495528 = idf(docFreq=5152, maxDocs=44218)
              0.0546875 = fieldNorm(doc=1228)
      0.33333334 = coord(1/3)
  0.16666667 = coord(1/6)

Abstract

Interoperability between digital libraries depends on effective sharing of metadata. Successful sharing of metadata requires common standards for metadata exchange. Previous efforts have focused on either defining a single metadata standard, such as Dublin Core, or building digital library middleware, such as Z39.50 or Stanford's Digital Library Interoperability Protocol. In this article, we propose a distributed architecture for managing metadata and metadata schema. Instead of normalizing all metadata and schema to a single format, we have focused on building a middleware framework that tolerates heterogeneity. By providing facilities for typing and dynamic conversion of metadata, our system permits continual introduction of new forms of metadata with minimal impact on compatibility.

0.001290741 = product of:
  0.007744446 = sum of:
    0.007744446 = product of:
      0.023233337 = sum of:
        0.023233337 = weight(_text_:system in 5443) [ClassicSimilarity], result of:
          0.023233337 = score(doc=5443,freq=2.0), product of:
            0.13353272 = queryWeight, product of:
              3.1495528 = idf(docFreq=5152, maxDocs=44218)
              0.042397358 = queryNorm
            0.17398985 = fieldWeight in 5443, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.1495528 = idf(docFreq=5152, maxDocs=44218)
              0.0390625 = fieldNorm(doc=5443)
      0.33333334 = coord(1/3)
  0.16666667 = coord(1/6)

Abstract

Sharing code between libraries is not a new phenomenon and neither is Google Tag Manager (GTM). GTM launched in 2012 as a JavaScript and HTML manager with the intent of easing the implementation of different analytics trackers and marketing scripts on a website. However, it can be used to load other code using its tag system onto a website. It's a simple process to export and import tags facilitating the code sharing process without requiring a high degree of coding experience. The entire process involves creating the script tag in GTM, exporting the GTM content into a sharable export file for someone else to import into their library's GTM container, and finally publishing that imported file to push the code to the website it was designed for. This case study provides an example of designing and sharing a GTM container loaded with advanced Google Analytics configurations such as event tracking and custom dimensions for other libraries using the Summon discovery service. It also discusses processes for designing GTM tags for export, best practices on importing and testing GTM content created by other libraries and concludes with evaluating the pros and cons of encouraging GTM use.

0.001290741 = product of:
  0.007744446 = sum of:
    0.007744446 = product of:
      0.023233337 = sum of:
        0.023233337 = weight(_text_:system in 5444) [ClassicSimilarity], result of:
          0.023233337 = score(doc=5444,freq=2.0), product of:
            0.13353272 = queryWeight, product of:
              3.1495528 = idf(docFreq=5152, maxDocs=44218)
              0.042397358 = queryNorm
            0.17398985 = fieldWeight in 5444, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.1495528 = idf(docFreq=5152, maxDocs=44218)
              0.0390625 = fieldNorm(doc=5444)
      0.33333334 = coord(1/3)
  0.16666667 = coord(1/6)

Abstract

Columbia University Libraries recently embarked on a multi-phase project to migrate nearly 4,000 records describing over 70,000 linear feet of archival material from disparate sources and formats into ArchivesSpace. This paper discusses tools and methods brought to bear in Phase 2 of this project, which required us to look closely at how to integrate a large number of legacy finding aids into the new system and merge descriptive data that had diverged in myriad ways. Using Python, XSLT, and a widely available if underappreciated resource-the Google Sheets API-archival and technical library staff devised ways to efficiently report data from different sources, and present it in an accessible, user-friendly way,. Responses were then fed back into automated data remediation processes to keep the migration project on track and minimize manual intervention. The scripts and processes developed proved very effective, and moreover, show promise well beyond the ArchivesSpace migration. This paper describes the Python/XSLT/Sheets API processes developed and how they opened a path to move beyond CSV-based reporting with flexible, ad-hoc data interfaces easily adaptable to meet a variety of purposes.

0.001032593 = product of:
  0.0061955573 = sum of:
    0.0061955573 = product of:
      0.018586671 = sum of:
        0.018586671 = weight(_text_:system in 1192) [ClassicSimilarity], result of:
          0.018586671 = score(doc=1192,freq=2.0), product of:
            0.13353272 = queryWeight, product of:
              3.1495528 = idf(docFreq=5152, maxDocs=44218)
              0.042397358 = queryNorm
            0.13919188 = fieldWeight in 1192, product of:
              1.4142135 = tf(freq=2.0), with freq of:
                2.0 = termFreq=2.0
              3.1495528 = idf(docFreq=5152, maxDocs=44218)
              0.03125 = fieldNorm(doc=1192)
      0.33333334 = coord(1/3)
  0.16666667 = coord(1/6)

Abstract

In the June 2003 issue of D-Lib Magazine, Kenney et al. (2003) discuss a comparative study between Cornell's email reference staff and Google's Answers service. This interesting study provided insights on the potential impact of "computing and simple algorithms combined with human intelligence" for library reference services. As mentioned in the Kenney et al. article, Bill Arms (2000) had discussed the possibilities of automated digital libraries in an even earlier D-Lib article. Arms discusses not only automating reference services, but also another library function that seems to inspire lively debates about automation-metadata creation. While intended to illuminate, these debates sometimes generate more heat than light. In an effort to explore the potential for automating metadata generation, the Digital Knowledge Center (DKC) of the Sheridan Libraries at The Johns Hopkins University developed and tested an automated name authority control (ANAC) tool. ANAC represents a component of a digital workflow management system developed in connection with the digital Lester S. Levy Collection of Sheet Music. The evaluation of ANAC followed the spirit of the Kenney et al. study that was, as they stated, "more exploratory than scientific." These ANAC evaluation results are shared with the hope of fostering constructive dialogue and discussions about the potential for semi-automated techniques or frameworks for library functions and services such as metadata creation. The DKC's research agenda emphasizes the development of tools that combine automated processes and human intervention, with the overall goal of involving humans at higher levels of analysis and decision-making. Others have looked at issues regarding the automated generation of metadata. A session at the 2003 Joint Conference on Digital Libraries was devoted to automatic metadata creation, and a session at the 2004 conference addressed automated name disambiguation. Commercial vendors such as OCLC, Marcive, and LTI have long used automated techniques for matching names to Library of Congress authority records. We began developing ANAC as a component of a larger suite of open source tools to support workflow management for digital projects. This article describes the goals for the ANAC tool, provides an overview of the metadata records used for testing, describes the architecture for ANAC, and concludes with discussions of the methodology and evaluation of the experiment comparing human cataloging and ANAC-generated results.