Protokoll 2. Beteiligungsforum am 14.10.2022

Zoom Meeting am Freitag, 14.10.2022 von 10 bis 14 Uhr

Anwesende: Janine Thoenelt, Sören Fenner, Patrick Krüger, Judith Brückmann, Angelika von Ammon, Livia Rutishauser, Rainer Glaap, Beat Estermann, Natalie Fingerhut, Melanie Gruß, Margret Schild, Patrick Primavesi, Andreas Lübbers, Claudia Marks, Ann-Sophie Garthe, Henning Fülle, Caroline Helm

1 Begrüßung und Rückblick der bisherigen Schritte durch Janine Thoenelt

Sammlung bisheriger Protokolle und weitere Informationen unter: https://theapolis-support.de/projekt-inszenierungsdatenbank/ 

2 Konzeptionsaspekte der Produktionsdatenbank, Sören Fenner

Sören Fenner stellt sechs Aspekte vor, die die Grundlage für das Datenmodell und die Software-Entwicklung darstellen.

1) FAIR-Prinzipien – Findable, Accessable, Interoperable, Reusable

Das Konzept der geschlossenen Datensilos ist zunehmend veraltet, weil Daten aus Datensilos häufig inkompatibel sind. Sie verlangsamen Prozesse, sind intransparent und verschwenden Ressourcen. Außerdem ist die Datenqualität in Datensilos oft schlechter als in Datenaustausch-Systemen.

Wir entwickeln daher die Produktionsdatenbank nach den FAIR-Prinzipien und machen alle Daten auffindbar, zugänglich, interoperabel. Wir planen also von vornherein den Datenaustausch mit anderen Datenbanken und Plattformen ein. Dieser Datenaustausch erfolgt über Schnittstellen, APIs (Application Programming Interfaces). Über diese Schnittstellen kann Plattform A die Daten der Plattform B verwenden – wenn diese es Plattform A erlaubt hat. Über diese APIs können später Produktions-Daten mit Wikidata und der Deutschen Nationalbibliothek ausgetauscht werden. Aber auch mit z.B. mit Spectyou, nachtkritik, Dispositions-Software, Veranstaltungskalendern, Gastspielmärkten, Ticketing-Systemen, usw. Unsere Datenbank ist also konzeptionell so angelegt, dass sie von anderen Datenbanken mit-benutzt werden kann und gleichzeitig auch die Daten externer Datenbanken (z.B. der DNB und von Wikidata) mit verwendet.

Außerdem verwenden wir bei der Bezeichnung der Daten die internationalen Standards. Das ist eine weitere Grundvoraussetzung dafür, dass andere Datenbanken die bei uns gespeicherten Informationen problemlos auslesen und übernehmen können.

2) Unterschied Inszenierung – Produktion

Veraltete Definitionen erkennen „Inszenierung“ oft nicht als eigenständiges, künstlerisches Werk an, sondern als Werk, welches auf Basis eines Originals stattfinden und somit in der künstlerischen Wertigkeit hierarchisch “unter” diesem Original steht. 

Bei den Produktionen der Freien Darstellenden Künste handelt es sich in erster Linie um eigenständige Künstlerische Werke. Diese sind zwar auch oft von anderen Künstlerischen Werken (z.B. Kompositionen und Texten) inspiriert oder basieren vielleicht sogar auf ihnen. Dennoch kann von einer „Inszenierung“ im Sinne der veralteten Definition nicht mehr die Rede sein. Daher wurde sich dazu entschieden, nicht mehr das Wort “Inszenierung”, sondern den in der Szene üblichen Begriff der „Produktion” zu verwenden sowie die “Produktion” im Datenmodell als ein vollständig autonomes Künstlerisches Werk zu behandeln.

Für die Konzeption der Datenbank heißt das, dass die Eingabe einer Produktion keine Angabe zum “Originalwerk” erzwingt. Natürlich kann eine Produktion ein oder mehrere Werke haben, auf denen sie basiert oder von denen sie inspiriert wurde. Die “Bindungstiefe” zum relationierten Werk kann man später ebenfalls definieren, und zwar mit den Begriffen “von” (“based on” – starke Bindungstiefe) und “frei nach” (“inspired by” – geringe Bindungstiefe).

3) Trennung Künstlerisches Werk (Creative Work) – Vorstellungen (Events)

