Difference between revisions of "OJS-OAI DRIVERGuidelines"

From PKP Wiki
Jump to: navigation, search
 
(3 intermediate revisions by one user not shown)
Line 3: Line 3:
 
Die Open Archives Initiative (OAI) entwickelte das Protocol for Metadata Harvesting (OAI-PMH), ein anwendungsunabhängiges Interoperabilitäts-Framework, das die Kommunikation zwischen Data- und Service-Anbietern ermöglicht und auf Metadaten-Harvesting basiert. Als Standard für die Metadaten wird meist Dublin Core (DC) verwendet. Da diese Standards aber auch Raum für die lokale Interpretation und Implementierung lassen, werden sie unterschiedlich verwendet, wodurch die Interoperabilität erschwert ist. Im Rahmen des Projekts DRIVER wurden deshalb Leitfäden für die Verwendung von Standards entwickelt, um die Interoperabilität von Data- und Service-Anbietern zu erleichtern.  
 
Die Open Archives Initiative (OAI) entwickelte das Protocol for Metadata Harvesting (OAI-PMH), ein anwendungsunabhängiges Interoperabilitäts-Framework, das die Kommunikation zwischen Data- und Service-Anbietern ermöglicht und auf Metadaten-Harvesting basiert. Als Standard für die Metadaten wird meist Dublin Core (DC) verwendet. Da diese Standards aber auch Raum für die lokale Interpretation und Implementierung lassen, werden sie unterschiedlich verwendet, wodurch die Interoperabilität erschwert ist. Im Rahmen des Projekts DRIVER wurden deshalb Leitfäden für die Verwendung von Standards entwickelt, um die Interoperabilität von Data- und Service-Anbietern zu erleichtern.  
  
Im Rahmen des Projekts „Funktionaler Ausbau von und Mehrwertdienste für ‚Open Journal Systems‘ (OJS)“ [1] wurden folgende Anpassungsnotwendigkeiten gemäß den DRIVER Guidelines 2.0 identifiziert und die OJS-OAI-Schnittstelle wurde entsprechend verändert:
+
Im Rahmen des Projekts „Funktionaler Ausbau von und Mehrwertdienste für ‚Open Journal Systems‘ (OJS)“ [http://www.cedis.fu-berlin.de/ojs-de] wurden folgende Anpassungsnotwendigkeiten gemäß den DRIVER Guidelines 2.0 identifiziert und die OJS-OAI-Schnittstelle wurde entsprechend verändert:
  
 
===Verwendung des Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)===
 
===Verwendung des Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)===
  
''Resumption Token Lifespan''
+
=====Resumption Token Lifespan=====
  
 
Die Resultate einer OAI-PMH-Anfrage können manchmal sehr lang sein, sodass es von Vorteil wäre, diese in mehrere kleinere Anfragen und Resultate zu verteilen und eine Zeit lang aufzubewahren. Resumption Tokens stellen einen Mechanismus dar, der das ermöglicht. Laut DRIVER-Guidelines 2.0 ist die angemessene Lebensdauer eines Resumption Tokens 24 Stunden, damit Harvester genügend Zeit haben und im Fall eines Fehlers in der Lage sind, von da weiter zu harvesten, wo sie zuletzt waren, anstatt von vorne anzufangen. Die Lebensdauer der Resumption Tokens in OJS wurde dementsprechend angepasst.
 
Die Resultate einer OAI-PMH-Anfrage können manchmal sehr lang sein, sodass es von Vorteil wäre, diese in mehrere kleinere Anfragen und Resultate zu verteilen und eine Zeit lang aufzubewahren. Resumption Tokens stellen einen Mechanismus dar, der das ermöglicht. Laut DRIVER-Guidelines 2.0 ist die angemessene Lebensdauer eines Resumption Tokens 24 Stunden, damit Harvester genügend Zeit haben und im Fall eines Fehlers in der Lage sind, von da weiter zu harvesten, wo sie zuletzt waren, anstatt von vorne anzufangen. Die Lebensdauer der Resumption Tokens in OJS wurde dementsprechend angepasst.
  
