###### tags: `WissKI`
# Things to hack

hackathon.nasarek.org
!beware!light-Theme-attracts-1984-Bugs-per-minute

gui
hack
UfuUQ6Hnjjxp7G7

## Notices, Warnings, Errors
**Bugfixes**
### Notice: Trying to access array offset on value of type null in Drupal\wisski_pathbuilder\Form\WisskiPathbuilderConfigureFieldForm->form() (line 234 of modules/contrib/wisski/wisski_pathbuilder/src/Form/WisskiPathbuilderConfigureFieldForm.php).

### Notice: Trying to access array offset on value of type null in Drupal\wisski_pathbuilder\Form\WisskiPathbuilderConfigureFieldForm->form() (line 143 of /var/www/html/wisski.com/web/modules/contrib/wisski/wisski_pathbuilder/src/Form/WisskiPathbuilderConfigureFieldForm.php)

#### When deleting a pathbuilder
#### Type php
#### Date Thursday, September 30, 2021 - 10:14
#### User wisski
#### Location
http://wisski.com/admin/config/wisski/pathbuilder/bibliography/delete?destination=%2Fadmin%2Fconfig%2Fwisski%2Fpathbuilder
#### Referrer
http://wisski.com/admin/config/wisski/pathbuilder/bibliography/delete?destination=/admin/config/wisski/pathbuilder
#### Message
TypeError: htmlentities(): Argument #1 ($string) must be of type string, Drupal\Core\Url given in htmlentities() (line 31 of /var/www/html/wisski.com/web/modules/contrib/wisski/wisski_pathbuilder/src/Form/WisskiPathbuilderDeleteForm.php)

#0 /var/www/html/wisski.com/web/modules/contrib/wisski/wisski_pathbuilder/src/Form/WisskiPathbuilderDeleteForm.php(31): htmlentities()
#1 /var/www/html/wisski.com/web/modules/contrib/wisski/wisski_pathbuilder/src/Form/WisskiPathbuilderDeleteForm.php(51): Drupal\wisski_pathbuilder\Form\WisskiPathbuilderDeleteForm->getCancelUrl()
#2 [internal function]: Drupal\wisski_pathbuilder\Form\WisskiPathbuilderDeleteForm->submitForm()
#3 /var/www/html/wisski.com/web/core/lib/Drupal/Core/Form/FormSubmitter.php(113): call_user_func_array()
#4 /var/www/html/wisski.com/web/core/lib/Drupal/Core/Form/FormSubmitter.php(51): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers()
#5 /var/www/html/wisski.com/web/core/lib/Drupal/Core/Form/FormBuilder.php(593): Drupal\Core\Form\FormSubmitter->doSubmitForm()
#6 /var/www/html/wisski.com/web/core/lib/Drupal/Core/Form/FormBuilder.php(321): Drupal\Core\Form\FormBuilder->processForm()
#7 /var/www/html/wisski.com/web/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm()
#8 [internal function]: Drupal\Core\Controller\FormController->getContentResult()
#9 /var/www/html/wisski.com/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#10 /var/www/html/wisski.com/web/core/lib/Drupal/Core/Render/Renderer.php(578): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#11 /var/www/html/wisski.com/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext()
#12 /var/www/html/wisski.com/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#13 /var/www/html/wisski.com/vendor/symfony/http-kernel/HttpKernel.php(158): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#14 /var/www/html/wisski.com/vendor/symfony/http-kernel/HttpKernel.php(80): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#15 /var/www/html/wisski.com/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle()
#16 /var/www/html/wisski.com/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle()
#17 /var/www/html/wisski.com/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#18 /var/www/html/wisski.com/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#19 /var/www/html/wisski.com/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle()
#20 /var/www/html/wisski.com/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#21 /var/www/html/wisski.com/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#22 /var/www/html/wisski.com/web/core/lib/Drupal/Core/DrupalKernel.php(717): Stack\StackedHttpKernel->handle()
#23 /var/www/html/wisski.com/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#24 {main}

.
Severity Error
Hostname 127.0.0.1
Operations

## Improving Stuff
**Extent existing moduls**
### Restrict the field options for Entity Reference
santity References
- must have disambiguation
- must have bundle
- must not have datatype property

