Beleg zu Daten & Prozesse
Make gegen Zapier, an einer echten Strecke
Wer Daten automatisch füllen lassen will, steht vor zwei Fragen: Welches Werkzeug? Und was passiert, wenn die Quelle nichts hergibt? Beantwortet wird das meist mit einer Produktseite. Hier sind beide Wege gebaut und einer davon viermal gelaufen, aufgezeichnet – samt dem Lauf, der auf einen erfundenen Pflanzennamen keinen Datensatz zurückgab, sondern einen Fehler.
Ein Pflanzenname geht hinein, ein gefüllter Datensatz kommt heraus. Das Datenmodell steht: 31 Felder, überwiegend mit kontrolliertem Vokabular. Für den Weg dahin gibt es zwei Artefakte – eine Make- und eine Zapier-Strecke –, und die Zapier-Strecke ist am 3. September 2026 viermal gelaufen: einmal normal, einmal mit derselben Pflanze von der anderen Seite, einmal mit einem erfundenen Namen und einmal mit einer Hybride. Diese Seite zeigt, was dabei herauskam – auch dort, wo es unbequem ist.
Wer Pflanzen für eine Fläche auswählt, braucht dieselben Angaben immer wieder: Standort, Bodenfeuchte, Wuchshöhe, Winterhärte, Schnittzeit. Diese Angaben stehen verstreut in Katalogen, Lexikonartikeln und Erfahrungswissen. Sie einmal in eine Struktur zu bringen, ist die eigentliche Arbeit – und der Punkt, an dem sich entscheidet, ob eine Sammlung später auswertbar ist oder nur voll.
Deshalb liegt der Aufwand hier im Datenmodell und nicht in der
Automation. 31 Felder, davon 24 mit kontrolliertem Vokabular: Wer
Lichtbedarf ausfüllt, wählt aus einer Liste und tippt
nicht frei. Das macht die Datenbank filterbar – „alle Halbsträucher
für trockene, sonnige Standorte" ist eine Abfrage und keine
Textsuche.
Die Automation soll den mühsamen Teil übernehmen: Ein Pflanzenname wird eingetragen, ein Sprachmodell schlägt die Feldwerte vor, die Vorschläge landen im Datensatz. Das Sprachmodell ist dabei Zulieferer, nicht Quelle. Genau darin liegt der offene Punkt dieses Belegs – siehe unten.
Was hier belegt ist – und was nicht
- Belegt: das Datenmodell, sein kontrolliertes Vokabular, der Aufbau beider Automationsstrecken und der Zustand des Datenbestands.
- Belegt seit 03.09.2026: dass die Zapier-Strecke läuft. Vier aufgezeichnete Läufe, Schritt für Schritt protokolliert, mit Tokenverbrauch – hier nachzusehen.
- Weiterhin nicht belegt: dass die Make-Strecke läuft. Sie wurde im Oktober/November 2025 zugunsten von Zapier abgebrochen und ist nachprüfbar auf dem Stand der unveränderten Vorlage.
- Nicht belegt: dass die Angaben botanisch stimmen. Die Strecke prüft die Form jedes Wertes, nicht seinen Wahrheitsgehalt.
- Nicht belegt: Berufserfahrung mit Make, Zapier oder Notion. Das hier ist ein eigenes Werkzeug für eigene Zwecke.
Es sind meine eigenen Daten, keine Kundendaten. Trotzdem stehen hier Struktur und Füllgrade, nicht die vollständigen Inhalte.
Was im Datenmodell steht
- 31 Felder · 24 mit kontrolliertem Vokabular
- 9 Datensätze im Export, davon 3 nahezu vollständig
- 2 Felder in keinem Datensatz gefüllt
- 5 von 9 Datensätzen mit Quellenlink
- Kein Feld für Prüfstatus – der offene Punkt
- Make: 3 Module · Zapier: 7 Schritte
- 4 aufgezeichnete Läufe · 3 durchgelaufen, 1 abgebrochen
- 0 Werte außerhalb des Vokabulars geschrieben
Das Datenmodell
Notion kennt Feldtypen, und die Wahl des Typs ist die Festlegung: Auswahl lässt genau einen Wert aus einer Liste zu, Mehrfachauswahl mehrere, Text alles. Je mehr Felder einen Typ mit Liste haben, desto auswertbarer wird die Sammlung – und desto mehr Nachdenken kostet sie beim Anlegen.
| Feldgruppe | Felder | Typ | Vokabular im Export |
|---|---|---|---|
| Identität | deutscher Name, botanischer Name | Titel, Text | frei – ein Artname lässt sich nicht aus einer Liste wählen |
| Standort | Lichtbedarf, Bodenfeuchtigkeit, Bodenart / Struktur, pH-Wert (Toleranz), Trockenheitstoleranz | Mehrfachauswahl, Auswahl | Sonne, Halbschatten · Trocken, Mäßig · Sand, Kies, Lehm, Humus, Kalkhaltig · pH 4,5 bis 8,0 in Halbschritten |
| Wuchs | Wuchsform, Wuchsbreite, Wuchsgröße (Höhe), Wurzel, Lebensdauer, Wachstumstyp | Auswahl, Mehrfachauswahl | Baum, Strauch, Halbstrauch, Kletterpflanze · 30–60 cm, 1–2 m, 2–5 m, >5 m · Pfahlwurzel, Ausläufer |
| Erscheinung | Blütezeit, Blütenfarbe, Frucht, Besonderheiten | Mehrfachauswahl, Text | Juni bis September · neun Farbwerte einschließlich „Keine" und „Unauffällig" |
| Pflege | Pflegeaufwand, Pflege / Schnittzeit, Pflege-Notizen, Nährstoffbedarf, Nährstoffzusammensetzung, Winterhärte (Freiland), Winterhärte (Topf), Vermehrung | Auswahl, Mehrfachauswahl, Text | Gering, Mittel · Frühling/Sommer/Herbst mit Zusatz · Samen, Steckling, Teilung, Ableger |
| Verwendung | Verwendung / Nutzen, Bestens geeignet für …, Insektenfreundlich, Transporttyp | Mehrfachauswahl, Text, Auswahl | Bienenfreundlich, Duft, Sichtschutz, Windschutz, Hangbepflanzung, Strukturpflanze, Blattschmuck, Pflegeleicht |
| Herkunft | Quellenlink, Bild / Skizze | URL | frei |
Zwei Entscheidungen darin sind erklärungsbedürftig. Wuchshöhe ist keine Zahl, sondern eine Auswahl aus vier Spannen. Eine Zahl wäre genauer, suggerierte aber eine Genauigkeit, die es bei einer Pflanze nicht gibt; für die eigentliche Frage – passt das unter ein Fenster oder nicht – reicht die Spanne, und sie ist filterbar. Winterhärte ist in zwei Felder geteilt, Freiland und Topf, weil dieselbe Art im Kübel mehrere Grade früher erfriert.
Der gedachte Ablauf
Schritte 1 bis 5 sind in beiden Artefakten angelegt. Schritt 6 findet statt, hinterlässt aber keine Spur im Datensatz – man sieht einem gefüllten Feld nicht an, ob es geprüft wurde.
Make oder Zapier – die Entscheidung
Für denselben Ablauf liegen zwei Artefakte vor, und das hat einen Grund: Beides wurde probiert. Im Oktober/November 2025 habe ich mit Make angefangen und dort aufgehört, weil sich die Anbindung der OpenAI-API und von Notion als umständlicher erwies als erwartet. Weitergebaut habe ich in Zapier – trotz des technischeren Interfaces.
Weniger hübsch heißt nicht schlechter. Die Zapier-Strecke enthält einen selbst geschriebenen JavaScript-Schritt, einen Filter und eine Schleife über Einzelwerte. Ohne diese Möglichkeit gäbe es weder die Vokabularschranke noch die Prüfliste – die Oberfläche verlangt mehr und lässt dafür mehr zu. Das ist keine allgemeine Aussage über die beiden Anbieter, sondern die Begründung dieser Entscheidung.
Was von Make übrig ist, ist deshalb kein halbfertiger Aufbau, sondern der Rest eines abgebrochenen Versuchs – und genau so sieht die Datei auch aus. Die Prüfung unten hat das unabhängig festgestellt, bevor die Vorgeschichte bekannt war; sie deckt sich mit ihr.
Dieser Befund hat ein Datum – und ist womöglich veraltet
Die Einschätzung „mit Make umständlicher" stammt aus Oktober/November 2025. Beide Anbieter entwickeln ihre Integrationen weiter; es kann gut sein, dass sich OpenAI und Notion in Make heute genauso schnell verbinden lassen. Diese Seite behauptet also nicht, Make sei das schwächere Werkzeug. Sie sagt, wie eine Entscheidung an einem bestimmten Tag zustande kam und warum sie nicht revidiert wurde – die Zapier-Strecke läuft.
| Kriterium | Make | Zapier |
|---|---|---|
| Vorliegendes Artefakt | Blueprint-Datei, 53 KB JSON | 4 aufgezeichnete Läufe, Bildschirmfotos aller Schritte, Anweisung und Code im Wortlaut |
| Schritte | 3 | 7 |
| Auslöser | notion:watchDatabaseItems, nach Erstellzeit, Limit 20 |
Notion New Data Source Item, Abfragetakt 2 Minuten (Stand 03.09.2026) |
| Sprachmodell | OpenAI Create Chat Completion, Modell gpt-4 |
ChatGPT (OpenAI), Conversation, Modell gpt-5.6-luna |
| Anweisung an das Modell | leer Eine Systemnachricht ist angelegt, ihr Inhalt fehlt | vollständig rund 400 Zeilen: Namensregeln, Entscheidungslogik, 22 Wertelisten, Ausgabeschema |
| Antwort zerlegen | nicht vorhanden | Code by Zapier – ein eigener JavaScript-Schritt |
| Feldzuordnung | keine Das Notion-Modul schreibt nur die Seiten-ID zurück, kein einziges Feld | 28 Felder im Code-Schritt einzeln zugeordnet, mit Ausweichnamen für abweichende Schreibweisen |
| Weitere Verarbeitung | keine | Filter auf gemeldete neue Werte, Looping über Einzelwerte, Rückschreiben in eine zweite Datenbank |
| Zieldatenbank | stimmt nicht Auslöser und Ziel tragen zwei verschiedene IDs, keine davon ist die der Pflanzendatenbank | Notion Update Database und Create Data Source Item |
| Spuren eigener Arbeit | keine Dateiname und Aufbau entsprechen der unveränderten Make-Vorlage | deutlich Versionsstand v5, drei Zapier-eigene Hilfsschritte (Code, Filter, Looping), davon einer selbst geschrieben |
| Erfolgreicher Lauf belegt? | nein – nie fertiggebaut | ja 3 von 4 Läufen vollständig durch, der vierte absichtlich abgebrochen – nachzusehen |
Die Entscheidung – und warum sie anders ausfällt als geplant
Die Make-Datei ist keine Automation, sondern eine geladene
Vorlage. Das ist nachprüfbar und keine Einschätzung: Die
Systemnachricht an das Sprachmodell hat kein content, das
Notion-Modul zum Zurückschreiben hat kein einziges Feldmapping, und
Auslöser- und Zieldatenbank tragen zwei verschiedene Kennungen, von
denen keine zur Pflanzendatenbank gehört. Der Dateiname ist der
unveränderte Name der Make-Vorlage.
Die Zapier-Strecke trägt Spuren von Arbeit. Sieben
Schritte, davon ein selbst geschriebener JavaScript-Schritt, ein
Filter und eine Schleife über Einzelwerte. Nichts davon ist
Bestandteil einer Vorlage, und der Stand v5 sagt, dass
fünf Fassungen nötig waren. (Der frühere
Stand dieser Seite nannte acht Schritte – gezählt auf einem
Bildschirmfoto der Übersicht. Die Laufansicht vom 03.09.2026 zeigt
sieben; maßgeblich ist der Lauf.)
Für die Portfolio-Darstellung wird deshalb die Zapier-Strecke geführt – sie ist die gebaute, und seit dem 03.09.2026 auch die belegt laufende.
Nachtrag zur Vorgeschichte. Ein früherer Stand dieser Seite schloss aus der Aktenlage: „Zur Wahl standen nie zwei Strecken." Das war zu weit gegriffen. Eine Wahl gab es sehr wohl – sie fiel im Oktober/November 2025 gegen Make aus, wegen des Aufwands bei der Anbindung von OpenAI-API und Notion. Der Artefaktbefund bleibt richtig; falsch war der Schluss, den ich daraus auf die Vorgeschichte gezogen habe. Eine unfertige Datei sagt, dass nicht fertiggebaut wurde – nicht, dass nie verglichen wurde.
Nachtrag 03.09.2026 · die eine Hälfte ist jetzt gelaufen
Der Absatz oben stand hier seit dem 1. September und sagte: nicht getestet. Für die Zapier-Strecke gilt das nicht mehr. Vier Läufe sind aufgezeichnet, und sie beantworten genau die Fragen, die hier offen waren: was bei einer unvollständigen Eingabe geschieht (Lauf B), was bei einer unbekannten Pflanze (Lauf C) und was ein Durchlauf verbraucht.
Ein Vergleich ist es trotzdem nicht. Die Make-Strecke ist nicht gelaufen und kann es nicht – der Versuch wurde 2025 abgebrochen. Was hier steht, ist der Nachweis einer Strecke, nicht die Gegenüberstellung zweier. Die Zeile „Make gegen Zapier" in der Tabelle oben bleibt deshalb ein Artefaktvergleich.
Vier Läufe, aufgezeichnet
Am 3. September 2026 ist die Zapier-Strecke viermal gelaufen. Nicht viermal dieselbe Pflanze – viermal eine andere Frage an dieselbe Strecke. Jeder Lauf ist Schritt für Schritt protokolliert, samt der Antwort des Modells im Wortlaut.
| Lauf | Eingabe | Die Frage dahinter | Ergebnis |
|---|---|---|---|
| A | Acer griseum botanisch, ohne deutschen Namen |
Der Normalfall – läuft die Strecke durch? | 28 Felder geschrieben 3 Werte gemeldet |
| B | Zimtahorn deutsch, botanisches Feld leer |
Dieselbe Pflanze von der anderen Seite – kommt dasselbe heraus? | 28 Felder geschrieben 2 Werte gemeldet |
| C | Dracodendron luminara frei erfunden |
Erfindet das Modell Angaben zu einer Pflanze, die es nicht gibt? | abgebrochen kein einziges Feld geschrieben |
| D | × Cuprocyparis leylandii Hybride, mit Malzeichen |
Kommt die Strecke mit einem Sonderzeichen im Namen zurecht? | 28 Felder geschrieben kein Wert gemeldet |
Die vier Läufe Schritt für Schritt ansehen
Fünf Befunde
1 · Das Modell hat nichts erfunden
Auf Dracodendron luminara – ein Name, der botanisch
einwandfrei aussieht und nichts bezeichnet – kam
{"Fehler":"Kein gültiger Pflanzenname erkannt"}
zurück. Der Notion-Datensatz blieb vollständig leer.
Von 329 Ausgabe-Tokens entfielen 311 auf das Nachdenken und 18 auf die Antwort. Das Modell hat lange überlegt und dann kurz abgesagt.
2 · Dieser Schutz ist keine Regel
Abgefangen hat den erfundenen Namen weder ein Filter noch eine Zeile Code. Die Namensregel der Anweisung prüft nur auf Platzhalter wie „Untitled Page“; formal ist Dracodendron luminara ein tadelloser botanischer Name. Erkannt hat ihn das Modell.
Ein gutes Ergebnis und eine dünne Absicherung: Sie ist genau so verlässlich wie das Modell an diesem Tag.
3 · Nur erlaubte Werte kamen durch
22 der 28 Felder haben eine feste Werteliste. Über die drei
durchgelaufenen Läufe steht kein einziger Wert außerhalb
dieser Listen in der Datenbank. Fünf Werte, die nicht
passten, wurden über ein eigenes Feld NEUE_WERTE
gemeldet und in eine zweite Datenbank geschrieben – statt ins Feld.
Der Unterschied ist der ganze Punkt: Bei Acer griseum ist die Frucht eine Flügelnuss. Die Liste kennt den Begriff nicht, wohl aber unbedeutend – das hätte gepasst und harmlos ausgesehen. Das Feld blieb stattdessen leer, und „Flügelnuss“ ging in die Prüfliste. Eine Lücke, die man sieht, ist besser als ein Wert, der zu stimmen scheint.
4 · A und B bestimmen dieselbe Pflanze und beschreiben sie verschieden
Lauf A bekam den botanischen Namen, Lauf B den deutschen. Beide landen auf Acer griseum – die Bestimmung ist stabil. Von 28 Feldern sind 19 gleich und 9 verschieden, davon vier in Feldern mit fester Werteliste:
| Feld | Lauf A | Lauf B |
|---|---|---|
| Winterhärte (Topf) | −15 °C | −10 °C |
| Insektenfreundlich | Ja | Mäßig |
| Pflege / Schnittzeit | leer, „Spätsommer“ gemeldet | Sommer (Formschnitt) |
| Lebensdauer | Mehrjährig (lang lebend) | Mehrjährig (langlebend) |
Bei den ersten beiden ist mindestens eine Angabe falsch, und die Strecke merkt es nicht – sie prüft die Form, nicht den Wahrheitsgehalt. Genau dafür wäre der Prüfstatus da, der unten als offener Punkt steht.
5 · Die letzte Zeile ist ein Befund über die Datenbank, nicht über das Modell
Mehrjährig (lang lebend) und
Mehrjährig (langlebend) sind zwei Optionen
desselben Feldes – derselbe Begriff, zwei Schreibweisen. A
hat die eine gewählt, B die andere. Kein Lauf hat einen Fehler
gemacht; beide haben einen erlaubten Wert genommen. Der Fehler liegt
in der Werteliste.
Gefunden hat ihn nicht die Prüfung, sondern der Vergleich zweier
Läufe derselben Pflanze. Ein Lauf allein hätte ihn nie gezeigt –
und das ist der Grund, warum Lauf B überhaupt gemacht wurde. Dasselbe
gilt für drei überlappende Größenklassen: Ein 8 m hoher Baum
passt in 5–10 m und in >5 m, beide wären
richtig – womit die Spalte zum Filtern taugt wie ein Freitextfeld.
Was im Datenbestand steckt
Der Export lässt sich prüfen, auch ohne Zugang zur Automation. Neun Datensätze sind wenig – aber sie zeigen genau die Fehler, die eine wachsende Sammlung später unbrauchbar machen.
| Datensatz | Gefüllte Felder | Quellenlink |
|---|---|---|
| Echter Lavendel · Lavandula angustifolia | 29 / 31 | ja |
| Echter Salbei · Salvia officinalis | 29 / 31 | ja |
| Kartoffel-Rose · Rosa rugosa | 29 / 31 | ja |
| Trompetenblume · Campsis radicans | 24 / 31 | nein |
| Küstenmammutbaum · Sequoia sempervirens | 19 / 31 | nein |
| Efeu · Hedera helix | 18 / 31 | nein |
| spanische Tanne · Abies pinsapo | 11 / 31 | ja |
| Urweltmammutbaum · Metasequoia glyptostroboides | 9 / 31 | ja |
| Hainbuche – nur der deutsche Name | 1 / 31 | nein |
Drei Befunde
1. Derselbe Wert steht zweimal in der Auswahlliste
Das Feld Winterhärte (Freiland) führt
-15 °C und –15 °C als
zwei Optionen. Der Unterschied ist ein Zeichen: einmal der
Bindestrich U+002D, einmal der Gedankenstrich
U+2013. Küstenmammutbaum und Kartoffel-Rose tragen die
eine Variante, Lavendel und Salbei die andere.
Das ist der teuerste Fehler von den dreien, weil er unsichtbar ist: Ein Filter auf „−15 °C" findet die Hälfte der passenden Pflanzen und meldet dabei keinen Fehler. Diese Prüfung ist automatisierbar und läuft im Prüfskript mit – sie vergleicht nur Zeichen und beurteilt keine Bedeutung.
2. Ein Vokabular vermischt drei Fragen
Das Feld Frucht kennt die Werte
keine, Zapfen, essbar,
Weiß und unbdeutend. Darin stecken drei
verschiedene Fragen – gibt es eine Frucht, was für eine ist es, kann
man sie essen – und dazu eine Farbe. Wonach hier gefiltert werden
soll, ist damit nicht beantwortbar. unbdeutend ist
außerdem ein Tippfehler, und weil er in der Auswahlliste selbst
steht, wiederholt er sich in jedem Datensatz, der ihn verwendet.
3. Zwei Felder wurden nie gefüllt
Wachstumstyp und Transporttyp sind in keinem
der neun Datensätze belegt. Ein Feld, das nie gefüllt wird, ist
entweder überflüssig oder es fehlt der Schritt, der es füllt – beides
sollte man wissen, bevor die Sammlung wächst.
Befund 1 findet eine Regel. Befund 2 und 3 findet ein Mensch, der die
Vokabelliste liest. Im Prüfskript stand zunächst eine Regel, die
Tippfehler automatisch erkennen sollte; sie hat 30–60 cm
gemeldet und unbdeutend übersehen – also genau falsch
herum. Sie wurde entfernt und durch die vollständige Ausgabe des
Vokabulars ersetzt. Eine Prüfung, die danebenliegt, ist schlechter als
keine, weil man ihr glaubt.
Der offene Punkt
Fünf von neun Datensätzen tragen einen Quellenlink, alle fünf auf die deutschsprachige Wikipedia. Bei den übrigen vier steht nicht, woher die Angaben kommen. Und bei keinem einzigen steht, ob sie geprüft wurden.
Das ist die eigentliche Lücke dieses Belegs, und sie ist keine Kleinigkeit. Ein Sprachmodell, das Pflanzeneigenschaften vorschlägt, liegt oft richtig und manchmal plausibel daneben – und beides sieht in einem gefüllten Notion-Feld identisch aus. Solange der Datensatz nicht mitführt, woher ein Wert stammt und wer ihn bestätigt hat, ist die Datenbank eine Sammlung von Behauptungen mit ordentlicher Struktur.
Was fehlt – konkret
- Feld
Status(Auswahl): Vorschlag · geprüft · strittig. Vorbelegt mit Vorschlag, wenn die Automation schreibt. - Feld
Quellenlinkzur Pflicht machen, sobald der Status auf geprüft steht – ein geprüfter Wert ohne Quelle ist keiner. - Feld
geprüft am(Datum), damit alte Prüfungen als alt erkennbar bleiben.
Drei Felder, eine knappe halbe Stunde Arbeit. Dass sie fehlen, steht hier, weil dieser Beleg sonst mehr behaupten würde, als in der Datenbank steht. Der Vorschlag ist ein Vorschlag und nicht der Zustand des Systems.
Nachtrag 03.09.2026 · die Läufe machen die Lücke schärfer
Zwei Beobachtungen aus den vier Läufen gehören hierher, und beide machen den offenen Punkt dringender, nicht kleiner.
Erstens: Lauf A und Lauf B beschreiben dieselbe Pflanze und geben bei Winterhärte (Topf) −15 °C gegen −10 °C an. Eine der beiden Angaben ist falsch. Beide stehen fehlerfrei in der Datenbank, beide sehen gleich verlässlich aus. Das ist nicht mehr ein hypothetisches Risiko, sondern ein gemessener Fall.
Zweitens: Es gibt sehr wohl ein Statusfeld – nur an der falschen Stelle. Die Prüfliste, in der gemeldete neue Vokabeln landen, hat eines. Im aufgezeichneten Lauf kam es leer an. Die Strecke sammelt also sauber ein, was zu entscheiden wäre, und nichts erzwingt, dass jemand es entscheidet. Der Mensch ist im Ablauf vorgesehen und nirgends verpflichtet – für die Vokabeln so wenig wie für die Pflanzenangaben.
Grenzen dieses Belegs
- Vier Läufe sind keine Messreihe. Seit dem 03.09.2026 gibt es eine Laufhistorie – aber nur für die Zapier-Strecke und nur für vier ausgesuchte Fälle. Sie zeigen, dass die Strecke in diesen vier Fällen tut, was sie soll. Über die Trefferquote auf hundert Pflanzen sagen sie nichts.
- Die Make-Strecke ist weiterhin nicht gelaufen. Der Versuch wurde im Oktober/November 2025 abgebrochen; die Datei ist auf dem Stand der unveränderten Vorlage. Wo im Vergleich „nicht belegbar" steht, heißt das nicht „funktioniert vermutlich".
- Kein Urteil über Make als Werkzeug. Der Grund für den Abbruch – die Anbindung von OpenAI-API und Notion war umständlicher – ist meine Erfahrung aus Oktober/November 2025 und nicht nachgemessen. Beide Anbieter entwickeln ihre Integrationen weiter; heute kann das anders sein. Diese Seite belegt eine Entscheidung, keinen Produktvergleich.
- Keine Berufserfahrung mit Automationswerkzeugen. Make, Zapier und Notion sind hier privat und für eigene Zwecke eingesetzt. Es gibt keine berufliche Station, in der ich damit gearbeitet habe.
- Neun Datensätze sind kein Datenbestand. Das Datenmodell ist für mehr gebaut, gefüllt ist es kaum. Was hier gezeigt wird, ist die Struktur und ihre Prüfung, nicht eine gepflegte Pflanzendatenbank.
- Keine fachliche Prüfung der Inhalte. Ob Rosa rugosa tatsächlich bis −15 °C freilandhart ist, sagt dieser Beleg nicht. Er sagt, dass diese Angabe im Datensatz steht, dass sie auf einen Wikipedia-Artikel verweist und dass kein Feld dokumentiert, ob jemand sie nachgeprüft hat. Die Läufe A und B zeigen den Fall inzwischen live: zwei verschiedene Winterhärteangaben zu derselben Pflanze, beide unbeanstandet.
- Keine Zugangsdaten, keine Schlüssel. Weder in dieser Seite noch im Projektordner. Die Blueprint-Datei wurde ausgewertet, aber nicht veröffentlicht – sie enthält Verweise auf Verbindungen und Datenbank-Kennungen.
Zum Nachrechnen
Feldbericht (CSV) Die vier Läufe (CSV) Jedes Feld jedes Laufs (CSV) Die gemeldeten Werte (CSV) Die Wertelisten (CSV)
Der Feldbericht führt je Feld den Typ, den Füllgrad und das im Export
vorkommende Vokabular. Erzeugt von
skripte/pflanzendatenbank-pruefen.py; dasselbe Skript
gibt die drei Befunde oben aus. Die vier Zapier-Dateien erzeugt
skripte/zapier-export.py aus denselben Modulen, mit
denen die Demo im Browser rechnet – Seite und Download können daher
nicht auseinanderlaufen. Beide Skripte liegen außerhalb des
Website-Ordners und werden nicht mit ausgeliefert.
Weiterlesen
Zurück zum Einstieg für Daten und Prozesse · dieselben Prüffragen an einem größeren Bestand und mit SQL: 378 Bilddatensätze, acht Prüfabfragen · ein Sprachmodell, das seine Textstelle mitliefern muss: Gartenanfragen vorprüfen · Normalisieren und Lückenreport getrennt: Produktdaten bereinigen.
Wenn eine Strecke zwischen zwei Systemen laufen soll
Wenn Sie eine Rolle besetzen, in der Prozesse automatisiert und Datenqualität gesichert werden: Hier steht eine laufende Strecke mit ihrem Halluzinationstest und den Befunden, die der Vergleich zweier Läufe zutage gefördert hat.