Im Zuge der Modernisierung der technischen Infrastruktur des URN-Service wurde der ursprüngliche Harvester nun endgültig abgelöst. Wie schon vor längerem angekündigt, arbeitet der neue Harvester weniger fehlertolerant, weshalb nur noch valides xepicur-XML verarbeiten werden kann.

Beim Import der geharvesteten xepicur-Datensätze haben wir die Verwendung des sehr komplexen Transferformats etwas vereinfacht und so wieder näher an die ursprüngliche OAI-Funktionalität gebracht. Insbesondere wird die Weiterverarbeitung der xepicur-records NICHT mehr durch sogenannte „Update-Status“ gesteuert. Wie auch sonst beim Einsatz von OAI-PMH, wird die URN-Datenbank entsprechend der auf Ihrem Repository vorhandenen URN und URL-Kombinationen aktualisiert. Dazu muss Ihre Schnittstelle jeweils alle aktuell gültigen URLs liefern. Alle nicht mehr gelieferten URLs werden aus der URN-Datenbank gelöscht.

Wenn die Update-Status wie zuvor verwendet werden, kann es deshalb zu Fehlern kommen. So würde beispielsweise bei „url-delete“ gerade die URL in die Datenbank eingetragen, die eigentlich gelöscht werden sollte, alle anderen vorhandenen URLs aber würden gelöscht. Ähnlich würde bei Verwendung von „url_insert“ anschließend nur noch die aktuell gelieferte URL noch in der Datenbank stehen. Kein Konflikt zur neuen Funktionalität entsteht, wenn ausschließlich „urn_new“ und „url_update_general“ verwendet werden.

Die Update-Status werden also zwar nicht mehr ausgewertet, es muss aber dennoch ein Update-Status angegeben werden, da sonst das xepicur-Format nicht valide ist und beim Harvesten nicht akzeptiert würde. Bei größeren Serverwechseln und Systemwechseln wird die URN-Aktualisierung mit dem neuen Harvester deutlich vereinfacht. Zusätzlichen Komfort für Sie erhoffen wir uns davon, dass nun auch eine Set-Einschränkung möglich ist.

Die ursprüngliche xepicur Dokumentation wird ergänzt mit den Hinweisen, welche Elemente aktuell und in Zukunft tatsächlich ausgewertet werden.

Zu beachten ist insbesondere: Bitte liefern Sie alle aktuell gültigen URLs mit Ihrer URN. Alle nicht mehr mitgelieferten URLs werden in der URN-Datenbank gelöscht.

Generelle Hinweise

Gültigkeit:

Für Datensätze zur Administration von URNs wird xepicur zukünftig nur noch für die Übertragungsart OAI-PMH verbindlich sein.

Hinweise zu Datenstruktur und Syntax

Für den Datensatz ist als Dokumentformat XML verbindlich.

• Elementtypen
  • Der Metadatensatz enthält Datenelemente, die nach Elementtypen differenziert in strukturierter Form angegeben sind. Jedes Datenelement wird durch einen Elementbezeichner (tag) eingeleitet, der den Elementnamen angibt.

  • Beispiel: <identifier>

• Attribute
  • Elementbezeichner werden durch Attribute spezifiziert. Es gibt sowohl obligatorische Attribute ("type", "scheme", "imt") als auch optionale Attribute ("role", "status" oder "type").
  • Beispiel: <identifier scheme="url" role="primary">

Beschreibung des Datenformates, Reihenfolge und Struktur der Elemente

Generelle Struktur

Ein XML-Datensatz besteht aus einem Wurzelelement

<epicur>

und zwei hierarchisch untergeordneten Elementen

<administrative_data>
<record>

Wurzelelement "epicur"

<epicur> 

  <administrative_data>
  [...] 
  </administrative_data> 

  <record> 
  [...]
  </record>

</epicur>

Elementgruppe "administrative_data"

Element "administrative_data"

<administrativ_data>

 <delivery>

  [...]

 </delivery>

</administrative_data>

Element "authorization" 

<administrative_data>
 <delivery>
  <authorization>
   <person_id>F6000123</person_id>
   <urn_snid>urn:nbn:de:089</urn_snid>
  </authorization>
 </delivery>
</administrative_data>

Element "update_status"

<update_status type="urn_new"/>

Element "transfer"

Element "resupply"

Beispiel "administrative_data"

<epicur>

<administrative_data>

<delivery>

<update_status type="urn_new"/>

</delivery>

</administrative_data>

[...]

</epicur>

Elementgruppe "record"

Element "record"

<record>

  [...]

</record>

Element "identifier"

<identifier scheme="urn:nbn:de"> 

   [...] 

 </identifier>

 <identifier scheme="url"> 

   [...] 

 </identifier>

 <identifier scheme="url" role="primary"> 

   [...] 

 </identifier>

Element "isVersionOf"

Element "hasVersion"

Element "resource"

<resource>

  <identifier scheme="url">

   [URL des Objektes]

  </identifier>

  <format scheme="imt">

   [MimeType des Objektes]  
  </format>

</resource>

Element "format"

<format scheme="imt">
  [MimeType des Objektes]
</format>

Element "isPartOf"

<isPartOf>
  [...]
</isPartOf>

Beispiel "record"

<epicur>

<administrative_data>

[...]

<update_status type="urn_new"/>

[...] 

</administrative_data>

<record>

<identifier scheme="urn:nbn:de">
  urn:nbn:de:gbv:089-3321752945
</identifier>

<resource>

<identifier scheme="url" role="primary" >http://edok01.tib.uni-hannover.de/edoks/e01dh01/</identifier>

<format scheme="imt">text/html</format>

</resource>

</record>

</epicur>

Priorität

Das bisherige Primary-Modell wird durch die Priorität abgelöst.

Dabei gilt folgende Logik:

1. Höchste Priorität haben immer die URLs der Organisation, der auch Inhaber des entsprechenden Unternamensraum ist.
2. Diesen nachgeordnet sind URLs, die von Organisationen, denen die entsprechende URN NICHT gehört hinzugefügt wurden. (sogenannte Kuckucks-URLs)
3. Über die geringste Priorität verfügen die URLs, die also sogenannte Archiv-URL von der DNB bei der Ablieferung der Netzpublikation, automatisiert hinzugefügt werden.

Darum haben nur die Organisation, die für den jeweiligen Namensraum verantwortlich sind, die Möglichkeit, eine URL mit der Priority 1, also der höchsten Priorität, auszuzeichnen. (Bei allen weiteren URLs wird die Priorität intern hochgezählt.) 

NUR als für den Namensraum verantwortliche Organisation wird, wenn Sie in xepicur die role primary liefern, diese als Priorität 1 umgesetzt.

<identifier scheme="url" role="primary">