EndNote2MARC

[Daniel Zimmel]

Hallo,

hat jemand schon mal EndNote-Files (oder auch BibTeX) nach MAB oder MARC
gewandelt? Also den umgekehrten Weg, den man normalerweise geht.

Mir ist schon klar, dass es vielleicht ungewöhnlich klingt, und auch, dass
es knallen wird. Wir brauchen aber auch kein bibliothekarisches Gütesiegel
drauf.
Anlass ist, dass wir gerne bibliographische Sammlungen durchsuchbar machen
würden parallel zu unserem Bestand (inkl. SFX). Wenn alles MARC ist, können
wir dafür einfach unser vorhandenes Setup nutzen.

Mit Catmandu komme ich nicht so recht weiter, BibTeX gibts da bisher nur als
Exporter.
Wär halt schön, wenn man bereits was nutzen könnte, aber vermutlich müssen
wir uns da selbst was zurechtfummeln?

Beste Grüße,

Daniel

--
Daniel Zimmel Tel. +49 228 91416-17

Max-Planck-Institut zur
Erforschung von Gemeinschaftsgütern, Bonn ||/| Bibliothek

[Wagner, Alexander]

Hallo!

Bibutils enthält mindestens einen Konverter in ein wahrscheinlich brauchbares xml-Zwischenformat bin mir nicht sicher ob nicht sogar mods. Damit käme man von sowohl EndNote als auch  BibTeX u.U. den halben Weg.

Für einfache Suchbarkeit dürfte es gar nicht soooo schlimm werden. Einspielen in den Katalog wäre wohl eine andere Nummer. Kommt auch ein bisschen drauf an was das für Daten sind. U.U. kann man gegen andere Quellen laufen und ein paar Scharten auswetzen.

--
Kind regards,


Alexander Wagner

Subject Specialist
Central Library
52425 Juelich

mail : a.wa...@fz-juelich.de
phone: +49 2461 61-1586
Fax  : +49 2461 61-6103
www.fz-juelich.de/zb/DE/zb-fi

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

[flimm]

Hallo,

Am Montag, 1. Juli 2013 16:38:02 UTC+2 schrieb dzimmel:

hat jemand schon mal EndNote-Files (oder auch BibTeX) nach MAB oder MARC
gewandelt? Also den umgekehrten Weg, den man normalerweise geht.

wir haben das im Rahmen des KUG noch nicht gemacht, aber mit Perl und dem MARC::Record-Modul sollte das sehr einfach sein, zumal VuFind - wie Du schon selbst sagtest - out-of-the-box MARC-Records verarbeiten kann. Das alte Perl MAB2-Modul waere dafuer ohnehin nicht so gut geeignet und MAB2 ist de-facto sowiso tot.

Als unbedenkliches Ausgangsformat auf EndNote-Seite kenne ich allerdings nur das alte refer-Format bzw. RIS, da Thomson Reuters - gemessen an Ihrer dann aber abgewiesenen Klage gegen Zotero - es anscheinend nicht so gerne sieht, wenn man ihr moderneres XML-EndNote-Format verwendet. Es ist kein Zufall, dass ziemlich viele Rechercheportale fuer einen "EndNote"-Export lediglich das refer-Format bzw. RIS anbieten. Darueber hinaus ist refer/RIS sehr einfach und uebersichtlich. Selbstverstaendlich kann man ohne Probleme das XML-Format durch draufschauen 'reverse-engineeren', aber warum sollte man sich mit so einen Produkt auseinandersetzen, Arbeit und Personalkosten hineinstecken, wenn man danach eins auf die Finger bekommt.

Aus diesem Grund unterstuetzen wir EndNote im KUG und USB Portal nur auf homoeopathischem refer/RIS-Niveau.

Etwas schwieriger als die Konvertierung der Kategorien sehe ich die Praegung eines persistenten Identifiers fuer einen Datensatz. Wollt Ihr da ueber den Bibkey wie BibSonomy gehen?

Gruss

O. Flimm

[Daniel Zimmel]

Danke fürs Feedback!

> wir haben das im Rahmen des KUG noch nicht gemacht, aber mit Perl und dem
MARC::Record-Modul sollte das sehr einfach sein, zumal VuFind - wie Du schon
selbst sagtest -
> out-of-the-box MARC-Records verarbeiten kann. Das alte Perl MAB2-Modul
waere dafuer ohnehin nicht so gut geeignet und MAB2 ist de-facto sowiso tot.

das wäre eine schöne Erweiterung für Catmandu.
Wir haben hier halt nur begrenzte Perl-Expertise.
Wir nutzen die proprietären Aleph-Routinen, PHP (ja, ich weiß, schlimm ;-),
bissel XSLT und wenns ganz schlimm kommt awk.

