###### tags: `hackathon`
# Hackathons
## 11.11.2022
### Done
* [Autocomplete pattern issue abgeschlossen](https://git.drupalcode.org/project/wisski/-/commit/af06b5c2bf1ee49d47636793fa12d66771239ec7)
### Todo
## 18.11.2022
### Done
* Vorstellung [WissKI-Example Umgebung 1.5.0](https://hub.docker.com/repository/docker/rnsrk/wisski_example)
* [Permalinks](https://git.drupalcode.org/project/wisski/-/tree/8.x-3.x/wisski_permalink) überschreiben bei WissKI Entities den Link in der URL bar
* [Pathbuilder Export von GND gefixed](https://git.drupalcode.org/project/wisski/-/commit/4e9bf8327b4a84497e341aee4701cd0b58f98650) (einfach überspringen, wenn keine direct queries ausführen kann)
* [Code refactoring XML export](https://git.drupalcode.org/project/wisski/-/commit/a03f10834c351f4c5a431d89c0b4e51034e8e66d) auf eine Funktion
* [LinkIt Matcher for WissKI Entities](https://git.drupalcode.org/project/wisski/-/commit/2d49e3949a64e23d979cf8d236bd208ceb3ade85)
* [Permalinks bei Bundle Views](https://git.drupalcode.org/project/wisski/-/commit/b3d0168e2581bd0fbef3d75c3b69e1d8dc529411), gibt eine Option in den WissKI Configurations (/admin/config/wisski/settings)

## Hackweek (12.12. - 16.12.2022)
### Wochenplan für Hackathon
#### Teilnehmende
Mark Fichtner, Robert Nasarek, Kai Amann, Tom Wiesing, Philipp Eisenhuth, Myriel Fichtner, Gustavo Riva (digital)

<img src="https://i.imgur.com/WxwtJog.jpg"  width="300" height="300">

#### Mailingliste
Mail an wisski-eu, damit Leute nicht auf Slack kommen müssen

#### Händchen halten
Leute versuchen zu motivieren in den Hackathon zu kommen; stärker einbinden, zeigen wie man pusht

#### Federated Queries
<details>
<summary>Motivierendes Beispiel (Annahme: 4 Adapter)</summary>

Konfiguration der Adapter
Adapter 1 und 2 sind federated, Adapter 3 und 4 nicht
Adapter 1, 2 und 3 haben Personendaten und wir fragen Personendaten an
nur Adapter anfragen, die auch sinnvoll sind (d.h. die etwas zu liefern haben auch eine Anfrage)
Inhalte der Adapter
Adapter 1: 30 Personen die mit A anfangen, 80 mit B, 1 mit D
Adapter 2: 10 Personen die mit A anfangen, 20 mit B, 90 mit C
Adapter 3: 1 Person mit A, 1203 mit D
Adapter 4: keine Personen

Annahme: innerhalb Adaptern sortiert
Wenn WissKi sagt, gib mir die ersten 100, dann holt es von Adapter1: 30 x A, 70 x B; von Adapter2: 10 x A, 20 x B, 70 x C; von Adapter 3: 1 x A, 99 x D
Federated: 2 Adapter als 1 Adapter sehen => Adapter 1 und 2 hätten also: 40 Personen die mit A anfangen, 100 mit B, 90 mit C, 1 mit D
Federation mit min+max implementieren
und: über Interface Priosierung ermöglichen, damit klar ist welcher Adapter auf jeden Fall angesprochen werden sollen
</details>

#### Links
[Ablauf des Query-buildings](https://lucid.app/lucidchart/84657d1f-dcb4-48f1-bfd6-d62a89014e94/edit?viewport_loc=-3061%2C-921%2C9621%2C4457%2C0_0&invitationId=inv_9c7747ba-326c-451d-8ecd-24035455a493)

[Cases for Queries](https://lucid.app/lucidchart/c54c8bea-2a1a-4c76-a66b-d88cee85a172/edit?viewport_loc=-750%2C-41%2C4571%2C2118%2C0_0&invitationId=inv_38d45f6c-a9b2-4bec-976d-fcbe7cb3ed38)

[Lucid Chart 2](https://lucid.app/lucidchart/8d7ffac5-af26-45b5-ac86-7b555d323d5b/edit?invitationId=inv_106ccd2a-6154-4afe-bb67-f91d2f0668f2)

[Lucid Chart 3](https://lucid.app/lucidchart/9d839f85-f023-4568-8a45-a2fc7ec11449/edit?invitationId=inv_07825bca-7fd8-4c28-951b-80cff2924f17)

[Lucid Chart 4](https://lucid.app/lucidchart/9d839f85-f023-4568-8a45-a2fc7ec11449/edit?invitationId=inv_07825bca-7fd8-4c28-951b-80cff2924f17)

### 12.12.2022

#### ToDo
* Pathbuilder Export leitet um zu der erstellten XML
* Im Laufe der Hackweek: Neuen zeitlichen Rahmen für den Standard WissKI Hackday Freitags besprechen (=> vllt 10-14 Uhr)
* NFDI anfragen (siehe unten)

#### Diskussion
* WissKI Config backup
* Devel hat config export
* NFDI anfragen wegen rocket.chat mit domain rocket.wiss-ki.eu @1sm4zt1jSWmoXGMeNA0MlA

##### Git
* Wie mit commits umgehen?
* branches jetzt online
* dokumentation + merges + test mit einplanen (1h)
* branches so kurz wie möglich am Leben halten (am Abend müssen sie spätestens in den main branch gemerged werden)
* Wer das isst ist doof (approved)

### 13.12.2022

* Wiederverwendbares und konkretes Beispiel auf https://hackathon.nasarek.org/ mit konkreten Testfällen

* back-end 1, 2, 3: Ontologie CIDOC CRM (http://erlangen-crm.org/211015/)
* back-end 4: Ontologie NFDI4Culture
* adapter "Adapter 1": non-federated
* adapter "Adapter 2", "Adapter 3": federated

- [x] Test-Fall "Single Adapter Plan" (https://hackathon.nasarek.org/single-adapter-plan)
* Egal ob Adapter federatable oder non-federatable
* Im Beispiel: Wisski Entity: Bundle/Group (= Actor) AND Wisski Entity: Actor -> Name (act_name) in example-pathbuilder (contains t)

- [ ] Test-Fall "Single Federation Plan" (https://hackathon.nasarek.org/single-federation-plan):
* Falls Adapter 2 und 3 "non-federated": Multi Partition Plan wird ausgeführt
* 

* Falls Adapter 2 und 3 "federatable": Multi Partition Plan wird ausgeführt => wird gefixt

* Neue Begrifflichkeiten:
* 

### 14.12.2022
<details>
<summary>OR Query zum Testen:</summary>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ecrm: <http://erlangen-crm.org/211015/>
SELECT DISTINCT * WHERE {
{
?v1 a ecrm:E39_Actor .
} UNION {
SERVICE <repository:backend> {
?v1 a ecrm:E21_Person .
}
}
}
</details>

<details>
<summary>Query:</summary>

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ecrm: <http://erlangen-crm.org/211015/>

SELECT DISTINCT * WHERE {
{
?v1 a ecrm:E39_Actor .
?v1 ecrm:P1_is_identified_by ?a1 .
?a1 a ecrm:E41_Appellation .
?a1 ecrm:P3_has_note ?a2 .
} UNION {
SERVICE <repository:backend> {
?v1 a ecrm:E39_Actor .
?v1 ecrm:P1_is_identified_by ?a1 .
?a1 a ecrm:E41_Appellation .
?a1 ecrm:P3_has_note ?a2 .
}
}
}
</details>

<details>
<summary>Query:</summary>
/**
* Get an array of query parts to build up the dependent queries.
* currently it contains:
* - The where string
* - The eids (values-part)
* - The order string
*/
public function getQueryParts() {
// TODO: Iterate over the tree in this::Groups
list($where_clause, $entity_ids) = $this->makeQueryConditions($this->condition);

return array("where" => $where_clause, "eids" => $entity_ids, "order" => $this->orderby);
}
</details>

## Hackweek (06.02. - 08.02.2023)
### Wochenplan für Hackathon
#### Teilnehmende
Mark Fichtner, Robert Nasarek (digital), Kai Amann, Tom Wiesing, Philipp Eisenhuth, Myriel Fichtner, Laura Albers, Elias
#### Essen gehen am Mittwoch, Taqueria: https://oraletaqueriabar.com/ um 17:30 Uhr
#### Montag, 06.02.2023
- Alle Pläne aufgeteilt immer in: "executeCount[AdapterPlan]" und "executeNormal[AdapterPlan]" und in denen jeweils execute[AdapterPlan] aufgerufen mit verschiedenen Parametern (=> im count fall mit $count = true)
- Single Adapter Plan, Single Federation Plan implementiert und getestet

#### Dienstag, 07.02.2023
- Single Partition Plan implementieren:
- Innerhalb eines Blattes gehen wir davon aus, dass die Daten aus einem Adapter kommen
- Ein Single Partition Plan wird in einen Multi Partition Plan umgewandelt, in dem für jedes Blatt ein Multi Partition Plan ausgeführt wird
- wir haben verschiedene Fälle:
- Single Partition Plan mit Aggregate "AND" zwischen zwei Blättern (z.B. Daten aus A1 und A2); das wird gemapped auf zwei Multi Partition Pläne pro Blatt und innerhalb wird pro Adapter der vorkommt (also A1 und A2) ein eigener Plan ("Single Adapter Plan") erstellt (in unserem Fall also 2 Pläne). Anschließend werden die beiden Multi Partition Pläne mit einem "AND" verknüpft.
- Single Partition Plan mit Aggregate "OR" zwischen zwei Blättern;
- Single Partition Plan mit "FILTER" == also ein Blatt; Adapter anschauen, die an einem Filter

- Sort implementieren (nur Single Adapter und Single Federation geschafft)

#### Mitwoch, 08.02.2023
- Sort für Single Partition und Multi Partition Plan

## Testfälle
### Konfiguration im System

Konfiguration der Adapter
Adapter 2, 3, und 6 sind federated, Adapter 1 und 4 nicht
Adapter 1, 2 und 3, 5 (Kopie von 2) und 6 haben Personendaten und wir fragen Personendaten an
nur Adapter anfragen, die auch sinnvoll sind (d.h. die etwas zu liefern haben auch eine Anfrage)

Ontologien der Adapter
Adapter 1: CIDOC CRM (http://erlangen-crm.org/211015/)
Adapter 2: CIDOC CRM (http://erlangen-crm.org/211015/)
Adapter 3: CIDOC CRM (http://erlangen-crm.org/211015/)
Adapter 4: NFDI4Culture
Adapter 5: CIDOC CRM (http://erlangen-crm.org/211015/)
Adpater 6: CIDOC CRM (http://erlangen-crm.org/211015/)
Inhalte der Adapter
Adapter 1: 3 Personen: Marie Müller (Backend 1), Bernd Biatro (Backend 1), Sarah Sitri (Backend 1)
Adapter 2: 3 Personen: Batata Masim (Backend 2), Lopin Gagisim (Backend 2), Wopum Toroto (Backend 2)
Adapter 3: 5 Personen: Zumo Fortula (Backend 3), Sihana Ope (Backend 3), Lola Werti (Backend 3), Rutilo Tuma (Backend 3), Cikol Deritto (Backend 3)
Adapter 4: keine Personen (noch nicht eingerichtet)
Adapter 5: ist eine Kopie von Adapter 2 bzw. der Pathbuilder von Adapter 2 ist kopiert und läuft also nochmal auf Adapter 5; dadurch hat man auf Adapter 5 exakt die gleiche Bundles, wie auf Adapter 2 (= gleich in der ID)
Adapter 6: 4 Personen: Kaya Afrau (Backend 6), Myriun Eichner (Backend 6), Mareike Eichner (Backend 6), Philippia Blechmützeh (Backend 6)

**-- WICHTIG: Wir gehen davon aus, dass die Daten "normalisiert" sind, das heißt, dass jede Entity genau EINE eindeutig URI hat. --**

### - Leerer Plan -
=> ignorieren, nur wichtig, dass es im Code berücksichtigt wird
### - Single Pläne -
(= genau 1 Query/Anfrage an 1 oder mehr Adapter)
### Testfall 1: "Single Adapter Plan" (https://hackathon.nasarek.org/single-adapter-plan)
* Definition
** Alle Daten, die für die Query relevant sind, liegen in einem Adapter.
** Das heißt nicht, dass es nicht grundsätzlich mehrere Adapter geben kann (in einem realen System gibt es vermutlich mehrere Stores)

* Aufbau:
** Es gibt einen Adapter (Adapter 1)
** Egal ob Adapter federatable oder non-federatable

* Anfrage:
** Schickt eine Query an **genau einen** Adapter
** "Eine Nachricht an eine Person: Bringe einen Salat mit."

* Beispiel auf Server:
** Wisski Entity: Bundle/Group (= Actor) AND Wisski Entity: Actor -> Name (act_name) in example-pathbuilder (contains t)
** Ziel: Bekomme alle Personen/Actors von Adapter 1, die ein "t" enthalten, d.h. 2 Personen (Marie Müller nicht!)
** View des Beispiels wie folgt eingerichtet:

### Testfall 2: "Single Federation Plan" (https://hackathon.nasarek.org/single-federation-plan):
* Definition
** Relevante Daten liegen in > 1 untereinander föderierbaren Adaptern.

#### Testfall 2a: "Single Federation Plan (nur mit Bundles)"

* Aufbau:
** Zwei (oder mehr) Adapter (Adapter 3 und Adapter 6)
** Alle Adapter sind *federatable*

* Anfrage:
** Schickt eine Query an einen federated Adapter (und durch SERVICE strings)** an alle Repositorien in der Federation, d.h. es wird z.B. aktiv an Adapter 2 (= Chef der Federation) geschickt und Adapter 3 erhält die Nachricht dadurch implizit).
** "Eine Nachricht an den Leiter: Hey Leiter, leite die Nachricht an Deine Mitarbeiter weiter und gibst uns einen gesammelten Salat ... wir brauchen Gurken von Mitarbeiter 1 und dir, Tomaten von Mitarbeiter 2 und dir und Salat von dir." (alles Banane)

* Beispiel auf Server:
** Wisski Entity: Bundle/Group (= Person from backend 6) OR Wisski Entity: Bundle/Group (= Person from backend 3)
** Ziel: Bekomme alle Personen aus Adapter 6 UND alle Personen aus Adapter 3, d.h. 9 Personen
** View des Beispiels wie folgt eingerichtet, Pager: max. 3 Personen:
** TODO: Screenshots vom Pathbuilder

#### Testfall 2b: "Single Federation Plan" (mit Bundles und 1 Filter) (nur für Tests!)
* Version von 2, aber zusätzlich mit folgendem Filter: Wisski Entity: Person from backend 6 -> Name (name) in Pathbuilder for backend 6 (contains t)


### Testfall 3: "Partition Plan"
(zwei folgende Teilfälle (nur zum Testen für die Views! Konzeptionell kein Unterschied))

#### Testfall 3a: "Single Partition Plan (Pure)" (https://hackathon.nasarek.org/single-partition-plan-pure):
* Defintion
+ Relevante Daten liegen in > 1 NICHT untereinander föderierbaren Adaptern.

* Aufbau:
+ Zwei (oder mehr) Adapter (Adapter 2 und Adapter 5)
+ Die Adapter sind gemischt; ein Adapter ist *federatable*, ein Adapter ist *non-federatable*
+ ***wichtig***: Sie sprechen im Pathbuilder über diesselbe Ontologie und auch über EXAKT dasselbe Bundle (ID gleich)
+ innerhalb eines Blattes gehen wir davon aus, dass die Daten aus einem Adapter kommen. (Person: Namen kommen aus einem Adapter, Geburtsorte kommen aus einem Adapter.)

* Anfrage:
+ Schickt **eine** Query an zwei oder mehrere Arten von Adaptern, die untereinander nicht federated sind.
+ "Hey Mitarbeiter1, ich möchte Tomatensalat; Hey Mitarbeiter2, ich möchte Tomatensalat". Außerdem bin ich dafür verantwortlich, dass alle Tomatensalate bei mir ankommen.
+ Das heißt man muss sie alle einzeln anfragen, aber macht fragt alle **dasselbe**.

* Implementierung:
+ Wenn Adapter gemischt vorkommen (non federated und federated) und über exakt das gleiche Bundle gesprochen wird (gleiche IDs), dann führen wir einen Single Partition Plan aus

* Beispiel auf Server:
+ Wisski Entity: Bundle/Group (= Person from backend 2)
+ Ziel: Es müssen 3 Personen angezeigt werden (nämlich genau die 3 Personen aus Adapter 2 bzw. Adapter 5) und es muss ein Single Partition Plan gewählt werden, siehe screenshot:
+ View des Beispiels wie folgt eingerichtet:

#### Testfall 3b: "Single Partition Plan (Converted)" => wird abgehandelt durch Multi Partition Plan (https://hackathon.nasarek.org/single-partition-plan](https://hackathon.nasarek.org/single-partition-plan-multi)):
* Definition
+ Relevante Daten liegen in > 1 (NICHT untereinander föderierbaren) Adaptern.
* Aufbau:
+ Drei Adapter (Adapter 1 und Adapter 2 und Adapter 5)
+ Die Adapter sind gemischt; ein Adapter (A2) ist *federatable*, zwei Adapter (A1 und A5) sind *non-federatable*
+ Adapter 1 und Adpater 5 sprechen über exakt dasselbe Bundle (ID gleich) => ist aber in diesem Beispiel nicht wichtig, Bundle ID kann auch nicht gleich sein
+ innerhalb eines Blattes gehen wir davon aus, dass die Daten aus einem Adapter kommen

* Anfrage:
+ Schickt **eine** Query an zwei oder mehrere Arten von Adaptern, die untereinander nicht federated sind.
+ "Hey Mitarbeiter1, ich möchte Tomaten- oder Nudelsalat, was auch immer du kennst; Hey Mitarbeiter2, ich möchte Tomaten- oder Nudelsalat, was auch immer du kennst; Hey Mitarbeiter3, ich möchte Tomaten- oder Nudelsalat, was auch immer du kennst". Außerdem bin ich dafür verantwortlich, dass alle Tomatensalate/Nudelsalate bei mir ankommen.
+ Das heißt man muss sie alle einzeln anfragen, aber macht fragt alle **dasselbe**.

* Implementierung:
+ Wenn Adapter gemischt vorkommen (non federated und federated) und über verschiedene Bundle gesprochen wird (verschiedne in ID, semantisch kann es über das gleiche sprechen), dann konvertieren wir den Single Partition Plan in einen Multi Partition Plan

* Beispiel auf Server:
+ Wisski Entity: Bundle/Group (= Person from backend 2) OR Wisski Entity: Bundle/Group (= Actor)
+ Ziel: Es müssen 6 Personen angezeigt werden; die 3 aus Adapter 2/5 und die 3 aus Adapter 1
+ View des Beispiels wie folgt eingerichtet:

### - Multi Pläne -
(= 2 oder mehr Anfragen (an 2 oder mehr Adapter), bei denen die Ergebnisse gemerged werden müssen)
### Testfall 4: "Multi Partition Plan" (https://hackathon.nasarek.org/multi-partition-plan)
* Definition
+ Relevante Daten liegen in > 1 (NICHT untereinander föderierbaren) Adaptern.
+ Man hat verschiedene Pläne und möchte die Ergebnisse mit einem UND oder ODER zusammenführen.

* Aufbau:
+ Zwei (oder mehr) Adapter (Adapter 1 und Adapter 2)
+ Die Adapter sind gemischt; ein Adapter ist *federatable*, ein Adapter ist *non-federatable*

* Anfrage:
+ Es werden zwei Anfragen geschickt: Eine an Adapter 1 und eine an Adapter 2 (zwei komplett verschiedene Queries) und ich merge die beiden zusammen.
+ Jeder Teil wird wir ein individueller Plan behandelt und einzeln ausgeführt; am Schluss zusammen gemerged
+ Konzeptionell sind es zwei Adapterpläne und es werden diese Pläne ausgeführt und mit einem AND oder OR zusammengemerged
+ "Hey Mitarbeiter1, ich möchte Tomatensalat; Hey Mitarbeiter2, ich möchte Nudelsalat; Hey Mitarbeiter3, ich möchte Kartofflesalat". Außerdem bin ich dafür verantwortlich, dass alle Tomatensalate/Nudelsalate/Kartofflesalate bei mir ankommen.

* Beispiel auf Server:
**
** Ziel:
** View des Beispiels wie folgt eingerichtet:

Grundsätzlich kann es sein, dass in den beiden Adpater von denen jeweils in den Testfällen gesprochen wird, die Bundle die betrachtet werden, in einer Beziehungssituation stehen (z.B. Vererbung). Und dann befinden sich Entitäten in beiden Bundles.
Also eine Entität die im Bundle Person ist, ist auch im Bundle Actor, da Person eine Unterklasse von Actor ist.

## Sortieren
- Sprache wird übergeben beim Sortieren, damit abhängig von der gewählten Interfacesprache korrekt sortiert werden kann.
Beispielsweise dass "ä" im Deutschen nach "a" kommt.
- Wir bauen das sort von Anfang an ein und ziehen es überall mit durch, damit man es auch austauschen könnte
- Wir müssen das Sorting für alle 6 Fälle implementieren:
- [x] gefixt für Empty Plan
(für Single Pläne einfacher Fall, d.h. in der Query wird ein "sort" mit eingebaut)
- [x] gefixt für Single Adapter
- [x] gefixt für Single Federation
- Sortierung ist ein separater special case vom Query Plan
- [ ] gefixt für Single Partition / Multi Partition
- neuer Plan: Resort Plan (sagt grundsätzlich aus: führ den jeweils anderen Plan aus, nimm alle Ergebnisse zusammen und sortiere diese neu)
- dieser wird in einer Ebene über Multi Partition Plan und Single Partition Plan definiert; dafür gibt es einen Optimizer
- Optimizer:
- 1) anschließend wird er den MP/SP Plänen mitgegeben und diese geben sie dann jeweils an ihre Blätter (= Single Adapter Pläne) weiter
- 2) schmeißt Teile raus, die für den Plan nicht relevant sind

## Hackweek (24.04. - 26.04.2023)
### Wochenplan für Hackathon
#### Teilnehmende
Mark Fichtner, Robert Nasarek, Kai Amann, Tom Wiesing, Philipp Eisenhuth, Myriel Fichtner
#### Essen gehen am Dienstag, Inder: https://goo.gl/maps/MfHLiFx6tYRAE7iM9 um 17:30 Uhr
#### Montag, 24.04.2023

##### DONE
* Pläne vervollständigt und Testfälle zum laufen gebracht bis auf sorting
* Sorting Probleme identifiziert
+ Funktioniert nur NoAdapter, SingleAdapter
+ Single Partition, SingleFederation und MultiPartition muss noch gemacht werden.
* Array-Pläne in eigene Klassen ausgelagert. \wisski_salz\Query\{AST, AAST, Plan}
* Klassen entsprechend angepasst (ASTAnnotator, ASTBuilder, ASTOptimizer)
* Noch zu erledigen für PlanBuilder, PlanConverter, PlanOptimizer, WisskiQueryDelegator, QueryBuilder
##### Doku
* in WissKIQueryDelegator.pptx
##### Todo
* Klassen fertig stellen für PlanBuilder, Planoptimizer, WisskiQueryDelegator, PlanConverter
* Pagination in single federation plan geht nicht
* Sort Funktion bugged noch
* Laufzeitprobleme bei Sortierung von Mengen ist noch strukturelles Problem
* Adapter mit sortierten Mengen
* CodeDoku noch vervollständigen
* Termin WissKI Future (Wie soll die Entwicklung von WissKI langfristig weitergehen)
* Testfall 2b geht noch nicht => TODO: siehe buildSparqlFilterQuery() in WissKiQueryDelegator.php
* **Wird die Optimale SPARQL Query gebaut?** Keine unnötigen Klammern, Filter, Values, ASK vs. SELECT - Muss man microtimen.

Hauptziel: sort einbauen
* Im Sort haben wir zwei Kategorien (Kategorie 1):

* Field Abstraktion (wir sortieren nach einem Feld, das zu einem Bundle gehört)

* PB und Pfad Implementation (wir sortieren nach Pathbuilder.Pfad)

* unbekannt, Feld was Drupalartig ist, aber nichts mit WissKI zu tun hat => ignorieren

* Darüberhinaus wissen wir orthogonal (Kategorie 2):

* Felder, die jede WissKI Entity hat (EID, Label)

* Felder, die nur für spezifische Entities gesetzt sind, konkret für spezifische Bundles. Zum Beispiel Bundle Person, das einen Namen hat. (in den versch. PBs/Adaptern liegen)
Konkreteres Beispiel: 2 Bundles: 1 Bundle Person, 1 Bundle Institution, jeweils ein Pfad "Name"
Sortiere nach dem Feld "Personenname"; Dann kommt von Institution nichts zurueck, weil Institutionen keine Personnamen haben.

    
  

#####