### Extent output of ODBC-Modul
- show Table, which is currently imported

### Set triggered Element

### Upgrade Mirador-Implementation to Version 3

### Delete Namespaces
AF: Hallo zusammen, noch ein Vorschlag für ein schönes Hackathon-Thema: Wenn man in WissKI eine Ontologie importiert, werden die Namespaces in die Drupal-DB-Tabelle "wisski_core_ontology_namespaces" geschrieben -- da verschwinden sie aber nie wieder, auch dann nicht, wenn eine Ontologie gelöscht wird! Es wäre prima, auf der Seite .../admin/config/wisski/ontology neben "Delete Ontology" einen weiteren Button "Delete Ontology and Namespaces" zu haben, dann hätte man die Option, eine Ontologie sauberer aus dem System zu entfernen.

## New Moduls
**Brand new moduls with fresh funtionality**

### Fedarable Adapters
#### Problem
In den Views sind Filterkriterien adapteragnostisch, dass heißt
Adapter werden nicht einzeln angesprochen, sondern die Query richtet sich an alle vorhandenen Adapter.
Das erzeugt eine zu große Ergebnismenge und stellt ein Performanceproblem dar.
#### System und Kontextgrenzen
Systemgrenzen des adapterabhängigen Filters für das WissKIsystem sind:
- Um das Filtern nach Bundles und Feldern bei der Anzeige zu ermöglichen, muss das Drupalsystem dem Administrator die Möglichkeit bieten, Filterkrieterien einzugeben.
- Die Filteranzeige muss so gestaltet sein, dass ein Administrator Main-Bundles und Felder mit UND/ODER-Verknüpfungen vereinen kann.

Kontextgrenzen:
- Das WissKIsystem muss dem Administrator die Möglichkeit bieten, Daten aus Adaptern nach Kriterien zu filtern.

#### Anforderungen
- Sobald der Administrator die Filterkriterien gespeichert hat, muss das WissKIsystem fähig sein gefilterte Bundle-Ids zu finden.
- Falls die Filterkriterien nur aus Feldern bestehen, muss das WissKIsystem fähig sein, eine Bundle-Id zuzuordnen.
- Nachdem das WissKIsystem Bundle-Ids zugeordnet hat, muss das WissKIsystem fähig sein angeschlossene Adapter nach Bundle-Ids mit einer geeigneten Query zu durchsuchen.
- Das WissKIsystem muss fähig sein zwischen der Federated und Non-Federated Adapterart zu unterscheiden.
- Falls ein Adapter die gefilterte Bundle-Id hat und ein Tripple-Store ist, muss das WissKIsystem eine einfache Sparql-Abfrage an den Adapter senden.
- Falls mehrere Adapter die gefilterte Bundle-Id haben und alle Federated Tripple-Stores sind, muss das WissKIsystem eine federated Sparql-Abfrage an einen pivot-Adapter senden, der alle anderen anspricht.
- Falls mehrere Adapter die gefilterte Bundle-Id haben und nicht alle Federated Tripple-Stores sind, muss das WissKIsystem unterschiedliche Queries an die Adaper senden und die Ergebnismengen verschmelzen.
- Nachdem das WissKIsystem die Entity-Ids der verschmolzenen Ergbnismenge zugeordnet hat, muss das WissKIsystem die Entity-ids in der NAVIGATE-Ansicht laden.
#### Ziel
- WissKI übersetzt mit den Filterkrieterien, die Drupal zur Auswahl stellt und für alle angeschlossenen Adapter
- Drupal erzeugt automatisch alle Main-Bundles und Felder als Filterkriterien
- Adapter können unterschiedlicher Art sein und unterschiedliche Daten enthalten.
- Eine Query hängt von der Adapterart ab.
- Filterkrieterien haben mindestens ein Bundle, da Felder immer zu einem Bundle gehören.
- Adapter, die die gefilterten Bundle-Ids nicht haben, werden ausgeschlosen.
- So dass nur Adapter geladen werden, deren Daten die Bundle-Ids und Felder und entsprechend die Filterkriterien haben.
- In den Filtern sollen nur die Adapter angesprochen werden, deren Bundles ausgewählt wurden.
- Die Query an die Adapter soll federated sein, also nach dem Schema:

