Talk:Pragmatic vs. Perfectionist Approaches in Knowledge Modeling
Wenn Du den Themen in Holger Knublachs Paper folgst kommst Du auf gut abgelagerte Dinge. Die GFP Spec aus dem Jahr 1997 ist da ziemlich erhellend, was die Nutzung von Begriffen wie "Slot" angeht, die auch heute noch z.B. bei LinkML üblich sind. Strukturell hat sich da leider nicht viel getan. Leider gibt es kaum Ansätze, die Gegensätze zu überbrücken. Wenn es z.B. darum geht eine Beziehung zwischen Person und Adresse zu modellieren wird die naive Aussage zu erst sein, dass es eine fuktionale Abhängigkeit gibt, kenne ich die ID einer Person kenne ich auch die Adresse. Dann kommt irgendwann die Erkenntnis dass ich unterscheiden muss zwischen der Person und Ihrem Personalausweis und das es exotische Fälle gibt von Personen mit mehren Ausweisen (Geheimdienst, Zeugenschutzprogramm, Verbrecher mit gefälschten Ausweisen) Dann stellt sich heraus das die Adresse natürlich nur ein Konstrukt ist das für verbindliche Zustellungen relevant ist - daher gibt es ja soviele Väter, die keinen Unterhalt zahlen - deren Wohnadresse ist einfach nicht deren Zustelladresse - aber es gibt natürlich auch Rechnungsadressen, Lieferadressen, Urlaubsadressen. Und dann kann man natürlich noch die Frage stellen was die Urlaubsadresse eines Internet-Nomaden ist. Nun sagt die eine Denkrichtuung: das muss alles nur präzise modelliert werden und der dazu notwendige Einigungs- und Klärungsprozess erhört die Qualität des Ergebnisses (manch träumen hier von : bis zur Perfektion) und die andere Denkrichtung sagt: es wird immer die pragmatischen Ergebnisse geben, die einfach "gut genug" sind und sich über Statistik und Ökonomie oder einfach nur Trägheit (bis hin zur Bräsikeit) definieren. Die Dinge sind wie sie sind und gelten als "betriebsbewährt."
Qualitätskriterien aufzustellen ist in dieser Gemengelage schwierig. Das ist der Grund, weswegen ich auf "Frustvermeidung" statt "Opimtierung" plädiere. Eine Frust vermeidende Modellierung interessiert sich für Details wie Häufigkeit(Relevanz) insbesondere bei der Beschreibung der Kardinalitäten. Es wird also keine Kardinalität gefordert sondern nur in statistischer Beziehung zu den Usecases gesetzt. Dann kann man Aussagen treffen wie: im Usecase A ist das immer so, im Usecase B ist das häufig so, Im Usecase C ist das selten so und im Usecase D ist das nie so.
Meiner Ansicht nach kann ich dan Usecase spezifische APIs und Queries schaffen, in dem ich usecase spezifisch filtere. In der Grundstruktur kann ich mir dann auch leisten meinen lokalen Subgraphen passend zu optimieren. Global glaube ich jedoch nicht daran.
Den Text oben habe ich LLM mässig aufbereiten lassen:
https://cr.bitplan.com/index.php/Pragmatic_vs._Perfectionist_Approaches_in_Knowledge_Modeling
Hier die Links: