SEMANTISCHES WEB, TEIL 3
Vom Modell zur Datenbank
Beim Erstellen eines Modells für eine Graph-Datenbank hilft das Tool Protégé bei Axiomen, ObjekteigenschaftenObjekt-Eigenschaften, Individuals, Annotationen und Internationalisierung.
ie Die Grundlagen des „Semantischen Web“ hat die dotnet- pro dotnetpro in den beiden zurückliegenden Ausgabe 4/2020 und 5/2020 vorgestellt: Im ersten Teil waren das die Standards RDF und OWL, Klassenhierarchien, Taxonomien, Data- und Object-Eigenschaften mitsamt ihren Einschränkungen und semantischen Metadaten, Individuals, die eigentlichen Ob- jekte Objekte in einer semantischen Graph-Datenbank, Reasoner, die für die Konsistenz der Daten sorgen, und die Inferenz, die lo- gische logische Schlussfolgerungen und damit das maschinelle Ler-nen Lernen ermöglicht [1].
Nach diesen technischen Grundlagen führte der zweite Teil in die praktische Arbeit mit Ontologien ein, also das Erstellen eines semantischen Datenmodells, wobei als Werkzeug die Software Protégé zum Einsatz kam [2]. Gezeigt wurde, wie Sie mit Protégé Klassen, Eigenschaften, Individuals und An- notationen Annotationen verwalten, wie Sie Schemata und Klassifizierun- gen Klassifizierungen umsetzen, wie Sie Restrictions einsetzen und den Reasoner nutzen und wie Sie Modelle importieren und exportieren. Im vorliegenden dritten Teil geht es nun darum, wie diese Modelle mit einer semantischen Graph-Datenbank synchro- nisiert synchronisiert und dort für das Wissensmanagement verwendet wer- denwerden. Er schließt ohne Umschweife an den zweiten Teil an.
Protégé ist ein sehr ausgereiftes und eines der am häufigs- ten häufigsten eingesetzten freien Tools zum Modellieren von Ontolo- gienOntologien. Betreut wird es von der Stanford University, und es ist auf deren Website kostenfrei verfügbar [3]. Die Software hat sich daher als Modellierungs-Tool etabliert, dessen generier- te generierte Modelle in ihren verschiedenen Formaten von allen W3C-konformen semantischen Datenbanken unterstützt werden.
Für einfache Testzwecke bietet das Programm ein Plug-in für SPARQL-Abfragen. Wie der Name schon andeutet, kön- nen können damit SPARQL 1.0-konforme select-Abfragen ausgeführt werden. Die SPARQL-1.1-Operationen insert oder delete un- terstützt das Plug-in (noch) nicht.
Protégé positioniert sich somit klar als UI-orientiertes Mo- dellierungswerkzeug Modellierungswerkzeug und überlässt sowohl den operativen Betrieb als auch das programmatische Datenmanagement den Datenbank- und App-Herstellern.
...
Wichtig zu wissen ist, dass sowohl Range- als auch Domain- Axiome (siehe [2]) global wirken, wenn sie direkt für Eigen- schaften Eigenschaften definiert werden – mit entsprechenden Auswirkun- gen Auswirkungen für die Ontologie.
Versehen Sie beispielsweise eine spezifische Eigenschaft companyName mit einem Domain-Axiom Company, so sorgt der Reasoner dafür, dass jedes Individual, das companyName verwendet, automatisch zu einem Mitglied der Klasse Com- pany Company wird – ohne dass dies einer expliziten Klassenzuwei- sung Klassenzuweisung à la dnp:Company_EbnerVerlag rdf:type dnp:Company bedarf – die gewünschte und hilfreiche Seite der Inferenz.
Wenn Sie hingegen eine generische Eigenschaft name mit einem Domain-Axiom Product versehen, so werden ebenfalls alle Individuals, die diese Eigenschaft verwenden, automa- tisch automatisch zu Mitgliedern der Klasse Product. Folgerichtig würde auch eine Person, welche die Eigenschaft name verwendet, ebenfalls zu einem Product-Objekt, was dann zwar logisch richtig, semantisch aber natürlich unsinnig ist.
Bei generischen Eigenschaften mit allgemeinem Charakter sollte man also besonnen mit Domain-Axiomen umgehen, um spätere Überraschungen durch unerwartete Klassenzuord- nungen Klassenzuordnungen zu vermeiden. Eine gute Praxis ist, Axiome als Instru- ment Instrument zur automatischen Klassifizierung von Individuals zu verwenden – Range-Axiome zur Klassifizierung der Objekte und Domain-Axiome zur Klassifizierung der Subjekte – und nicht zum Validieren oder als (Typ-)Constraints.
Wollen Sie lokal für eine Klasse spezifizieren, dass eine Ei- genschaft Eigenschaft auf einen bestimmen Datentyp oder Wertebereich beschränkt sein soll, so definieren Sie dies als Type-/Value-Restriction auf Klassenebene. Da die Nutzung gemeinsam verwendeter Eigenschaften sowohl in Klassen als auch in In- dividuals Individuals in einem Graphen sehr leicht zu ermitteln ist, kann die Konsistenz der Ontologie ebenfalls leicht validiert wer- denwerden, aber ohne den Effekt der automatischen Klassifizierung. Bei der Spezifikation von Klassen weiter unten wird der Arti- kel Artikel darauf noch genauer eingehen.
...
Während Dateneigenschaften konkrete Werte verschiedener Datentypen, sogenannte Literale, für Individuals enthalten,
...
Anlegen einer Object Property „hasCustomer“ (Bild 1)enthalten
...
referenzieren Objekteigenschaften (Object Properties) ande- re andere Individuals. Sie sind die Basis für die Beziehungen zwi- schen zwischen den Individuals in einem Graphen, beispielsweise die Relation zwischen einer Rechnung und dem dazugehörigen Kunden.
In RDF sind alle Entitäten, also auch alle Individuals und Eigenschaften, durch ihre IRIs eindeutig identifiziert. Ent- sprechend Entsprechend einfach sehen auch die Tripel für die Repräsenta- tion Repräsentation von Relationen aus. Ein Beispiel:
dnp:Invoice_A dnp:hasCustomer dnp:Customer_B
Die Objekteigenschaft hasCustomer verbindet hier die Rech-nung A mit dem Kunden B. Zum Anlegen einer solchen Ei- genschaft Eigenschaft klicken Sie im Protégé-UI unten auf das Register Object properties. Wie die Dateneigenschaften stammen in OWL alle Objekteigenschaften von owl:topObjectProperty ab. Selektieren Sie owl:topObjectProperty und klicken Sie den Button Add sub property an. Protégé fordert Sie auf, den Namen der Objekteigenschaft einzugeben (Bild 1).
Wie bei den IRIs für die Klassen setzt Protégé per Vorgabe den IRI der Eigenschaft aus dem Ontologie-IRI, dem Trenn- zeichen Trennzeichen # und dem eingegebenen Bezeichner zusammen. Das ist international eindeutig und in Abfragen gut lesbar.
...
Der nächste Schritt nach dem Erstellen von Taxonomie, Da- tenDaten- und Objekteigenschaften ist die Spezifikation der einzel- nen einzelnen Klassen mit ihren jeweiligen Eigenschaften und Con- straintsConstraints. Zuvor ging es darum, wie in Ontologien Domain- und Range-Axiome zur automatischen Klassifizierung von Indivi- duals Individuals eingesetzt werden, also zum automatischen Gruppie- ren Gruppieren von Individuals zu Mitgliedern einer oder mehrerer Klas- senKlassen: die implizite Einfach- oder Mehrfachklassifizierung.
Aus der OOP-Welt kommend ist man jedoch versucht, die Klassen in einer Ontologie nicht als Gruppen von Individuals, sondern als Schemata anzusehen, als einen vorgegebenen Rahmen von Eigenschaften und ihren Constraints, den die In- stanzen Instanzen der Klassen einhalten müssen. Generell sind seman- tische semantische Datenbanken aber zunächst einmal schemalos, was bedeutet, dass jedes einzelne Individual beliebige Eigen- schaften Eigenschaften erhalten kann. Auch müssen Individuals nicht zwangsläufig über eine oder gar mehrere Klassifizierungen verfügen, weder über explizite mithilfe von rdf:type noch über implizite durch Domain- und Range-Axiome.
Was wegen seiner Offenheit und Freiheitsgerade ideal für die Abbildung komplexer realer Umgebungen, von Umwelt und Wissensdomänen ist, mag verglichen mit den Tabellen und Kollektionen aus der SQL- und NoSQL-Welt unpraktika- bel unpraktikabel erscheinen, gibt es doch beispielsweise für ERP-Systeme meist eine Vielzahl gleichartiger Instanzen wie Kunden, Pro- dukte Produkte oder Rechnungen, die allesamt eigenen Schemata un- terliegenunterliegen. Doch auch OWL bietet Mechanismen, um Schema- ta Schemata zu definieren, wenn auch mit einem etwas anderen Blick- winkel Blickwinkel als vielleicht erwartet.
Während mit traditionellen Schemata zum Beispiel gesagt wird: „Eine Person hat einen Namen“, wird dies in Onto- ▶
...
Das Spezifizieren einer Dateneigenschaft für die Klasse „Product“ (Bild 3)
Die Spezifikation der Klasse „Product“ in Protégé (Bild 2)
- ▶
...
...
logien ausgedrückt mit: „Eine Person ist eine Unterklasse al- ler aller Dinge, die einen Namen haben“. Diese Ausdrucksweise stammt aus der Description Logic (DL), hört sich etwas ver-wirrend an, meint aber im Prinzip das Gleiche. Da es keine konkrete Klasse Ding mit einem Namen gibt, handelt es sich technisch um die Vererbung von einer sogenannten anony- men anonymen Klasse. Weil Mehrfachvererbung integraler Bestandteil von OWL ist, ist auch die Definition mehrerer Eigenschaften pro Klasse nach diesem Konzept nicht nur kein Problem, son- dern sondern beabsichtigte und etablierte Modellierungspraxis.
Bild 2 zeigt die Klasse Product mit ihren Dateneigenschaf- tenDateneigenschaften. Entsprechend der genannten DL-/OWL-Konventionen sind diese nicht etwa bei den Eigenschaften, sondern im Be- reich Bereich SubClass Of zu finden.
Die Datentypen werden angegeben als sogenannte Data-Restrictions (Bild 3), eine Art Type- und Value-Constraints. Die Angaben zur Kardinalität (der erlaubten Anzahl) der Eigen- schaften Eigenschaften ist ein zusätzliches Merkmal von OWL. Wichtig sind hier zwei Aspekte:
Zum einen werden die Restrictions – im Gegensatz zu den Domain- und Range-Axiomen – auf Klassenebene und nicht auf Ebene der Eigenschaften appliziert. Sie gelten
...
daher nicht global, sondern nur für die entsprechende Klasse.
Zum anderen führen Restrictions nicht wie die Axiome zu einer automatischen Klassifizierung der Individuals der Klasse. Sie haben vorrangig deskriptiven Charakter,
...
erzeugen keine neuen Tripel, werden aber vom Reasoner bei den Konsistenz-Checks berücksichtigt.
Aufgrund der Open World Assumption ist dies ist aber nicht gänzlich mit einem Validierungsschema vergleichbar. Ist im Beispiel eine minimale Kardinalität mit 1 angegeben und ver- fügt verfügt ein Individual nicht über eine entsprechende Eigen- schaftEigenschaft, so wird der Reasoner dies nicht als Verletzung erken-nenerkennen, denn die OWA besagt ja, dass alles, was nicht explizit angegeben ist, schlicht unbekannt, aber nicht zwangsläufig falsch ist. Das Tripel für die unbekannte Eigenschaft könnte sich ja in einer anderen Ontologie oder Datenbank befinden. Hier hilft SHACL [4]; dazu in einem Folgeartikel mehr.
Für die Objekteigenschaften gilt Gleiches. Der wichtige Unterschied ist, dass der Restriction Filler hier im rechten Be- reich Bereich anstatt der Datentypen eine Klasse in der Taxonomie (der Klassenhierarchie) zur Auswahl anbietet. Die Spezifika- tion Spezifikation der Kardinalität wirkt auf die Objekteigenschaften in identischer Weise wie bei den Dateneigenschaften.
...
Die Klassen mit ihren Restrictions sind angelegt, nun kom- men kommen die Individuals an die Reihe, die eigentlichen Datensät- ze Datensätze in der Ontologie. In Protégé wechseln Sie dazu zum Regis- ter Register Individuals by class und unten links in den Bereich Direct Instances. Er zeigt alle bereits vorhandenen Individuals der oben ausgewählten Klasse, in Bild 4 am Beispiel von Product. Beachten Sie, dass in der dotnetpro-Beispiel-Ontologie zu diesem Artikel [5] alle Produkte mit Labels versehen sind und
Die Individuals in Protégé verwalten (Bild 4)
...
Protégé generiert automatisch eindeutige IRIs (Bild 6)
...
...
...
der Protégé-Renderer im Screenshot die Labels anzeigt. Schwebt der Mauszeiger über einem Artikel, zeigt der Tool- tipp Tooltipp seinen vollständigen IRI.
Im Gegensatz zu Klassen und Eigenschaften, die pro Onto- logie Ontologie einmalig sind, gestaltet sich die IRI-Vergabe für eine Vielzahl von Individuals erwartungsgemäß anders. Während Klassen und Eigenschaften üblicherweise eindeutige und von Menschen lesbare Bezeichner erhalten, wäre bei mehre- ren mehreren Individuals mit gegebenenfalls gleichen Namen keine Eindeutigkeit des IRI pro Ressource mehr gewährleistet. Ein IRI dnp:AlexanderSchulze würde unweigerlich zu Konflikten mit einer gleichnamigen Person in der Datenbank führen.
...
Zum Anlegen eines neuen Individuals klicken Sie auf den Add-Button oberhalb der Liste und dann auf New Entity Op- tionsOptions. Protégé bietet einen Assistenten, mit dem sich die Ver- gabe Vergabe des IRI konfigurieren lässt (Bild 5).
Wählen Sie als Nächstes die Option Auto-genera- ted Autogenerated ID und geben Sie weiter unten das gewünsch- te gewünschte Präfix für den IRI ein, hier Product_. Sobald Sie dann einen Namen für das neue Individual einge- ben eingeben (Bild 6), erstellt Protégé mit jedem getippten Buchstaben eine neue UUID und hängt sie an das gewählte Präfix an.
Wie im Screenshot zu sehen ist, erstellt Protégé in diesem Fall automatisch ein Label für das betreffen- de Produkt und stellt dieses auch entsprechend in der Nutzeroberfläche dar. Mit dieser Technik sind also sowohl die weltweite Eindeutigkeit von Indivi- duals Individuals wie auch die Lesbarkeit für den Administra-Administrator gewährleistet.
Anlegen von Annotations
Annotationen sind Aussagen, die an jede Entität (Klasse, In- dividual Individual oder Eigenschaft) angehängt werden können, ohne dabei deren Semantik zu beeinflussen. Verwendet werden können sie zum Beispiel für Kommentare, zur Angabe von Autoren oder Versionsnummern, aber auch für Übersetzun- gen Übersetzungen in verschiedene Landessprachen. Sie werden wie Daten behandelt, lassen sich also via SPARQL abfragen und mani- pulierenmanipulieren. Reasoner berücksichtigen die Annotationen nicht.
Um eine Annotation für eine Entität anzulegen, selektieren Sie Letztere im linken Bereich des Protégé-UI. Rechts erschei- nen erscheinen dann deren Annotationen im gleichnamig benannten Tab. Bild 7 zeigt ein Beispiel für die Dateneigenschaft purchasePrice, für die schon zwei label- und zwei comment- Annotationen jeweils in deutscher und englischer Sprache angelegt wurden.
Um eine Annotation neu anzulegen, klicken Sie den Add- Button; um eine bestehende zu ändern, nutzen Sie den Edit-Button hinter der betreffenden Annotation. Protégé fordert Sie auf, den Typ der Annotation und deren Wert einzugeben. In Bild 8 sehen Sie die Eingabe einer Dokumentation in eng- lischer englischer Sprache für die Eigenschaft purchasePrice in Form ei-ner einer comment-Annotation.
Das Beispiel macht deutlich, dass in Ontologien direkt ein- gebundene eingebundene Metadaten nicht nur deren kulturübergreifen- ▶
tor gewährleistet.
Internationale „label“- und „comment“-Annotations (Bild 7)
...
Annotation in Englisch zu einer Dateneigenschaft hinzufügen (Bild 8)
...
...
de Dokumentation für Entwickler vereinfachen, sondern auch die Wartung von Inhalten für internationale Zielgrup- penZielgruppen. OWL erlaubt es zudem, beliebige weitere und ebenso internationalisierbare Annotation-Typen anzulegen.
...
Insbesondere für die Zusammenarbeit an Ontologien in inter- nationalen internationalen Teams ist ein Merkmal von Protégé besonders nützlich: Das Rendering der Bezeichner aller Entitäten ist konfigurierbar. So können Sie zum Beispiel bestimmen, ob Sie den kompletten IRI, die Named-Prefix-Notation oder ei- ne eine Annotation im UI darstellen wollen – im Fall der Annota- tion Annotation sogar, in welcher Sprache.
Eine gute Praxis hinsichtlich Dokumentation und interna- tionaler internationaler Nutzbarkeit von Ontologien ist daher, jede Klasse, Ei- genschaft Eigenschaft und jedes Individual mit mindestens einer comcomment- ment- und einer label-Annotation in englischer Sprache zu versehen, idealerweise auch in weiteren Sprachen, je nach Verteilung des Teams oder Umfang der Zielgruppe.
Zur Konfiguration des Renderers wählen Sie im Hauptme- nü Hauptmenü von Protégé unter dem Menüpunkt Preferences den Tab Renderer und dort die Option Render by annotation proper- ty. Den Einstellungsdialog zeigt Bild 9.
...
So lässt sich dann die Ontologie leicht auf die ge- wünschte gewünschte Sprache „umstellen“, was die Wartung von Ontologien auch kulturübergreifend sehr ein- fach einfach macht. Bild 11 zeigt exemplarisch, wie die Taxo- nomie Taxonomie nun in Deutsch gerendert wird.
Da die meisten Bezeichner für Klassen und Ei- genschaften Eigenschaften in Ihrer Ontologie wahrscheinlich oh- nehin ohnehin in Englisch erfasst werden, mag der Einsatz und die Wartung von Labels für jede Entität zu- nächst zunächst umständlich erscheinen. Spätestens aber, wenn Sie eine Vielzahl an Individuals in Protégé verwalten, werden Sie die Labels schnell zu schätzen wissen. Denken Sie etwa an IRIs mit UUIDs für Produkte wie das folgende:
Product_c2318c23_2db8_4c8b_9dbf_cd20970d7723
Im Protégé-UI ist hier das eigentliche Produkt nicht praktika- bel praktikabel identifizierbar. Versehen Sie es aber mit einem Label, so wird es mit eben diesem dargestellt. In der Beispiel-Ontolo- gie Ontologie sieht das dann so aus:
Blu-ray Player, HD, inklusive Kabel
...
Was in Protégé noch manuell erfolgt, lässt sich in Applikatio- nen Applikationen leicht automatisieren. Eine gute Praxis ist, für jede Klas- se Klasse eine Vorlage festzulegen, anhand der die Labels automa- tisch automatisch aus bestimmten Feldern der jeweiligen Individuals zu- sammengesetzt zusammengesetzt werden, für ein Produkt zum Beispiel aus den Feldern productCode und productName. Hierzu mehr in ei- nem einem späteren Artikel, wenn es um die Programmierung mit Ontologien und semantischen Graph-Datenbanken geht.
...
Da der Name von Individuals üblicherweise willkürlich und daher weder semantisch noch relational relevant ist, stellt sich die Frage, ob für derartige Angaben nicht grundsätzlich Annotationen statt Dateneigenschaften verwendet werden.
...
Den Renderer von Protégé einstellen (Bild 9)
Die Anzeige auf deutsche Labels umschalten (Bild 10)
...
sollten. Da Werte für Annotationen in SPARQL-Abfragen technisch ähnlich ermit-telt werden können wie die von Dateneigen- schaftenDateneigenschaften, erscheint dies legitim, insbesonde- re insbesondere um unnötige Redundanzen zu vermeiden. Und für überwiegend statische und manuell gepflegte Lookup-Listen oder Enumeratio- nen Enumerationen ist dies auch durchaus vertretbar.
Für dynamische Datenbestände kalkulie- ren kalkulieren Sie jedoch den manuellen Aufwand beim Erstellen gemischter Abfragen aus An- notationen Annotationen und Eigenschaften. Außerdem unterliegen Annotationen keinerlei Ein- schränkungen Einschränkungen – weder zu ihren Werten noch zu ihrer Kardinalität (Anzahl), was letztlich die Validierungsoptionen der Apps einschränkt und das Risiko von Mehrdeutig- keiten Mehrdeutigkeiten oder Inkonsistenzen erhöht.
Internationalisierung in Protégé, hier die deutschen Klassenbezeichner (Bild 11)
...
und ebenfalls konfigurierbare Reasoner. So kann Protégé der
Abfragen gegen Individuals von rein auf Eigenschaften ba- sierenden basierenden Klassen hingegen lassen sich leicht programma- tisch programmatisch und somit automatisch generieren. Individuals können programmatisch gegen die Property Constraints validiert und basierend darauf sogar SHACL-Shapes automatisch erzeugt werden. Hier eröffnet sich ein enormes Potenzial für Auto- matisierungen Automatisierungen und Produktivitätssteigerungen, die ein Folge- artikel Folgeartikel noch genauer beleuchten wird.
...
Zum Schluss dieses Beitrags sei noch ein Blick darauf gewor- fengeworfen, wie sich die in Protégé erzeugten Modelle für die Nut- zung Nutzung in W3C-konformen Graph-Datenbanken exportieren lassen. Dazu kann es aus Protégé einfach in einem der ange- botenen angebotenen Standardformate wie zum Beispiel RDF/XML, Turt- le Turtle oder JSON-LD gespeichert werden. Wählen Sie hierzu le- diglich lediglich den Menüpunkt File | Save As und selektieren Sie das gewünschte Format.
Semantische Graph-Datenbanken wie zum Beispiel Graph-DB von Ontotext verfügen über diverse Adapter, die den Im- port Import des Modells sehr vereinfachen. Für die Praxis empfiehlt es sich, Modell und Instanzen in getrennten Sub-Graphen zu verwalten. So ist es sehr leicht möglich, den Modellgraphen in der Datenbank nach Updates in Protégé zu aktualisieren, ohne dabei die bestehenden Daten zu gefährden.
...
Protégé ist ein ausgereiftes Werkzeug zum Modellieren von Ontologien und ein unverzichtbarer Assistent beim Erstellen und Warten von W3C-konformen semantischen Datenmodel- le Datenmodelle und Ontologien. Es bietet nützliche Funktionen, um Klas- seKlassen, Taxonomien, Eigenschaften und Constraints in einem für Entwickler komfortablen und konfigurierbaren UI zu verwal- tenverwalten, ohne sich um die darunterliegenden RDF-, RDFS- und OWL-Tripel und ihre vielfältigen Repräsentationen in den di- versen diversen Dateiformaten kümmern zu müssen.
Geschrieben ist Protégé in Java, es läuft somit auf allen Plattformen. Zur Seite stehen eine Vielzahl von Plug-ins, in- klusive inklusive solche für SPARQL, SHACL sowie unterschiedliche
umfangreichen Palette von Anforderungen an die Entwick-lung einer Ontologie gerecht werden, einschließlich Annota-tionen und Präfixen, IRI-Automatik und Internationalisierung bis hin zum Zusammenführen mehrerer Ontologien in Kata- logen Katalogen zum Aufbau umfangreicher Knowledge-Graphen.
Entworfen wurde Protégé als semantisches Modellierungs-Tool mit einer Import-/Export-Schnittstelle für alle gängigen W3C-konformen Dateiformate. Den effizienten Betrieb der eigentlichen Datenbank mit Millionen und Milliarden von Tripeln überlässt Protégé etablierten Herstellern wie etwa Ontotext oder Stardog, ebenso wie das eigentliche Wissens- management Wissensmanagement und die App-Entwicklung den Software- und Knowledge-Graph-Entwicklern überlassen bleibt.
Der nächste Artikel hierzu wird zeigen, wie Sie eine seman- tische semantische Graph-Datenbank einrichten und betreiben, ebenso wie Sie Daten und Wissen darin komfortabel verwalten und für Anwendungen bereitstellen. Bleiben Sie also dran! ■
[1] Alexander Schulze, Mit Wissen anstatt Daten arbeiten, Semantisches Web Teil 1, dotnetpro 4/2020, Seite 78 ff., http://www.dotnetpro.de/A2004Semantik
...
[4] Wikipedia, SHACL, http://www.dotnetpro.de/SL2006Semantik1
[5] GitHub Enapso ENAPSO dotnetpro Repository, http://www.dotnetpro.de/SL2006Semantik2
Alexander Schulze
Geschäftsführer der Innotrade GmbH, ist Ex-perte für semantisches Datenmanagement und Business Analytics. Als IT-Consultant, Speaker und Autor berichtet er regelmäßig über KI und Wissensmanagement und deren Nutzen. aschulze@innotrade.de
...