> Aus diesem Grund unterstuetzen wir EndNote im KUG und USB Portal nur
> auf homoeopathischem refer/RIS-Niveau.

Es gibt auch noch "Endnote Tagged" - wird z.B. in VuFind per default
ausgegeben.

> Etwas schwieriger als die Konvertierung der Kategorien sehe ich die
> Praegung eines persistenten Identifiers fuer einen Datensatz. Wollt Ihr da
> ueber den Bibkey wie BibSonomy gehen?

vielleicht einfach ein eindeutiges Präfix plus fortlaufende Zählung.

Da es scheinbar keine fertigen Sachen gibt (ist ja auch ein bescheuerter
Weg), ist allerdings die Frage, ob wir nicht doch besser den Schuh andersrum
aufziehen sollten (also statt Konvertierung nach MARC Portieren der
vorhandenen Logik für MARC-Daten). Auf Dauer hat man sicher mehr davon. Und
genau, es soll in erster Linie in die Suchmaschine (VuFind), Katalog bleibt
dem tatsächlichen Bestand vorbehalten.

Beste Grüße,

Daniel

[Alexander Wagner]

On 02.07.2013 10:39, Daniel Zimmel wrote:

Moin!

>> wir haben das im Rahmen des KUG noch nicht gemacht, aber mit Perl und dem
> MARC::Record-Modul sollte das sehr einfach sein, zumal VuFind - wie Du schon
> selbst sagtest -
>> out-of-the-box MARC-Records verarbeiten kann. Das alte Perl MAB2-Modul
> waere dafuer ohnehin nicht so gut geeignet und MAB2 ist de-facto sowiso tot.
>
> das wäre eine schöne Erweiterung für Catmandu.
> Wir haben hier halt nur begrenzte Perl-Expertise.

Das MARC-Modul braucht da nicht so wahnsinnig viel, das geht alles recht
zivil und flach.

> Wir nutzen die proprietären Aleph-Routinen, PHP (ja, ich weiß, schlimm ;-),
> bissel XSLT und wenns ganz schlimm kommt awk.

Wenn man XSLT vorzieht würde ich definitiv mal in die bibutils schauen.

http://sourceforge.net/p/bibutils/home/Bibutils/

Konvertiert wie gesagt BibTeX/Endnote/RIS-Formate in ein einges XML oder
eben halt in der Tat nach MODS, wenn einem das lieber ist. Ggf. kann man
bei MODS mit dem LoC-Zeigl aufsetzen.

>> Etwas schwieriger als die Konvertierung der Kategorien sehe ich die
>> Praegung eines persistenten Identifiers fuer einen Datensatz. Wollt Ihr da
>> ueber den Bibkey wie BibSonomy gehen?
>
> vielleicht einfach ein eindeutiges Präfix plus fortlaufende Zählung.
>
> Da es scheinbar keine fertigen Sachen gibt (ist ja auch ein bescheuerter
> Weg),

So bescheuert ist der gar nicht.

Im Prinzip wollen wir sowas mittelfristig auch in unserem Repo als
Ingester haben. Nur ist da das Problem garnicht das BibTeX->Marc sondern
das "und wie ergänzt man alle fehlenden Daten sauber". In unserem
Kontext enthält BibTeX/Endnote einfach viel zu wenig.

> ist allerdings die Frage, ob wir nicht doch besser den Schuh andersrum
> aufziehen sollten (also statt Konvertierung nach MARC Portieren der
> vorhandenen Logik für MARC-Daten). Auf Dauer hat man sicher mehr davon.

Bin ich mir nicht so ganz sicher. BibTeX ist ja noch vergleichsweise gut
definiert. Endnote/RIS und was da so herumfliegt, also wenn jemand da
eine Spezifikation hat in der wirklich mal steht wie dieses Zeug
aussehen /muss/... Daher ist IMHO Marc garnicht sooo dumm als Überformat
in das alles reinpaßt. (Mit MODS z.B. machen wir da ein paar Stiche
nicht...)

--

Kind regards,

Alexander Wagner
Subject Specialist
Central Library
52425 Juelich

mail : a.wa...@fz-juelich.de
phone: +49 2461 61-1586
Fax : +49 2461 61-6103
www.fz-juelich.de/zb/DE/zb-fi

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00 bis 17:00 Uhr: http://www.tagderneugier.de

[Daniel Zimmel]