Die Art der Durchführung von Vorstellungen unterscheidet sich von Produktion zu Produktion teilweise maximal voneinander. Auch die Besetzung wechselt in vielen Fällen. Aus diesem Grund werden im Rahmen der Datenbank die Produktionen von den Vorstellungen getrennt. Die Vorstellungen können später anderweitig mit einer App hinzugefügt werden. Die einzigen Ausnahmen bilden hierbei das Premierendatum und der Premieren-Spielort, damit die Produktion später besser identifiziert werden kann.

4) Konzentration auf das Wesentliche, Vorbereitung für Apps

Es soll sich auf einen Minimal-Datensatz beschränkt werden, der allerdings so angelegt ist, dass eine definitive Zuordnung erfolgen kann.

Jeder Eintrag erhält einen Unique Identifier, der von allen dazu verwendet werden kann, Informationen zu einer Produktion zuzuordnen. Im besten Fall können dann Kritiken, Videos, Fotos, Förderunterlagen, Statistiken, Vorstellungs- und Besetzungslisten, Technical Riders, usw. alle automatisiert der Produktion zugeordnet werden, weil alle diese Informationen mit dem jeweiligen Unique Identifier gekennzeichnet sind – und die Portale über APIs miteinander verbunden sind.

5) Relevanz und Geschäftsmodell

Wikidata und auch die Deutsche Nationalbibliothek nehmen nur Informationen an, die bestimmten Relevanz-Kriterien entsprechen (siehe: https://www.wikidata.org/wiki/Wikidata:Notability/de) Ein Relevanz-Merkmal für eine Theater-Produktion ist z.B. die Durchführung einer Premiere an einem Aufführungsort, der von Wikidata oder der DNB ebenfalls als “relevant” definiert wurde. Eine Produktion kann folglich dort nicht gespeichert werden, wenn es noch keine Premiere gab.

In der Produktionsdatenbank sollen hingegen auch vage Produktions-Ideen mit aufgenommen werden, auch wenn noch keine „Relevanz“ oder ein fester Premierenort existieren.

Anreize für Theaterschaffende ihre Produktionsdaten in die Datenbank einzutragen können somit sein:

  • mehr Aufmerksamkeit im Vorfeld der Premiere,
  • stärkere Sichtbarkeit in den Medien
  • mehr Ticketverkauf,
  • eventuell zusätzliche Gastspiele.
  • mehr Vorstellungen und mehr Publikum

6) Dialog-Konzept

Das Projekt Produktionsdatenbank steht und fällt mit der Akzeptanz der Theaterschaffenden. Wenn sie nicht bereit sind bzw. keinen Grund dafür sehen, in Zukunft ihre Produktions-Kerndaten in die Produktionsdatenbank einzutragen, dann ist sie nur eine leere Hülle.

Um das zu ermöglichen, muss die Möglichkeit bestehen, die Daten nach-und-nach einzutragen. Also müssen sich die Nutzer*innen einloggen können, um ihre Daten zu pflegen. Das wiederum ermöglicht zwei Dinge:

  • Weitere Bearbeiter*innen hinzufügen 
  • Mit den Daten-Einträger*innen in einen Dialog zu treten.

Durch automatisierte Push-Notifications an Nutzer*innen sowie ein regelmäßiges Erinnern an die Wichtigkeit der Daten in der Produktionsdatenbank, kann eine höhere Datenqualität erreicht werden. Die Reminder bieten außerdem die Möglichkeit, kleine Nutzungs-Infos und Hilfestellungen zu integrieren. 

Zusammengefasst

  • FAIR-Prinzipien, um Dialogfähigkeit und Wissenstransfer zu ermöglichen
  • die Produktion als eigenständiges Künstlerisches Werk (Trennung von Werk und Produktion)
  • die Produktion in Abgrenzung zu ihren Vorstellungen (Trennung Produktion und Vorstellungen)
  • jetzt nur Kerndaten mit Unique Identifier – und später dann darauf aufbauende Apps
  • Speicherung der Produktionen VOR der Relevanz als Geschäftsmodell, um möglichst sinnvolle sofortige Anwendungen zu ermöglichen
  • Dialogisches Kommunikationsmodell mit den Einträger*innen, um die Datenqualität zu sichern

