flexiblere Abfragemöglichkeiten

zur Zeit haben wir templatebasierte Abfragen. Diese bieten im wesentlichen die Möglichkeit, Felder des Entityobjekts festzulegen plus einzelne Terme, nach denen über die angegeben Felder gesucht werden soll.

Dies ist eine basic-Suche und nutzt die Möglichkeiten einer Suchmaschine kaum. Ziel sollte es sein, die Möglichkeiten der Elasticsearch-DSL besser auszunutzen

Vergleiche für die jetzigen Möglichkeiten auch http://data.swissbib.ch/docs

Möchte ich jetzt nach den Werken einer Person suchen, so brauche ich zuerst die ID (den Hashwert) einer Person und in einem zweiten request kann ich dann nach den bibliographischen Aufnahmen dieser Person suchen.

Beispiele hierfür:

http://data.swissbib.ch/bibliographicResource?q= http://data.swissbib.ch/person/04d720d4-c97c-3135-ba07-701b913f7fae&fields=contributor 

oder

curl -X GET "http://data.swissbib.ch/bibliographicResource?q= http://data.swissbib.ch/person/04d720d4-c97c-3135-ba07-701b913f7fae&fields=contributor" -H  "accept: application/ld+json"

Ziel: Können wir es ermöglichen, nach Namen von Personen zu suchen und als Ergebnis Personen mit ihren zugeordneten Werken zu erhalten?

Dies geht wohl nur, wenn wir entwder in die API-middleware oder den ES Adapter mehr logik hinterlegen

@Silvia: Welche weiteren Wünsche an die Abfrage hast Du?

häufig ist auch eine einfache ES-exists Abfrage sinnvoll. Beispiel: zeige mir alle Person entitities mit einer property sameAs (Verknüpft mit einem anderen repository). Denkbar ist die Abfrage: curl -X GET "http://data.swissbib.ch/person?fields=sameAs" -H "accept: application/ld+json" Da ich jedoch keinen Wert angebe, werden mir alle Personen zurückgeliefert

Man könnte sich auch diese Abfrage vorstellen: curl -X GET "http://data.swissbib.ch/person?q=*dbpedia*&fields=sameAs" -H "accept: application/ld+json"

Dies liefert jedoch 0 Treffer zurück

Auf Ebene ES wird eine wildcard-query so umgesetzt:

curl -s -X GET "localhost:8080/lsb/_search" -H 'Content-Type: application/json' -d'
{
    "query": {
        "wildcard" : { "owl:sameAs" : { "value" : "*viaf*" } }
    }
}' | python -m json.tool

Wie können wir das auf der API Ebene umsetzen

Erstellen eines openrefine Endpoints auf Basis der Restschnittstelle

HBZ lobid bietet unterdessen einen solchen Endpoint an. https://lobid.org/gnd/api#openrefine http://blog.lobid.org/2018/06/07/lobid-gnd.html

Können wir das umsetzen?

Möglichkeit zur Abbildung von Subobjects (or related objects)

wir können keine related objects abbilden, z.B. Adresse bei Organisationen http://data.swissbib.ch/organisation/ALEX-PSCH auf der neuen lobid - based API wird eine Abfrage (ohne templates) so aussehen können: institution mit Adresse

Diese ist aber vorhanden.

Mit den neuen Versionen der platform sollte das nicht so schwierig umzusetzen sein.

wie gehen wir mit den prefixes in den Terms (keys) um?

Ich denke wir sollten diese anbieten. Was tun wir sonst zum Beispiel mit gleichnamigen Termen aus unterschiedlichen Vokabularien.

brauchen wir wirklich zwei Kontexte (einen API Kontext und einen aus dem RDF Datenmodell?)

Können wir den vom RDF Datenmodell auch für api-platform verwenden?

Integration von GraphQL (wird von der Platform in der neuen Version angeboten)

Gibt uns das mehr Flexibilität?

GraphQL ist im Moment sehr sehr stark diskutiertes Thema. Wir wären hiermit im Bibliotheksumfeld aktuell so zimelich die ersten.

fixe kleinere aktuelle bugs

(z.B. rdf/xml wird nicht angezeigt

können wir Massendownloads anbieten

(z.B. basierend auf cursormodell von ES) Lobid scheint das zu können.

anstelle des eigenen template-Mechanismus den von ES verwenden?

→ bräuchten wir dan noch die Drittlibrary zum Erstellen der Queries? (Definition der queries über Konfiguration -analog der searchspec in VuFind) sollte grundsätzlich erhalten bleiben, aber sollten wir es vielleicht zugunsten von mehr Flexibilität in der RDF Schnittstelle aufweichen oder aufgeben? → von der UB Leipzig habe ich das Feedback, dass sie möglichst keine weiteren Drittlibraries verwenden wollen. Das ist verständlich. Als wir die Schnittstelle seinerzeit anfingen zu implementieren ist ES gerade i der Version 2.x erschienen. Wenn überhaupt war der native Templatemechanismus zu dieser Zeit gerade erst erschienen. man sollte sich anschauen, ob die ES templates gleichwertig zu der Kombination Drittlibrary/Templates Markus sind → war das ursprüngliche Entwicklungsziel, die Konfigurationsmöglichkeiten der VuFind searchspec abzubilden nicht zuviel des Guten? Wenn es geht würde ich versuchen diese beizubehalten

festgehaltene Fehler in github

https://github.com/linked-swissbib/hydra-swissbib.ch/issues oder https://trello.com/c/Xh4mZYi0/222-hydra-swissbibch-nachricht-benutzer-fehler-bei-aufruf-einer-libadmin-organisation