Liebe Gemeinde,
in der Erweiterten Suche gibt’s kein “nicht”, oder?
vg
Bei uns zumindest nicht, nein.
1 „Gefällt mir“
Ja na dann halt nicht.
zur Info: Wie im Dezember Digest angekündigt sammeln wir gerade User-Stories für eine Überarbeitung der Suche.
Ich war mal so frei diesen Punkt mit aufzunehmen 
1 „Gefällt mir“
Oh, danke. Da kann ich gerne die Hintergrundstory beisteuern:
wir suchen gerade Akten die Dokumente aus einem bestimmten Jahr, z.B. 1931 enthalten. Akten haben Laufzeiten, keine einzelne Jahresangaben.
Unser Ansatz: Gib mir alle Akten, deren Laufzeitbeginn zwischen 1900 und 1931 liegt und dessen Laufzeitende nicht(zwischen 1900 und 1930) liegt.
Ha! Ich habe einen Hack gefunden:
Man kann die SOLR-Query in die URL schreiben und dort verneinen:
((MD_DATECREATEDSTART:[01.01.1900+TO+01.01.1931] AND -MD_DATECREATEDEND:[31.12.1900 TO 31.12.1931])
Ein SOLR-Query-Injection sozusagen. Ist aber nicht sehr nutzerfreundlich.
Ich dachte schon, ich müsste irgendwie mit doppelter Bejahung arbeiten , oder so …
1 „Gefällt mir“
Interessant. So geht es mit einer SOLR-Query in den Viewer-Templates:
DOCSTRCT:Object NOT MD_TITLE:Nietzsche
Das identische Ergebnis bringt:
DOCSTRCT:Object AND -MD_TITLE:Nietzsche
Liege ich mit meiner Annahme falsch?
Ach, zu dem ganzen Thema “Formulieren von Solr-Queries” müssen wir noch einmal was aufschreiben. Ich kann mir das auch immer nicht merken. Ich frag mal @andrey.kozhushkov und @florian.alpers ob wir nicht perspektivisch einen FAQ Eintrag schreiben können in dem wir ein paar Beispiele geben (UND/ODER, Klammersetzung, NICHT, …)
Wäre es nicht sinnvoller, die Beispiele in der Inline-Hilfe der jeweiligen Templates unterzubringen? Ich wünsche mir an der Stelle einen Link auf einen passenden Eintrag im Goobi-Wiki. Das Wiki könnte Teil der Community werden. Dadurch wäre auch gewährleistet, dass es praxisnahe Inhalte bekommt?
Ja. Wir haben heute bereits individuelle Inline-Hilfe-Strings und werden das auch weiter verfolgen.
Ja. Einen Link zu einem passenden Eintrag in der Goobi viewer Dokumentation kann ich mir auch vorstellen. Deswegen auch mein Vorschlag da einen FAQ-Beitrag oder vergleichbar draus zu machen.
Einem Wiki stehe ich kritisch gegenüber. Vergleichbare Ansätze sind in der Vergangenheit aus unserer Sicht gescheitert. Die Inhalte waren oftmals veraltet und teilweise auch schlicht falsch, da sie auf Annahmen und Beobachtungen von Nutzern basierten aber nicht auf der Logik im Quelltext.
Aus genau dieser Erfahrung haben wir docs.goobi.io ins Leben gerufen. Dabei übernehmen wir die Pflege der dortigen Handbücher und Anleitungen. So ist sichergestellt, dass dort nichts falsches und nach Möglichkeit immer nur aktuelles steht. Anregungen aus der Community nehmen wir gerne auf und pflegen die dort dann ein.
Damit das ganze keine One-Way-Road und intranda exklusiv ist haben wir uns dazu entschieden ein System basierend auf Markdown Dateien zu nutzen und die Änderungen alle auch auf Github zu spiegeln.
Es gibt zwei Wege in das System: Man pusht seine Änderungen an den Markdown Dateien direkt in das Github Repository, dann werden die zu Gitbook übernommen (die bevorzugte Arbeitsweise bei den Goobi workflow Dokumentationen / Repositories) oder man arbeitet über die Gitbook Oberfläche und synchronisiert die Änderungen dann automatisch zu Github (die bevorzugte Arbeitsweise bei der Goobi viewer Dokumentation / den Repositories).
Die Community kann also entweder so wie bisher Anregungen zu der Dokumentation in Form von E-Mails an uns oder Hinweise hier im Community Forum anbringen und wir pflegen das ein. Alternativ besteht aber auch die Möglichkeit auf Github einfach einen Pull-Request für die Änderungen im Markdown zu erstellen die dann übernommen werden…
Die Bedenken teile ich grundsätzlich. Allerdings ist ein Wiki barriereärmer als zB Gitbook/Github?
Ich sehe folgende Möglichkeiten:
-
Die Inline-Hilfe zielt auf die von Dir beschriebenen Handbücher/ Anleitungen auf docs.goobi.io. Vorteil wäre eine gewisse Aktualität und Einheitlichkeit.
-
Die Inline-Hilfe zielt auf ein einrichtungsspezifisches Wiki, das im Backend des Viewers von jeder Einrichtung selbst gepflegt wird. Vorteil wäre, dass hier spezifische Herangehensweisen eingetragen werden können.
-
Die Inline-Hilfe zielt auf ein einrichtungsspezifisches externes “Wiki” ausserhalb des Viewers.
Habe ich eine Option vergessen?
Das sehe ich nicht so. Ob Wiki oder Github Repository:
- In beiden musst Du dich vorher registrieren / authentifizieren
- Beide folgen einer Formatierungssyntax die eingehalten werden muss
- In beiden hast Du eine visuelle Vorschau der Ergebnisse
- Beides ist versioniert
- Beides ist webbasiert betrachtbar…
Ich bin mir nicht sicher. Ich würde das ganze aber nicht nur auf den Goobi viewer beschränken sondern dann auch auf Goobi workflow etc. ausdehnen. Im Kern geht es doch darum einrichtungsspezifische Besonderheiten im “Digitalisierungsprozess” zu dokumentieren. Egal ob der jetzt im Backend oder im Frontend stattfindet.
Dafür lassen sich sicherlich Lösungen schaffen. Haben wir auch für Goobi Goobi workflow einmal gemacht, war vom Kunden beauftragt worden ist dann aber in der Praxis nicht angenommen worden.
Deswegen geht meine Strategie eher dahin auch die einrichtungsspezifischen Dinge in die offizielle Dokumentation mit zu übernehmen. Das sind ja ganz spannende Anwendungsfälle, warum sollte man die zurückhalten? Gleichzeitig können wir daraus lernen, Anforderungen an die Software ableiten und so weiter…
Nur am Rande:
Die optimale Query wäre übrigens
+DOCSTRCT:Object -MD_TITLE:Nietzsche
+ bedeutet: Muss zutreffen
- bedeutet: Darf nicht zutreffen
Der Vorteil dieser Schreibweise liegt darin, dass sie auch mit mehr als zwei Kriterien wie erwartet funktioniert. Logische Operatoren verhalten sich im allgemeinen Fall nicht so wie man es erwartet. Intern werden logische Operatoren auch immer in die native +/- Logik übersetzt
2 „Gefällt mir“
Kurze Nachfrage: Das heißt, man würde das AND als logischen Operator lieber nicht verwenden?
Wenn es in der Anfrage nur einen logischen Operator gibt, oder man konsequent Klammern setzt, kann man bedenkenlos AND und OR verwenden. Bei mehr als einem Operator und fehlender Klammerung sollte man auf AND und OR verzichten, da es zu falschen Ergebnissen führt (nicht sicher wie es bei NOT aussieht, aber konsequenterweise würde ich das genauso behandeln die die anderen logischen Operatoren).
Der Vorteil von AND/OR ist sicherlich, dass es einfacher lesbar ist. Ich würde die Schreibeweise also nicht ganz verwerfen aber mit Vorsicht genießen.
1 „Gefällt mir“