> Wenn man XSLT vorzieht würde ich definitiv mal in die bibutils schauen.
>
> http://sourceforge.net/p/bibutils/home/Bibutils/
>
> Konvertiert wie gesagt BibTeX/Endnote/RIS-Formate in ein einges XML oder
> eben halt in der Tat nach MODS, wenn einem das lieber ist. Ggf. kann man
> bei MODS mit dem LoC-Zeigl aufsetzen.

hab das mal ausprobiert, gefällt mir ganz gut:
BibTeX->MODS->XSLT->Solr-Schema.
Ein erster Test sieht gut aus, wird alles genehm indexiert.

Dazu habe ich hier ein zwar altes XSL gefunden, das aber schon
out-of-the-box gut funktioniert:
http://sourceforge.net/p/dlf-aquifer/code/675/tree/ruby/trunk/aquifer/xsl/mo
ds-solr.xsl

Wir brauchen schnelle Ergebnisse, kein sauberes neues Datenmodell. Da kanns
auch ruhig etwas schlampig sein.
Das XSLT können wir auf unser Schema schnell anpassen.

> Im Prinzip wollen wir sowas mittelfristig auch in unserem Repo als
Ingester
> haben. Nur ist da das Problem garnicht das BibTeX->Marc sondern das "und
> wie ergänzt man alle fehlenden Daten sauber". In unserem Kontext enthält
> BibTeX/Endnote einfach viel zu wenig.

wir wollen erstmal nichts ergänzen, daher erscheint eine Konvertierung nach
MARC mir wirklich nicht so zielführend, denn die ganze Komplexität
interessiert uns erstmal nicht so (naja, für SFX wäre Komplexität dann
wieder schon gut...)
Aber es wäre hilfreich, evtl. dazu mehr Code auszutauschen.

Gruß

DZ

[Alexander Wagner]

On 03.07.2013 11:41, Daniel Zimmel wrote:

Moin!

>> Wenn man XSLT vorzieht würde ich definitiv mal in die bibutils schauen.
>>
>> http://sourceforge.net/p/bibutils/home/Bibutils/
>>
>> Konvertiert wie gesagt BibTeX/Endnote/RIS-Formate in ein einges XML oder
>> eben halt in der Tat nach MODS, wenn einem das lieber ist. Ggf. kann man
>> bei MODS mit dem LoC-Zeigl aufsetzen.
>
> hab das mal ausprobiert, gefällt mir ganz gut:
> BibTeX->MODS->XSLT->Solr-Schema.
> Ein erster Test sieht gut aus, wird alles genehm indexiert.

[...]

> Wir brauchen schnelle Ergebnisse, kein sauberes neues
> Datenmodell. Da kanns auch ruhig etwas schlampig sein.
> Das XSLT können wir auf unser Schema schnell anpassen.

Klingt jetzt für mich nach einer funktionierenden Lösung,
oder?

>> Im Prinzip wollen wir sowas mittelfristig auch in unserem
>> Repo als Ingester haben. Nur ist da das Problem garnicht
>> das BibTeX->Marc sondern das "und wie ergänzt man alle
>> fehlenden Daten sauber". In unserem Kontext enthält
>> BibTeX/Endnote einfach viel zu wenig.
>
> wir wollen erstmal nichts ergänzen, daher erscheint eine
> Konvertierung nach MARC mir wirklich nicht so zielführend,