Nachfrage Patrick Primavesi: Fachterminologie, Theateröffentlichkeit und Journalismus sehen den Begriff der „Inszenierung“ schon lang nicht mehr so eng wie eingangs erwähnt. Es hat sich durchgesetzt, dass damit ein weiteres Feld beschreibt wird (ähnlich wie mit dem Begriff der Choreografie) —> Appel: nicht mit traditionellem Verständnis argumentieren, aber Begriff der Inszenierung nicht gleich zerschlagen, ist oft Identifikationsmerkmal! Zudem: Institution und Körperschaft ist wichtige Größe bei der Erfassung von Produktionsdaten, genauso wichtig sind Geostandorte

3 Vorstellung der technischen Umsetzung durch Patrick Krüger (Link zur kompletten Präsentation)

1) Vorstellung des Ist-Standes 

  • Erste Datengrundlage der Datenbank sind Einträge bei Theapolis —> schwierige Übernahme der Daten, da organisch gewachsenes Projekt aus den letzten Jahren 
  • Abfrage der Informationen zu Produktionen lief bisher über: Titel, zugeordnete Organisation, Jahr, Künstlerische Leitung. Keine Werkzugehörigkeit!  
  • Fast 90.000 Produktionen bei Theapolis verzeichnet, davon fast 7.000 Produktionen aus der freien Szene in Produktionsdatenbank eingepflegt

2) Datenaufbereitung 

  • Personen (50% Übereinstimmung) und Organisationen (hier große Diskrepanz) genau angeschaut – v.a. auf Dubletten geprüft und Matching mit Wikidata und GND 
  • Produktionstitel bereinigt + ebenfalls Matching durchgeführt 
  • Ziel: Zuordnung von eindeutigen Identifiern 
  • dabei wurden im Sinne der Nachvollziehbarkeit keine Daten überschrieben

3) Datenmodell —> schema.org als Grundlage  

  • Schema.org als vereinfachter Teilbereich, weitere Felddefinitionen aus Wikidata übernommen —> andocken an performing arts production, dance production, theatrical production etc. 
  • Produktionsdatenbank hat spezifische Anforderungen: verschiedene Stati von Produktionen, Prozesskriterien offen halten, Dublikatsverweise, externe Identifier für Fremdsysteme  
  • Produktion im Mittelpunkt, kann sich auf Werk beziehen, Personen lassen sich in bestimmten Verhältnissen zuordnen, genau wie Organisationen 
  • Werk und Produktion ist gleicher Datentyp —> daher auch Zuordnung zu Person möglich
  • jeder Datensatz im System bekommt zwei eindeutige Identifier (Wikidata Q Identifier und GND ID;  teilweise nicht deckungsgleich, daher Arbeit mit beiden Quellen) 
  • Mehrere Identifier über externe Systeme —> hier können und werden Duplikate vorkommen, für spätere Einträge aber Look-Up Prozess im Hintergrund, die auf bereits definierten Datensatz verweisen bei Neueintragung
  • Persistente Identifier für alle Entitäten —> keine Löschung, sondern Verweis auf neue Zuordnung, denn wenn es zwei gleiche Datensätze gibt, führt die Löschung des einen zum Verlust der Zuordnung richtiger verknüpfter Daten 

Beat Estermann im Chat: “Mergen” ist kein Problem. “Splitten” von Einträgen ist schwieriger…

 

  • Rückrichtung zu Wikidata: momentan noch keine Idee, vielleicht über Property, muss man beobachten und eventuell später Ketten erstellen 
  • Splitten: ein Datensatz kann nie zwei Wikidata Q oder GND Identifier haben, aber Dubletten können auftreten —> Kette durchlaufen: Zuordnung über Theapolis oder Berlin Bühnen Identifier möglich? Erst am Ende Personen Matching 

4) technische Grundlagen der Datenbank 

  • 1. Iteration: Datenmodell mit 4 Entitäten umgesetzt, Eingabeformulare angelegt, Detailansichten möglich, Übersicht der Produktionen mit Suche und Filter Möglichkeiten  
  • JSON:API sorgt für maschinenlesbare Entitäten 
  • Produktionsdatenbank als Tool, auf die weitere Apps zugreifen können 
  • API unterstützt das Erstellen, Updaten und Löschen von Daten 
  • Migration der Theapolis Daten: mitgelieferte JSON:API genutzt, um im Verlauf des Migrationsprozesses zu schauen, ob das für unsere Zwecke reicht; hat man mit JSON:API alle Möglichkeiten? – Nein
  • Deshalb nochmal neue Middleware (Übersetzung) aufgesetzt, können mit kompakterem Datensatz arbeiten
  • Viele notwendige Look Ups zur Vermeidung von Dubletten laufen so im Hintergrund (wichtig auch in Hinblick auf Anbindung an Drittsysteme)
  • Resultat: Gesamtbestand der übereinstimmenden Daten wurde übernommen (Migration Stand heute, siehe Beginn) 

