<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Sehr geehrter Herr Szott,<br>
herzlichen Dank für Ihre Antwort.<br>
Am 27.09.2012 14:28, schrieb Sascha Szott:<br>
</div>
<blockquote cite="mid:50644661.4040007@zib.de" type="cite">
<pre wrap="">Sehr geehrte Frau Baade-Kelishani,
On 26.09.2012 11:03, Annegret Baade-Kelishani wrote:
</pre>
<blockquote type="cite">
<pre wrap="">herzlichen Dank für Ihre Rückmeldung. Grundsätzlich fände ich es
natürlich sowieso wünschenswert, wenn man zusätzliche Suchfelder
einrichten könnte und wenn das insbesondere möglich wäre ohne
Auswirkungen auf die Listenanzeige.
</pre>
</blockquote>
<pre wrap="">Diese Anforderung ist durchaus nachvollziehbar. In der aktuellen
Implementierung müssen dazu aber mehrere Dateien angefasst werden. Zum
einen das XSLT-Stylesheet solr.xml im Verzeichnis
$BASEDIR/opus4/library/Opus/SolrSearch/Index/. Dort werden die
OPUS4-internen Datenfelder auf ein XML-Format gemappt, das schließlich
als Eingabe für den Solr-Indexer verwendet wird. Im Einzelfall kann es
auch noch nötig sein die Solr-Konfigurationsdatei schema.xml anzupassen.
Dort wird z.B. festgelegt, welche Indexfelder in der Standardsuche
durchsucht werden (Indexfeld 'text' mit den entsprechenden
copyField-Instruktionen).</pre>
</blockquote>
Ich glaube, Sie meinen die Datei solr.xslt. Das habe ich schon
ausprobiert. Wenn ich die Email hier eintrage, <br>
<blockquote type="cite"> <xsl:for-each
select="/Opus/Opus_Document/PersonAuthor"><br>
<xsl:element name="field"><br>
<xsl:attribute
name="name">author</xsl:attribute><br>
<xsl:value-of select="@FirstName" /><br>
<xsl:text> </xsl:text><br>
<xsl:value-of select="@LastName" /><br>
<xsl:text> </xsl:text><br>
<xsl:value-of select="@Email" /> <br>
<xsl:if test="position()!=last()"><br>
<xsl:text> ; </xsl:text> <br>
</xsl:if> <br>
</xsl:element><br>
</xsl:for-each><br>
</blockquote>
<br>
wird sie auch gefunden, das klappt gut. Nachteil ist allerdings,
dass sie dann in der Listenanzeige in der Frontdoor auch angezeigt
wird, etwa so (wenn, wie in diesem Beispiel 2 Autoren eine
Emailadresse haben und der dritte nicht):<br>
<blockquote type="cite">
<dl class="result_box even">
<dt class="results_title"> <a
href="http://opus4.bibliothek.fh-aachen.de/opus4/frontdoor/index/index/docId/4020">A
hyperelastic model of biological tissue materials in tubular
organs / Nguyen, N. H. ; Raatschen, H.-J. ; Staat, M.</a>
(2010) </dt>
<dt class="results_author"> <a
href="http://opus4.bibliothek.fh-aachen.de/opus4/solrsearch/index/search/searchtype/authorsearch/author/%22Manfred+Staat+%3B+%22">Manfred
Staat m.staat@fh-aachen.de ; </a> <a
href="http://opus4.bibliothek.fh-aachen.de/opus4/solrsearch/index/search/searchtype/authorsearch/author/%22N.+H.+Nguyen+%3B+%22">N.
H. Nguyen ; </a> <a
href="http://opus4.bibliothek.fh-aachen.de/opus4/solrsearch/index/search/searchtype/authorsearch/author/%22H.-J.+Raatschen%22">H.-J.
Raatschen raatschen@fh-aachen.de</a> </dt>
</dl>
</blockquote>
Und das ist aus meiner Sicht ein gravierender Nachteil.<br>
<blockquote cite="mid:50644661.4040007@zib.de" type="cite">
<pre wrap="">
Man könnte darüber nachdenken, ob man zumindest diese Konfiguration aus
der Solr-Konfiguration in die OPUS4-Konfiguration zieht, so dass
Änderungen prinzipiell nur an einer Stelle nötig sind. Das wäre
zumindest ein erster Schritt…
</pre>
<blockquote type="cite">
<pre wrap="">Bei uns ist es so, dass wir mit unserer zukünftigen OPUS4-Installation
nicht nur unsere bisherige OPUS3-Installation, sondern auch unsere
Veröffentlichungsliste (Hochschulbibliographie) ersetzen wollen, die
bisher mit eigenen php-Skripten und einer dahinter liegenden Datenbank
realisiert ist. Die Anzeige der Veröffentlichungen auf der Homepage des
jeweiligen Professors ist so realisiert, dass nach der Email-Adresse
gesucht wird (insbesondere natürlich auch deshalb, um - wie Sie schon
angedeutet haben - namensgleiche Autoren zu unterscheiden) und darauf
dann ein Export aufgebaut wird (der ja erfreulicherweise in OPUS 4 als
Option zur Verfügung steht), der dann wiederum in der erforderlichen
Form angezeigt werden soll. Mit anderen Worten, es geht mir in unserem
speziellen Anwendungsfall darum, dass ich eine URL bauen möchte, die die
Emailadresse enthält und dann einen entsprechenden Export anwirft
</pre>
</blockquote>
<pre wrap="">Statt der E-Mail-Adresse könnte man aber in diesem Fall auch einen
künstlichen Identifikator verwenden. </pre>
</blockquote>
Ja, das könnte man tun. Das haben wir bis vor kurzem auch so
gemacht. Der Nachteil war aber, dass dieser künstliche Identifikator
dann vom CMS auch regelmäßig nachgepflegt werden musste, was
arbeitsaufwändig und fehleranfällig war. Deshalb haben wir zur
Emailadresse gewechselt, weil die im CMS sowieso enthalten ist. Und
wenn dieser "künstliche Identifikator" nicht die OPUS-ID ist, wie es
bei uns war, dann hätte man das Problem mit der Suchbarkeit ja
genauso wie jetzt.<br>
<blockquote cite="mid:50644661.4040007@zib.de" type="cite">
<pre wrap="">Wer ruft denn in ihrem Szenario den
Export auf? Der Client (Browser des Benutzers) per AJAX oder das CMS,
das die Publikationslisten im Hintergrund bereits erzeugt und dann
serverseitig nur noch in die Seite "einhängt"? Im zweiten Fall könnte
man durchaus die Suche nach E-Mail-Adressen als privilegierte Funktion
betrachten, die nur ausgewählte Benutzer durchführen dürfen. Dann würde
man dem CMS-Prozess mit den erforderlichen Rechten für diese Operation
ausstatten.</pre>
</blockquote>
Zur Zeit das CMS. Von daher wäre es für mich natürlich auf jeden
Fall schon mal ein Fortschritt, wenn ich wüsste, wie man solch eine
privilegierte Funktion einrichten würde. Flexibler wäre man aber,
wenn auch der Weg über AJAX möglich wäre, man weiß ja nie, welche
Anforderung als nächstes kommt ... <br>
<blockquote cite="mid:50644661.4040007@zib.de" type="cite">
<pre wrap="">
Beste Grüße,
Sascha Szott
</pre>
</blockquote>
Viele Grüße aus Aachen und einen schönen Feierabend<br>
Annegret Baade-Kelishani<br>
<blockquote cite="mid:50644661.4040007@zib.de" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
Am 25.09.2012 17:12, schrieb Sascha Szott:
</pre>
<blockquote type="cite">
<pre wrap="">Sehr geehrte Frau Baade-Kelishani,
ich komme nochmal zurück auf die Anforderung 'Suche nach
E-Mail-Adressen' (OPUSVIER-2606). Können Sie uns den konkreten Use-Case
dahinter skizzieren. Wollen Sie die Adressen zur besseren Unterscheidung
von gleichnamigen Autoren verwenden?
I.A. sind E-Mail-Adressen als personenbezogene Daten zu schützen. Mit
der Suche nach E-Mail-Adressen wäre es nun zumindest möglich durch die
Eingabe einer E-Mail-Adresse zu prüfen, ob eine im System gespeicherte
Person (Autor) diese Mailadresse besitzt. Somit wird die E-Mail-Adresse
zwar nur indirekt "sichtbar", ich halte das dennoch für problematisch.
Innerhalb der Administration könnte ich mir das schon eher vorstellen.
Beste Grüße,
Sascha Szott
On 03.09.2012 13:26, Signe Weihe wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Liebe Frau Baade-Kelishani,
aktuell ist es nicht ohne weiteres möglich die Suche um zusätzliche
Felder zu erweitern. Es müssen an mehreren Stellen Änderungen
vorgenommen werden. Da uns immer wieder Wünsche zu zusätzlichen
Suchfeldern zugetragen werden gibt es bereits Überlegungen, einen
einfachen Erweiterungsmechanismus bereitzustellen oder zumindest in der
Doku zu beschreiben, wie eine Erweiterung um zusätzliche Felder
prinzipiell möglich ist (d.h. welche Dateien müssen editiert werden).
Dazu gibt es in unserer Entwicklung bereits das Ticket (in Planung)
OPUSVIER-1395 Erweiterung der Suche um zusätzliche Felder
das ich um eine Unteraufgabe
OPUSVIER-2606 Suche nach Emailadressen der Autoren
ergänzt habe.
Mit freundlichen Grüßen,
Signe Weihe
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Annegret Baade-Kelishani
Hochschulbibliothek der FH Aachen
Eupener Str. 70
52066 Aachen
+49241600952063</pre>
</body>
</html>