''Deleted Records Strategy''
+
=====Deleted Records Strategy=====
  
 
Damit Harvester die gelöschten Datensätze leichter entdecken können und Service-Provider nicht gelöschte Datensätze anzeigen, die es eigentlich nicht mehr gibt, empfehlen die DRIVER-Guidelines 2.0, Informationen über die gelöschten Datensätze mindestens einen Monat lang zu bewahren/zu verwalten. Bisher hatte OJS keine Informationen über die gelöschten Artikel bzw. Datensätze; nun wurde OJS so erweitert, dass die benötigten Informationen über die gelöschten Datensätze permanent aufbewahrt und über die OAI-Schnittstelle entsprechend berücksichtigt werden.  
 
Damit Harvester die gelöschten Datensätze leichter entdecken können und Service-Provider nicht gelöschte Datensätze anzeigen, die es eigentlich nicht mehr gibt, empfehlen die DRIVER-Guidelines 2.0, Informationen über die gelöschten Datensätze mindestens einen Monat lang zu bewahren/zu verwalten. Bisher hatte OJS keine Informationen über die gelöschten Artikel bzw. Datensätze; nun wurde OJS so erweitert, dass die benötigten Informationen über die gelöschten Datensätze permanent aufbewahrt und über die OAI-Schnittstelle entsprechend berücksichtigt werden.  
  
''Description Container''
+
=====Description Container=====
  
 
Um Harvestern Informationen über das System sowie die Möglichkeit zu geben, die Änderungen an den gelieferten Metadaten nachzuvollziehen und mit einer bestimmten Systemversion zu verknüpfen, sollten über die OAI-Schnittstelle die entsprechenden Systeminformationen (z.B. Titel und Version) geliefert werden. Diese Informationen waren bisher für OJS nicht verfügbar und wurden nun so in OJS umgesetzt, dass sie als ein Description Container geliefert werden. Dazu wird folgendes Schema verwendet: http://oai.dlib.vt.edu/OAI/metadata/toolkit.xsd.  
 
Um Harvestern Informationen über das System sowie die Möglichkeit zu geben, die Änderungen an den gelieferten Metadaten nachzuvollziehen und mit einer bestimmten Systemversion zu verknüpfen, sollten über die OAI-Schnittstelle die entsprechenden Systeminformationen (z.B. Titel und Version) geliefert werden. Diese Informationen waren bisher für OJS nicht verfügbar und wurden nun so in OJS umgesetzt, dass sie als ein Description Container geliefert werden. Dazu wird folgendes Schema verwendet: http://oai.dlib.vt.edu/OAI/metadata/toolkit.xsd.  
  
''DRIVER-Set''
+
=====DRIVER-Set=====
  
 
Repositorien können ihre Publikationen mithilfe sogenannter Sets organisieren.
 
Repositorien können ihre Publikationen mithilfe sogenannter Sets organisieren.
Line 26: Line 26:
 
===Verwendung des Dublin-Core-Formats===
 
===Verwendung des Dublin-Core-Formats===
  
''Creator''
+
=====Creator=====
  
 
Im DC-Element "Creator" sollen Daten über einen Autor/eine Autorin in dem Format "Nachname, Vorname(n)" geliefert werden. Die Ausgabe dieser Daten in OJS wurde entsprechend angepasst. Zusätzlich zu diesen Daten wird in OJS auch die Affiliation geliefert, auch wenn das den DRIVER-Guidelines 2.0 nicht entspricht, da dies hilfreich sein kann, um z.B. Publikationen einer Institution zusammenzufassen bzw. zu unterscheiden.
 
Im DC-Element "Creator" sollen Daten über einen Autor/eine Autorin in dem Format "Nachname, Vorname(n)" geliefert werden. Die Ausgabe dieser Daten in OJS wurde entsprechend angepasst. Zusätzlich zu diesen Daten wird in OJS auch die Affiliation geliefert, auch wenn das den DRIVER-Guidelines 2.0 nicht entspricht, da dies hilfreich sein kann, um z.B. Publikationen einer Institution zusammenzufassen bzw. zu unterscheiden.
  