5) Kontinuierliche Migration

  • Produktionen, die weiter auf Theapolis gepflegt werden oder neu eingetragen werden, sollen in Datenbank einfließen bzw. auch dort aktualisiert werden, wird gerade auch für Berlin Bühnen durchgeführt —> stetiger Abgleich mit Wikidata und GND 
  • kontinuierliche Anfrage für in Datenbank geführten Personen, um Daten zu vervollständigen —> damit auch kontinuierliche Arbeit an Datenqualität 
  • manuelle Nachbearbeitung durch Redaktion so gering wie möglich halten 

6) To Do

  • User*innen Interface
  • Aktuell: Drupal Interface —> muss noch angepasst werden für einfache, intuitive Eingabemaske 
  • Menge der auszufüllenden Felder in Abhängigkeit von bestimmten Faktoren —> Einstiegshürde nehmen, Daten einzutragen 
  • Weitere Mitarbeitende einladen an *meiner* Produktion mitzuarbeiten 
  • Dialog durch Push Benachrichtigungen, kontinuierliche Erinnerungen anhand bestimmter Zeit-Marker und Stati der eingetragenen Produktion

 

– PAUSE –

 

4 Einblick in die Datenbank 

—> Hinweis auf Arbeitsstand, Drupal Oberfläche, Beschreibende Texte sind noch nicht fertig etc.
—> Es werden verschiedene Usecases dargestellt 

  • Migration von Daten als beliebig wiederholbarer Prozess
  • Erklärung und Demonstration der verschiedenen Suchfelder und Filtermöglichkeiten  
  • Bsp. „Künstlerische Leitung“ als einschränkende Suche (Filter) —> Wie viele Treffer/Einträge habe ich zu der gesuchten Person, Top-Anzeigen mit am meisten eingetragenen Positionen werden als erstes ausgegeben 
  • Mehrstufige Suchanfragen möglich (Person, Werk, Spielort, Jahr)
  • autocomplete Suche (vervollständigende Suchanfrage bei Freitexteingabe) 

Beat Estermann: Ist hier auch angedacht, eine Unterscheidung zu machen zwischen “based on” und “inspired by”, wie vorhin erwähnt?

Patrick Krüger: Ist angedacht, aber noch nicht umgesetzt, das Matching dazu kommt in nächster Runde; hier geht es vor allem um eingangs erwähnte „Bindungstiefe des Werkes“, eventuell auch noch eine dritte Variante hinzufügen („influenced by”) —>  Frage: Wo liegen dabei die Unterscheidungen, evtl. hier in Forum besprechen? 

Sören Fenner: „von“ (Faust von Goethe), „nach“ (Zauberberg nach Thomas Mann, da kein Bühnenstück, aber inszeniert) und „frei nach“ (läuft bei schema.org als „inspired by“,Gretchen und der Liebe Gott frei nach Goethes Faust) 

Patrick Primavesi: Die Unterscheidung der Bindungstiefe bei Theapolis und deren Übersetzung in die Datenbank ist okay, aber es gibt noch viele Fälle mehr: Produktion basiert auf einem Film oder es handelt sich um eine bereits existierende Bühnenproduktion, die nachgestellt wird (Re-Inszenierung/Wiederaufnahme) —> ist trotzdem neue Produktion, kommt häufig im Ballett vor und muss bedacht werden! Außerdem: Feld „Production Company” trennt nicht scharf genug zwischen Company (Ensemble) und produzierender Institution

Sören Fenner: An diesen Stellen zeigen sich die Unzulänglichkeiten der Theapolis Datenbank, die aber aufgearbeitet werden. Weitere Frage: Kann eine Gruppe ein Creator sein? Oder müssen das Einzelpersonen sein? 

Henning Fülle: Beispiel „She She Pop“ —> Produzent*innen, die ähnliche Funktion wie Producer beim Film haben, sind im Theater eigene Organisation. Gerade in der Freien Szene spielt diese Arbeitsteilung eine große Rolle und muss bedacht werden 

Sören Fenner: Solche Informationen würde man wahrscheinlich den Kerndaten zuordnen + weiterer Aspekt: Proben-Orte unterscheiden sich von Aufführungsorten —> Wo nimmt man Proben-Orte auf? Wo wurde Stück entwickelt etc.? 