~~~sparql
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX books: <http://example.com/books/>

SELECT ?authorName WHERE {
?book rdfs:label "The Hitchhiker's Guide to the Galaxy" ;
books:author ?author .

SERVICE <repository:authors> {
?author rdfs:label ?authorName
}
}
~~~

- already started on [Branch hackday](https://git.drupalcode.org/project/wisski/-/refs/switch?destination=tree&path=&ref=8.x-3.x-hackday)

**Federated Query Ausgang: Ein Nutzer**

kann sich verschiedene Filterkriterien zusammen klicken und über UND,
ODER Verknüpfungen verbinden. Zu seiner Auswahl stehen alle Feldnamen
und Bundles zur Verfügung.
*HAUPTZIEL: NAVIGATE zeigt die richtigen Entitäten an, die den Filterkriterien entsprechen.*
Dateien: wisski_salz/Query/
- ASTAnnotator.php
- ASTHelper.php
- QueryPlaner.php
- WisskiQueryDelegator.php
**Ziel 1:** Filterkriterien lesen, vereinfachen
**Ziel 2:** Für die Anfrage an die Adapter (Datenquellen wie z.B Tripple Store,
XML-Datei, JSON, Excel-Tabelle) relevante Informationen speichern
**Ziel 3:** Gespeicherte Informationen für die Anfragen nutzen.
Wichtige Unterscheidung - Wie viele Bundles wurden in den Filterkriterien
erwähnt? Wie viele Adapter werden angesprochen? Je mehr verschiedene
Adapter angesprochen werden, desto komplizierter die Suchanfrage (query)
- Single Adapter Plan = Ein Bundle
- Multi Adapter Plan = Mehrere Bundles, also mehrere Adapter -> manueller merge der Anfragen.
- Null Adapter Plan = Kein Bundle im Filter
**Ziel 4:** Entscheiden welche Art der Anfrage an die Datenquellen geschickt
wird, diese hängt mit der Adapter-Art zusammen. Mögliche Arten:
Federated = ist ein Tripple Store und aus anderen Tripple Stores
anprechbar; Non-Federated = Tripple Store, der nicht von seinergleichen
angesprochen werden kann oder eine andere Adapter-Art (Datenquelle)
**Erreicht** ist der einfachste Fall: Die gefilterten/ angesprochenen Daten liegen
alle in Tripple Stores, die federated sind, oder einem einzigen Tripple
Store, was dasselbe wäre, da nur ein pivot Adapter die Anfrage sendet
und ggf. weiterleitet.

#### Alte QueryDelegator
https://gist.github.com/rnsrk/05afd29b0d0a81200972b9d8e5076cc6

#### Dev-Plan

START: der Nutzer filtert Entitäten nach
Feldern und Bundles, die er mit UND/ODER
Operatoren verknüpft.
|
|
v
In der erzugten Datenstrukur QUERY-AST
werden nur relevante Query-Informationen
aus dem (umfangreichen) FILTER-Objekt und
(vollständigkeitshalber) anderswoher
gesammelt. |
|
v
Hat der QUERY-AST einen Bundle?
/ \
/ \
JA / \ NEIN
/ \ (Ja, immer!)
v v
Adapteranzahl und -Art Bundle auswerten, zu dem
pro Bundle untersuchen. gefilterte Felder gehören.
|
|
v
Ist der Adapter FEDERATED?
/ \
JA/ \ NEIN
/ \
v v
Den ersten (einzigen) Adapter Wird die Adapter-Art erkannt?
als PIVOT-Adapter vermerken, | \
der die Query an andere JA | \NEIN
Federated Adapter weiterleitet. | \
| v v
| unterscheiden Drupal-Warnung
| / | \ für den Nutzer.
v / | \
Entity-Ids aus der Ergebnismenge v v v
von der gebauten SPARQL-Query holen. TRIPPLE XML EXCEL
| STORE\ | /
| \ | /
| \ | /
| v v v
| Queries bauen und wenn nötig
| Ergebnismengen verschmelzen.
| |
| |
v v
ENDE: Entity-Ids in NAVIGATE laden.