Hast Du falsch verstanden. Meine Lösung für Dein Problem
(soweit ich's verstandne habe) wäre was Du oben auch
beschreiben hast. Wenn man nur nen Indexer füttern will ist
das wahrscheinlich leicht gut genug.

Der Bezug zu unserem Repo (also der Grund warum ich Dir
keinen fertigen Code geben kann) ist, dass wir wegen
/unserer/ komplexeren Daten tatsächlich für die GA von JuSER
keinen BibTeX/EndNote-Import gebaut haben. Hätten wir den,
dann hätte ich eine Routine die aus BibTeX/EndNote Marc21
macht, weil JuSER das als Internformat benutzt.

Diesen Import hatte ich mir angeschaut, komme bis zu Deiner
Lösung und sogar noch ein gutes Stück weiter, weil mir JuSER
etwas Infrastruktur gibt, aber wir brauchen ein paar Daten,
die der Nutzer definitiv interaktiv ergänzen muss => wenn
mir jemand 50 Datensätze als BibTeX gibt muss ich das in
einem Submissionworkflow passend abbilden, so dass er die
gefragt wird. Man muss überlegen wie man damit umgeht wenn
er da zwischendrinnen aufhört, wie das ggf. mit Dubletten
ist, was passiert wenn die BibTeX-Daten "zu schlecht sind"
(journal="Nucl.Phys." volume="B123", am ende brauche ich
aber "Nuclear physics <Amsterdam> / B" =
PERI:(DE-600)1466567-0 und Volume "123" ) usw.

Das war zeitlich nicht drinnen, daher hatten wir das
vorläufig gestrichen. Das hat bei uns einfach ein paar
eklige Haken und Ösen, die wir z.B. alle nicht haben wenn
wir z.B. eine DOI importieren.

> denn die ganze Komplexität interessiert uns erstmal nicht
> so (naja, für SFX wäre Komplexität dann wieder schon
> gut...)

SFX hat aber noch vergleichsweise billige Metadaten. Wenn
das bei Dir Aufsätze sind und Du eine DOI/pmid hast kannst
Du die einfach an SFX schicken und den ganzen OpenURL-Müll
weglassen. Das ist der Teil an OpenURL der gut funktioniert.
Hast Du keine Ids stellt sich wahrscheinlich schnell die
Frage ob Deine EndNote/BibTeX-Daten so "gut"
(SFX-kompatibel) sind, dass SFX überhaupt was damit anfangen
kann. Das Zeigl ist ja doch recht "gscheckert".

> Aber es wäre hilfreich, evtl. dazu mehr Code auszutauschen.

Bin ich offen für alles.

[Daniel Zimmel]

> > Wir brauchen schnelle Ergebnisse, kein sauberes neues Datenmodell. Da
> > kanns auch ruhig etwas schlampig sein.
> > Das XSLT können wir auf unser Schema schnell anpassen.
>
> Klingt jetzt für mich nach einer funktionierenden Lösung, oder?

in der Tat, passt schon erstmal.

> SFX hat aber noch vergleichsweise billige Metadaten. Wenn das bei Dir
> Aufsätze sind und Du eine DOI/pmid hast kannst Du die einfach an SFX
> schicken und den ganzen OpenURL-Müll weglassen. Das ist der Teil an
> OpenURL der gut funktioniert.
> Hast Du keine Ids stellt sich wahrscheinlich schnell die Frage ob Deine
> EndNote/BibTeX-Daten so "gut"
> (SFX-kompatibel) sind, dass SFX überhaupt was damit anfangen kann. Das
> Zeigl ist ja doch recht "gscheckert".

so siehts aus, die Daten sind nicht wirklich gut.
Müssen wir uns auch konzeptionell nochmal genauer überlegen, was wir
überhaupt guten Gewissens machen können.

So komplex wollen wirs wie gesagt nicht bzw. da fehlt uns auch die Zeit und
Expertise, aber was hergeben muss es halt schon.
Wir backen hier lokal als kleines Institut natürlich deutlich kleinere
Brötchen als an den UBs und in den Verbünden, aber die müssen ja auch
schmecken ;-)
Danke für die Hinweise!

Gruß Daniel

[Alexander Wagner]

On 03.07.2013 15:15, Daniel Zimmel wrote:

Hallo!

[...]

> So komplex wollen wirs wie gesagt nicht bzw. da fehlt uns auch die Zeit und
> Expertise, aber was hergeben muss es halt schon.
> Wir backen hier lokal als kleines Institut natürlich deutlich kleinere
> Brötchen als an den UBs und in den Verbünden, aber die müssen ja auch
> schmecken ;-)

Was hast du denn für Daten? U.U. mögen die unsere Migrationsroutinen,
und dann ginge das mit kleinen Brötchen auch gut.

[Daniel Zimmel]

> Was hast du denn für Daten? U.U. mögen die unsere Migrationsroutinen,
> und dann ginge das mit kleinen Brötchen auch gut.

in erster Linie gehts um zusammengewürfelte Endnote-Referenzen unserer
Klientel, die wir in VuFind werfen möchten, um so noch mehr relevante
Nachweise zu haben.
Dublettenkontrolle passiert da noch nicht bzw. müssen wir eh durchschleppen
via externe Indizes.

Soviel Daten haben wir übrigens noch gar nicht, sondern sind erstmal dabei,
die lokale Machbarkeit zu erkunden. Das ernste Problem sind in der Tat
Dubletten und Qualität.

Gruß Daniel

[Alexander Wagner]

On 03.07.2013 16:22, Daniel Zimmel wrote:

Moin!

DOIs oder pmids sind da der Bringer. Da kann man dann viele nette Sachen
mit ganz billigem Entrez oder crossref machen. Das kann lohnend sein,
wenn das nicht viel ist, diese IDs zu ergänzen bevor man anfängt weiter
zu spielen. Auch arXiv ist immer wieder gerne genommen.