Janine Thoenelt: Bezug zum Film wurde bei der Integration der Daten mitbedacht, gibt bereits Daten, die als Werkbezug einen Film haben. Kann ich mich bei Eingabe bereits darauf beziehen? 

Patrick Krüger: Werk als Minimaldatendatz mit sämtlichen Formen von Creative Works + Instanzierung ist möglich, aber noch nicht vollständig —> Bezug kann anhand von Eingaben (bzw. durch Import von Daten) bei Wikidata und GND eingegeben werden 

Patrick Primavesi: Rekonstruktionen dürfen nicht reduziert werden und müssen auch als eigenständiges künstlerisches Werk anerkannt werden! Außerdem: Premierendatum bisher nur als Jahr bei Theapolis angegeben, es braucht aber genaues Kalenderdatum + Ort als Institution und entsprechende Geodaten müssen für eindeutige Referenzierbarkeit ebenfalls einwandern

Sören Fenner: Wir brauchen „Produzenten App“: wir verlinken Produzent*innen und weitere Informationen im Nachhinein als externe Links, bzw. bitten Produzent*innen um Eintragung —> Kerndaten nicht überfrachten! 

Patrick Primavesi: Die Flexibilität, wichtige Informationen mit Apps nachträglich hinzuzufügen, ist sinnvoll (auch Infos zu Förderern, Festivals, Koproduktionsmodellen, etc.)

Rainer Glaap im Chat: Externe Links a la IMDB – Rezensionen … nachtkritik, theater heute etc.pp hinzufügen 

Rainer Glaap: Wie geht ihr mit Mehrsprachigkeit um? Der Originaltitel wäre of hilfreich, z.B. “August Osage County” ist in Deutschland so nicht bekannt. In deutschen Theater lief das lange unter “Eine Familie“. Wer den Film kannte, konnte erstmal keinen Bezug herstellen.

Patrick Krüger: Mehrsprachigkeit ist bedacht. Für erste Synchro wurde Deutsch mit Englischem Fallback gewählt, eigentliche Produktionstitel in Originalsprache wären zu überlegen —> für Werke lässt sich das einfach realisieren, wenn vorher im Englischen Interface eine Übersetzung angeben wurde

Henning Fülle: Frage nach Darstellung historischer Zusammenhänge: HAU gibt es erst seit 2001, ging aus verschiedenen Institutionen hervor, genauso Berliner Ensemble. Wie geht man mit solchen Namensänderungen und Fusionen um? 

Sören Fenner: Im Datensilo von Theapolis gibt es folgende Lösung: Status der historischen Institution als „geschlossen“ (nicht mehr aktiv, keine Produktionen eintragbar); GND ist aber mit Herstellung von Bezügen noch besser ausgestattet —> GND hilft bei Organisations-ID 

Patrick Krüger: Lösung: Wikidata Pfad nachvollziehen + intelligentes Mapping anwenden

Patrick Primavesi: AG Performing Arts bei GND —> Es wird gerade angefangen, solche Detailinformationen, die spezifisches Fachwissen voraussetzen, für Datensätze einzugeben und nachzuvollziehen. Schlägt enge Zusammenarbeit mit der AG vor; unterschiedliche fachliche Stakeholder müssen einbezogen werden 

Sören Fenner: Interessierte aus diesem Kreis sollen sich bei ihm oder Janine melden, damit an PP und MG weitergeleitet werden kann

 

Es folgt eine Demonstration der Arbeit mit den Suchfiltern und Suchleisten.

  • bei Werken und Personen „also known as“ Feld, um unterschiedliche Schreibweisen abzufangen und Datensätze trotzdem auffindbar zu machen 
  • Aktuelle Eingabemaske für Produktionen ist auf einer Seite zusammengefasst, soll aber in Zukunft als Fluss konzipiert werden, um die Eingabe in übersichtliche Stücke aufzuteilen 
  • Tags können Querverbindungen herstellen —> die Bezeichnungen, die am häufigsten eingeben werden, werden automatisch vorgeschlagen; kann auch in eigener Taxonomie erfolgen 

Beat Estermann im Chat: Bei der Verschlagwortung könnte man auch auf Wikidata verlinken. Hier ein Beispiel für Verschlagwortung mit direkter Verlinkung auf Wikidata (inhaltliche Verschlagwortung von Fotografien): https://isa-dev.toolforge.org/campaigns/8/participate 

 

  • Auswahlliste „basiert auf“ bei Produktionen: am häufigsten verwendete Werke kommen ganz oben, wenn das entsprechende Werk nicht gefunden wird gibt es zwei Eskalationsstufen: 1) auf Wikidata und GND nachschauen + importieren 2) Basisinformationen des neuen Werkes anlegen und durch Redaktionsteam auf Richtigkeit prüfen lassen
  • Feld „Basierend auf“ umfasst nur Werke, keine angelegten Produktionen, weil es sonst sehr unübersichtlich wäre —> das muss noch angepasst werden, ist aber gerade noch zu spezifisch

Sören Fenner: Wir brauchen einen gesonderten Termin für spezifische Fragestellungen zur Eingabemaske!

Janine Thoenelt: Hinweis: Es geht uns nicht um Theapolis Daten, ist aber aktuell der beste Kontakt und die größte Menge zur Einspeisung; Arbeit mit Daten von Berlin Bühnen parallel auch am anlaufen 

Sören Fenner: Ist bei den Kerndaten der Personen eine Aufteilung in Künstlerische Leitung / Musikalische Leitung / Choreografie sinnvoll, oder einfach Person eintragen und freie Eingabe für Berufs- und Rollenbezeichnung? Personen lassen sich ungern in Schubladen packen, jede künstlerische Leitung ist anders formuliert —> Ist eine solche vorgefertigte Eingabemaske einschränkend? 

Andreas Lübbers: Wie flexibel ist dieser Weg? Kann man das im Verlauf noch abändern? 

Rainer Glaap: Künstlerische Leitung – sind da mehrere Personen eintragbar? – Antwort: Ja // Großer Zuspruch zu Tags mit Freitext und vorgefertigte Genres 

Margret Schild: Nie endgültige Lösung, muss immer nach Daten gehen, mit denen man arbeitet —> ist beides gleichzeitig möglich – Personen mit vorgefertigten Positionen + Freitextfeld? Es muss Redaktions-Workflow geben, welche Begriffe in vorgefertigte Maske mit rein genommen werden; zu spezifische Beschreibungen sind an der Stelle nicht zielführend für Nutzer*innen, aber wichtig als Alleinstellungsmerkmal für Künstler*innen —> Mittelweg finden 

Patrick Primavesi: stimmt Margret Schild zu. Es gibt eine Gruppe, die sich mit genau diesem Problem der Berufsbezeichnungen befasst; wird gerade in GND Performing Arts Gruppe überführt um weiter daran zu arbeiten —> generell: sehr unübersichtliches, veränderliches Feld (nicht jeder der ein Bühnenbild gemacht hat, ist Bühnenbildner! Semantische Verknüpfungen beachten!); gibt tradierte Begriffe, die man durchaus anbieten kann (Regie, Choreografie, etc.). Auch hier muss eine eindeutige Referenzierbarkeit gegeben sein! Mischung aus Angebot + Freitextfeld vorgeschlagen 

Andreas Lübbers: schließt sich an, Erfassung der Daten in Layers denken (einheitliche Grunderfassung mit Möglichkeit zur Spezifizierung) – muss aber auch immer Nutzer*innenfreundlich sein! 

Patrick Krüger: Personen können sich verwirklichen, aber kontinuierlicher Import von Daten erfolgt auch über Muster und „Schubladen“; braucht man dafür auch, sonst wird es unübersichtlich 

 

Weitere Eingabefelder werden erklärt und getestet. Die aus Theapolis importierten Daten werden automatisch in die Datenmaske eingefüllt und können später komplettiert werden. So läuft es auch bei Importen aus anderen Datenbanken. 

 

Andreas Lübbers: Irritation bei den Künstlern, wenn man keine Benachrichtigung bekommt, ob Daten nach Speicherung tatsächlich eingegangen sind. Rückmeldung macht Sinn alá „Vorgang ist abgeschlossen, Daten sind bei uns“

Janine Thoenelt: Benachrichtigung ist an vielen Stellen geplant, Push-Benachrichtigungen sollen User*innen animieren kontinuierlich an Datensätzen weiterzuarbeiten 

Sören Fenner: Frontend soll personalisiert sein „Hallo, Andreas“, „Hier kannst du deine eingegebenen Produktionen ansehen“, sehr dialogisch gestalten.

 

– PAUSE – 

 