''Subject''
+
=====Subject=====
  
 
Ein grober Vergleich der in den DRIVER-Guidelines 2.0 erwähnten Subject Classifications wurde vorgenommen. Am häufigsten verwendet und in den DRIVER-Guidelines vorgeschlagen wird die DDC-Klassifikation. Die ersten 1.000 Klassen können unter definierten Bedingungen heruntergeladen bzw. verwendet werden (s. http://www.oclc.org/research/activities/browser/terms.htm und http://www.oclc.org/research/activities/researchworks/terms.htm). Im Projekt ist noch zu klären, ob die Verwendung der ersten 1.000 Klassen der DCC-Klassifikation für Zeitschriftenartikel sinnvoll ist bzw. ob sie granular genug sind. Weiter ist zu klären, wie eine Integration mit OJS in Hinblick auf die Lizenz aussehen und technisch realisiert werden könnte, um z.B. Autor/innen und Redakteur/innen eine Auswahlliste für die Artikelklassifikation anbieten zu können.
 
Ein grober Vergleich der in den DRIVER-Guidelines 2.0 erwähnten Subject Classifications wurde vorgenommen. Am häufigsten verwendet und in den DRIVER-Guidelines vorgeschlagen wird die DDC-Klassifikation. Die ersten 1.000 Klassen können unter definierten Bedingungen heruntergeladen bzw. verwendet werden (s. http://www.oclc.org/research/activities/browser/terms.htm und http://www.oclc.org/research/activities/researchworks/terms.htm). Im Projekt ist noch zu klären, ob die Verwendung der ersten 1.000 Klassen der DCC-Klassifikation für Zeitschriftenartikel sinnvoll ist bzw. ob sie granular genug sind. Weiter ist zu klären, wie eine Integration mit OJS in Hinblick auf die Lizenz aussehen und technisch realisiert werden könnte, um z.B. Autor/innen und Redakteur/innen eine Auswahlliste für die Artikelklassifikation anbieten zu können.
  
''Contributor''
+
=====Contributor=====
  
 
Gemäß den DRIVER-Guidelines 2.0 sollen in diesem Element die inhaltlich beitragenden Personen, Institutionen oder Dienste geliefert werden (nicht zu verwechseln mit "Creator"=Autor/in oder "Publisher"). Dabei soll ein Element pro Institution usw. verwendet werden. OJS sieht nur ein Feld sowohl für inhaltliche als auch andere (z.B. finanziell) Beitragende vor. Eine Trennung würde den Rahmen dieses Pakets sprengen und wird deswegen hier nicht berücksichtigt. Deshalb werden auch die nicht inhaltlich Beitragenden (z.B. Sponsoren) über dieses Element geliefert, was den Leitlinien nicht entspricht. Bis jetzt wurden die Betragenden in OJS in einem einzigen Element mit Semikolon getrennt geliefert. Dies wurde so angepasst, dass nun ein Element pro beitragender Institution usw. verwendet wird.
 
Gemäß den DRIVER-Guidelines 2.0 sollen in diesem Element die inhaltlich beitragenden Personen, Institutionen oder Dienste geliefert werden (nicht zu verwechseln mit "Creator"=Autor/in oder "Publisher"). Dabei soll ein Element pro Institution usw. verwendet werden. OJS sieht nur ein Feld sowohl für inhaltliche als auch andere (z.B. finanziell) Beitragende vor. Eine Trennung würde den Rahmen dieses Pakets sprengen und wird deswegen hier nicht berücksichtigt. Deshalb werden auch die nicht inhaltlich Beitragenden (z.B. Sponsoren) über dieses Element geliefert, was den Leitlinien nicht entspricht. Bis jetzt wurden die Betragenden in OJS in einem einzigen Element mit Semikolon getrennt geliefert. Dies wurde so angepasst, dass nun ein Element pro beitragender Institution usw. verwendet wird.
  
''Type''
+
=====Type=====
  
 
In diesem Element soll der "Typ" einer Publikation beschrieben werden, z.B. deren Gattung oder Art der Verbreitung. Leser/innen können so unmittelbar sehen, ob es sich z.B. um ein Buch oder einen Artikel handelt, ob die Publikation nur intern oder auch extern verwendet werden kann usw. Es existieren verschiedene Vokabulare für Publikationstypen (z.B. DCMI , Eprints , DINI); diese können jedoch auch frei vergeben werden. Als Publikationstyp soll laut den DRIVER-Guidelines 2.0 zuerst der entsprechende Typ aus dem kontrollierten DRIVER-Vokabular für Publikationstypen geliefert werden. Danach sollen, falls vorhanden, die im System frei vergebenen Typen geliefert werden. Abschließend und optional sollte dann der Versionstyp aus dem kontrollierten DRIVER-Vokabular für Versionen geliefert werden.  
 
In diesem Element soll der "Typ" einer Publikation beschrieben werden, z.B. deren Gattung oder Art der Verbreitung. Leser/innen können so unmittelbar sehen, ob es sich z.B. um ein Buch oder einen Artikel handelt, ob die Publikation nur intern oder auch extern verwendet werden kann usw. Es existieren verschiedene Vokabulare für Publikationstypen (z.B. DCMI , Eprints , DINI); diese können jedoch auch frei vergeben werden. Als Publikationstyp soll laut den DRIVER-Guidelines 2.0 zuerst der entsprechende Typ aus dem kontrollierten DRIVER-Vokabular für Publikationstypen geliefert werden. Danach sollen, falls vorhanden, die im System frei vergebenen Typen geliefert werden. Abschließend und optional sollte dann der Versionstyp aus dem kontrollierten DRIVER-Vokabular für Versionen geliefert werden.  
Line 44: Line 44:
 
Publikationen in OJS sind Zeitschriftenartikel, d.h. vom Typ "info:eu-repo/semantics/article" im Sinne des DRIVER-Vokabulars. Deshalb wird für alle Artikel an erster Stelle dieser Typ geliefert. Dem folgen die wie bis jetzt in OJS von Autor/innen und Redakteur/innen frei vergebenen Typen (z.B. "redaktionell begutachteter Artikel", "Rezension" u.Ä.). Da in OJS nur die veröffentlichten Artikel über die OAI-Schnittstelle geliefert werden, wird abschließend der entsprechende Versionstyp "info:eu-repo/semantics/publishedVersion" geliefert.
 
Publikationen in OJS sind Zeitschriftenartikel, d.h. vom Typ "info:eu-repo/semantics/article" im Sinne des DRIVER-Vokabulars. Deshalb wird für alle Artikel an erster Stelle dieser Typ geliefert. Dem folgen die wie bis jetzt in OJS von Autor/innen und Redakteur/innen frei vergebenen Typen (z.B. "redaktionell begutachteter Artikel", "Rezension" u.Ä.). Da in OJS nur die veröffentlichten Artikel über die OAI-Schnittstelle geliefert werden, wird abschließend der entsprechende Versionstyp "info:eu-repo/semantics/publishedVersion" geliefert.
  
''Identifier''
+
=====Identifier=====
  
 
Gemäß den Guidelines ist eine eindeutige Referenz zur Publikation (z.B. URL, URN) zu liefern. Bei Vorhandensein mehrerer Referenzen sollte die wichtigste an der ersten Stelle sein, d.h. es ist im Kontext von Service-Providern eine Referenz zum Volltext erwünscht. Da es in OJS jedoch oft mehrere Volltexte (z.B. in verschiedenen Sprachen und Formaten) gibt, wird hier wie bisher an der ersten Stelle der Link (URL) zur Front-Page/Abstract-Ansicht geliefert. Die Front-Page/Abstract-Ansicht in OJS wurde jedoch um die Links zu allen Volltexten erweitert, sodass Leser/innen von dort leicht zum Volltext gelangen können.
 
Gemäß den Guidelines ist eine eindeutige Referenz zur Publikation (z.B. URL, URN) zu liefern. Bei Vorhandensein mehrerer Referenzen sollte die wichtigste an der ersten Stelle sein, d.h. es ist im Kontext von Service-Providern eine Referenz zum Volltext erwünscht. Da es in OJS jedoch oft mehrere Volltexte (z.B. in verschiedenen Sprachen und Formaten) gibt, wird hier wie bisher an der ersten Stelle der Link (URL) zur Front-Page/Abstract-Ansicht geliefert. Die Front-Page/Abstract-Ansicht in OJS wurde jedoch um die Links zu allen Volltexten erweitert, sodass Leser/innen von dort leicht zum Volltext gelangen können.
  
''Language''
+
=====Language=====
  
 
Bisher lieferte OJS in diesem Element alle Sprachen durch Semikolon getrennt und im Format ISO 639-1. Gemäß den DRIVER-Leitlinien werden die Sprachen der Volltexte jetzt in diesem Element im Format ISO 639-3 ausgegeben, und für jede Sprache wird ein Element verwendet.
 
Bisher lieferte OJS in diesem Element alle Sprachen durch Semikolon getrennt und im Format ISO 639-1. Gemäß den DRIVER-Leitlinien werden die Sprachen der Volltexte jetzt in diesem Element im Format ISO 639-3 ausgegeben, und für jede Sprache wird ein Element verwendet.
  
''Relation''
+
=====Relation=====
  
 
Zusätzlich zu den bisher gelieferten Links (URLs) zu Zusatzdateien werden jetzt auch die Links (URLs) zu Volltexten in diesem Element ausgegeben. Für jede URL wird ein Element verwendet.
 
Zusätzlich zu den bisher gelieferten Links (URLs) zu Zusatzdateien werden jetzt auch die Links (URLs) zu Volltexten in diesem Element ausgegeben. Für jede URL wird ein Element verwendet.
  
''Leere Elemente''
+
=====Leere Elemente=====
  
 
Leere Elemente (z.B. beim Fehlen der Stichwörter) werden jetzt, den DRIVER-Guidelines folgend, nicht mehr ausgegeben.
 
Leere Elemente (z.B. beim Fehlen der Stichwörter) werden jetzt, den DRIVER-Guidelines folgend, nicht mehr ausgegeben.

Latest revision as of 02:32, 24 July 2013

Anpassungen der OJS-OAI-Schnittstelle an DRIVER-Guidelines 2.0

Die Open Archives Initiative (OAI) entwickelte das Protocol for Metadata Harvesting (OAI-PMH), ein anwendungsunabhängiges Interoperabilitäts-Framework, das die Kommunikation zwischen Data- und Service-Anbietern ermöglicht und auf Metadaten-Harvesting basiert. Als Standard für die Metadaten wird meist Dublin Core (DC) verwendet. Da diese Standards aber auch Raum für die lokale Interpretation und Implementierung lassen, werden sie unterschiedlich verwendet, wodurch die Interoperabilität erschwert ist. Im Rahmen des Projekts DRIVER wurden deshalb Leitfäden für die Verwendung von Standards entwickelt, um die Interoperabilität von Data- und Service-Anbietern zu erleichtern.

Im Rahmen des Projekts „Funktionaler Ausbau von und Mehrwertdienste für ‚Open Journal Systems‘ (OJS)“ [1] wurden folgende Anpassungsnotwendigkeiten gemäß den DRIVER Guidelines 2.0 identifiziert und die OJS-OAI-Schnittstelle wurde entsprechend verändert:

Verwendung des Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)

Resumption Token Lifespan

Die Resultate einer OAI-PMH-Anfrage können manchmal sehr lang sein, sodass es von Vorteil wäre, diese in mehrere kleinere Anfragen und Resultate zu verteilen und eine Zeit lang aufzubewahren. Resumption Tokens stellen einen Mechanismus dar, der das ermöglicht. Laut DRIVER-Guidelines 2.0 ist die angemessene Lebensdauer eines Resumption Tokens 24 Stunden, damit Harvester genügend Zeit haben und im Fall eines Fehlers in der Lage sind, von da weiter zu harvesten, wo sie zuletzt waren, anstatt von vorne anzufangen. Die Lebensdauer der Resumption Tokens in OJS wurde dementsprechend angepasst.

Deleted Records Strategy

Damit Harvester die gelöschten Datensätze leichter entdecken können und Service-Provider nicht gelöschte Datensätze anzeigen, die es eigentlich nicht mehr gibt, empfehlen die DRIVER-Guidelines 2.0, Informationen über die gelöschten Datensätze mindestens einen Monat lang zu bewahren/zu verwalten. Bisher hatte OJS keine Informationen über die gelöschten Artikel bzw. Datensätze; nun wurde OJS so erweitert, dass die benötigten Informationen über die gelöschten Datensätze permanent aufbewahrt und über die OAI-Schnittstelle entsprechend berücksichtigt werden.

Description Container

Um Harvestern Informationen über das System sowie die Möglichkeit zu geben, die Änderungen an den gelieferten Metadaten nachzuvollziehen und mit einer bestimmten Systemversion zu verknüpfen, sollten über die OAI-Schnittstelle die entsprechenden Systeminformationen (z.B. Titel und Version) geliefert werden. Diese Informationen waren bisher für OJS nicht verfügbar und wurden nun so in OJS umgesetzt, dass sie als ein Description Container geliefert werden. Dazu wird folgendes Schema verwendet: http://oai.dlib.vt.edu/OAI/metadata/toolkit.xsd.

DRIVER-Set

Repositorien können ihre Publikationen mithilfe sogenannter Sets organisieren. Im Projekt DRIVER wurden eine Infrastruktur zur Vernetzung verteilter Repositorien von Universitäten und Forschungseinrichtungen in Europa sowie darauf basierende Dienstleistungen für verschiedene Nutzungsgruppen entwickelt. Eine Voraussetzung für die Teilnahme ist das Vorhandensein des DRIVER-OAI-Sets, das nur Open-Access-Publikationen beinhalten darf. Um auch Zeitschriften zu ermöglichen, ein Teil dieser Infrastruktur zu werden, wurde ein Plug-In entwickelt, das das DRIVER-Set in OJS berücksichtigt und alle Open-Access-Publikationen einer Zeitschrift bündelt.

Verwendung des Dublin-Core-Formats

Creator

Im DC-Element "Creator" sollen Daten über einen Autor/eine Autorin in dem Format "Nachname, Vorname(n)" geliefert werden. Die Ausgabe dieser Daten in OJS wurde entsprechend angepasst. Zusätzlich zu diesen Daten wird in OJS auch die Affiliation geliefert, auch wenn das den DRIVER-Guidelines 2.0 nicht entspricht, da dies hilfreich sein kann, um z.B. Publikationen einer Institution zusammenzufassen bzw. zu unterscheiden.

Subject

Ein grober Vergleich der in den DRIVER-Guidelines 2.0 erwähnten Subject Classifications wurde vorgenommen. Am häufigsten verwendet und in den DRIVER-Guidelines vorgeschlagen wird die DDC-Klassifikation. Die ersten 1.000 Klassen können unter definierten Bedingungen heruntergeladen bzw. verwendet werden (s. http://www.oclc.org/research/activities/browser/terms.htm und http://www.oclc.org/research/activities/researchworks/terms.htm). Im Projekt ist noch zu klären, ob die Verwendung der ersten 1.000 Klassen der DCC-Klassifikation für Zeitschriftenartikel sinnvoll ist bzw. ob sie granular genug sind. Weiter ist zu klären, wie eine Integration mit OJS in Hinblick auf die Lizenz aussehen und technisch realisiert werden könnte, um z.B. Autor/innen und Redakteur/innen eine Auswahlliste für die Artikelklassifikation anbieten zu können.

Contributor

Gemäß den DRIVER-Guidelines 2.0 sollen in diesem Element die inhaltlich beitragenden Personen, Institutionen oder Dienste geliefert werden (nicht zu verwechseln mit "Creator"=Autor/in oder "Publisher"). Dabei soll ein Element pro Institution usw. verwendet werden. OJS sieht nur ein Feld sowohl für inhaltliche als auch andere (z.B. finanziell) Beitragende vor. Eine Trennung würde den Rahmen dieses Pakets sprengen und wird deswegen hier nicht berücksichtigt. Deshalb werden auch die nicht inhaltlich Beitragenden (z.B. Sponsoren) über dieses Element geliefert, was den Leitlinien nicht entspricht. Bis jetzt wurden die Betragenden in OJS in einem einzigen Element mit Semikolon getrennt geliefert. Dies wurde so angepasst, dass nun ein Element pro beitragender Institution usw. verwendet wird.

Type

In diesem Element soll der "Typ" einer Publikation beschrieben werden, z.B. deren Gattung oder Art der Verbreitung. Leser/innen können so unmittelbar sehen, ob es sich z.B. um ein Buch oder einen Artikel handelt, ob die Publikation nur intern oder auch extern verwendet werden kann usw. Es existieren verschiedene Vokabulare für Publikationstypen (z.B. DCMI , Eprints , DINI); diese können jedoch auch frei vergeben werden. Als Publikationstyp soll laut den DRIVER-Guidelines 2.0 zuerst der entsprechende Typ aus dem kontrollierten DRIVER-Vokabular für Publikationstypen geliefert werden. Danach sollen, falls vorhanden, die im System frei vergebenen Typen geliefert werden. Abschließend und optional sollte dann der Versionstyp aus dem kontrollierten DRIVER-Vokabular für Versionen geliefert werden.

Publikationen in OJS sind Zeitschriftenartikel, d.h. vom Typ "info:eu-repo/semantics/article" im Sinne des DRIVER-Vokabulars. Deshalb wird für alle Artikel an erster Stelle dieser Typ geliefert. Dem folgen die wie bis jetzt in OJS von Autor/innen und Redakteur/innen frei vergebenen Typen (z.B. "redaktionell begutachteter Artikel", "Rezension" u.Ä.). Da in OJS nur die veröffentlichten Artikel über die OAI-Schnittstelle geliefert werden, wird abschließend der entsprechende Versionstyp "info:eu-repo/semantics/publishedVersion" geliefert.

Identifier

Gemäß den Guidelines ist eine eindeutige Referenz zur Publikation (z.B. URL, URN) zu liefern. Bei Vorhandensein mehrerer Referenzen sollte die wichtigste an der ersten Stelle sein, d.h. es ist im Kontext von Service-Providern eine Referenz zum Volltext erwünscht. Da es in OJS jedoch oft mehrere Volltexte (z.B. in verschiedenen Sprachen und Formaten) gibt, wird hier wie bisher an der ersten Stelle der Link (URL) zur Front-Page/Abstract-Ansicht geliefert. Die Front-Page/Abstract-Ansicht in OJS wurde jedoch um die Links zu allen Volltexten erweitert, sodass Leser/innen von dort leicht zum Volltext gelangen können.

Language

Bisher lieferte OJS in diesem Element alle Sprachen durch Semikolon getrennt und im Format ISO 639-1. Gemäß den DRIVER-Leitlinien werden die Sprachen der Volltexte jetzt in diesem Element im Format ISO 639-3 ausgegeben, und für jede Sprache wird ein Element verwendet.

Relation

Zusätzlich zu den bisher gelieferten Links (URLs) zu Zusatzdateien werden jetzt auch die Links (URLs) zu Volltexten in diesem Element ausgegeben. Für jede URL wird ein Element verwendet.

Leere Elemente

Leere Elemente (z.B. beim Fehlen der Stichwörter) werden jetzt, den DRIVER-Guidelines folgend, nicht mehr ausgegeben.

Verwendung des MPEG-21 DIDL-Formats

Zusätzlich zu DC empfehlen die DRIVER-Guidelines 2.0 die Verwendung des MPEG-21 DIDL-Formats. Dieses ermöglicht die Beschreibung komplexer Objekte (die z.B. aus mehreren Teilen bestehen) und eine eindeutige Adressierung von deren Einzelteilen (Metadaten, Dateien, Start-/Front-Page). Eine Anpassung an das MPEG-21 DIDL-Format ist im vorgesehenen Zeitrahmen und mit den verfügbaren Mitteln für die Anpassung von OJS an die DRIVER-Guidelines leider nicht möglich. Da Compound Objects bzw. Linked Data aber immer mehr an Bedeutung gewinnen, obwohl sie in der Praxis noch wenig Anwendung gefunden haben, werden wir die Entwicklungen weiter verfolgen und zu einem späteren Zeitpunkt aufzugreifen versuchen.