Um google 'Things, not strings' von 2012 einmal aus anderer Perspektive zu betrachten:
Warum werden in vielen Ontologien, wie z.B. gist, Elemente wie Adressen oder Adressbestandteile nicht als Strings, sondern als Objekte dargestellt.
Das zwingt uns, an diese Objekte wiederum Strings zu hängen. Wie unpraktisch. Ein Hop mehr, um an die druckbare Adresse zu kommen.
Die Frage eines Kunden hat mich auf die Idee gebracht, die Einflüsse auf meine Modellierungsstrategien und meine eigenen Einstellungen und Leitlinien einmal zusammenzuschreiben.
Dies sind meine Regeln nach meinen momentanen Erfahrungen, Ende 2023. Sie sind nicht allgemeingültig sondern dokumentieren den Stand meiner Entwicklung.
Im wundervollen Vortrag "Design in Practice" spricht Rich Hickey davon, wie wichtig ein aktuelles Glossar im Designprozess ist.
Ich sehe das ganz ähnlich, und sehe etwas wie "Business Knowledge Blueprints" als wichtige Grundlage für geschäftliche Anwendungen und besonders für Datenmodelle und (Enterprise) Knowledge Graphs.
Oder Reifizieren vs. RDF-Star. Oder Davidsonsche Ereignissemantik beim Modellieren.
Ich glaube obiges Beispiel mit Caesar habe ich aus John Sowas „Knowledge Representation“, dass ich leider verliehen und nie zurückbekommen habe, darum fehlt die genau Seitenangabe.
Heute hörte ich mir den Workshop "Democratize the Knowledge Graph and Concrete Tooling Requirements" von Adam Keresztes auf der 2023 Knowledge Graph Conference in NYC an.
Verschiedene Leute dort betonten die Schwierigkeit, Nichtontologen den Unterschied zwischen Klassen und Instanzen zu erklären.
Das hat mich dazu gebracht, darüber nachzudenken, wie ich mit dieser Terminologie arbeite, und ich habe festgestellt, dass ich dazu neige, 'Menge' statt 'Klasse' zu verwenden.
Gestern war ich auf dem Connected Data Meetup in London und hörte mir einen Vortrag von Madi Weland Solomon an, in dem sie Taxonomien als Ausgangspunkt für die Erstellung von Ontologien befürwortete.
Sie ging nicht ausführlich darauf ein, daher ist das Folgende mein Verständnis, alle Fehler und schlechten Ideen sind von mir :)
Business Knowledge Blueprints sind ein leistungsfähiges Instrument zur Identifizierung der grundlegenden Struktur und Anforderungen eines Unternehmens. Durch die Zusammenarbeit mit einem Coach oder Moderator bei der Erstellung eines Business Knowlege Blueprints können Unternehmen ein klareres Verständnis ihres Geschäftsmodells und dessen Einordnung in den breiteren Markt erlangen.
RDF, OWL und SHACL sind leistungsstarke Formalismen, die verwendet werden können, um die Ergebnisse eines Business Knowledge Blueprint Coachings oder Workshops auszudrücken und zu analysieren. Diese Formalismen ermöglichen es Unternehmen, Daten auf strukturierte und aussagekräftige Weise darzustellen und zu manipulieren, so dass sie fundiertere Entscheidungen über ihr Geschäftsmodell und ihre Strategie treffen können.
Logik und Semantik spielen bei der Datenmodellierung eine entscheidende Rolle, da sie dabei helfen, Daten auf klare und sinnvolle Weise zu strukturieren und zu organisieren. Durch die Verwendung logischer und semantisch reichhaltiger Datenmodelle können Unternehmen und Organisationen ihre Daten besser verstehen und nutzen, um fundierte Entscheidungen zu treffen und das Wachstum zu fördern.
Es werden keine Dienste zur Analyse Ihres Verhaltens genutzt, wir tracken sie nicht.