5 Ausblick/ Zukunftsperspektive durch Andreas Lübbers 

  • Genossenschaften als Kapitalgesellschaftsform ist sehr attraktiv —> Empfehlung
  • User*innenfreundliche Bedienung der Eingabemaske als zentrales, zukunftsfähiges Element
  • Wir sprechen große Zahl an Personen mit dem Projekt an 
  • Genossenschaftsmitgliedschaft ermöglicht starke User*innenbindung an Plattform 
  • Schlägt folgende Kategorisierung vor: 1) Institutionelle Mitglieder 2) gewerbliche Mitglieder 3) Presse- und Öffentlichkeitsmitglieder 4) Fördermitglieder —> unterschiedliche Genossenschaftsanteile und Monatsbeiträge für unterschiedliche Nutzungsmodelle der Datenbank in Satzung festlegen
  • Freie Einzelkünstler*innen wären Hauptzielgruppe der Ansprache —> grundsätzlich keine verpflichtende Mitgliedschaft in Genossenschaft, aber Einladung Mitglied zu werden (niedrigschwelliger Beitrittsbetrag) 
  • Konkreter Wirtschaftsplan muss ausgearbeitet werden, um Zahlen festzulegen 
  • Um gut arbeiten zu können, muss Genossenschaft „Eintrittsgeld“ verlangen können (wird nicht zurückgezahlt), Genossenschaftsanteile bleibt über gesamte Zeit im Eigentum des Zahlenden (kündbar und wieder auszahlbar bei Austritt) 
  • Vorschlag: In der Eingabemaske folgt nach erfolgreicher Registrierung eine Aufforderung zum Eintritt in die Genossenschaft, aber immer auch Skip-Button
  • Einzelkünstler*innen hätten als Genossen folgende Vorteile: 
    • Verifizierung der Eingaben wird durch Genossenschaft garantiert: Eingaben werden als verifiziert gekennzeichnet (deutliche Abhebung ggü. Nichtmitgliedern!), Nicht-Mitglieder können natürlich auch eintragen, aber ohne Label („ohne Gewähr“) 
    • Vergütung: Eingaben für alle und grundsätzlich kostenlos; aber Genossen Angebot der Vergütung machen. Bsp. Januar und Februar als „langsame Monate“, in denen nicht viel passiert —> Angebot, dass wir Daten vergüten, die sie in dieser Zeit eingeben (Aufwandsentschädigung), muss auch nicht an bestimmte Zeiten gebunden sein; muss mit Wirtschaftsplan erarbeitet werden 
  • Ziel: umfassende Zahl an Nutzer*innen generieren und Anreize für Eingabe schaffen 

Sören Fenner: Frage nach Aufsichtsrat? 

Andreas Lübbers: Genossenschaftsgesetzes sieht Wahl eines Aufsichtsrates aus Mitte der Generalversammlung vor

Sören Fenner: Aussicht, wie viele Produktionen im Jahr kommen können? Wie viele Neuproduktionen gibt es in den Freien Darstellenden Künsten im Jahr ca.? —> Weiß keiner, Anhaltspunkt sind 20.000 Werke in Werkstatistik pro Jahr, wird in den Freien Künsten sicherlich geringer ausfallen 

Sören Fenner: Zusammenfassung: verschiedene Arten der Mitglieder, Vergütung über Nutzung, Förderung als fest eingeplantes Modul —> Infos zu Gründung? Zeitlicher Ablauf?

Andreas Lübbers: Genossenschaftsgesetz spielt sich auf pandemische Lagen ein – Gründungsversammlung via Zoom wäre möglich, aber auch gern persönlich. Satzungserstellung ist in den nächsten Wochen möglich, dann Kontakt zur Satzungssichtung und Prüfverband —> könnten Anfang Dezember in eine Gründungssitzung gehen; Es bedarf 3 Genossen zur Gründung einer Genossenschaft 

Sören Fenner: schlägt hybride Veranstaltung zur Gründung vor, damit alle Interessierten teilnehmen können. Go für Satzungserstellung von Sören Fenner und Janine Thoenelt. Sobald Satzungsentwürfe fertig sind, werden sie per Mail geteilt.

Sören Fenner: Hinweis: möchten neue Produktionsdatenbank von Theapolis ablösen, daher war Frage welches Betreibermodell sinnvoll ist, um den Outcome weiter für Theapolis nutzbar zu machen, ohne es gleichzeitig leiten und führen zu müssen, essenziell

