RE: [InetBib] JabRef-Plugin für den GVK

["Kay Heiligenhaus" <kay.heiligenhaus@xxxxxxxxxxxx>]

Liebe PICA/SRU-Enthusiasten,

> Der Sourcecode ist dem Plugin beigefügt, im Prinzip kann man einfach
> die URL der GVK-SRU-Schnittstelle gegen eine andere austauschen. Probleme
> kann es geben, wenn man aufgrund einer unterschiedlichen
> SRU-Implementierung eine andere Abfragesyntax vorfindet (z.B. verhalten
> sich nicht alle SRU-Schnittstellen konform der Spezifikation) oder
> natürlich wenn PICA/XML als Rückgabeformat nicht unterstützt wird.

Wenn es nur so einfach wäre! Selbst wenn "PICA+-XML" von einem PICA-Katalog 
zurückgeliefert wird, hat man echte Implementierungsherausforderungen, denn:

1) Es gibt nicht unerhebliche Unterschiede in der Katalogisierungs_praxis_ der 
einzelnen "PICA-Verbünde" (GBV, HeBIS, BSZ) sowie der DNB, die sich in 
"semantisch" abweichenden Feld/Subfeldbelegungen sowie in "strukturell" 
unterschiedlichen Feld/Subfeldnutzungen materialisieren. Merke: PICA+-XML ist 
_semantisch_ nicht gleich PICA+-XML.

2) "PICA+-XML" ist nicht standardisiert. Die mir bekannten 
PICA+-XML-Implementierung (GBV und HeBIS) sind bereits auf "XML-Ebene" (Feld- 
und Attributnamen) vollkommen unterschiedlich. Das führt in unserer eigenen 
Implementierung (realisiert in XSLT) zu diesem Konstrukt, um beide Formate 
parallel überhaupt interpretieren zu können:

  * * *

        <func:function name="vls:getDatafieldValue">
                <xsl:param name="datafieldValue"/>
                <xsl:param name="subfieldValue"/>
                <xsl:param name="occurrence"/>
                <xsl:variable name="result">
                        <xsl:choose>
                                <xsl:when test="$occurrence = '' ">
                                        <xsl:value-of
                                                
select="child::*[local-name()=$datafieldElementName][substring(attribute::*[local-name()=$datafieldAttributeName],
 1, 
4)=$datafieldValue]/child::*[local-name()=$subfieldElementName][attribute::*[local-name()=$subfieldAttributeName]=$subfieldValue]"
                                        />
                                </xsl:when>
                                <xsl:otherwise>
                                        <xsl:choose>
                                                <xsl:when test="$picaType = 
'hebis' ">
                                                        <xsl:value-of
                                                                
select="child::*[local-name()=$datafieldElementName][attribute::*[local-name()=$datafieldAttributeName]=concat($datafieldValue,
 '/', 
$occurrence)]/child::*[local-name()=$subfieldElementName][attribute::*[local-name()=$subfieldAttributeName]=$subfieldValue]"
                                                        />
                                                </xsl:when>
                                                <xsl:otherwise>
                                                        <xsl:value-of
                                                                
select="child::*[local-name()=$datafieldElementName][substring(attribute::*[local-name()=$datafieldAttributeName],
 1, 
4)=$datafieldValue][@occurrence=$occurrence]/child::*[local-name()=$subfieldElementName][attribute::*[local-name()=$subfieldAttributeName]=$subfieldValue]"
                                                        />
                                                </xsl:otherwise>
                                        </xsl:choose>
                                </xsl:otherwise>
                        </xsl:choose>
                </xsl:variable>
                <func:result select="$result"/>
        </func:function>

  * * * 

Wer von Ihnen etwas XSLT/XPath lesen kann, sieht den Abgrund, in den man hier 
(technisch) blickt. Merke: PICA+-XML ist _syntaktisch_ nicht gleich PICA+-XML!

Schließlich kommt hinzu, daß von den vier genannten Einrichtungen genau _eine_ 
eine mir bekannte SRU-Implementierung bietet. Und das ist der GBV. Wenn sich 
das inzwischen geändert haben sollte, wäre das schon ein echter Schritt nach 
vorne. Aber m.W. wird damit in den nächsten Jahrzehnten nicht zu rechnen sein. 
(Naja, vielleicht sollte man nicht so skeptisch sein. Ich bin es aber 
inzwischen - leider.)

Beste Grüße,
Kay Heiligenhaus

-- 
http://www.inetbib.de