Patrick Primavesi: Argument der Öffentlichen Relevanz ist Förderungskriterium, steht die Gründung einer Genossenschaft dem im Weg?

Andreas Lübbers: Nein, schließt sich nicht aus. Genossenschaft muss sich kontrollieren lassen (Verwendungsnachweise) und sich als seriöse und verifizierbare Instanz glaubwürdig machen + Genossenschaft braucht einen Namen, der sich gut verkaufen lässt —> Vorschläge gern an Andreas Lübbers senden

 

Hinweis Sören Fenner: Es wurden zwei neue weitere Förderanträge für Projekt gestellt 1) Fonds Darstellende Künste 2) GVL (Gesellschaft zur Verwertung von Leistungsschutzrechten)

 

Patrick Primavesi: Zusammenarbeit mit „Performing the Archive“, wie eng ist Kooperation angedacht? 

Sören Fenner: Eigentlich sehr eng, hängen momentan in der Luft, da “Performing the Archive” sich mit einem hauptamtlichen Team konstituiert, sind aber in Austausch – Produktionsdatenbank wurde von Anfang an im Dialog konzipiert 

 

Zusammenfassung:

Fokus dieses Jahr: Herstellung der Datenbank und Gründung der Genossenschaft

Fokus nächstes Jahr: Konsolidierung, Vernetzung mit Partner*innen, Kommunikation mit potenziellen Nutzer*innen (Verbesserung und Kommunikation)

 

6 Abschließende Feedbackrunde

Andreas Lübbers: spricht seinen Dank aus, sieht großes Potenzial, Appell: Nicht in Details verheddern! Keinen „akademisierten Dschungel“ aufbauen!

Livia Rutishauser: Danke für Aktivismus!

Sören Fenner: Wo sollten wir genauer hingucken oder langsamer Arbeiten? 

Livia Rutishauser: Datenbank macht sehr guten Eindruck; Kategorisierung von Genres und Hierarchisierung von Mitarbeitendenpositionen sind evtl. zu überdenken —> ist das fördernd oder hinderlich? 

Andreas Lübbers:  Was ist mit Datenschutz? Konzept zum Umgang? Anreiz zur Veröffentlichung? 

Sören Fenner: Solange kein urheberrechtlich geschütztes Material verwendet und gespeichert wird, ist das kein Problem (Bilder, Videos, etc.) —> genutzte Daten sind beruflich, nichts privates; keine persönlichen Daten. Es geht um Kommunikation eines künstlerischen Angebots —> Vertrauen aufbauen und vermitteln dass die Eingabe der Daten den Geber*innen was nützt und nicht schadet

Patrick Primavesi: Verhältnis der spezifischen Informationen und der notwendigen Kerninformationen zur eindeutigen Referenzierbarkeit immer im Auge behalten; pure Pragmatik führt zum Datensilo —> immer über Tellerrand schauen; Feinjustierung der Eingabefelder gründlich prüfen und mit Menschen aus Praxis abgleichen; sinnvolle Organisation ist notwendig

Patrick Krüger: Die Einspeisung der Daten aus Berlin Bühnen liefert weitere große Masse an Daten, je mehr Datengeber*innen dazu kommen, desto mehr Aushandlungsprozesse bedarf es – desto mehr erhöht sich aber auch die Datenqualität

Sören Fenner: Punkt für nächstes Jahr: Wenn Datenbank fertig ist, Häuser bitten, Premierendaten, die eventuell noch nicht genau sind, nachzutragen (Jahr mit Tag und Monat vervollständigen) 

Beat Estermann: Gutes Gefühl, sind gut auf Kurs

 

„Spread the Word“ – Sören Fenner bittet die Teilnehmende um Kommunikation und Verbreitung des Projektes. Wenn es um die Einspeisung vieler neuer Daten geht, ist das Projekt auf Hilfe und Expertise angewiesen.

Ein weiteres Beteiligungsforum ist in der Planung, genau wie ein Treffen zur Genossenschaftsgründung. Sobald die Termine feststehen, werden sie per Mail mitgeteilt. 

 

Dieses Projekt wird gefördert vom Fonds Darstellende Künste aus Mitteln der Beauftragten der Bundesregierung für Kultur und Medien im Rahmen von NEUSTART KULTUR.

classic-editor-remember:
classic-editor

Hier geht’s zurück zu Theapolis:

Theapolis

Log in or Sign Up