Diplomarbeit Extraktion und Erstellung einer Ontologie in verschiedenen XML-Formaten am Beispiel des Forschungsprojekts MetaChart This book is dedicated to you. Vorwort Some content is always required. Einführung
Motivation Das Wissen über den Standort von Information ist kaum mehr ohne Hilfsmittel vorstellbar. Die Angebote der Informationsspeicherung und des Internets [stellen] uns zwar mehr potenzielles Wissen zur Verfügung, aber die Praxis [zeigt], dass viele Menschen beim Wissenserwerb durch die Informationsfülle eher behindert denn gefördert werden bpv00. Die Informationsfülle droht zum Informationschaos zu werden, wo der sinngebende Kontext einer Information verloren geht. Das Ziel ist eindeutig die Informationssouverenität des Menschen: Das Informationsangebot so zu gestalten, dass der Überblick erhalten bleibt, Einblick, Erfassung und Aufnahme ermöglicht werden, um so schließlich das Verstehen und die Bildung von Wissen zu fördern. Wie Informationen abzulegen sind, damit dieses Ziel erreichbar wird, soll in dieser Arbeit untersucht werden.
Gliederung der Arbeit In werden grundlegende Begriffe geklärt. untersucht die vorhandenen Strukturen im MetaChart-Projekt. Die technische Umsetzung der Ontologieerstellung nach einer Klärung der dafür zugrundeliegenden Methoden der Wissensrepräsentation wird in dargestellt. Das Ergebnis wird in betrachtet. Konventionen Folgende Hervorhebungen werden benutzt: Fremdsprachige Ausdrücke und Eigennamen: kursiv Computerein- /ausgaben: dicktengleich Datenbanktabellen und -attribute: dicktengleich oblique
Ontologie als Teil der Metaphysik Metaphysik Philosophie Philosophie Metaphysik Etymologisch bedeutet Ontologie Ontologie Metaphysik Ontologie (griechisch ont-: seiend, logos: Lehre) die Lehre vom Sein, die zwischen Sein und dem Seienden unterscheidet. Als Teil der Metaphysik wird sie, von Aristoteles ausgehend, verstanden als Erste Philosophie, Philosophie insofern sie nach den ersten Gründen und Ursprüngen des Seienden als Seienden fragt Kunzmann99. Ontologisch erklärt sich die Existenz Existenz der Dinge aus ihrer Denkmöglichkeit. Martin Heidegger (1889–1976) formuliert: Ontologie ist das explizite theoretische Fragen nach dem Sein des Seienden. Anselm von Canterburys ontologischer Gottesbeweis beispielsweise akzeptiert, dass etwas, das man als Ziel allen vernünftigen Handelns ansieht, auch existieren müsse. Immanuel Kant kritisierte dies jedoch (in seiner Kritik der reinen Vernunft), indem er die Unmöglichkeit aufzeigte, vom Begriff Begriff Gottes auf sein Dasein Dasein Existenz zu schließen.
Daten, Information, Wissen Zur Erläuterung von Daten, Information, Wissen und deren Beziehung zueinander wird der sprachwissenschaftliche Begriff Semantik benötigt, der griechischen Ursprungs ist. Meyer92 Semantik Semantik Semiotik Semantik ist neben Syntaktik Syntaktik Semiotik Syntaktik und Pragmatik Pragmatik Semiotik Pragmatik ein Teilgebiet der Semiotik, der Lehre von der Entstehung, dem Aufbau und der Wirkweise von Zeichen und Zeichenkomplexen (Symbolen): Am Zeichen werden drei Dimensionen unterschieden: die Beziehung zwischen ihm und dem Bezeichneten (Semantik), die zwischen ihm und dem Verwender (Pragmatik) und die zwischen dem Zeichen und den anderen Zeichen im Rahmen des Zeichensystems (Syntaktik). Die Semantik befasst sich also mit den Bedeutungen sprachlicher Zeichen und Zeichenfolgen. In der Logik Logik versteht man unter Semantik die allgemeine Bezeichnung für die Theorie der Wahrheit logischer Sätze und Folgerungen, z. B. die Interpretation formaler Sprachen. Daten Daten sind bloße Kombinationen von Zeichen Zeichen und Symbolen. Symbol Schreibt man den Daten eine Syntax Syntax zu, die die erlaubte Anordnung der Zeichen eines definierten Zeichenvorrats beschreibt, so spricht man von Information(en). Information Wesentlich für eine Information ist, dass die Daten von einem Sender zu einem Empfänger gelangen und von diesem entschlüsselt, d. h. verstanden werden. Die Mindestvoraussetzung dafür ist eine gemeinsame Syntax, die die erlaubten Anordnungen eines Zeichenvorrats beschreibt. Die Art des Kommunikationsmediums spielt dabei keine Rolle. Nach Warren Weaver in einem Vorwort zu Shannons Mathematical Theory of Communication (1949) treten in der Kommunikation Probleme auf, die neben technischen Aspekten und den unberechenbaren Rezeptionseinflüssen der Kommunikationspartner auch die Semantik der übermittelten Symbole betreffen (vgl. Johnson00). Hier kommt die Abgrenzung von Wissen gegenüber Information zum Tragen: Informationen sind noch lange kein Wissen Korbmann01. Der Information im Vergleich zum Wissen fehlt Semantik. Wissen Wissen bezeichnet jedoch eine bedeutungsvolle Vernetzung von Informationen. Der Bedeutungsgehalt ist auf den Kontext Kontext der Situation bezogen, hängt vom Anwendungszweck ab und unterliegt damit auch subjektiven Faktoren Reimann00.
Wissen schaffen Nach Strassmann02 bleibe in Unternehmen bleibe zu viel Wissen ungenutzt. Ein Ziel des neuen Forschungszweigs Wissenmanagement Wissensmanagement seien Systeme, die auch das implizite Wissen Wissen implizites in den Köpfen der Mitarbeiter erfassen. Strassmann02 Es handelt sich dabei um tazites Wissen tazites Wissen – Wissen, das aus Erfahrungen gewonnen wird und den Handelnden oft gar nicht bewusst ist Reimann00. Diesen Schatz zu heben ist ein hartes Brot. […] Rechner sollten mit dem impliziten Wissen Wissen implizites am besten so umgehen wie wir Menschen: Wir legen unser Wissen (wahrscheinlich) in Mustern ab, die das Relevante dieses Wissens beschreiben. Gelänge es, den Wissensschatz im Hirn der Mitarbeiter in Muster zu übersetzen und zu digitalisieren, könnten Rechner es erfassen und sinnvoll vernetzen. Kontinuierlich ließe sich das Know-how der Experten am Arbeitsplatz absaugen und benutzerfreundlich präsentieren. Bloß, all das ist reine Zukunftsmusik, so Vajna in Strassmann02. Kreative Sitzungen (dort wird womöglich Wissen produziert!) können heute von einem Programm begleitet werden, das keine Brainstorming-Idee übersieht und implizites in explizites Wissen Wissen explizites umwandelt – aber nur, wenn die kreativen Köpfe ihre Gedanken dem Laptop anvertrauen Strassmann02. Dieses implizite Wissen zu externalisieren [… helfen] Methoden und Werkzeuge, die Gedanken, Konzepte und Vorgehensweisen dokumentieren können. Dazu zählen etwa Programme zur Darstellung von Mind Maps, die das Produkt einer Brainstorming-Sitzung sein können, Präsentationsgrafik-Software wie Microsoft Powerpoint, Diagramming-Werkzeuge wie Visio oder Programme zur Modellierung von Geschäftsprozessen, beispielsweise Aris (www.ids-scheer.de) Reimann00. Das Kreativitätswerkzeug MetaChart MetaChart Kreativitätswerkzeug MetaChart des Fraunhofer Instituts für Arbeitswirtschaft und Organisation (IAO) lässt sich nun hier als weiteres Beispiel anfügen.
Ontologie in der Informationswissenschaft Die philosophische Kategorienanalyse Kategorie als Richtung der Ontologie […] zielt auf die Herausarbeitung übergreifender Strukturen (kategoriale Gesetze) des Seins sowie der Eigengesetzlichkeiten verschiedener Seinsbereiche Brockhaus01 und trifft so recht gut den Begriff der Ontologie Ontologie im informationsverarbeitenden Kontext. The two major contributors to the development of formal ontology are the philosophers Charles Sanders Peirce Peirce Philosophie Peirce and Edmund Husserl Sowa01. Ontologien definieren allgemeine Begriffe Begriff (Konzepte), Konzept die dazu genutzt werden, ein Wissensgebiet zu beschreiben und zu repräsentieren. Ontologien werden von Menschen, Datenbanken und Applikationen verwendet, Informationen innerhalb von Domänen auszutauschen. Eine Domäne Domäne stellt dabei ein spezifisches Themengebiet dar. Ontologien beinhalten maschinenverständliche Definitionen der in der Domäne zugrunde liegenden Konzepte sowie auch domänenübergreifendes Wissen. Somit machen sie dieses Wissen wiederverwendbar. Mögliche Merkmale einer Ontologie Klassen (allgemeine Dinge) in den interessierenden Domänen Instanzen (einzelne Dinge) Beziehungen zwischen diesen Dingen Eigenschaften (Charakteristiken) dieser Dinge Einschränkungen (constraints) und Regeln für diese Dinge Klasse Taxonomie Instanz Taxonomie Taxonomie Klasse Taxonomie Instanz Ontologien werden meist in logikbasierten, formalen Sprachen dargestellt, um genaue, konsistente und sinnvolle Unterscheidungen zwischen den Klassen, Instanzen, Eigenschaften und Relationen machen zu können. Manche Ontologie-Werkzeuge können automatisch Folgerungen aus der Ontologie mittels definierten Regeln Regel Logik Regel ziehen. Eine Sichtweise auf Ontologien sind Schemata (Formatvorlagen) für Metainformationen, die deren Bedeutung strukturieren. Der Begriff der Ontologie ist sehr weitläufig und kann die simple Darstellung einer Taxonomie Taxonomie (Klassenhierarchie, -einteilung, Klassifizierung) Hierarchie über einen Thesaurus Thesaurus (Begriffe und deren Synonyme) bis hin zu Logiktheorien über komplexes, konsistentes Wissens meinen. Tom R. Gruber definiert: An ontology is a formal, explicit specification of a shared conceptualization und Ontologies establish a joint terminology between members of a community of interest. These members can be human or automated agents Gruber93. Konzeptualisierung conceptualization (conceptualization): Ein abstraktes Modell bestimmter Phänomene und Domänen mit deren identifizierten relevanten Begriffen. Explizit (explicit): Art und Bedingung eines jeden Begriffs werden explizit angegeben und definiert. Formal (formal) müssen Ontologien sein, um maschinenverständlich zu sein, was eine natürlichsprachliche Darstellung ausschließt. Gemeinsam (shared) signalisiert, dass es sich bei einer Ontologie nicht um eine einzelne, individuelle Ansicht von Wissen handelt, sondern um eine Darstellung, auf die sich eine bestimmte Benutzergruppe geeinigt hat und über die folglich ein Konsens besteht. Die Beschreibung der Gegenstände und deren Beziehungen zueinander, die für eine Gruppe von Personen begriffsbildend sind, müssen, um im Rahmen eines wissensbasierten Systems computergestützt verarbeitet werden zu können, formal definiert sein. Eingesetzt werden Ontologien in der Wissensverarbeitung zur Formalisierung Formalisierung Repräsentation der Wissensrepräsentation und zum Austausch von Wissen. Als Repräsentation Repräsentation wird das Aufschreiben von Symbolen Symbol bezeichnet, insbesondere wenn dazu Angaben vorliegen, wie die Merkmale der repräsentierten Welt abzubilden sind. Diese Merkmale werden Interpretationsvorschrift Interpretation genannt. (Vgl. Reimer91 S. 9) Dieter Fensel nennt Ontologien konsensuale und formale Spezifikationen von Begrifflichkeiten Fensel01. John F. Sowa schreibt: The subject of ontology is the study of the categories of things that exist or may exist in some domain. The product of such a study, called an ontology, Ontologie ontology Ontologie is a catalog of the types of things that are assumed to exist in a domain of interest.[…] By itself, logic says nothing about anything, but the combination of logic Logik with an ontology provides a language that can express relationships about the entities in the domain of interest Sowa01. entity Entität Entität Vereinfacht dargestellt sind Ontologien, wie es James Hendler und auch Fensel ausdrücken, machine-readable semantics. semantics Semantik Semantik Ihr Sinn liegt in der Ermöglichung der Kommunikation zwischen Computern, und zwar losgelöst von der jeweiligen, individuellen Technologie, der Informationsorganisation und dessen Anwendungsgebiet. Dazu ist primär ein Basiswortschatz und eine exakte Definitionen der enthaltenen Begriffe vorauszusetzen. Die Verbindung zum Ontologiebegriff im klassischen Sinne liefert Anderson00 mit der Frage, an welchem Punkt man eine metaphysische Diskussion beginnen müsse, ob eine Maschine überhaupt etwas verstehen könne. Als Antwort darauf ist anzuführen: The computer doesn’t truly understand any of this information, but it can now manipulate the terms much more effectively in ways that are useful and meaningful to the human user Berners01a. Für Tim Berners-Lee ist damit die Vision des Semantic Webs in erreichbare Nähe gerückt: Das Semantic Web soll von sich aus Aufgaben des Alltags bewerkstelligen können: The Semantic Web is a computer system, a distributed machine which should function so as to perform socially useful tasks Berners98. Konkreter formulieren die Experten Tim Berners-Lee, James Hendler und Ora Lassila: The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation Berners01.
Das Forschungprojekt <wordasword>MetaChart</wordasword>
Die <wordasword>MetaChart</wordasword>-Idee Das Projekt MetaChart MetaChart stellt eine Art Adaption der Kreativitätstechnik Metaplan Metaplan Kreativitätstechnik Metaplan als Java-Applikation zur Verfügung. Durch die Verwendung von Java und der Enterprise Java Beans-Technologie ist Plattformunabhängigkeit gegeben. Das erarbeitete Konzept ermöglicht verteiltes, also nicht ortsgebundenes, gruppenbasiertes, kreatives Arbeiten. Die Ideenfindung wird dabei durch eine intuitive Benutzeroberfläche mit Stiftgestenerkennung sowie Spracheingabe unterstützt. Metaplan (auch: Moderationsmethode, Kärtchentechnik) ist eine Kreativitäts- und Strukturierungsmethode, die unter anderem deshalb etwa 1975 entwickelt wurde, um bei der Ideenfindung nicht nur auditive Sinne, sondern auch visuelle und haptische Sinne anzusprechen und zu fordern. Dabei werden Ideen stichwortartig auf Karten festgehalten und auf einer großen Pinnwand positioniert, um der Visualisierung Rechnung zu tragen. Die Methode wird überwiegend zur zielorientierten Gestaltung von Kommunikations- und Kooperationsprozessen innerhalb von Gruppen, insbesondere zur Ideensammlung, Idee Strukturierung Struktur und Visualisierung eingesetzt. Sie kann nach Scholles98 damit in verschiedenen Anwendungsfeldern hilfreich sein: Themenspeicher bei Ideensammlung Ideenproduktion Strukturierung und Gliederung von Ideen oder Problemen logische Verknüpfung von Sachverhalten Ursachenanalyse Prioritätenbildung Bewertung von Lösungsansätzen Als Nachteil der konventionellen-Metaplan-Technik ist die fehlende Möglichkeit der informationstechnischen Weiterverarbeitung zu nennen, was bei der Pinnwand bestenfalls durch Abfotografieren initiiert werden kann. (Vgl. Magerkurth01) Dieser Nachteil wird mit MetaChart ausgeglichen. In der MetaChart-Welt heißen die Ideenkarten MetaCharts. Sie dienen als Container für Informationen beliebiger Art und strukturieren diese. Die dem MetaChart zugedachte Idee kann durch sogenannte MetaChart-Attributes ergänzt werden. Attribute Attribut bedeuten hier mediale Objekte, wie z. B. Texte und Grafiken sowie beliebige Dateien, die auch per Drag and Drop eingebunden werden können: According to model-view-controlling (Krasner and Pope, 1988), each member of the group may simultaneously work at the same model and therefore interact from any place on a shared work space. Modifications of the model layer, e. g. adding attributes, creating links or structuring information objects, are visible to all participants mttwz01. Durch die Rekursionsfähigkeit Rekursion der MetaCharts können Hierarchien Hierarchie beliebiger Tiefe erzeugt werden; Querverbindungen werden durch Kanten zwischen (allen vier Kombinationsmöglichkeiten von) MetaCharts und MetaChart-Attributes ermöglicht: Kante Assoziation Objects (visualized by a rectangle) can be arranged graphically in two ways: One rectangle can be contained in another or two rectangles can be associated via an arrow. In addition, each rectangle can be associated with a set of attributes (content) and metadata (describing data) mttwz01. (Siehe auch ) Das vorgestellte Werkzeug zur strukturierten Erfassung und Aufbereitung von Informationen zu den verschiedensten Themenbereichen innerhalb einer Gruppe liefert mit der zugrundeliegenden relationalen Datenbank Datenbank relational einen interessanten Ausgangspunkt zur Erstellung einfacher Ontologien auf der Repräsentationsebene. Examples of formal ontologies include theories in science and mathematics, the collections of rules and frames in an expert system, and specification of a database schema in SQL [Structured Query Language] Sowa01.
Datenbankstruktur Die relationale MetaChart-Datenbank (mcdb) ist auf einem Oracle 8i-System realisiert. Die enthaltenen Tabellen spiegeln die angesprochene Aufteilung zwischen MetaCharts und den MetaChart-Attributes wider; sie trennen deren Metadaten und Darstellungsdaten, genannt Views, von den Inhalten. Als singulärer Punkt für den Content an sich steht das Feld value der Tabelle attributes zur Verfügung. Als zentrale Tabelle des vernetzten Modells ist die Tabelle meta_charts anzusehen; diese Tabelle enthält das Wurzelelement der MetaChart-Hierarchie und geht die meisten Beziehungen mit anderen Tabellen.
Relationenschema der <wordasword>MetaChart</wordasword>-Datenbank
Relation Beziehung Tabelle Primärschlüssel Schlüsselkandidat Relationenshema Datenbank Relation Datenbank Tabelle Datenbank Beziehung Datenbank Primärschlüssel Datenbank Schlüsselkandidat Datenbank Relationenschema Im Folgenden werden die im MetaChart-Projekt vorhandenen Tabellen und deren Beziehungen zueinander erläutert. Da das Projekt noch nicht abgeschlossen ist, ist hier mit eventuellen Veränderungen/Optimierungen zu rechnen. Schlüsselkandidaten (Candidate Keys) bedeuten dabei minimale, identifizierende Attributkombinationen. Einer dieser Schlüsselkandidaten kann als Primärschlüssel ausgezeichnet sein. (Dies ist beispielsweise nicht der Fall bei meta_datas: mc_id und attr_id sind hier alternativ zu besetzen.) In sind Schlüsselkandidaten fett ausgezeichnet; die Fremdschlüssel (FK) verweisen auf die Primärschlüssel (PK) der referenzierten Tabelle.
Relationenschemata und deren Attribute Attribut Datenbank Attribut
<database moreinfo="none">meta_charts</database> MetaCharts treten in verschiedenen Rollen auf. Sie enthalten wiederum MetaCharts oder verweisen auf andere Entitäten. Primary Key: mc_id mc_id VARCHAR(30) PRIMARY KEY Das Attribut mc_id wird wie jede ID als String mit einer maximalen Länge von dreißig Zeichen abgelegt. IDs gehorchen im MetaChart-Projekt folgender, als regulärer Ausdruck (siehe perlre) notierten Syntax: ([a-z]+)([0-9]+); mc_ids im Speziellen mc[0-9]+. type VARCHAR(50) NOT NULL Das Attribut type beschreibt die Ausprägung des MetaCharts, wodurch sich die MetaCharts in Kategorien einteilen lassen. Derzeit sind nur Informationscharts definiert. owner VARCHAR(30) NOT NULL REFERENCES meta_charts Das Attribut owner verweist auf das MetaChart, das den User (Benutzer) identifiziert, dem dieser MetaChart gehört. (Benutzer und Benutzergruppen mit Name und Logindaten werden als MetaChart angelegt.) parent VARCHAR(30) DEFAULT NULL REFERENCES meta_charts Das Attribut parent verweist auf den Vater des MetaCharts. Ist kein Wert angegeben, so handelt es sich um ein Wurzelelement. Mehrere Wurzelelemente sind möglich, da jede kreative Sitzung (session) ihre eigene Wurzel besitzt. Zur Rekursion der MetaCharts siehe .
<database moreinfo="none">attributes</database> MetaChart-Attributes sind die Inhaltsträger für sowohl konkrete als auch abstrakte Inhalte. Primary Key: attr_id attr_id VARCHAR(30) PRIMARY KEY MetaChart-Attributes sind über attr_id identifizierbar. mc_id VARCHAR(30) NOT NULL REFERENCES meta_charts MetaChart-Attributes werden durch diesen Fremdschlüssel dem MetaChart eindeutig zugeordnet. Es kann kein MetaChart-Attribute ohne MetaChart existieren. type VARCHAR(50) NOT NULL Das Attribut type weist dem MetaChart-Attribute einen Typ zu, mit dem die Art des MetaChart-Attributes angegeben wird, beispielsweise text/plain oder image/png. Das Attribut ist unabdingbar zur korrekten Rückwandlung des value-Wertes im Tupel. value LONG RAW Hier werden die eigentlichen Informationen, die ein MetaChart-Attribute trägt, als binary stream gespeichert. Der Typ LONG RAW erlaubt die Speicherung großer Datenmengen.
<database moreinfo="none">meta_datas</database> Diese Tabelle nimmt Metainformationen sowohl der MetaCharts als auch der MetaChart-Attributes auf. Candidate Keys: mc_id und attr_id mc_id VARCHAR(30) DEFAULT NULL Ist mc_id besetzt, so bedeutet dies die Zugehörigkeit der Metadaten zum MetaChart mit dieser ID. Wird dieses Attribut gesetzt, so muss das Attribut attr_id auf jeden Fall NULL sein und vice versa. Jedoch muss eines der beiden Attribute gesetzt sein. (Diese Integritätsprüfung ist derzeit durch eine stored procedure realisiert.) attr_id VARCHAR(30) DEFAULT NULL Ist attr_id besetzt, so bedeutet dies die Zugehörigkeit der Metadaten zum MetaChart-Attribute mit dieser ID. Hier gilt Analoges zu mc_id. type VARCHAR(50) NOT NULL Metainformationen werden anhand type charakterisiert. Explizite Werte sind nicht festgelegt; als Beispiel sind jedoch createDate und title zu nennen. value VARCHAR(2000) In diesem Attribut wird die eigentliche Metainformation gehalten. Sie wird durch einen String repräsentiert.
<database moreinfo="none">views</database> Views beschreiben die Darstellung der MetaCharts, z. B. durch Angabe der Rechteckskoordinaten oder der Hintergrundfarbe. Primary Key: {view_id, mc_id, type} view_id VARCHAR(30) NOT NULL Jeder View hat eine ID, unter der mehrere type/value-Kombinationen angelegt sind. mc_id VARCHAR(30) NOT NULL REFERENCES meta_charts Das mc_id zeigt verweist auf das MetaChart, das mit diesem View dargestellt wird. gr_us_id VARCHAR(30) DEFAULT NULL REFERENCES meta_charts Das mc_id zeigt den Besitzer des Views (User, auch Group) an, der als MetaChart identifiziert wird. type VARCHAR(50) NOT NULL Im Attribut type wird der Typ des Attributs value durch einen String spezifiziert. Im Beispiel von oben wäre dies etwa rect und backgroundcolor. value VARCHAR(2000) Das Attribut value enthält den Wert der durch type spezifizierten View-Information. Views werden in noch diskutiert.
<database moreinfo="none">attribute_views</database> Die Darstellung der MetaChart-Attributes wird analog zu views mit dieser Tabelle bestimmt. Primary Key: {attr_id, view_id, type} attr_id VARCHAR(30) NOT NULL REFERENCES attributes Das Attribut attr_id verweist auf das MetaChart-Attribute, das mit diesem View dargestellt wird. view_id VARCHAR(30) NOT NULL REFERENCES views Das Attribut view_id verweist auf den zugehörigen MetaChart-View. So wird auch die Verbindung zum besitzenden User-/Group- MetaCharts festgelegt. type VARCHAR(50) NOT NULL Im Attribut type wird der Typ des Attributs value durch einen String spezifiziert. Als Beispiele wären dieselben wie in views.type anzuführen. value VARCHAR(2000) Das Attribut value enthält den Wert der durch type spezifizierten View-Information.
Beziehungen zwischen den Relationenschemata Kardinalität Datenbank Kardinalität meta_datas beschreiben meta_charts Kardinalität one-to-many: jedem Eintrag in meta_datas ist genau ein Eintrag in meta_charts zugeordnet. views stellen meta_charts dar Kardinalität one-to-many: jedem Eintrag in views ist genau ein Eintrag in meta_charts zugeordnet. attributes gehören meta_charts Kardinalität one-to-many: jedem Eintrag in attributes ist genau ein Eintrag in meta_charts zugeordnet. meta_datas beschreiben attributes Kardinalität one-to-many: jedem Eintrag in meta_datas ist genau ein Eintrag in attributes zugeordnet. attribute_views stellen attributes dar Kardinalität one-to-many: jedem Eintrag in attribute_views ist genau ein Eintrag in attributes zugeordnet. views besitzen attribute_views Kardinalität one-to-many: jedem Eintrag in attribute_views ist genau einem Eintrag in views zugeordnet. views gehören meta_charts Kardinalität one-to-many: jedem Eintrag in views ist genau ein Eintrag in meta_charts zugeordnet. Ein View gehört einem User/einer Group, der/die durch ein MetaChart definiert ist.
Normalform Normalform Datenbank Datenbank Normalform Datenbank Atomizität Zur Betrachtung des Datenbankschemas bezüglich Normalformen wird Atomizität auch für abgelegte Java-Objekte oder Spezialfälle wie z. B. Rechteckskoordinaten oder RGB-Farbwerte angenommen, da diese Werte für sich eine semantische Einheit bilden und da es sich um ein sehr generisches, d. h. auch flexibles Schema handelt, das (ähnlich wie Topic Maps, siehe ) mit relativ einfachen Mitteln, die Darstellung komplexer Strukturen erlaubt. Die Relationen der mcdb befinden sich mindestens in der ersten Normalform (1NF), da alle Attribute im obigen Sinn atomar sind. Fürderhin gelten die Elemente einer Domäne in SQL stets als atomar. Die zweite Normalform (2NF) ist jedoch nicht gegeben, da das Relationsschema Views Attribute enthält, die nicht Schlüssel sind, aber voll funktional abhängig von Schlüsselkandidaten sind: Das Nichtschlüsselattribut gr_us_id ist von den Teilattributen view_id und mc_id ab. (view_id tritt redundant auf.) Die dritte Normalform (3NF) läge vor, wenn das Schema der 2NF genügte und kein Nichtschlüsselattribut transitiv abhängig von einem Schlüsselattribut wäre.
Mögliche Optimierung untersucht eine mögliche Optimierung des vorhandenen Relationenschemas mit Hinblick auf eine höhere Normalform.
<foreignphrase>Entity Relationship Model</foreignphrase> via <foreignphrase>Reverse Engineering</foreignphrase> Unter reverse engineering ist im Bereich der Datenbanken die Erstellung eines Entity Relationship Models anhand bestehender Tabellen und der zugrundeliegenden Semantik zu verstehen. Als Entity Relationship Model (ER-Modell) bezeichnet man die grafische Repräsentation eines Formalismus' zur Beschreibung konkreter Anwendungsfälle mit Hinblick auf die Transformation in ein Datenbankmodell. Das Ziel des reverse engineering-Prozesses ist es, ausgehend von einem logischen Schema einer existierenden Datenbank eine konzeptionelle Beschreibung der betreffenden Anwendung zu erzeugen, d. h. zum Beispiel ausgehend von einer SQL-Schemadeklaration […] auf ein ER-Diagramm für die Anwendung zu kommen Vossen00. Im Gegensatz zum forward engineering, dem klassischen Entwurfsprozess, der in Anforderungsanalyse konzeptioneller Entwurf logischer Entwurf physischer Entwurf gegliedert ist, wird für ein reverse engineering zumeist Benutzerinteraktion benötigt. (vgl. Vossen00)
Entitäten und Relationen in <wordasword>MetaChart</wordasword> Unter Betrachtung des vorhandenen relationalen Modells und dessen geschilderten Einsatzzwecks nach sind folgende Entitäten (Entities) zu erkennen: MetaChart (MC) MetaChart-Attribute (A) MetaData (MD) View (V) ViewData (VD) User (U) Diese gehen folgende Beziehungen (Relations) ein: Entitäten Beziehung MC—A MetaChart bettet MetaChart-Attribute ein MD—MC MetaData beschreibt MetaChart MD—A MetaData beschreibt MetaChart-Attribute U—MC User ist ein MetaChart V—MC View stellt MetaChart dar V—A View stellt MetaChart-Attribute dar V—U View gehört User VD—V ViewData beschreibt View Die grafische Darstellung liefert zusätzlich die jeweiligen Kardinalitäten zu den Beziehungen zwischen den Entitäten:
<foreignphrase>Entity Relationship Model</foreignphrase>
Die drei dominanten Entitäten metachart, attribute und view sind ähnlich in Anbetracht ihrer weak entities (schwache Entitäten sind nur durch ihre Beziehung zum Besitzer identifizierbar; im ER-Modell gekennzeichnet durch Doppellinien): metachart und attribute besitzen jeweils die schwache Entität metadata, view besitzt die schwache Entität viewdata.
Transformation in ein relationales Modell Das aus obigem Entity Relationship Model projizierte relationale Modell entspricht dem vorhandenen, in vorgestellten Modell mit Ausnahme der Entitäten View und ViewData. Die weak entities werden im relationalen Modell durch Referenzen zu ihrem Besitzer aufgelöst, d. h. sie enthalten den Primärschlüssel (Primary Key) des Besitzers als Fremdschlüssel. Im Beispiel der MetaData-Entität sind dies zwei Fremdschlüssel, die jedoch NULL-Werte zulassen, um die alternative Referenzierung, wie in beschrieben, zu ermöglichen. Die Auflösung der weak entity View bedarf in ihrer Tabelle views einer ID (gr_us_id) zur Fremdschlüssel-Referenzierung des besitzenden meta_charts.mc_ids (Group/User). Ähnlich der Tabelle meta_datas soll nun eine Tabelle views sowohl zur Darstellung der MetaCharts als auch der MetaChart-Attributes reichen. D. h., auch hier sind zwei Attribute mc_id und attr_id, die alternativ besetzt auf die jeweilige Tabelle meta_charts bzw. attributes verweisen. In einer Tabelle view_datas sind die Beschreibungen (Darstellungsdaten) der Views abgelegt, d. h. view_datas referenziert wiederum views, wozu eine view_id, die als Primary Key in views angelegt wird, sinnvoll erscheint. Die zwei Tabellen sind folgendermaßen aufzubauen: Attribute der Tabelle <database moreinfo="none">views</database> view_id PRIMARY KEY gr_us_id REFERENCES meta_charts mc_id NULL REFERENCES meta_charts attr_id NULL REFERENCES attributes Attribute der Tabelle <database moreinfo="none">view_datas</database> view_id REFERENCES views type value Primary Key {view_id, type} Für den Relationship-Typ is a in User is a MetaChart reicht laut Vossen00 die Hinzunahme zu bereits existierenden Relationenschemata, also hier zur Tabelle meta_charts, da keine weitere Spezialisierung in User gegenüber MetaChart vorliegt. Dies entspricht der tatsächlichen Modellierung. Durch die Erstellung der zusätzlichen Tabelle viewdata und den damit verbundenen Schlüssel-Änderungen liegt das Datenbankschema in dritter Normalform vor.
Rekursion der <wordasword>MetaCharts</wordasword> Die Rekursion der MetaCharts kommt durch die Angabe einer mc_id in parent der Tabelle meta_charts zustande. Steht beispielsweise im Tupel der meta_charts mc01 als parent zu mc02, so definiert dies mc02 als Child-MetaChart zu mc01. mc_id parent mc01 — mc02 mc01 mc03 mc01 mc04 mc02 Diese Tupel in meta_charts ergeben folgende Struktur: <wordasword>MetaChart</wordasword>-Hierarchie MetaChart mc01 MetaChart mc02 MetaChart mc04 MetaChart mc03
Assoziationen der <wordasword>MetaCharts</wordasword> Querverweise zwischen MetaCharts und MetaChart-Attributes heißen im MetaChart-Projekt Assoziationen. Folgende vier Kombinationen sind dabei möglich: Quelle (source) Ziel (destination) MetaChart MetaChart MetaChart MetaChart-Attribute MetaChart-Attribute MetaChart MetaChart-Attribute MetaChart-Attribute Das generische Datenbankschema enthält keine explizite Relation für Assoziationen. Diese werden vielmehr als MetaChart-Attribute desjenigen MetaCharts abgelegt, das als Quelle der Assoziation eingetragen ist. Das Feld value der Tabelle attributes wird dabei mit einem Java-Objekt de.fhg.iao.metachart.Edge beschrieben. Assoziationen sind durch vier IDs bestimmt: source-mc_id, source-ID, destination-mc_id, destination-ID. Zu den direkten source- und destination-IDs werden auch immer die mc_ids derjenigen MetaCharts abgelegt, denen die teilnehmenden Assoziationspartner angehören. Im Falle der Teilnahme eines MetaCharts an der Assoziation wird dessen ID demnach mehrfach (redundant) abgelegt.
Realisierung der Repräsentation
Hilfsmittel zur Wissensrepräsentation
Semantische Netze
Konzepte Konzept Unter einem Konzept werden alle konkreten und abstrakten Dinge verstanden, die Beschreibungsgegenstand sind und über die Aussagen vorliegen. Die Bezeichnung Konzept ist aus dem englischen concept abgeleitet und meint dasselbe wie die Bezeichnung Begriff, nur ist im Feld der Künstlichen Intelligenz (KI) erstere gebräuchlich. (Vgl. Reimer91 S. 16) Künstliche Intelligenz Artificial Intelligence Künstliche Intelligenz Die Merkmale eines Konzepts werden durch Eigenschaften beschrieben, die sich insofern von Konzepten unterscheiden, als primär keine weiteren Aussagen über sie gemacht werden. Eigenschaften werden auch als Attribute oder Attributwerte bezeichnet – vergleichbar mit den Attributen im Bereich der relationalen Datenbanken (siehe ). Aussage
Semantische Beziehungen Semantische Beziehung Beziehung Beziehung semantische Relation Konzepte werden neben ihren Eigenschaften auch durch ihre Beziehungen zu anderen Konzepten charakterisiert. Diese semantischen Beziehungen (Relationen) bilden Aussagen zu zwei (oder auch mehreren) Konzepten. Zu untergliedern sind semantische Beziehungen u. a. in folgende Beziehungstypen; bei manchen kann Transitivität gegeben sein: Teil-von-Beziehung Kausal-Beziehung Instanz-von-Beziehung is-a-Beziehung (type-subtype-relation) Aussagen werden durch eine Darstellung wie xRy , mit R als Relation und x, y, z als Konzepten, formalisiert. Transitivität ist gegeben, wenn gilt: Transitivität
Transitivität
Beispielsweise muss dies nicht immer für eine Teil-von-Beziehung gelten: physisch ist ein Griff Teil einer Tür und somit auch Teil eines Hauses; funktional jedoch nur Teil der Tür. Diese Unterscheidung wird jedoch nicht auf der Beziehungstypebene getroffen. (Vgl. Reimer91 S. 18) Die Unterscheidung zwischen Konzepten, Eigenschaften und semantischen Beziehungen ist nicht a priori festgelegt. Wird eine Eigenschaft oder eine Beziehung näher beschrieben, erhält diese Konzeptcharakter.
Konzeptklassen Konzept Klasse Instanz Individualkonzept Konzept Objekt Bei Konzepten ist zwischen Konzeptklassen und Individualkonzepten zu unterscheiden. Eine Konzeptklasse steht dabei für eine Menge gleichartiger Objekte (Klassenelemente). Das Individualkonzept hingegen enthält nur ein Objekt. Zu jeder Konzeptklasse gibt es eine Menge von Individualkonzepten; die semantische Beziehung zwischen den beiden nennt sich Instanz-von-Beziehung. Dabei erhält (erbt) ein Individualkonzept alle Merkmale, die auch der Konzeptklasse innewohnen. Die Unterscheidung zwischen Klasse und Instanz ist in vielerlei Bereichen zu sehen; am bekanntesten ist wohl die objektorientierte Programmierung, aber auch bei XML-Applikationen tritt diese Distinktion auf (siehe auch ). Von Unterklassen Unterklasse Klasse Klasse Unterklasse spricht man, wenn es zu Konzeptklassen speziellere Konzeptklassen gibt, die einen Unterbegriff des durch die erste Konzeptklasse beschriebenen Begriffs darstellt. Unterklassen definieren speziellere Merkmale zu den von der Konzeptklasse vererbten Merkmalen. Die Ober-/Unterbegriffsbeziehung, die zwischen Klassen und Unterklassen herrscht, ist eine is-a-Beziehung. Beispiel: Cat is-a[n] Animal. Der Unterschied zwischen den beiden semantischen Beziehungen (Instanz-von, is-a) besteht demnach darin, dass im ersten Fall ein einzelnes, konkretes, individuelles Objekt in Beziehung gebracht wird, das Element aus der Konzeptklasse ist; im zweiten Fall ist eine (verschiedene) Teilmenge der Elemente/Objekte der Konzeptklasse zu verstehen, die eine speziellere Konzeptklasse für sich bilden. Die Menge aller Konzeptklassen mit den zwischen ihnen bestehenden is-a-Beziehungen ist als Hierarchie Hierarchie definiert. (Vgl. Reimer91 S. 20) A type hierarchy is a partial ordering of concept types by the type-subtype relation Sowa01.
Bäume und Wälder (Graphentheorie) Ein Graph G Graph ist ein geordnetes Tripel Tripel (N, E, A), wobei N die Menge der Knoten Knoten oder Ecken (nodes), E die Menge der Kanten (edges) und A eine Abbildung (Relation) von E in die geordneten oder ungeordneten Paare aus N bezeichnet. Relation Graph geordnet Graph ungeordnet Eine Kante Kante edge Kante n von G heißt gerichtet, wenn A(n) ein geordnetes Paar von Knoten ist. Hat G nur gerichtete Kanten, so heißt G gerichteter Graph oder Digraph. G heißt einfach, wenn A bijektiv (1-1-deutige Relation von E auf N) ist. Ein konverser (entgegensetzter) Graph wird mit G-1 bezeichnet. Ein gerichteter Graph kann zwischen zwei Knoten durchaus mehrere Kanten haben. Solche Kanten nennt man Mehrfachkanten; haben zwei Mehrfachkanten die gleiche Richtung, so sind sie parallel. Ein Graph mit Mehrfachkanten heißt auch Multigraph. Dieser ist nicht 1-1-deutig. (Vgl. Vachenauer97) Für einen Digraph bedeutet ein Weg/Pfad eine Folge von Kanten, so dass der Endknoten einer jeden Kante der Anfangsknoten der nächsten ist. Fallen Anfangs- und Endknoten zusammen, so liegt ein Kreis (Zyklus) vor. Zyklus Graph Zyklus Kreis Zyklus Ein Graph, der keinen Kreis enthält, ist ein Wald. Ein zusammenhängender Wald ist ein Baum, also ein zusammenhängender Graph ohne Zyklen, in dem genau ein Knoten, die Wurzel, den Eingangsgrad 0 hat und alle anderen Knoten den Eingangsgrad 1 haben. Ein Baum entspricht demnach der Darstellung einer Hierarchie. Baum Hierarchie Graph Baum Ist jeder Knoten eindeutig identifizierbar, so ist der Graph geordnet. Graph geordnet Topologie Dies ist Grundvoraussetzung zur Sortierung der (Baum-)Knoten. Es gibt verschiedene topologische Sortierungen für Bäume. Als die beiden wichtigsten sind die Tiefensuche (auch kanonische Suche genannt) und die Breitensuche zu nennen. Bei der Tiefensuche wird erst ein Weg bis zum Blatt durchlaufen um anschließend im nächsten Teilbaum wieder den direkten Weg bis zum Blatt einzuschlagen. Mit der Methode der Breitensuche hingegen würden jeweils zuerst alle Knoten einer Ebene durchlaufen. (Vgl. Diestel00) Tiefensuche Baum Breitensuche Baum
Conceptual Graphs Conceptual Graphs konzepueller Graph Conceptual Graphs Graph konzeptueller Conceptual Graphs Als Möglichkeit zur formalen Wissensrepräsentation Wissensrepräsentation wurde von John F. Sowa die Theorie der konzeptionellen Graphen (Conceptual Graphs, CG) entwickelt. Sie definiert Graphen und das Regelwerk, mit dessen Hilfe die Graphen modelliert werden können. Sie beruht auf der von Charles Sanders Peirce formulierten Logik mit ihren existenziellen Graphen und auf den semantischen Netzen der Künstlichen Intelligenz (KI): Künstliche Intelligenz Logik Peirce They express meaning in a form that is logically precise, humanly readable, and computationally tractable. With a direct mapping to language, conceptual graphs serve as an intermediate language for translating computer-oriented formalisms to and from natural languages. With their graphic representation, they serve as a readable, but formal design and specification language Sowa01. <foreignphrase>Existential Graphs</foreignphrase> nach Peirce By an existential relation I mean any relation R, such that anything that is R to x (where x is some particular kind of object) is nonexistent in case x is nonexistent. Thus lovers of women of bright green complexions are nonexistent in case there are no such women Sowa01. Relation existenzielle Ein CG besteht aus Knoten Knoten und verbindenden gerichteten Kante Kanten. Sowohl Konzepte Konzept als auch Relationen werden als Knoten bezeichnet; die Verbindung zweier Relationen ist dabei ungültig. Diese disjunkte Trennung zwischen Konzepten und Relationen erlaubt somit keine genauere Beschreibung der Relationen mittels Relationen, wie in angedeutet. Sowa definiert Konzepte hier als etwas, das auf eine Entität, eine Sammlung oder einen Bereich von Entitäten verweist. Entitäten sind dabei alles, was existiert, existierte und existieren könnte; also Objekte aus der realen Welt. Entität Grafisch werden Konzepte durch Rechtecke, Relationen durch Ellipsen und die Kanten als Pfeile dargestellt. In der linearen Notation sind die Konzepte mit eckigen Klammern, die Relationen mit runden einzuschliessen: [Cat]->(On)->[Mat] Als Beispiel wird in der Literatur gern Eric Mottrams (1924-1995) Stabreim The cat sat on the mat bzw. Die Katze saß auf der Matratze angeführt. [Cat] repräsentiert dabei eine Instanz Instanz einer Katze, [Mat] eine Instanz einer Matratze. Die Conceptual Relation (On) verbindet die zwei Instanzen:
<foreignphrase>Conceptual Graph</foreignphrase>
Das Modell der Conceptual Graphs ist in vielen Punkten im Resource Description Framework wiederzuerkennen. (Siehe )
Netze Semantisches Netz Konzept Eine Anzahl von Konzepten, die semantisch in Beziehung zueinander stehen, läßt sich als Netzwerk darstellen, in dem Knoten die Konzepte und Kanten die Beziehungen versinnbildlichen und so Aussagen bilden, die miteinander vernetzt werden. Semantische Netzwerke gewinnen ihre Ausdrucksstärke durch unterschiedliche Kantentypen. Die Modellierung mit semantischen Netzen steht nach Reimer unter der Vereinbarung der Namenseindeutigkeit der Knoten sowie der Einmaligkeit der Knoten, d. h. jeder Knoten (oder jedes Konzept) ist ein Unikat, definiert durch seine Beschriftung. Die Typisierung der Kanten wiederum ist auf verschiedenen Ebenen anzusiedeln. Kantentypen wie is-a, hat-Teil und synonym sind domänenunabhängig, also epistemische Primitive, die a priori als Grundvokublar anzusehen sind. (Vgl. Reimer91 S. 15f;)
Prädikatenlogik und Inferenz Logik kann dazu herangezogen werden, Wissen zu repräsentieren und Schlussfolgerungen auf diesem Wissen zu ermöglichen. Ihre Attraktivität liegt dabei in der schon eingeführten Syntax und Semantik sowie in der Bereitstellung eines Schlussfolgerungsapparats. Prädikatenlogik Logik Prädikatenlogik Interessant in Bezug auf Wissensrepräsentation Wissensrepräsentation ist die Prädikatenlogik, in der sich Variablen nur auf Funktionssymbole, nicht aber auf Prädikatsymbole beziehen können (Reimer91 S. 29). D. h., es sind keine weiteren Aussagen über die Prädikate möglich, was analog zu den Relationen der conceptual graphs zu sehen ist. In der (klassischen) Aussagenlogik sind Aussagen atomar, d. h. es sind keine Aussagen über Teile der Aussagen möglich. Aussage Konzept In der Prädikatenlogik stehen Terme für Objekte und somit für Konzepte, während Formeln Aussagen über Objekte darstellen. (Vgl. Reimer91 S. 29) Ein wesentliches Merkmal dieser Logik besteht darin, dass unter Zuhilfenahme von Inferenzregeln Inferenz Regel Inferenzregel neue Aussagen abgeleitet werden können. Aus einer impliziten wird eine explizite Darstellung, was menschlichem Schlussfolgern sehr nahe kommt. Eine allgemein bekannte und in der KI am häufigsten angewandte Inferenzregel ist der modus ponens, der auf Implikation Implikation basiert. Darum wird auch in der KI oft einfache Induktion schon als Inferenzregel bezeichnet. Der modus ponens besagt, dass eine Aussage b dann wahr ist, falls a gilt und aus der Aussage a die Aussage b folgt. (Vgl. Reimer91 S. 33) Inferenzregeln werden wie folgt notiert: Allgemeine Inferenzregel a,b>c a b - c Auf is-a-Relationen bezogen, bedeutet dies: Für x is-a y und y is-a z gilt x is-a z. Inferenz der <foreignphrase>is-a</foreignphrase>-Relation x is-a y is-a z x is-a y y is-a z -------- x is-a z Somit ist die is-a-Relation als transitiv definiert. Transitivität Verbunden mit CG ist folgendes Beispiel anzuführen: Inferenz mit <foreignphrase>Conceptual Graphs</foreignphrase> cat [Cat]-->(is-a)-->[Mammal] [Mammal]-->(is-a)-->[Animal] ---------------------------- [Cat]-->(is-a)-->[Animal] Um Redundanz zu vermeiden, könnten derartige transitive Kanten bei der Modellierung einer Wissensrepräsentation weggelassen werden. Hier ist auch eine Analogie zur dritten Normalform im Datenbankdesign zu sehen, bei der dies Voraussetzung ist ().
XML und Semantik Semantik Robin Cover sieht es als alte SGML-Polemie an, zu behaupten, XML würde durch seine oft selbstbeschreibenden Tags wie z. B. TITLE, Paragraph oder association deren Bedeutung implizieren. Für den Menschen mag der Name eines Elements oder eines Attributs durchaus andeuten, um welche Art von Information es sich handelt, für einen SGML/XML-Prozessor jedoch sind die Tags alle gleichermaßen bedeutungslos. Dies rührt auch daher, dass (plain) XML nur eine syntaktisch definierte Serialisierung Serialisierung darstellt. (Vgl. Cover98) Um verschiedenartige XML-Dokumente dennoch ohne Verlust der Bedeutung austauschen zu können, bedarf es einer semantischen Erklärung der verwendeten Elemente. Idealerweise ist auch diese Erklärung nicht nur für Menschen sondern auch Maschinen verständlich, was letztlich durch Verweise von diesen Elementen auf einen Pool von bekanntem, exakt definiertem Vokabular realisiert wird. Ontologie Als Ziel einer formalen Sprache für Ontologien ist eine XML-Serialisierung wünschenswert, da diese den Austausch der Ontologien/Daten in einem standardisierten Format ermöglicht. Durch die weite Verbreitung von XML gibt es sehr viele Software-Anwendungen zur Weiterverarbeitung, die für Ontologien wiederverwendet und erweitert werden können: To represent a conceptualization a representation language is needed. […] For applications on the web it is important to have a language with a standardized syntax. Because XML [Extensible Markup Language] emerges to be the standard language for data interchange on the web, it is desirable to also exchange ontologies using an XML syntax, thus simplifying the task of writing parsers. This requirement leads again to XML-based languages, defining a language on top of XML DeckerSW. Einen Überblick über die in dieser Arbeit berücksichtigten Aufbauten zu XML gibt (angelehnt an Berners01). Zu XHTML sei nur gesagt, dass es eine XML-konforme Erweiterung des in SGML definierten HTML4-Standards darstellt (Vgl. Pemberton00).
Wissensrepräsentation mit XML
Konzeptklassen für eine <wordasword>MetaChart</wordasword>-Ontologie Eine Basisontologie enthält die grundlegenden Konzepte einer Domäne. Sie ist analog zu einem XML-Schema, einem Template in Topic Maps oder Klassen im Resource Description Framework anzusehen. Die Basisontologie benötigt dabei in Übereinstimmung mit [Gruber93] dem Entity Relationship Diagram ähnliche Begriffe: Ontologies are also like conceptual schemata in database systems. Die Ontologie wird durch folgendes Modell bestimmt: MetaCharts betten MetaChart-Attributes ein. MetaDatas beschreiben MetaCharts und MetaChart-Attributes. Views stellen MetaCharts und MetaChart-Attributes dar. MetaCharts treten als parent und child auf, und gehen entsprechende relationship-Beziehungen ein. MetaCharts und MetaChart-Attributes assoziieren sich gegenseitig. Die Entität User wird wie im relationalen Datenbankschema (siehe ) als spezielles MetaChart gehandhabt und somit hier nicht explizit aufgeführt. Die Entität Views als Container für Darstellungsdaten enthält keine semantischen Auszeichnungen, die für die Erstellung einer Ontologie ausschlaggebend sind.
Konzepte und deren Beziehungen in <wordasword>MetaChart</wordasword>
Extraktion der Daten
Algorithmus Der zugrundliegende Algorithmus zur Datenbankextraktion gestaltet sich für die verschiedenen Zielformate identisch. Erst in der Aufbereitung der Daten zur Ausgabe zeigen sich Unterschiede. Ein MetaChart als Ausgangsbasis betrachtend sind folgende Bereiche zu unterscheiden: MetaDatas MetaChart-Attributes Views Children Für jede dieser Einheiten steht eine eigene Methode zur Verfügung, die von der übergeordneten Methode processMetaChart aufgerufen werden. In processChildren wird für jedes Child-MetaChart die Methode processMetaChart rekursiv gestartet. Assoziationen werden in processAttributes behandelt. Einzelne MetaChart-Attributes besitzen ebenso wie MetaCharts MetaDatas und Views; dementsprechend werden dieselben Methoden auch von der MetaChart-Attribute-verarbeitenden Methode aufgerufen, d. h. sowohl processMetaChart als auch processAttribute rufen processMetaDatas und processViews auf.
Abhängigkeiten der konzeptverarbeitenden Methoden
Jede dieser fünf Methoden arbeitet nach einem ähnlichen Algorithmus (siehe ): Zu einer übergebenen ID (mc_id oder attr_id) werden die davon abhängigen IDs ermittelt um die zugehörigen Inhalte, die z. B. im MetaChart-Objekt zwischengespeichert werden, der Dokumentinstanz anzuhängen. Eine Anfrage dieser Art findet sich z. B. in der Methode Service.getAttributeIds(ID).
Algorithmus innerhalb einer konzeptverarbeitenden Methode
Den Einstieg liefert eine erste Datenbankanfrage, die eine Liste von mc_ids als Vector zurückgibt: Vector mcIds = Service.getStartingMetaChartIds(); Je nach Umfang des Exports kann dies eine bis viele IDs umfassen. Sinnvoll ist z. B. der Einstieg über ein Session-MetaChart, dessen ID alternativ mitübergeben werden kann. Zurückgegeben werden dann nur die davon abhängigen IDs, d. h. nur die in dieser Sitzung erstellten MetaCharts werden exportiert; diese sind Child-MetaCharts des Session-MetaCharts. Im Gegensatz zum Export aller MetaCharts aus der Datenbank, was bei mehreren Sitzungen einen Wald als Resultat lieferte, erhält man so einen Baum. (Siehe auch und ) DOM XML-Instanzen werden im Document Object Model (DOM) durch Bäume dargestellt. Deshalb ist eine der in dargestellten Traversierungsmethoden (auch Plättung genannt) heranzuziehen, um den Baum sequentiell in ein Dokument zu schreiben, d. h. zu serialisieren. Serialisierung
Datenbankanfragen Sämtliche Methoden zur Datenbankabfrage sind in der Klasse Service abgelegt. (Siehe ) Die Methoden geben meist Objekte der Klassen Vector, Hashtable oder String zurück, wobei Vektoren oft nur eine Liste interessierender IDs für weitere Anfragen enthalten; in Hashtables werden beispielsweise spezielle Objekte wie MetaChart und MetaDatas mit dessen IDs als Schlüssel abgelegt. Eine komplette Serialisierung der Datenbankinhalte stellt eine spezielle Sichtweise auf die Daten dar. So könnte man sich einen relationalen View (Sicht) auf die Datenbank als Repräsentation der Daten vorstellen. Von einer Sicht ist nur der Bildungsalgorithmus abgespeichert: Zentral für die Definition eines Views ist die Verwendung eines SELECT-Kommandos (Vossen00 S. 134). Dieser Anfrageausdruck ist hier anhand von equi-joins zu realisieren. Diese joins geben diejenigen Tupel verschiedener Tabellen zurück, die identische Attributwerte enthalten. Das Result Set jedoch ist nicht unbedingt handlich in der Weiterverarbeitung,.
Erstellung Die in diskutierten Konzepte werden via Instanz-von-Beziehungen mit den in einer Individualschicht auftretenden Individualkonzepten verbunden. Hier treten die gleichen Beziehungen wie in der Konzeptschicht auf.
Konzepte und Individuen im <wordasword>MetaChart</wordasword>-Export
<wordasword>MetaChart</wordasword>-XML XML
XML-Aufbau/-Elemente Die Form der MetaChart-XML-Struktur ist stark von der Datenbankstruktur bestimmt, jedoch nicht nur eine tabellenbasierte Abbildung, bei der die Document Type Definition (DTD) dem Datenbankschema entspräche. Der folgende Baum beschreibt den Zusammenhang zwischen den verschiedenen Konzepten MetaChart, MetaData, MetaChart-Attribute und View und entspricht somit eher einer objektbasierten Abbildung: <varname>metacharts</varname> metachart metadatas views attributes attribute metadatas views value children Referenz auf oder Einbettung von metachart metachart … … Dieser Aufbau wiederholt sich prinzipiell auch in XML Topic Maps und im Resource Description Framework; auch die jeweiligen Signaturen der Java-Methoden sind ähnlich. Mittels eines Schalters (Java-Property) kann zwischen einer baumartigen und einer flachen XML-Instanz gewählt werden, d. h. die Child-MetaCharts können entweder komplett als Kindelement von children auftreten oder aber als Verweis mittels mcref (IDREF) zur entsprechenden mc_id (ID) nur referenziert werden. Beide Abbildungen zeigen jeweils andere Vorteile – je nach Anwendungsfall, z. B. Transformation in eine visuelle Darstellung (siehe ) oder bei Importen – auf.
Strukturvergleich XML stellt eine sehr vielseitige Formalisierung zum Datenaustausch dar. Um Daten jedoch zu speichern und individuell zugreifbar zu machen, sind (relationale) Datenbanken in den meisten Bereichen unschlagbar. Diese basieren auf den mathematischen Arbeiten von E. F. Codd im Jahre 1970 – die Boyce-Codd-Normalform stellt eine Verschärfung der dritten Normalform dar. Während die Struktur der XML-Repräsentation einer Hierarchie entspricht und somit hierarchischen (HDBMS, Hierarchical Database Management System) und auch objektorientierten Datenbanken (ODBMS, Object Database Management System) gleicht, ist das relationale Modell (RDBMS, Relational Database Management System) flach. Letzteres zeigt grosse Vorteile in selektiven Anfragen, erschwert jedoch die Erstellung: the design of tables can become quite elaborate, involving subtle decisions Mertz01. Dass jedes Stück Information an nur einer Stelle in der Datenbank abgelegt wird, bringt ein hierarchisches Modell fast automatisch mit sich; im relationelen Kontext ist die Vermeidung von Redundanzen durch Normalisierung der Tabellen zu erarbeiten. Im Vergleich zu HDBMS stellen sich manche Anfragen an an ein RDBMS relativ umständlich dar; Anfragen, die im HDBMS jedoch nur sehr schwer zu formulieren sind, bewerkstelligt ein RDBMS mühelos. (Vgl. Mertz01) Das mächtigste Instrument in relationalen Datenbanken stellt jedoch die Überprüfung von Einschränkungen (constraints) dar, die beim Design der Datenbank beispielsweise mittels Kardinalitäten in Beziehungen zwischen Attributen verschiedener Tabellen formuliert werden. Diese definieren die Häufigkeit der Teilnahme der Beziehungspartner in der Relation. Selbst bei strukturellen Änderungen des Datenbankschemas kann eine inhaltsabbildende XML-Instanz meist gleich bleiben, da sich zum Exportieren der Daten oft nur die Anfrageformulierungen ändern. Selbst diese können in Views (siehe ) auf ein Modell bestimmt werden, so dass für den Export an sich keine Änderungen vorzunehmen sind.
<wordasword>MetaChart</wordasword>-DTD DTD Die Document Type Definition (DTD) legt das Content-Model (Inhaltsmodell) einer XML-Applikation fest. Sie beschreibt den Aufbau der nach ihr konformen XML-Instanzen, d. h. es werden die Namen der Elemente und deren Attribute festgelegt, sowie die Struktur der Elemente zueinander. (Erst dadurch wird XML zur XML-Applikation.) A DTD can be regarded as a very primitive ontology, however, it is basically just a set of terms and does not define the relationship between different terms DeckerSW. Attribute können eine spezielle Ausweisung, wie z. B. die als ID, erhalten, d. h. Attributwerte dieser Attribute müssen eindeutig sein und bestimmte formale Voraussetzungen erfüllen. Nach Bray00 dürfen diese ID-Werte beispielsweise nicht mit Ziffern beginnen. Für welche Inhalte jeweils Elemente oder Attribute erstellt werden, ist nicht a priori festgelegt (Vgl. Cover02). Identifizierende Werte als ID-Attribute anzuführen ist jedoch sinnvoll, da so validierende Parser die genannten und andere Constraints (Einschränkungen) – z. B. müssen IDREFs auf IDs verweisen – überprüfen können. Attribute dürfen jedoch nur einfache Strings ohne Anführung enthalten – CDATA-Sections, die die für XML reservierten Zeichen wie < und & enthalten dürfen, jedoch dort nicht als MarkUp (Befehle für den Parser) geparst werden, sind in Attributen nicht vorgesehen. Gerade für Elemente, die keinen explizit definierten Inhalt enthalten, ist dieses Konstrukt praktisch unverzichtbar. CDATA-Sections werden in XML durch die Tags <![CDATA[ und ]]> eingeschlossen. Im Falle des Auftretens der Zeichenfolge ]]> im Content – was die CDATA-Section beenden würde und zu nicht wohlgeformtem XML führe – kann die CDATA-Section zwischen ] und ]> geschlossen und sodann unmittelbar neu begonnen werden. Bei Elementen und Attributen gelten also unterschiedliche Constraints: So ist auch die Reihenfolge der Attribute eines Elements nicht vorgeschrieben. Eine Mehrfachverwendung eines Attributs innerhalb eines Elements ist nicht zulässig: Im Gegensatz zu Elementen müssen die Attribute eindeutig sein, d. h. die Häufigkeit des Auftretens von Elementen kann in der DTD mittels Konnektoren (Occurrence Operators) (?, + und *) definiert werden. Attribute hingegen können als (nicht) zwingend und Attributwerte durch einer Auswahl an (fixen) Werten festgesetzt werden. Die explizite Umsetzung der MetaChart-Struktur in eine DTD ist in zu sehen.
XML-Schema für <wordasword>MetaChart</wordasword> XML-Schema Je restriktiver bestimmt ist, welchen Regeln die Dokumentinstanzen gerecht werden müssen, umso früher können Fehler im Vorfeld durch einen validierenden Parser abgefangen werden. Das Content-Model sowie die Constraint-Modellierung der DTDs ist relativ ausdrucksschwach (vgl. Fallside01). Deshalb enstand neben einer Reihe anderer Schemasprachen das XML-Schema, das in manchen Bereichen als Nachfolger der DTDs zu sehen ist: The purpose of a schema is to define a class of XML documents, and so the term instance document is often used to describe an XML document that conforms to a particular schema Fallside01. Die Elemente von XML-Schema sind in einem eigenen Namensraum definiert. Instanz XML Instanz Klasse Instanz Namensraum (Namespaces) sind Erweiterungen zur XML-Syntax in Form reservierter Attribute, die mit xmlns beginnen. Als Attributwert ist eine URI anzugeben. Im jeweiligen Gültigkeitsbereich (scope) des Namespaces innerhalb einer XML-Instanz dürfen die Elemente des jeweiligen Namensraums verwendet werden. Es können also Elemente benutzt werden, die nicht Teil einer DTD sind. Sinnvollerweise sind die Elemente aus dem Namensraum an der durch die URI bestimmten Stelle als XML Schema definiert und erläutert – dies ist jedoch nicht vorgeschrieben. Die Spezifikation schreibt keine Validierung dieser Elemente vor, so dass ein Dokument mit Namespaces syntaktisch wie semantisch ungenauer bestimmt ist als ein DTD-konformes Dokument. Der Verweis auf ein XML Schema ist bei Bedarf explizit mit schemaLocation anzugeben (Vgl. Bray99). Als Beispiel sei ein gleichlautendes Element in verschiedenen Namespaces angeführt, die beide in einem Dokument auftreten dürfen: <mathml:transpose> und <music:transpose>. Namespace Namensraum Namensraum DOM XML Schema Definitionen (W3C Recommendation und zweiteilige Spezifikation siehe Fallside01, Thompson01 und Biron01) werden selbst in XML notiert, was den Vorteil hat, dass beispielsweise Anwendungen mittels DOM (Document Object Model) darauf zugreifen und sie auch mittels XSLT (Extensible Stylesheet Language Transformations) verarbeitet werden können. Auch ist die DTD-Syntax oft schwer zu lesen und die Bedeutungen der Inhaltsmodelle nicht klar, was dazu führen kann, dass v. a. bei großen DTDs, wie z. B. DocBook DTD DocBook DocBook (siehe auch ), Elemente für nicht vorgesehene Zwecke entfremdet und fehlinterpretiert werden. Neben den in DTDs zur Verfügung stehenden Konnektoren gibt es in XML Schema auch für die und-Beziehung ein Konstrukt: Elemente können in Gruppen gegliedert werden, die das Auftreten der Elemente entweder in beliebiger oder vorgeschriebener Reihenfolge oder alternativ festsetzen. Auch für Attribute gibt es Gruppen um öfter auftretende Attributkombinationen an zentraler Stelle zu definieren. Für die attributeGroups gibt es jedoch kein Wrapper-Element, das ein kombinatorisches Auftreten der Attributgruppen festlegt. So müsste ein Element, das mit differierenden Attributgruppen auftreten kann, auf der Elementebene, je nach den gewünschten Kombinationen, mehrmals definiert werden. Im MetaChart-Beispiel wäre dies für das VALUE-Element in Betracht zu ziehen, da diesem Element, je nach Wert im Datenbankattribut attributes.type, ein anderes Inhaltsmodell zugrundeliegt. In DTDs kann der Datentyp #PCDATA (parsed character data) eines Textknotens nicht näher bestimmt werden. Dies ist in XML Schema nicht nur durch die in Biron01 vordefinierten Datentypen (z. B. date, integer, string) möglich, auch Restriktionen wie z. B. die Anzahl und die Art der Zeichen sind denkbar. So kann beispielsweise die Form einzelner IDs genauer mittels pattern-expressions (die der Perl-Syntax der regulären Ausdrücke (siehe perlre) genügen müssen) definiert werden: <?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:simpleType name="mc-type-raw"> <xs:restriction base="xs:string"> <xs:pattern value="mc\d+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="mc-type"> <xs:union memberTypes="mc-type-raw xs:ID"/> </xs:simpleType> <xs:simpleType name="owner-type"> <xs:union memberTypes="mc-type-raw xs:IDREF"/> </xs:simpleType> <xs:element name="METACHART"> <xs:complexType> <xs:attribute name="mcid" type="mc-type" use="required"/> <xs:attribute name="owner" type="owner-type" use="optional"/> <!-- ... --> Der Auszug beschreibt das mcid- und das owner-Attribut des MetaChart-XML-Schema näher. So wird mit mc\d+ die Form des Attributwerts beginnend mit mc und einer Anzahl größer Null von Ziffern (digits) bestimmt. Sodann werden die Attribute mcid als ID und owner als IDREF ausgezeichnet. Das XML Schema von MetaChart ist in zu sehen.
Die <wordasword>MetaChart</wordasword>-XML Instanz Der Export der Daten wird exemplarisch für ein MetaChart-Attribute, insbesondere dessen value, dargestellt: Die Methode processAttributes(mcID) in der Klasse DOMAttributes bekommt u. a. die mcId (meta_charts.mc_id in der Datenbank) und die Elementinstanz des Elements übergeben, an das in dieser Methode erstellte Elemente angehängt werden. Im konkreten Fall ist dies eine Instanz des Elements METACHART, an das sodann das Wrapper-Element ATTRIBUTES für ATTRIBUTE-Tochter-Elemente angehängt wird. Durch den Aufruf von Vector attrIds = Service.getAttributeIds(mcId); werden zunächst sämtliche MetaChart-Attributes dieses MetaCharts identifiziert. for (Enumeration enum = attributes.elements(); enum.hasMoreElements(); ) { Attribute a = (Attribute)enum.nextElement(); String attrId = new String(a.getId()); AttributeType type = new AttributeType(a.getType()); // ... // if/else-block } Die Schleife durchläuft alle Elemente der Enumeration, die die Elemente des Vectors enthält, d. h. die folgenden Anweisungen werden für jedes auftretende MetaChart-Attribute abgehandelt. (Siehe ) Das ATTRIBUTE-Element mit dessen ID als XML-Attribut wird erstellt und in ATTRIBUTES eingehängt: Element el_attribute = doc.createElement("ATTRIBUTE"); el_attributes.appendChild(el_attribute); el_attribute.setAttribute("attrid", attrId); Für das Kindelement VALUE, das die MetaChart-Attribute-Daten an sich enthält, wird in einem if/else-Block (ein switch/case-Statement ist im Zusammenhang mit Strings nicht möglich) der Typ des MetaChart-Attributes bestimmt, der als AttributeType-Objekt vorliegt. Diese Klasse AttributeType hält derzeit folgende Methoden zur Typbestimmung bereit, die boolean, also wahr oder falsch zurückgeben: isAssoziation() isProspector() isUserPreferences() isBase64() isPlain() Dazu wird in der AttributeType-Klasse type ein String, der den Wert von attributes.type aus der Datenbank enthält, untersucht. Mit Ausnahme der MetaChart-proprietären Typen wird das Format als MIME-type abgelegt. MIME <acronym>MIME</acronym>-type ist ein Standard System zur Identifizierung des Datenformats einer Datei anhand ihrer Dateinamenendung (Extension). Derzeit ist die Liste in acht Gruppen unterteilt: application, audio, image, message, model, multipart, text und video. Der Typ wird durch den Verzeichnisseperator / abgetrennt, z. B. text/plain, text/xml oder image/png. (Vgl. MIME) Mittels String-Vergleichen wie beispielsweise type.equalsIgnoreCase("assoziation") oder type.startsWith("text/") wird schließlich bestimmt, wie der jeweilige Wert aus attributes.value zu dekodieren ist. Je nach Typ werden dem VALUE-Element verschiedene XML-Attribute angehängt. Im Falle der Assoziation sind dies srcId, dstId, srcMCId, dstMCId, deren Werte durch Methoden in der Klasse de.fhg.iao.metachart.Edge abzurufen sind. Dieses Objekt Edge (die Assoziation), wird in der Datenbank im Feld attributes.value abgelegt. Um die Assoziationen aus der Datenbank zu lesen, sind spezielle Casts (Datentypumwandlungen) nötig, die in der Methode Service.getAttributeValueAsEdge implementiert sind. Falls es sich um Typen handelt, die Base64-kodiert abzulegen sind, wird die entsprechende query-Methode aufgerufen und der Datenstrom kodiert, um schließlich in ein Kindelement VALUE als CDATA-Section einzufließen. Für manche Typen bleibt der Textknoten leer. Base64 ist eine Kodierung (Content Transfer Encoding) um binäre Daten in die 7bit-Ebene zu transformieren, um sie so über Protokolle mit gewissen Einschränkungen transportieren zu können. 7bit data bezeichnet dabei einen Datenstrom, der aus mit CRLF (Carriage Return [dezimal 13] Line Feed [dezimal 10]) abgetrennten Zeilen besteht und keine Bytes mit einem dezimalen Wert von über 127 enthält. (Vgl. RFC2045) Im MetaChart-Projekt gibt es noch eine Anzahl weiterer MetaChart-Attribute-Typen, die für den XML-Export explizit behandelt werden müssen. Auch ist das MetaChart-Projekt selbst noch nicht abgeschlossen, so dass gerade an dieser Stelle mit Erweiterungen zu rechnen ist. Im Falle auftretender, noch unbekannter Attributtypen, die keine MIME-types darstellen, wird das Element ATTRIBUTE nur mit einem Attribut type, das den Wert aus attributes.type mit dem Hinweis unknown enthält, angelegt. Das aktuelle attrId sowie das Element ATTRIBUTE werden schließlich an die Methoden processMetaDatas und processViews weitergegeben, um daran Metadaten sowie View-Daten anzuhängen. Eine Beispiel-Instanz ist in zu sehen.
Visualisierung des <wordasword>MetaChart</wordasword>-XML XML Visualisierung
<wordasword>MetaChart</wordasword>-XML mit Hyperlinks Ein Perlskript, das den URL (Uniform Resource Locator) einer MetaChart-XML-Instanz per CGI (Common Gateway Interface) übergeben bekommt, gibt diese Instanz als Klartext, formatiert in HTML (HyperText Markup Language), aus, wobei es entsprechende ID/IDREFs als Hyperlinks (Anker und Verweise) auflöst, um so das Springen zu referenzierten MetaCharts und MetaChart-Attributes innerhalb des Dokuments zu ermöglichen. Für String-Ersetzungen zur Hyperlink-Auszeichnung bietet sich das Konzept der regulären Ausdrücke (siehe perlre) an, das in Perl sehr einfach anzuwenden ist: $_ =~ s/mcid="([^"]+)"/mcid="<a name="\1"><b>\1<\/b><\/a>"/g; $_ =~ s/mcref="([^"]+)"/mcref="<a href="#\1">\1<\/a>"/g; Dieses Skript ist über erreichbar.
XML und <foreignphrase>Cascading Style Sheets</foreignphrase> CSS Visualisierung CSS Cascading Style Sheets (CSS) ist eine Stylesheet-Sprache, die es erlaubt, die visuelle Darstellung strukturierter Dokumente wie HTML-Dokumente oder XML-Applikationen näher zu bestimmen. Dies geschieht zumeist in einer externen Datei, wodurch die Layoutbeschreibung und der Dokumentinhalt getrennt sind. Dies ermöglicht zum einen verschiedene Layouts, zum anderen wird das Pflegen sowohl der Inhalte als auch des Layouts erleichtert. (Vgl. Bos98) Die folgenden Zeilen zeigen einen Ausschnitt der CSS-Datei für das MetaChart-XML; zeigt das Ergebnis der CSS-Darstellung. METACHART { display: block; padding: 30px; } VALUE { position: relative; display: block; font-family: serif; font-size: small; font-weight: normal; padding: 6px; }
<foreignphrase>Extensible Stylesheet Language</foreignphrase> – XML mit XSLT zu XSL Visualisierung XSL Visualisierung DSSSL DSSSL Extensible Stylesheet Language (XSL) stellt eine Sprache (in XML-Syntax) zur Beschreibung eines Dokuments und seines Layouts dar. Extensible Stylesheet Language Transformations (XSLT) ist die für XSL entworfene Transformationssprache, mit deren Hilfe ein XSLT-Prozessor XML-Dokumente nach XSL oder andere XML-Formate, auch text/plain, umwandeln kann. (Vgl. Adler01) Die bekanntesten XSLT-Prozessoren sind James Clarks XT sowie Apache Xalan. XSL baut auf den früheren Arbeiten zu Cascading Style Sheets Bos98 und Document Style Semantics and Specification Language (DSSSL) auf. So wird zu jedem Element beim Durchlaufen des XSLT-Prozessors durch den XML-Baum eine Regel gesucht, die folgende Form aufweist: <xsl:template match="Element"> <!-- Aktionen, meist der Form: --> <xsl:value-of select="."/> </xsl:template> XSL-Dokumente werden zur Darstellung formatiert, womit der Prozess gemeint ist, der die Dokumente in eine greifbare Form für den Empfänger – je nach Medium – bringt. In wird mittels XSLT das MetaChart-XML in eine text/plain-Datei (in die Linear Topic Map Notation) gewandelt. Als interessante Zielformate sind auch HTML, SVG (Scalable Vector Graphics), LaTeX oder Braille zu nennen. XSL Formatting Objects Visualisierung PDF FO Bei XSL Formatting Objects (XSL-FO) handelt es sich um Elemente des formatting object tree, die dem XSL Namensraum angehören. Die Formatting Objects beschreiben, welche Bereiche des Dokuments wie darzustellen sind, sowie deren hierarchische Struktur bezüglich Bereichen anderer Formatting Objects. Die Formatting Objects sind zweigeteilt in block-level- und inline-level-Elemente, vergleichbar mit Absatzformatierungen und Auszeichnungen. Darüberhinaus sind im Stylesheet Angaben wie Papierformat, Ränder und Kopf-/Fußzeilenbereiche im layout-master-set zu definieren, auf die sich dann Objekte beziehen, die in der page-sequence-Umgebung eine fixe Position (static-content) oder fliessende (flow) einnehmen. Seitenzahl und Kolumnentitel sind typische Angaben innerhalb static-content. Die Formatierung der Formatting Objects ist Aufgabe eines FO-Prozessors. Derzeit sind erst wenige Prozessoren verfügbar. Zu den am weitesten verbreiteten zählen Apache FOP und RenderX XEP. Als weitere Vertreter sind AntennaHouse XSL Formatter, XMLmind FO Converter (XFC) und Unicorn Formatting Objects (UFO) zu nennen. Neben der direkten Formatierung nach PDF PDF (Portable Document Format) sind Wege über LaTeX oder RTF mögliche Strategien – eine frühe Version des XEP benutzte beispielsweise Thomas Merz’ Perl PDF-Bibliothek. Das Stylesheet, das mit Apache FOP die PDF-Darstellung (siehe ) einer MetaChart-XML-Instanz erzeugt, ist in zu sehen. Auftretende base64-kodierte Grafiken sind vor der Formatierung in ihre Ursprungsdatei zu konvertieren, um sie als external-graphic einbinden zu können. Dazu wird im Stylesheet geprüft, ob das type-Attribut von VALUE mit image/ beginnt.
XML <foreignphrase>Topic Maps</foreignphrase> Topic Maps ist ein Standard, Wissensstrukturen zu beschreiben und diese mit Informationsressourcen zu verbinden. (Vgl. Pepper00). Holger Rath von Empolis (topicmaps.com) bezeichnet Topic Maps als Lösung zur Organisation und Navigation der immer größer werdenden Informationsmengen. (Vgl. Rath99) Die XML Topic Maps-Spezifikation der TopicMaps.Org-Authoring Group entstand aus dem Modell der Topic Maps in SGML (kurz HyTM), das als ISO/IEC-Standard 13250, basierend auf HyTime (Hypermedia/Time-based Structuring Language), definiert wurde. Der XML Topic Map Standard ist inzwischen auch Teil der ISO-Norm. Die XML Topic Maps-Spezifikation befindet sich in Pepper01, die ISO-Norm ist unter ISO13250 einzusehen. In dieser Arbeit wird nur auf XML Topic Maps (XTM) eingegangen.
Das Stichwortverzeichnis <foreignphrase>Topic Maps</foreignphrase> Topic Maps Topic Maps Topic Topic Maps Association Topic Maps Occurrence Association Topic Occurrence Die ersten Ideen zu Topic Map sind etwa Anfang der Neunziger anzusiedeln, als die jetzige Davenport Group über Austauschformate für Computerliteratur diskutierte und schließlich die DocBook DTD DocBook DocBook DTD (siehe Walsh99) spezifizierte (Vgl. Pepper00). Das Ziel, Stichwortverzeichnisse verschiedener Dokumentationen zu vereinigen, schlug damals fehl, weil es an formalen Wissensstrukturen in Form von Ontologien mangelte, mittels derer gleichbedeutende Stichworte erkannt werden hätten können. Fast ein Jahrzehnt dauerte es, bis die Systematik, die Stichwortverzeichnissen innewohnt, als Topic Map-Standard hervorging: Das Stichwort verbunden mit dem Vorkommen (im Text) bildet das TAO der Topic Map: Bezeichner Analogie Topic Stichwort, Thema, Begriff Association Verbindung, Beziehung Occurrence Auftreten, Vorkommen Trotz (oder vielleicht gerade aufgrund) der Trivialität dieses Modells ist es mit Topic Maps möglich, recht komplexe Strukturen abzubilden.
<foreignphrase>Topic</foreignphrase> A topic, in its most generic sense, can be any thing whatsoever – a person, an entity, a concept, really anything – regardless of whether it exists or has any other specific characteristics, about which anything whatsoever may be asserted by any means whatsoever Pepper00. Steve Pepper zieht auch einen Vergleich zu Platons Ideenlehre. Die Topics entsprächen den Schatten, die nach Platon von den Urbildern geworfen werden. (Vgl. Kunzmann99 S. 39) Die Art eines Topics kann durch Topic Types genauer spezifiziert werden. Topic Types sind Topics, die Teil einer is-a- oder Instanz-von-Beziehung sein können.
<foreignphrase>Association</foreignphrase> Associations beschreiben Beziehungen zwischen Topics. Wie Topics werden Associations auch durch Association Types charakterisiert, die wiederum selbst als Topics existieren. Die zwei in Beziehung gebrachten Topics werden als Member referenziert, und treten dabei als Role Player auf. Letzteres spezifiziert den Typ eines Topics innerhalb der Association – üblicherweise ist dieser identisch mit dem ihm zugewiesenen Topic Type. Ein Gegenbeispiel zeigt .
<foreignphrase>Occurrence</foreignphrase> Topics können mit relevanten Ressourcen verbunden werden. Dies wird durch Occurrences realisiert, die auf die Ressource zeigen oder die Information selbst beinhalten. Beispiele für Ressourcen können Bücher, Artikel, Grafiken oder jegliche vorstellbare Informationsträger zu diesem Thema sein.
Das <foreignphrase>Topic Map</foreignphrase>-Template Template Topic Maps Template Eine Topic Map ist prinzipiell zweigeteilt in ein Topic Map Template (basic ontology) und die eigentliche Topic Map, der Instanz. Letztere beinhaltet Begriffe als Topics, denen ein Typ (als Gattung) aus den Topics des Templates (auch Schemas) zugewiesen wird. Das Template nimmt dabei eine deklarative Funktion ein, besteht selbst jedoch auch aus Topics. Diese Unterteilung sowie die Zusammenhänge zwischen Topics, Associations und Occurrences lassen sich in Schmidt00 gut erkennen.
Konzepte und Individuen in <foreignphrase>Topic Maps</foreignphrase>
Klassen Klasse Anstatt von Topic Types kann man auch von Klassen sprechen. Holger Rath hat dafür spezielle Topics in Rath01 veröffentlicht, die jedoch nicht Teil des ISO-Standards sind. Diese Topics ermöglichen eine strukturierte Trennung zwischen Klassen im Template und Instanzen. Das Topic template.xtm#topic-class beschreibt Rath als concept of topic class; the class of which topic typing topics should be an instance of, d. h. den Topic Type Topics im Template kann als Topic Type wiederum ein spezielles Topic, das topic-class-Topic, zugewiesen werden, das das Konzept einer Klasse (siehe ) vergegenständlicht. Demnach ergäbe sich folgende Struktur: Topic #1 als Konzept der Klasse (template.xtm#topic-class) Topic #2 als Instanz von Topic #1 (Topic Type) Topic #3 als Instanz von Topic #2 (Individuum) Die Topics in von Steve Pepper ermöglichen im Gegensatz dazu nur die nähere Bestimmung von Association Types, beispielsweise bezüglich class-instance-Relationen: The class of association that represents class-instance relationships between topics, and that is semantically equivalent to the use of instanceOf subelements. (Siehe auch ) Um mit diesen Konstrukten Instanz-von-Beziehungen zu modellieren, bedarf es für jede Instanziierung einer Association.
<foreignphrase>Linear Topic Map Notation</foreignphrase> Die Firma Ontopia (ontopia.net) stellt eine Notation zur Verfügung, mit der sich Topic Maps in einfacher Textform modellieren lassen. Im Gegensatz zu XML Topic Maps, die im Grunde nicht dazu gedacht ist, direkt im Texteditor gelesen und geschrieben zu werden, ermöglicht die Linear Topic Map Notation eine anschaulichere Einführung in Topic Maps sowie die Diskussion über Topic Map-Aspekte in Diskussionsforen. Steve Pepper hatte die Idee, eine lineare Notation für Topic Maps analog zu der der konzeptionellen Graphen (siehe ) zu entwickeln. Linear Topic Map Notation-Instanzen können mittels eines Python-Scripts oder im Omnigator , der Topic Map-Engine von Ontopia, nach XML transformiert werden.
Ein <foreignphrase>Topic Map</foreignphrase>-Beispiel Topic Maps Topic Maps Topic Topic Maps Association Topic Maps Occurrence Association Topic Occurrence Als erläuterndes Beispiel wird eine Topic Map aus dem Bereich Studium, also eine Ontologie mit Studium als Domäne, erstellt. Von folgendem Sachverhalt soll dabei ausgegangen werden: Jenny Doe studiert in Weimar Architektur. Das Goethehaus ist eine Sehenswürdigkeit Weimars. Jenny Doe ist also Studentin, Architektur ein Studiengang und Weimar ein Ort. Als Klassen im Template für die zu erstellende Topic Map benötigen wir somit student, studiengang und ort. Die Instanzen dieser Klassen werden sein: jenny, architektur und weimar. Die Beziehungen zwischen den Studenten und den Studienorten studiert in werden in Topic Maps mittels Associations implementiert, die wiederum als Instanzen eines speziellen Topics auftauchen. Dieser Topic wird Association Type-Topic genannt. Im folgenden wird das Beispiel erst in Linear Topic Map Notation, anschließend in XML Topic Maps (zeilennummeriert) notiert.
Erstellung von <foreignphrase>Topics</foreignphrase> In Linear Topic Map Notation wird ein Topic jenny vom Typ student erstellt: [jenny : student = "Jenny Doe"] Dabei wird von dem Linear Topic Map Notation-Prozessor automatisch ein Topic student erzeugt, der auch manuell mittels [student] explizit erzeugt werden könnte, was insofern auch sinnvoll ist (vgl. Variablendeklaration in Java), da so der Topic student zugleich mit BaseName versehen werden kann; student fungiert nur als ID dieses Topics, die nicht zur Anzeige in Topic Map-Browsern o. ä. gedacht ist. Dem Topic student wird der Name Student(in) zugewiesen: [student = "Student(in)"] Als Wurzelelement in XML Topic Maps dient topicMap: <topicMap xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"/> Um diese zwei Topics in XML Topic Maps zu erhalten, werden folgende Elemente in topicMap eingehängt: <topic id="student"> <baseName> <baseNameString>Student(in)</baseNameString> </baseName> </topic> <topic id="jenny"> <instanceOf> <topicRef xlink:href="#student"/> </instanceOf> <baseName> <baseNameString>Jenny Doe</baseNameString> </baseName> </topic> Der Topic student soll je nach Genus als Studentin oder Student benannt sein, d. h. es muss ein Gültigkeitsbereich des jeweiligen BaseNames definiert werden. Dies wird mittels scopes realisiert. Dazu ist ein Topic genus als Klasse, sowie dessen Unterklassen feminin und maskulin zu generieren: [genus = "Geschlecht"] [feminin : genus = "weiblich"] [maskulin : genus = "männlich"] In XML Topic Maps wird notiert: <topic id="genus"> <baseName> <baseNameString>Geschlecht</baseNameString> </baseName> </topic> <topic id="feminin"> <instanceOf> <topicRef xlink:href="#genus"/> </instanceOf> <baseName> <baseNameString>weiblich</baseNameString> </baseName> </topic> <topic id="maskulin"> <instanceOf> <topicRef xlink:href="#genus"/> </instanceOf> <baseName> <baseNameString>männlich</baseNameString> </baseName> </topic> Nun kann der Name des Topics student mittels Genusunterscheidung genauer definiert werden, was in Topic Map durch eine Einschränkung des scopes möglich ist: [student / feminin = "Studentin"] [student / maskulin = "Student"] Dem Topic jenny wird schließlich der betreffende Genus zugewiesen: [jenny : student / feminin] D. h., jenny als Instanz von student gilt nur im Scope feminin der Klasse student. In XML Topic Maps wird das Topic student um zwei BaseName-Elemente erweitert: <baseName> <scope> <topicRef xlink:href="#feminin"/> </scope> <baseNameString>Studentin</baseNameString> </baseName> <baseName> <scope> <topicRef xlink:href="#maskulin"/> </scope> <baseNameString>Student</baseNameString> </baseName> Das BaseName-Element im Topic jenny wird um das Scope feminin erweitert: <scope> <topicRef xlink:href="#feminin"/> </scope>
Erstellung von <foreignphrase>Associations</foreignphrase> Weiterhin soll modelliert werden, Jenny studiere in Weimar Architektur. Dazu werden vorab die Topics weimar und architektur – hier inklusive der alternativen Namen zur Sortierung und besonderen Anzeige – erstellt: [weimar : ort = "Weimar"; "Weimar, Goethestadt"; "Goethestadt Weimar"] [architektur : studiengang = "Architektur"] In XML Topic Maps wird notiert: <topic id="weimar"> <instanceOf> <topicRef xlink:href="#ort"/> </instanceOf> <baseName> <baseNameString>Weimar</baseNameString> <variant> <parameters> <topicRef xlink:href="#core_display"/> </parameters> <variantName> <resourceData>Goethestadt Weimar</resourceData> </variantName> </variant> <variant> <parameters> <topicRef xlink:href="#core_sort"/> </parameters> <variantName> <resourceData>Weimar, Goethestadt</resourceData> </variantName> </variant> </baseName> </topic> Die variantNames stellen eine Besonderheit dar, da sie nach core_display und core_sort verweisen. Dieses sind Topics, die auf Public Subject Indicators verweisen. (Siehe ) Das Topic architektur ist analog dazu zu erstellen. Es bedarf zweier Assoziationstypen: student studiert studiengang und student studiert in ort: [studiert-in = "studiert in"] [studiert = "studiert"] Es folgt die Deklaration, welches Topic mit welchem Topic in Beziehung steht: studiert-in([jenny], [weimar]) Damit die Assoziation bidirektional Sinn macht, wird der jeweiligen Formulierung ein Scope (entweder Student oder Ort) zugewiesen, der anzeigt, von welchem Topic die Relation ausgeht. Je nach Kontext Kontext der Visualisierung/Auswertung (welches Topic im Vordergrund steht), wird von der Topic Map-engine erwartet, die entsprechende Formulierung (basenamestring) auszuwählen: [studiert-in = / student "studiert in"] [studiert-in = / ort "ist Studienort von"] [studiert-in = "Student-Ort-Relation"] In XML Topic Maps ist für den kompletten Association Type-Topic zu notieren: <topic id="studiert-in"> <baseName> <baseNameString>Student-Ort-Relation</baseNameString> </baseName> <baseName> <scope> <topicRef xlink:href="#ort"/> </scope> <baseNameString>ist Studienort von</baseNameString> </baseName> <baseName> <scope> <topicRef xlink:href="#student"/> </scope> <baseNameString>studiert in</baseNameString> </baseName> </topic> Die Assoziation erhält man durch: <association> <instanceOf> <topicRef xlink:href="#studiert-in"/> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#ort"/> </roleSpec> <topicRef xlink:href="#weimar"/> </member> <member> <roleSpec> <topicRef xlink:href="#student"/> </roleSpec> <topicRef xlink:href="#jenny"/> </member> </association> Analoges gilt für die Assoziation studiert in der Relation Jenny studiert Architektur. Die menschliche Ratio erlaubt zu folgern, dass Architektur ein Studiengang in Weimar sei; in der Topic Map müsste dies jedoch explizit als eigene Association modelliert werden. Wünschenswert wären Inferenzprozessoren, die mittels formalisierten Regeln, wie z. B. stud [x]-->(studiert-in)-->[y] [x]-->(studiert)-->[z] ------------------------- [y]-->(bietet-an)-->[z] folgende neue Aussage als Association ableiten könnten: stud [Jenny]-->(studiert-in)-->[Weimar] [Jenny]-->(studiert)-->[Architektur] -------------------------------------- [Weimar]-->(bietet-an)-->[Architektur] (Dass ein(e) Student(in) an verschiedenen Orten studieren kann, sei in dieser Beispieldomäne nicht in Betracht gezogen.)
Erstellung von <foreignphrase>Occurrences</foreignphrase> Um Topics bestimmte Ressourcen zuzuordnen existieren Occurrences, die zum einen auf Vorkommnisse jeglicher Art mittels URIs verweisen, oder aber die Ressource selbst beinhalten. Als eine Art Klasse werden vorab die Occurrence Type-Topics sights und website erstellt: [website = "Website"] [sights = "Sehenswürdigkeiten"] Occurrences benötigen dreierlei Information: Erstens, welchem Topic die Occurrence angehörig ist, zweitens, welcher Art die Occurrence ist (Occurrence Type) und schließlich die URI der Occurrence oder die Daten der Ressource selbst: {weimar, website, "http://www.weimar.de"} {weimar, sights, [[Goethehaus, Schillerhaus, ...]]} {weimar, sights, [[Nietzsche-Archiv]]} In XML Topic Maps wird notiert: <topic id="website"> <baseName> <baseNameString>Website</baseNameString> </baseName> </topic> <topic id="sights"> <baseName> <baseNameString>Sehenswürdigkeiten</baseNameString> </baseName> </topic> Die Occurences werden in das Topic weimar gehängt: <topic id="weimar"> <occurrence> <instanceOf> <topicRef xlink:href="#sights"/> </instanceOf> <resourceData>Nietzsche-Archiv</resourceData> </occurrence> <occurrence> <instanceOf> <topicRef xlink:href="#website"/> </instanceOf> <resourceRef xlink:href="http://www.weimar.de"/> </occurrence> <occurrence> <instanceOf> <topicRef xlink:href="#sights"/> </instanceOf> <resourceData>Goethehaus, Schillerhaus, ...</resourceData> </occurrence> ...
<foreignphrase>Public Subject Identifiers</foreignphrase> Public Subject Indicator PSI PSI Topic Maps Topic Maps PSI Auf folgende Topics wird im obigen Beispiel (siehe ) verwiesen, um die Art des Namens des Topics genauer zu bestimmen. <topic id="core_display"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#display"/> </subjectIdentity> </topic> <topic id="core_sort"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#sort"/> </subjectIdentity> </topic> Das Dokument in Pepper01a enthält Topics, sogenannte Published Subject Indicators (PSIs), auf die von Topics aus anderen Topic Maps verwiesen werden soll, wenn diesen dieselbe Idee (Subject) innewohnt. So könnte ein Topic Map-Prozessor die Bedeutung eines speziellen Topics nachverfolgen und Topics aus externer Quelle, z. B. beim Zusammenführen (merging) mehrerer Topic Maps, als ein Topic ansehen, dem die gleiche Idee innewohnt. Gleichbedeutende Topics vereinen je nach Scope auftretende Associations und Occurrences. In der XTM-Spezifikation Pepper01 ist explizit festgelegt, wie gleichbedeutende Topics festzustellen sind und wie mit beteiligten Associations und Occurrences zu verfahren ist.
<wordasword>MetaChart</wordasword> als <foreignphrase>Topic Map</foreignphrase>
Das <wordasword>MetaChart</wordasword>-Template Die Aufteilung der MetaChart-Konzepte, wie in , spiegelt sich auch im Template der Topic Map wider, das zu diesen Konzepten verschiedene Topic Types enthält. Speziellere Ausartungen können bei Bedarf erstellt werden.
<foreignphrase>Topic Types</foreignphrase> Für folgende Begriffe sind Topic Types zu erstellen: Begriff Topic Type MetaChart mc MetaChart-Attribute attribute Titel title Erstelldatum createDate
<foreignphrase>Association Types</foreignphrase> Beziehungen zwischen Topics treten hauptsächlich auf bei der rekursiven Einbindung von MetaCharts untereinander, bei der Einbettung von MetaChart-Attributes in MetaCharts und bei Kanten, also bei den in angesprochenen vier Kombinationen. Associations verbinden Topics (Member), die typischerweise als Role Player des ihnen zugeordneten Topic Types auftreten. Andere Rollen sind jedoch denkbar. So treten in der Association zur hierarchischen Verknüpfung der MetaCharts die Topics des Typs mc als child und parent auf. Beziehung Association Type Partner (und Rolle) Rekursion der MetaCharts at_relationship mc (als parent) is parent of mc (als child) is child of Assoziation zwischen den vier Kombinationen aus MetaChart und MetaChart-Attribute at_edge_[mc|a]_[mc|a] mc bzw. attribute associates mc bzw. attribute associates MetaChart-Attribute-Einbettung in MetaChart at_attribute mc has attribute attribute is attribute of Titel eines MetaCharts at_mc_title mc is titled title is title of Titel eines MetaChart-Attributes at_attribute_title attribute is titled title is title of Erstelldatum eines MetaCharts at_mc_createDate mc was created at createDate is createDate of Erstelldatum eines MetaChart-Attributes at_attribute_createDate attribute was created at createDate is createDate of
<foreignphrase>Occurrence Types</foreignphrase> Das Topic attribute tritt auch zugleich als Topic Type und Occurrence Types auf. Topics des Typs attribute nehmen die Daten aus attributes.value als Occurrence auf.
Das Beispiel als <wordasword>MetaChart</wordasword>-<foreignphrase>Topic Map</foreignphrase> Um obiges Beispiel mit den in MetaChart vorhandenen Konzepten (siehe ) darstellen zu können, ist eine Verallgemeinerung spezieller Topics nötig, um sie ins Schema einzupassen. Mathematisch gesehen liegt also eine Abbildung ohne eindeutige Umkehrfunktion vor: Eine Vielzahl verschiedenartiger Topic Types wird auf eine beschränkte Anzahl abgebildet. Im Einzelnen sind dies die Topics ort, weimar, studiengang, architektur, student und jenny. Diese werden als Topics des Typs mc abgebildet, wobei jenny als Child-MetaChart von student, weimar als Child-MetaChart von ort, sowie architektur als Child-MetaChart von studiengang abgebildet wird. Die Associations studiert-in und studiert werden als Associations der edge-Typen abgebildet. Als Topic attribute treten auf sights und website mit jeweiliger eingebetteter Occurrence Goethehaus, Schillerhaus, ... und Nietzsche-Archiv sowie einer externen Occurrence http://www.weimar.de. Schließlich ist jenny mit weimar sowie jenny mit architektur via edges zu assoziieren. Natürlich sind neben dieser auch andere Abbildungen denkbar.
Erstellung der <foreignphrase>Topic Map</foreignphrase> in Java Die hier verwendete Open Source-Bibliothek tm4j in der Version 0.5 von Kal Ahmed Ahmed02 stellt mit ihrem Java-Application Programmers Interface (API) in der Klasse TopicMapFactory (tmf) Methoden zur Topic-, Association- und Occurrence-Generierung auf niederer Ebene zur Verfügung. Es erspart die explizite Erstellung der dazu nötigen XML-Elemente auf DOM-Ebene. Beispielsweise werden Topics mittels Topic topic = tmf.createTopic(topicID) erstellt, wobei das Anhängen eines BaseNames via BaseName bn = tmf.createBaseName(baseNameID); bn.setString(baseNameString); Topic.addName(); zwingend erforderlich ist. Daher ist es sinnvoll, für derartige wiederkehrende Konstrukte eigene Methoden zu definieren, die zugleich die IDs auf Eindeutigkeit überprüfen. Im konkreten Fall wurde dies mit einer Methode realisiert, die die erstellten Topics in eine Hashtable (mit deren IDs als Schlüssel) ablegt, falls diese ID dort noch nicht vorhanden ist. Im anderen Fall wird das durch die ID referenzierte Topic aus der Hashtable zurückgegeben. Template Die in angesprochene Zweiteilung einer Topic Map kommt auch hier zum Tragen. So werden zu Beginn des Exports in der Methode xtmCreateTopix (siehe ) die (grundlegenden) Topic Types, wie weiter oben erläutert, erstellt. Diese Topics werden dabei nach festem Schema in einer Hashtable abgelegt. (Schlüssel ist der String aus dem Datenbankattribut attributes.type.) Individuen Die Daten der individuellen Topics werden mit denselben Methoden aus der Klasse Service wie beim MetaChart-XML-Export eingeholt und mit ähnlichen Methoden wie in xref verarbeitet. Dabei wird beispielsweise zu jedem MetaChart-Topic der MetaChart-Topic Types aus der Hashtable miteinbezogen. Miteinander verbundene MetaCharts oder MetaChart-Attributes werden mittels Associations in der Topic Map in Beziehung gebracht, wozu ein passender Association Type aus der Hashtable genommen oder aber ein eigener neu erstellt wird. Zur Erstellung einer Association inklusive speziellem Association Type stehen die Methoden createAssociationTopic und createAssociation in der Klasse TopicHash () zur Verfügung.
XSL Transformation von <wordasword>MetaChart</wordasword>-XML nach <foreignphrase>Topic Maps</foreignphrase> Es bietet sich an, das vorhandene MetaChart-XML () mittels XSL Transformation zum Einen in die Linear Topic Map Notation, da diese mit recht einfachen Anweisungen auskommt, zum Anderen direkt nach XML Topic Maps, was einen Zwischenschritt erspart, zu überführen. zeigt Ausschnitte des Stylesheets für die Linear Topic Map Notation. Das Stylesheet in erstellt im XSL-Template METACHARTS alle grundlegenden Topics (Topic Types und Association Types) für MetaChart, MetaChart-Attribute Metadaten, Rekursion und Assoziation (siehe ). Dabei setzt dieses Stylesheet zur Repräsentation der Metadaten das von Ontopia vorgeschlagene PSI ein. Die Metainformation wird hier – anstatt mit einer Association verbunden – direkt als Occurrence in das Topic eingebunden. Ontopias Topic Map-Browser stellt diese Metadaten gesondert dar. Im Template METACHART wird erst der Topic der MetaChart-Instanz erstellt, um dann dessen Metadaten im Template METADATAS/METADATA als Occurrence anzuhängen. Die Traversierung des XML-Baums wird in den Templates CHILDREN und ATTRIBUTES fortgesetzt. Egal ob Child-MetaCharts als Kindelement zu CHILDREN eingebunden oder in CHILD referenziert sind, wird eine Parent-Child-Association generiert. Das Template ATTRIBUTE enthält Fallunterscheidungen für die verschiedenen attributes.types. Mittels xsl:choose und xsl:when wird zwischen MetaChart-Attributes vom Typ assoziation, Binärdaten und Texten unterschieden. Für MetaChart-Assoziationen werden individuelle Association Types und Associations angelegt, Binärdaten werden mit ihrem Dateinamen als externe Occurrence und Texte als interne Occurrence eingebunden. Schließlich werden auch für die MetaChart-Attributes im Template METADATA deren Metainformationen behandelt. Dabei werden den Metainformationen des Typs title und createDate gesonderte Occurrence Types zugewiesen. Eine MetaChart-Topic Map ist in Auszügen in zu sehen. Proprietäres XML als Ausgangsbasis zur Erstellung einer Topic Map mag nicht immer die Flexibilität eines direkten Exports mittels Java erreichen; im konkreten Fall jedoch ist das XML für eine Abbildung nach Topic Maps ausreichend strukturiert. Der Aufwand der Javaimplementierung dagegen ist relativ hoch.
<foreignphrase>Resource Description Framework</foreignphrase> RDF RDF Resource RDF Property Ontologie Metainformation Metadatum Metainformation Das Resource Description Framework (RDF) (siehe Lassila99) ist eine ressourcenbeschreibende XML-Applikation, primär dazu gedacht, Metadaten abzulegen und Ontologien zu erstellen. RDF erfährt eine starke Unterstützung des W3Cs zur Verwirklichung der Semantic Web-Vision: Web pages at the moment in HTML are designed to be read by humans. In the future, some Web pages will be in RDF. This will be read by computer programs which will help us organize ourselves and our data and possibly everything we do BernersQA. Eine übliche Kurzdefinition des Begriffs Metadaten lautet: Daten über (andere) Daten; Informationen über (andere) Informationen. So sind Verfasser, Titel und Erstelldatum eines Dokuments Metadaten des Dokuments, was Daten an sich enthält. Meistens helfen Metadaten Informationen zu finden. Während manche Daten für ein Programm Metadaten darstellen, können dieselben Daten aus anderer Sicht nur Daten an sich sein. Im Bereich der relationalen Datenbanken beispielsweise ist genau definiert, wo Daten enden und Metadaten beginnen: Der Name jeder Tabelle und der Typ jeder Spalte sind Metadaten der abgelegten Daten. (Vgl. Ogbuji00) RDF basiert auf drei grundlegenden Konzepten: Resources (Ressourcen), Properties (Eigenschaften) und Statements (Aussagen). Resources sind analog zu Konzepten in der Theorie der Conceptual Graphs zu sehen. Die Kanten/Relationen der CGs entsprechen den Properties Sobald alle (In-)Begriffe durch Ressourcen definiert sind, können Aussagen über die Domäne gemacht werden. Dies geschieht, indem man Tripel aus Ressourcen, Eigenschaften und Werten (Literale oder eine andere Ressource) bildet. (vgl. Anderson00) Diese Tripel entsprechen gerichteteten Graphen. Es ergibt sich eine Subject-Predicate-Object-Grammatik, die wie folgt interpretiert wird: subject has a Property valued by object. Das Beispiel aus würde hier lauten: cat has the Property on valued by mat. Tripel RDF <foreignphrase>Resources</foreignphrase> Alles was in RDF beschrieben wird, nennt sich Resource. Diese werden durch Uniform Resource Identifiers (URI) (vgl. RFC2396) und mittels # angehängte Fragment Identifier benannt. Alles Erdenkliche kann einer URI zugewiesen werden: A Resource can be anything that has identity. Familiar examples include an electronic document, an image, a service, and a collection of other Resources. Not all Resources are network retrievable; e.g., human beings, corporations, and bound books in a library can also be considered Resources RFC2396. <foreignphrase>Properties</foreignphrase> Eine Property ist eine spezifische Eigenschaft oder eine Beziehung, die eine Resource näher beschreibt. RDF definiert nur wenige Properties, da beliebige Properties mittels Resources definiert werden können. <foreignphrase>Statements</foreignphrase> RDF Statement Die angesprochenen Tripel aus Subject, Predicate und Object heißen Statements (Aussagen). Das Object eines Statements kann eine andere Resource oder als Literal direkt eingebunden sein. Letzteres wird in XML als String oder anderer primitiver Datentyp abgelegt, der auch XML-Markup enthalten darf, das nicht weiter von RDF-Prozessoren untersucht wird.
RDF NameSpaces, Vocabulary RDF definiert nur wenige Kernelemente sowie die Syntax der Tripel. RDF definiert nicht das Vokabular, das zur Beschreibung der Resources und Properties genutzt wird. Dieses wird mit Hilfe der Kernelemente von RDF und Resource Description Framework Schema (RDFS) (siehe Brickley00) erzeugt. Für typische Eigenschaften empfiehlt sich der Gebrauch weitverbreiteter Vokabulare, wie z. B. Dublin Core (siehe RFC2413).
RDF und RDFS Taxonomie Klasse Instanz RDF und RDFS sind definierte Namespaces. Im Gegensatz zu XML verweist die Namespace-Angabe gleichzeitig auf das RDF Schema. RDFS erweitert die Ausdrucksstärke der Resource-Property-Object-Tripel in RDF zu einem Netzwerk an verwandten Beschreibungen mittels Taxonomien durch Klassen und Instanzen. The membership of one or the other namespace may not always seem logical, and must have historical reasons mostly Champin01. Ein Dokument, das eine Sammlung von Properties und Klassen definiert, also die Bedeutung der Resourcen beschreibt, nennt sich Schema. RDF-Schema is a simple ontology language able to define basic vocabularies Fensel00. RDFS ist selbst, wie auch andere Schemata, in der RDF-Syntax definiert Lassila99.
Klassen in RDF Instanzen von Klassen sind Resources, die mittels der Property rdf:type auf die entsprechende Klasse verweisen. Diesen Klassenresources wiederum ist als Property rdfs:Class zuzuweisen. Analog verweisen alle Properties mittels rdf:type auf rdf:Property. Ein Beispiel zur Bildung von Klassen und Instanzen findet sich in
Das <emphasis>Dublin Core</emphasis>-Vokabular Die Dublin Core Metadata Initiative (dublincore.org), eine internationale Gruppe von Experten, definiert als RDF Applikation ein Vokabular über fünfzehn typische Meta-Angaben wie title, creator, date, format, references. Zu vielen Angaben sind noch Verfeinerungen wie z. B. relation.isPartOf oder encoding-schemes festgelegt, wie z. B. Formatierung von Datumsangaben nach ISO in : YYYY-MM-DDThh:mm:ssTZD. Die Elemente werden u. a. in RFC2413 erläutert.
RDF-Syntax RDF RDF Resource RDF Property Weiter Verbreitung erfreut sich die Notation 3 (N3) als Alternative zur XML-Darstellung der Tripel. Die Gemeinschaft der RDF Interest Group stellt eine Vielzahl von Tools – meist in Python realisiert – für dieses Format zur Verfügung. N-Triples ist eine ähnliche, von N3 abgeleitete Kurzform. Als Beispiel sei der Satz Jenny Doe ist die Autorin einer am 28. März 2002 vorgelegten Seminararbeit mit dem Titel Bauhaus Hausbau in RDF dargestellt: In N3 ist zu formulieren: @prefix : <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix dc: <http://purl.org/dc/elements/1.0/> . <http://localhost/doc/seminararbeit> dc:creator "Jenny Doe"; dc:date "2002-03-28"; dc:description "Eine Seminarbeit in Architektur"; dc:title "Bauhaus Hausbau" . Die XML-Syntax ist etwas länger: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.0/"> <rdf:Description rdf:about="http://localhost/doc/seminararbeit"> <dc:creator>Jenny Doe</dc:creator> <dc:title>Bauhaus Hausbau</dc:title> <dc:description> Eine Seminarbeit in Architektur </dc:description> <dc:date>2002-03-28</dc:date> </rdf:Description> </rdf:RDF> Das Attribut rdf:about verweist auf die Ressource, die die Rolle des Subjects einnimmt, um näher bestimmt zu werden, z. B. mittels der Property dc:creator, die den Wert Jenny Doe trägt. Neben dieser Form sind noch andere verkürzende XML-Syntax gültig, beispielsweise können die Objektliterale anstelle von Textknoten auch als Attributwerte dargestellt werden. Das Wurzelelement ist rdf:RDF. Es werden zwei Namensräume angegeben: die RDF-Syntax-Definition des W3-Konsortiums und die von Dublin Core (DC). Dadurch lassen sich mit rdf: Tags aus dem W3-Namensraum benutzen, und mit dc: Tags aus dem Dublin-Core-Namensraum. Das Beispiel ist in folgende Tripel zerlegbar: Tripel eines RDF-Modells # Subject Predicate Object 1 http://localhost/doc/seminararbeit http://purl.org/dc/elements/1.0/creator Jenny Doe 2 http://localhost/doc/seminararbeit http://purl.org/dc/elements/1.0/title Bauhaus Hausbau 3 http://localhost/doc/seminararbeit http://purl.org/dc/elements/1.0/description Eine Seminarbeit in Architektur 4 http://localhost/doc/seminararbeit http://purl.org/dc/elements/1.0/date 2002-03-28
Jedes Tripel erzeugt einen gerichteten Graphen, dessen Knoten und Kanten mit URIs gekennzeichnet sind. Die Kanten werden mit Prädikaten benannt, die Knoten mit Subjekten oder Objekten.
Grafische Darstellung der RDF-Tripel
Erweiterung zu Klassen Jenny Doe soll nun als Instanz der Klasse Student erscheinen. Dazu wird <dc:creator…> ersetzt durch: <dc:creator rdf:resource="http://localhost/jenny"/> Weiterhin sind folgende Tripel anzufügen, die die Resource jenny als Instanz der Resource student, die wiederum als RDF-Klasse definiert ist, ausweist: <rdf:Description rdf:about="http://localhost/student"> <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> <dc:title>Student(in)</dc:title> </rdf:Description> <rdf:Description rdf:about="http://localhost/jenny"> <rdf:type rdf:resource="http://localhost/student"/> <dc:title>Jenny Doe</dc:title> </rdf:Description> Der Verweis auf #Class entstammt dem RDFS-Namespace, der zu Beginn als solcher deklariert werden kann, wie in Notation3 formuliert: @prefix : <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix dc: <http://purl.org/dc/elements/1.0/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . <http://localhost/doc/seminararbeit> dc:creator <http://localhost/jenny>; dc:date "2002-03-28"; dc:description "Eine Seminarbeit in Architektur"; dc:title "Bauhaus Hausbau" . <http://localhost/jenny> a <http://localhost/student>; dc:title "Jenny Doe" . <http://localhost/student> a rdfs:Class; dc:title "Student(in)" . Vor allem das rdf:type-Konstrukt ist in N3 durch a sehr lesbar. Im folgenden Graphen ist zur Verdeutlichung der Klassenbeziehung auch John Doe als Instanz von student modelliert: Visualisierung RDF
Grafische Darstellung der RDF-Tripel mit einer Klasse
Auch ist es möglich, Unterklassen (subClassOf) sowie Untereigenschaften (subPropertyOf) zu modellieren. Dabei ist zu beachten, keine transitiven Zyklen zu erstellen. Sei τ die durch τ(s, p, o) = wahr, genau dann wenn s has t valued by o definierte Relation, dann gelten folgende Transitivitäten: Sei i eine Instanz der Klasse/vom Typ c 1 und c 1 Unterklasse von c 2, so ist i auch vom Typ c 2. type-subClass-type-Transitivität $$\forall \; i, c_1, c_2 \;\; \tau(c_1, \mathtt{rdf\!:\!type}, c_2) \;\wedge\; \tau(c_1, mathtt{rdfs\!:\!subClassOf}, c_2) \Rightarrow \tau (i, \mathtt{rdf\!:\!type}, c_2)$$ Sei c 1 Unterklasse von c 2 und c 2 Unterklasse von c 3, so ist c 1 auch Unterklasse zu c 3. subClass-subClass-subClass-Transitivität Zyklen sind nicht gültig, d. h. τ ist in keinem Fall reflexiv: Zyklus Analoge Überlegungen gelten für subPropertyOf. Die in vorgestellte Schreibweise für Inferenzen wäre ebenso denkbar; die Aussagen sind ähnlich.
Speziellere RDF(S)-Elemente Definitionsmenge und Wertemenge von Objekte können mit Constraintseingeschränkt werden. Dies geschieht mit den RDFS-Elementen domain bzw. range, die einer Property zugewiesen werden können. Beispielsweise könnte ein domain-Constraint der dc:author-Property festlegen, dass diese Property nur von Resources ausgehen darf, die Instanzen einer Klasse book sind. Ebenso könnte mittels range definiert werden, dass der Wert von dc:author eine Instanz der Klasse person sein muss. Ähnlich den XML-Schema-Konstrukten zur Gruppierung von Elementen gibt es in RDF ungeordnete Listen (Bag), geordnete Listen (Seq) sowie Gruppen von Alternativen (Alt). Diese drei Elemente sind Unterklassen der RDFS-Klasse Container. (Vgl. Brickley00) Mittels rdfs:label und rdfs:comment können für menschliche Betrachter Ressourcen benannt bzw. erläutert werden.
<wordasword>MetaChart</wordasword> im RDF-Modell Zur Erstellung einer Abbildung von MetaChart nach RDF wurde Jena, eine Open Source-Bibliothek mit Java-API McBride02 von Brian McBride, in der Version 1.3 verwendet. Die Erstellung eines RDF-Modells mittels XSL Transformation aus dem MetaChart-XML erscheint aufwändiger als den Export mit Hilfe dieser weit verbreiteten, ausgereiften Bibliothek, da diese einen leichten Zugriff auf die definierten Namensräume und Vokabulare ermöglicht, sowie die Erstellung der Tripel mittels intuitiven Methoden bereitstellt. Analog zur Erstellung des Templates in Topic Maps (siehe ) werden hier vorab Resources zur Abbildung der MetaChart-Konzepte MetaChart, MetaChart-Attribute und View erstellt. Die benötigten Vokabulare werden von com.hp.hpl.mesa.rdf.jena.vocabulary.RDF, .RDFS und .DC importiert, um auf die enthaltenen Konstanten zugreifen zu können. Ressourcen können damit einfach als Klasseninstanzen erstellt werden: Resource metachart = Model.createResource(RDFTools.appendURI("metachart"), RDFS.Class) .addProperty(RDFS.label, "MetaChart"); Dies erzeugt folgende Resource: <rdf:Description rdf:about='http://dayf.de#metachart'> <rdf:type rdf:resource='http://www.w3.org/2000/01/rdf-schema#Class'/> <rdfs:label>MetaChart</rdfs:label> </rdf:Description> Der Aufruf von appendURI bewirkt dabei, den localpart an eine absolute URI zu hängen. Beziehungen zwischen den Ressourcen werden mittels Properties aus dem Dublin Core Element Set modelliert. Die Hierarchie der MetaCharts entsteht durch das Element DC.relation.isPartOf bzw. DC.relation.hasPart, wobei die Verfeinerung von relation nicht in der Jena Vokabularklasse definiert ist; sie muss als String angefügt werden. Für Assoziationen wird einheitlich das Element DC.relation.references verwendet: Property hasPart = m.createProperty(DC.relation + ".hasPart"); Property references = m.createProperty(DC.relation + ".references"); Die weitere Erstellung verläuft analog zum XML-Export, d. h. Methoden namens processMetaChart, processMetaData, processAttribute, processView und processChildren sind auch hier mit den entsprechenden gegenseitigen Aufrufen (siehe ) wiederzufinden. Gerade im Export nach RDF sind Metadaten von besonderem Interesse, da das Dublin Core Element Set viele Properties in diesem Bereich definiert und die Verwendung dieser eine breite Unterstützung in vorhandenen Anwendungen zusichert. Darum werden die Metadaten mit bekannten Typen explizit behandelt: if (metadata.getType().equalsIgnoreCase("createDate")) { instance.addProperty(DC.date, metadata.getValue()); } Falls also das Objekt metadata eine Metainformation des Typs createDate enthält, wird der jeweiligen MetaChart- bzw. MetaChart-Attribute-Instanz (instance) als Wert der Property DC.date die Metainformation zugewiesen (siehe auch ). Auftretende MetaChart-Attribute-Werte werden als Literal (ein String der die Rolle des Objects einnimmt) an die MetaChart-Attribute-Instanz im Modell gehängt. Als verbindende Property steht RDF.Value zur Verfügung: MetaChart-Attribute has the Property RDF.Value valued by attributes.value. Ausschnitte der Beispielinstanz sind in zu sehen. Im Beispiel Jenny studiert Architektur in Weimar könnte nun eine Inferenzregel definiert werden, die als resultierende Aussage Architektur ist ein Studiengang in Weimar oder Weimar bietet-an Architektur liefert. In Notation3 und für CWM (Tim Berners-Lee’s Closed World Machine, Palmer01) oder Sean B. Palmers Eep Palmer02 ist die Regel wie folgt zu formulieren: ?x <#studiert> ?y . ?x <#studiert-in> ?z . log:implies ?z <#bietet-an> ?y . Für die zwei Tripel <#jenny> <#studiert-in> <#weimar> . <#jenny> <#studiert> <#architektur> . liefert das Pythonskript dieses neue Tripel: <#weimar> <#bietet-an> <#architektur> . Die Inferenzprozessoren nutzen beispielsweise auch die Definition einer Property als transitiv (siehe ), um Aussagen wie in dargestellt, zu erstellen.
Ergebnisbetrachtung XML Topic Maps Topic Maps Multipurpose Internet Mail Extension MIME Resource Description Framework RDF Portable Document Format PDF Formatting Objects FO Document Object Model DOM Cascading Style Sheets CSS Document Type Definition DTD Document Style Semantics and Specification Language DSSSL KI Künstliche Intelligenz Den verschiedenen Wissensrepräsentationsformaten RDF und Topic Maps ist gemeinsam, dass sie Aussagen Aussage Logik über benennbare Dinge (siehe ) erlauben. Sei als Resource oder Topic – die Idee bleibt dieselbe: Wohl definierte Dinge werden mittels Symbolen Symbol dargestellt. Für reine XML-Repräsentationen hingegen gibt es keine Auszeichnung eines Elements als Ding. Hier ist der Hauptunterschied zu Formaten der Wissensrepräsentation Wissensrepräsentation zu sehen. Ist ein Ding als solches nicht definierbar, können auch keine charakterisierenden Eigenschaften benannt oder Aussagen darüber gemacht werden. Das MetaChart-XML bietet in seiner strukturierten Form jedoch eine gute, serialisierte Ausgangsbasis für die verschiedensten Zielformate. Ein RDF-Modell besteht aus primitiven, dreiteiligen Einträgen und ist somit einfach zu handhaben. Die Abfolge der Tripel Tripel – wie auch der Topics Topic Maps Topic Maps Topic Topic Maps Association Topic Maps Occurrence Association Topic Occurrence und Associations in Topic Maps – ist nicht bezeichnend im Gegensatz zur Elementreihenfolge in DTD-konformen XML-Instanzen. Für ein zu publizierendes Dokument macht es beispielsweise Sinn, festzulegen, dass der Titel eines Abschnitts vor den Absätzen zu erscheinen hat – bei der Notierung von Metadaten ist es hingegen gleichgültig, in welcher Reihenfolge Titel, Autor, Datum und ähnliches erscheinen. Der Vorteil flacher Strukturen, die keine Elementreihenfolge und -verschachtelung in tiefe Ebenen vorgeben, liegt in ihrer Skalierbarkeit: Rekursive Referenzierungen bilden Hierarchien; zu diesen können jederzeit neue Ebenen hinzugefügt oder bestehende einfach durch Änderungen ihrer Referenzen verschoben werden. Sollen Anfragen an modellierte Wissensstrukturen gestellt werden, sind diese in einer Engine, die die Daten in einer internen, datenbankähnlichen Struktur vorhält – losgelöst von der jeweiligen serialisierten Serialisierung Wissensrepräsentation – auszuwerten.
<foreignphrase>Topic Maps</foreignphrase> und RDF in der Anwendung
<foreignphrase>Resource Description Framework</foreignphrase> Neben der breiten Verwendung von RDF(S) in Bibliotheken ist die automatische Generierung der Metainformationen in Adobe Acrobat zu nennen: In den Dokumentinformationen einer PDF-Datei finden sich RDF-Tripel, die auch das Dublin Core Element Set nutzen. Ein sehr großes RDF-Modell hält das Open Directory Project (dmoz.org) vor: The Open Directory Project is the largest, most comprehensive human-edited directory of the Web. It is constructed and maintained by a vast, global community of volunteer editors. Es bildet die inhaltliche Grundlage für Webverzeichnisse vieler Suchmaschinen. Die Generierung der RDF-Daten aus deren Datenbank dauert ein komplettes Wochenende.
<foreignphrase>Topic Maps</foreignphrase> Die Börse Stuttgart (boerse-stuttgart.de) präsentiert ihren Optionsscheinleitfaden als Topic Map. Ein Java-Applet stellt diese als navigierbaren, hyperbolischen Baum dar, d. h. das interessierende Topic wandert in den Vordergrund während weiter entfernte ausgeblendet werden. Die Information zum jeweiligen Thema wird außerhalb des Applets angezeigt. Univers Immedia (universimmedia.com) bietet eine Zusammenstellung von Ressourcen für das Semantic Web und verwandte Technologien. Die Daten liegen als Topic Map vor; für das entsprechende Topic im Fokus werden die verknüpften Themen und die zugehörigen Ressourcen aufgelistet.
RDF und <foreignphrase>Topic Maps</foreignphrase> im Vergleich Resource RDF Resource Ein erster Unterschied zwischen RDF und Topic Maps zeigt sich in der Modellierung eines Dings: Ressourcen in RDF sind durch URIs identifiziert, während Topics mittels URIs auf Ressourcen verweisen, die das Topic verkörpern, und zusätzlich auf URIs verweisen, um das Topic zu beschreiben. Die Definition der Art der Dinge stellt sich in beiden Modellen mittels Instanz-von-Beziehungen ähnlich dar. Wie jedoch Aussagen zu Begriffen oder Beziehungen untereinander formuliert werden, ist für Topic Maps und RDF sehr unterschiedlich. Während RDF das Konzept der Conceptual Graphs Conceptual Graphs aufgreift und somit gerichtete Graphen erzeugt, sind Associations in Topic Maps stets ungerichtet, d. h. in beide Richtungen gültig. Zur Darstellung der Eigenschaften eines Konzepts Konzept bedarf es in RDF eigener Tripel, die diese Eigenschaft als Literal oder als Ressource mit dem Konzept verbinden. Eine Unterscheidung ähnlich dem Entity Relationship Model in Entitäten und Attributen ist hier nicht möglich. Im Gegensatz dazu ist bei Topic Maps zwischen verschiedenen Konstrukten abzuwägen: Erstellung einer Association zu einem charakterierenden Topic Referenzierung als externe Occurrence Einbindung als interne Occurrence Analog zum Prädikat (Property) eines Tripels, das die Art des Attributs definiert, kann den Occurrences ein Topic als Typ zugewiesen werden. In Topic Maps ist also eine Unterscheidung zwischen Namen, einfachen Eigenschaften und verbundenen Ressourcen somit implizit. In RDF ist es v. a. für einen Prozessor schwierig, Unterschiede auszumachen. Ein Hauptvorteil für Topic Maps zeigt sich in der Modellierung eines relevanten Kontexts eines Konzepts. In Topic Maps gibt es dafür Scopes. Diese könnten einem Topic Map-Browser als Filter dienen, so dass nur interessierende Topics angezeigt werden. Steve Pepper sieht dieses Instrument als unschlagbares Konstrukt im Vergleich zu RDF: This is the killer argument for me; until someone can prove that scope can be modelled intuitively using RDF I see no way in which RDF could usefully replace topic maps Pepper00a. Die angesprochenen Punkte zeigen, dass Topic Maps differenziertere Konstrukte aufweisen als RDF, d. h. letzteres ist semantisch Semantik auf einer tieferen, generischeren Ebene anzusiedeln. Daraus resultieren verschiedene Aspekte: conceptualization Datentyp Visualisierung Topic Maps Konzepte sind in Topic Maps einfacher zu erkennen (conceptualization). Damit ist auch eine interaktive Visualisierung der Topic Map verständlicher zu gestalten, wie die Beispiele in verdeutlichen. RDF lässt sich vielseitig erweitern. Darpa Agent Markup Language (DAML) und Ontology Inference Layer (OIL) als RDF Schemasprache erweitern RDFS beispielsweise um Konstrukte zur Beschreibung der Semantik sowie zur Einschränkungen von Datenstrukturen, die in RDF beschrieben werden. So können in DAML explizit Klassen als disjunkt zu anderen Klassen, oder Eigenschaften als invers oder transitiv definiert werden. Zudem erlaubt DAML die Verwendung der Datentypen aus dem XML Schema. (siehe ) Tabelle vergleicht die Konstrukte von Conceptual Graphs, Resource Description Framework und Topic Maps: CGs versus RDF versus <foreignphrase>Topic Maps</foreignphrase> CG RDF Topic Maps Beispiel Konzeptinstanz Resource Topic [the] cat, [the] mat Konzeptklasse rdf:type(rdfs:Class) Topic Type cat, mat Relation Property Association/Occurrence (sat/is) on Relationstyp rdf:type(rdf:Property) Association Type/Occurrence Type Verb mit Präposition Konzepte in Relation Statement-Tripel Topic associates Topic Topic occurs in Occurrence The cat sat on the mat.
Conceptual Graphs Allgemein betrachtet, stellen Topic Maps und RDF unterschiedliche Abstraktionsstufen dar: Topic Maps stellen ein Themengebiet oder einzelne Themen in den Vordergrund und bilden eine semantische Netzwerkschicht über den Ressourcen, während RDF von der Ressource als Quelle ausgeht und diese mit Anmerkungen versieht. (Vgl. Pepper00a) Eine breitere Verfügbarkeit von Browsern für Topic Maps ist somit verständlich, während sich für RDF Tripel eine statische, graphische Darstellung anbietet. (Siehe .) RDF RDF Resource RDF Property Topic Maps Topic Maps Topic Topic Maps Association Topic Maps Occurrence Association Topic Occurrence Verschiedene Untersuchungen über die gegenseitige Abbildung der Modelle (um Datenstrukturen eines Modells in das andere überführen zu können und vice versa) stellen fest, dass dies zwar möglich sei, jedoch grundlegende Unterschiede vorhanden seien. (Vgl. Moore01): A topic map may be encoded in RDF, but an RDF processor would not be able to do anything useful with it because of the loss of semantics. There would be no way for the processor to know the difference between topics and information resources, or between occurrences [and] associations Pepper99. Betrachtet man die umgekehrte Situation, RDF als Topic Map abzubilden, könnte ein RDF Statement entweder als eine Association oder eine Occurrence in der Topic Map repräsentiert werden. Falls sowohl das Subject als auch das Object als Topics innerhalb der Topic Map dargestellt sind, ist eine Association zu modellieren; handelt es sich um ein Literal oder eine Ressource ausserhalb der Topic Map, ist eine Occurrence das passende Konstrukt. Kombination von RDF und <foreignphrase>Topic Maps</foreignphrase> Um Vorteile beider Modelle zu nutzen, ist ein verflechtetes Modell denkbar, das beispielsweise in Teilbereichen Metainformationen als RDF auszeichnet und diese Stücke vermöge der Topic Map assoziiert. Konkret würde dies eine Einbettung oder Referenzierung von RDF-ausgezeichneten Daten als Occurrences in der Topic Map bedeuten. Dies ist am Beispiel MetaChart in zu sehen. Als Nachteil dieser Lösung ist jedoch der Verlust der Verbindung zwischen der semantischen Ebene der Topic Map und den Metainformationen zu sehen. Gerade die Formulierung von Transitivitäten, wie in Aufbauten zu RDF möglich ist, sowie der Einsatz von Schlussfolgerungsprozessoren, die für RDF(S) mit TRIPLE (vgl. Decker02) und den in vorgestellten Pythonskripten vorhanden sind, fehlt bei Topic Maps. Inferenzen zu bilden ist zwar Aufgabe eines Prozessors und nicht eines statischen Dokuments: in beiden Modellen sind die Ergebnisse als neue Association bzw. als neues Tripel dem Dokument zuzufügen. RDF erlaubt jedoch im Gegensatz zu Topic Maps eine direktere Deklarierung der Inferenzregeln in der eigenen Syntax, wie in erläuterten Beispielen ersichtlich ist. Transitivität
Vergleich der XML-Formate im <wordasword>MetaChart</wordasword>-Kontext Obwohl XML und XML Schema keinerlei Semantik beinhalten, bietet sich das proprietäre XML wie in erläutert, zur Transformation nach Topic Maps an. Primär gedacht zum Datenaustausch (wie z. B. mit IDS Scheer, die MetaChart-Sessions nach Aris (ein Analysewerkzeug für Geschäftsprozesse) importieren, erlaubt das XML auch eine Transformation nach PDF über XSL-FO und ermöglicht so auch wieder einen visuellen Bezug zu den erarbeiteten Ergebnissen aus MetaChart-Sitzungen ähnlich einer MetaPlan-Sitzung (siehe ). XSL Semantik PDF Extensible Stylesheet Language XSL Konzept Vergleicht man die Abbildung des MetaChart-Modells in Topic Maps mit der RDF-Abbildung, so erscheint das Topic Map-Modell für MetaChart geeigneter. Der Grund ist in einer direkteren Abbildung der MetaChart-Konzepte in Topic Types und Topics zu sehen, die, wie oben beschrieben, im Vordergrund stehen. Das RDF-Modell mit der Gleichwertigkeit der – aus kleineren Einheiten bestehenden – Aussagen, zeigt dagegen Vorteile im Bereich logischer Abfragen, wie z. B. den gezeigten, einfachen Inferenzen, sowie in der Abbildung der Metainformationen. Für weiterreichende Klassendefinitionen, die beispielsweise mit DAML und/oder OIL möglich sind, ist das Ausgangsmaterial der generisch gehaltenen MetaChart-Datenbank nicht komplex genug. Für das gruppenbasierte Kreativitätswerkzeug MetaChart ist ein Logikaufbau kaum von Nutzen – Kreativität ist nicht deterministisch. Die Abbildungen beider Modelle sind ausreichend detailliert, um einen MetaChart-Import zu genügen. Dazu ist vorab die MetaChart-Hierarchie aus den Statements bzw. Associations wieder in eine explizite Form zu bringen. Ist ein Import allgemeiner Topic Maps angestrebt, muss entschieden werden, welche Association eine transitive Beziehung, z. B. is-a- oder Instanz-von-Beziehungen, darstellt, um diese als Hierarchie umzusetzen.
Fazit Fakten in der richtigen Aufbereitung sind wertvoll, bedeuten aber noch lange nicht Wissen (vgl. Korbmann01), und das Problem der wissenserstickenden Informationsfülle ist mit den vorgestellten Repräsentationen nicht aus der Welt geschafft – immerhin beschreibt es jedoch einen Schritt in die richtige Richtung: Informationen kategorisieren, ihren Zusammenhang darstellen, den Überblick ermöglichen und nicht zuletzt die Auffindbarkeit einzelner Dokumente erhöhen. Es steckt jedoch einiger Aufwand dahinter, Dokumente derartig auszuzeichnen: There is no realistic hope of globally classifying all concepts, terms and relationships; we need to be able to manage and interrelate our ontologies project by project, domain by domain, so that scalability is achieved without either runaway complexity or over-simplification Wrightson01. Durch das intuitive Konzept der MetaChart-Applikation entstehen in kreativen Sitzungen Wissenstrukturen, die mit dem Export nach RDF und Topic Maps am globalen Projekt teilhaben können. Kritiker des frühen World Wide Webs wiesen darauf hin, dass es nie eine gut organisierte Bibliothek werden könne: Without a central database and tree structure, one would never be sure of finding everything Berners01a. Es ist richtig, dass sich in dieser Vielseitigkeit nie alles finden lassen wird – mit Ontologien in RDF und Topic Maps jedoch könnte sich das vom Chaos beherrschte Internet in ein beherrschtes Chaos verwandeln.
<wordasword>MetaChart</wordasword>-XML
<wordasword>MetaChart</wordasword>-Applikation
<wordasword>MetaChart</wordasword>-DTD <!-- root element --> <!ELEMENT METACHARTS (METACHART*)> <!ATTLIST METACHARTS timestamp CDATA #IMPLIED quantity CDATA #IMPLIED date CDATA #IMPLIED > <!-- the only element within the root element --> <!ELEMENT METACHART (TITLE?, ATTRIBUTES?, CHILDREN?, METADATAS?, VIEWS?)> <!ATTLIST METACHART mcid ID #REQUIRED owner IDREF #IMPLIED parent IDREF #IMPLIED > <!-- Title of MetaChart (redundant: also at metachart/metadatas/metadata(type=title)) --> <!ELEMENT TITLE (#PCDATA)> <!ELEMENT ATTRIBUTES (ATTRIBUTE*)> <!ATTLIST ATTRIBUTES quantity CDATA #IMPLIED > <!-- Attributes of MetaCharts --> <!-- <!ELEMENT ATTRIBUTE ((VALUE | VIEWS | METADATAS)*) > --> <!ELEMENT ATTRIBUTE (VALUE*, VIEWS?, METADATAS?) > <!ATTLIST ATTRIBUTE attrid CDATA #REQUIRED > <!-- Container for any Data (probably wrapped by a CDATA section) --> <!-- (srcId, dstId, srcMCId, dstMCId, title) for ATTRIBUTE type=edge|assoziation --> <!-- other attributes may follow in newer versions --> <!ELEMENT VALUE (#PCDATA)> <!ATTLIST VALUE mimetype CDATA #IMPLIED type CDATA #REQUIRED encoding CDATA #IMPLIED srcId CDATA #IMPLIED dstId CDATA #IMPLIED srcMCId CDATA #IMPLIED dstMCId CDATA #IMPLIED title CDATA #IMPLIED fullName CDATA #IMPLIED userName CDATA #IMPLIED password CDATA #IMPLIED > <!-- --> <!ELEMENT VIEWS (VIEW*)> <!ATTLIST VIEWS quantity CDATA #IMPLIED > <!ELEMENT VIEW (VIEWDATA*)> <!ATTLIST VIEW viewid CDATA #REQUIRED owner IDREF #REQUIRED > <!-- --> <!ELEMENT VIEWDATA (#PCDATA)> <!ATTLIST VIEWDATA type CDATA #REQUIRED > <!-- reference to (or embedding of) child-MetaCharts of MetaChart [embedding only intended for xsl:fo] --> <!ELEMENT CHILDREN (( CHILD* | METACHART* ))> <!ATTLIST CHILDREN quantity CDATA #IMPLIED > <!ELEMENT CHILD (#PCDATA)> <!ATTLIST CHILD mcref IDREF #REQUIRED > <!-- MetaData for MetaCharts or Attributes. e.g. title, createDate --> <!ELEMENT METADATAS (METADATA*)> <!ATTLIST METADATAS quantity CDATA #IMPLIED > <!ELEMENT METADATA (#PCDATA)> <!ATTLIST METADATA type CDATA #REQUIRED >
XML Schema <?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:simpleType name="attr-type"> <xs:restriction base="xs:string"> <xs:pattern value="attr\d+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="view-type"> <xs:restriction base="xs:string"> <xs:pattern value="vi\d+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="mc-type-raw"> <xs:restriction base="xs:string"> <xs:pattern value="mc\d+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="mc-type"> <xs:union memberTypes="mc-type-raw xs:ID"/> </xs:simpleType> <xs:simpleType name="owner-type"> <xs:union memberTypes="mc-type-raw xs:IDREF"/> </xs:simpleType> <xs:simpleType name="parent-type"> <xs:union memberTypes="mc-type-raw xs:IDREF"/> </xs:simpleType> <!-- CHILD mcref="child-type" --> <xs:simpleType name="child-type"> <xs:union memberTypes="mc-type-raw xs:IDREF"/> </xs:simpleType> <xs:simpleType name="quantity-type"> <xs:union memberTypes="xs:decimal"/> </xs:simpleType> <!-- METADATA type="metadatatype-type" --> <xs:simpleType name="metadatatype-type"> <xs:union memberTypes="xs:string"/> </xs:simpleType> <!-- VIEWDATA type="metadatatype-type" --> <xs:simpleType name="viewdatatype-type"> <xs:union memberTypes="xs:string"/> </xs:simpleType> <xs:attributeGroup name="attribute-value-assoziation-group"> <xs:attribute name="srcId" type="xs:string"/> <xs:attribute name="dstId" type="xs:string"/> <xs:attribute name="srcMCId" type="mc-type"/> <xs:attribute name="dstMCId" type="mc-type"/> <xs:attribute name="title" type="xs:string"/> </xs:attributeGroup> <xs:attributeGroup name="attribute-value-userPreferences-group"> <xs:attribute name="fullName" type="xs:string"/> <xs:attribute name="userName" type="xs:string"/> <xs:attribute name="password" type="xs:string"/> </xs:attributeGroup> <xs:attributeGroup name="attribute-value-mimecoding-group"> <xs:attribute name="mimetype" type="xs:string"/> <xs:attribute name="encoding" type="xs:string"/> </xs:attributeGroup> <xs:element name="METACHARTS"> <xs:complexType> <xs:sequence> <xs:element ref="METACHART" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="timestamp" type="xs:string"/> <xs:attribute name="quantity" type="quantity-type"/> <xs:attribute name="date" type="xs:string"/> <!-- dateTime --> </xs:complexType> </xs:element> <xs:element name="METACHART"> <xs:complexType> <xs:sequence><!-- group order="any" --> <xs:element ref="TITLE" minOccurs="0"/> <xs:element ref="ATTRIBUTES" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="CHILDREN" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="METADATAS" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="VIEWS" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="mcid" type="mc-type" use="required"/> <xs:attribute name="owner" type="owner-type" use="optional"/> <xs:attribute name="parent" type="parent-type" use="optional"/> <!-- xs:ID --> <!-- xs:idref --> </xs:complexType> </xs:element> <xs:element name="TITLE" type="xs:string"/> <xs:element name="ATTRIBUTES"> <xs:complexType> <xs:sequence> <xs:element ref="ATTRIBUTE" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="quantity" type="quantity-type"/> </xs:complexType> </xs:element> <xs:element name="ATTRIBUTE"> <xs:complexType> <xs:sequence> <xs:element ref="VALUE" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="VIEWS" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="METADATAS" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="attrid" type="attr-type" use="required"/> </xs:complexType> </xs:element> <xs:element name="VALUE"> <xs:annotation> <xs:documentation>element can contain more or less "anything": from nothing over text to base64. and also can have a many different attributes, organized in attributeGroups</xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="type" type="xs:string" use="required"/> <xs:attributeGroup ref="attribute-value-mimecoding-group"/> <xs:attributeGroup ref="attribute-value-assoziation-group"/> <xs:attributeGroup ref="attribute-value-userPreferences-group"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="VIEWS"> <xs:complexType> <xs:sequence> <xs:element ref="VIEW" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="quantity" type="quantity-type" use="optional"/> <xs:attribute name="owner" type="owner-type" use="required"/> </xs:complexType> </xs:element> <xs:element name="VIEW"> <xs:complexType> <xs:sequence> <xs:element ref="VIEWDATA" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="viewid" type="view-type" use="required"/> </xs:complexType> </xs:element> <xs:element name="VIEWDATA"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="type" type="viewdatatype-type" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="CHILDREN"> <xs:complexType> <xs:choice> <xs:element ref="CHILD" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="METACHART" minOccurs="0" maxOccurs="unbounded"/> </xs:choice> <xs:attribute name="quantity" type="quantity-type"/> </xs:complexType> </xs:element> <xs:element name="CHILD"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="mcref" type="child-type" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="METADATAS"> <xs:complexType> <xs:sequence> <xs:element ref="METADATA" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="quantity" type="quantity-type"/> </xs:complexType> </xs:element> <xs:element name="METADATA"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="type" type="metadatatype-type" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:schema>
Beispielinstanz aus <wordasword>MetaChart</wordasword>-Export <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE METACHARTS SYSTEM "metacharts.dtd"> <METACHARTS date="Mon Mar 18 15:25:27 CET 2002" quantity="14" timestamp="20020318032527"> <!-- ... --> <METACHART mcid="mc1937120584" owner="mc1475124348" parent="mc1425722723"> <TITLE>Studium</TITLE> <ATTRIBUTES quantity="0"/> <CHILDREN quantity="3"> <CHILD mcref="mc502589505">Ort</CHILD> <CHILD mcref="mc1564127045">Studiengang</CHILD> <CHILD mcref="mc1841561650">Student(in)</CHILD> </CHILDREN> <METADATAS> <METADATA type="createDate">20020318022336</METADATA> <METADATA type="title">Studium</METADATA> </METADATAS> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi1112029776"> <VIEWDATA type="backgroundColor">-7693874</VIEWDATA> <VIEWDATA type="title">Studium</VIEWDATA> <VIEWDATA type="rect">40#51#1068#731</VIEWDATA> </VIEW> </VIEWS> </METACHART> <METACHART mcid="mc502589505" owner="mc1475124348" parent="mc1937120584"> <TITLE>Ort</TITLE> <ATTRIBUTES quantity="0"/> <CHILDREN quantity="2"> <CHILD mcref="mc2137864275">Weimar</CHILD> <CHILD mcref="mc443199914">Berlin</CHILD> </CHILDREN> <METADATAS> <METADATA type="createDate">20020318022422</METADATA> <METADATA type="title">Ort</METADATA> </METADATAS> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi577615540"> <VIEWDATA type="backgroundColor">-7693874</VIEWDATA> <VIEWDATA type="title">Ort</VIEWDATA> <VIEWDATA type="rect">565#10#407#426</VIEWDATA> </VIEW> </VIEWS> </METACHART> <!-- ... --> <METACHART mcid="mc1196092215" owner="mc1475124348" parent="mc1841561650"> <TITLE>Jenny Doe</TITLE> <ATTRIBUTES quantity="4"> <ATTRIBUTE attrid="attr653056631"> <VALUE encoding="plain" mimetype="text/plain" type="text/plain"> When "foo" is used in connection with "bar" it has generally traced to the WWII-era Army slang acronym FUBAR (Fucked Up Beyond All Repair), later modified to foobar. </VALUE> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi1109138964"> <VIEWDATA type="rect">103#6#285#127</VIEWDATA> <VIEWDATA type="backgroundColor">-723770</VIEWDATA> <VIEWDATA type="title">Seminararbeit</VIEWDATA> </VIEW> </VIEWS> <METADATAS> <METADATA type="createDate">20020318022751</METADATA> <METADATA type="title">private</METADATA> </METADATAS> </ATTRIBUTE> <ATTRIBUTE attrid="attr334267580"> <VALUE dstId="mc2137864275" dstMCId="mc2137864275" srcId="mc1196092215" srcMCId="mc1196092215" type="assoziation" title="studiert-in"> studiert-in </VALUE> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi1109138964"> <VIEWDATA type="edge">todo</VIEWDATA> </VIEW> </VIEWS> <METADATAS> <METADATA type="createDate">20020318023820</METADATA> <METADATA type="title">egde</METADATA> </METADATAS> </ATTRIBUTE> <ATTRIBUTE attrid="attr198592949"> <VALUE dstId="mc522272996" dstMCId="mc522272996" srcId="mc1196092215" srcMCId="mc1196092215" type="assoziation" title="studiert"> studiert </VALUE> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi1109138964"> <VIEWDATA type="edge">todo</VIEWDATA> </VIEW> </VIEWS> <METADATAS> <METADATA type="createDate">20020318031257</METADATA> <METADATA type="title">egde</METADATA> </METADATAS> </ATTRIBUTE> <ATTRIBUTE attrid="attr1768538671"> <VALUE encoding="plain" mimetype="text/plain" type="text/plain"> John and Jane are nobody. </VALUE> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi1109138964"> <VIEWDATA type="rect">40#46#37#48</VIEWDATA> <VIEWDATA type="backgroundColor">-723770</VIEWDATA> <VIEWDATA type="title">private</VIEWDATA> </VIEW> </VIEWS> <METADATAS> <METADATA type="createDate">20020318031431</METADATA> <METADATA type="title">Bauhaus</METADATA> </METADATAS> </ATTRIBUTE> </ATTRIBUTES> <CHILDREN quantity="0"/> <METADATAS> <METADATA type="createDate">20020318022622</METADATA> <METADATA type="title">Jenny Doe</METADATA> </METADATAS> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi1109138964"> <VIEWDATA type="backgroundColor">-7693874</VIEWDATA> <VIEWDATA type="title">Jenny Doe</VIEWDATA> <VIEWDATA type="rect">174#210#410#165</VIEWDATA> </VIEW> </VIEWS> </METACHART> <METACHART mcid="mc804971150" owner="mc1475124348" parent="mc1841561650"> <TITLE>John Doe</TITLE> <ATTRIBUTES quantity="1"> <ATTRIBUTE attrid="attr245993684"> <VALUE encoding="base64" mimetype="image/gif" type="image/gif"><![CDATA[ R0lGODlhZQBuAPcHAP////f39+/v7+fn597e3tbW1s7OzsbGxr29vbW1ta2traWlpZycnJSUlISE hHt7e3Nzc2tra2NjY1paWlJSUkpKSkJCQjk5OTExMSkpKSEhIRgYGBAQEAgICMbGvTlCKUJKOWuc ... 9HAePnhtPiGE7CYVRahumkiFSNiJVeiJoPiJ3KIVcygVPDiChlGCIeiDQqiCWZiCPRiL6SEPCiAP 7FaHdWGHfMIUiDF616cgvKggwuiLCJAKxViCwpiMcLeMzAhqAQEAOw==]]&gt;</VALUE> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi711092418"> <VIEWDATA type="rect">20#20#150#153</VIEWDATA> <VIEWDATA type="backgroundColor">-723770</VIEWDATA> </VIEW> </VIEWS> <METADATAS> <METADATA type="createDate">20020318032014</METADATA> <METADATA type="title">unicycle.gif</METADATA> </METADATAS> </ATTRIBUTE> </ATTRIBUTES> <CHILDREN quantity="0"/> <METADATAS> <METADATA type="createDate">20020318022633</METADATA> <METADATA type="title">John Doe</METADATA> </METADATAS> <VIEWS quantity="1"> <VIEW owner="mc1475124348" viewid="vi711092418"> <VIEWDATA type="backgroundColor">-7693874</VIEWDATA> <VIEWDATA type="title">John Doe</VIEWDATA> <VIEWDATA type="rect">43#55#260#234</VIEWDATA> </VIEW> </VIEWS> </METACHART> <!-- ... --> </METACHARTS>
Darstellung mit <foreignphrase>Cascading Style Sheets</foreignphrase>
XML-Darstellung mittels CSS
<foreignphrase>XSL Formatting Objects</foreignphrase> Stylesheet <?xml version="1.0" encoding="ISO-8859-1"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:fox="http://xml.apache.org/fop/extensions"> <xsl:output method="xml" indent="yes" version="1.0" encoding="iso-8859-1"/> <xsl:template match="METACHARTS"> <fo:root> <fo:layout-master-set> <fo:simple-page-master master-name="simple" page-height="29.7cm" page-width="21cm" margin-top="1cm" margin-bottom="2cm" margin-left="2.5cm" margin-right="2.5cm"> <fo:region-body margin-top="3cm"/> <fo:region-before extent="3cm"/> <fo:region-after extent="1.5cm"/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-reference="simple"> <fo:static-content flow-name="xsl-region-before"> <fo:block text-align="end" font-size="10pt" font-family="serif" line-height="14pt"> <xsl:text>MetaChart-Export </xsl:text><xsl:value-of select="/METACHARTS/@date"/><xsl:text> -- page </xsl:text><fo:page-number/> </fo:block> </fo:static-content> <fo:flow flow-name="xsl-region-body"> <fo:block> <xsl:apply-templates select="METACHART"/> </fo:block> </fo:flow> </fo:page-sequence> </fo:root> </xsl:template> <!-- end: defines page layout --> <!-- start page-sequence --> <!-- layout single metacharts --> <xsl:template match="METACHART"> <fo:block padding-top="12mm" font-family="sans-serif" font-size="24pt" font-weight="bold"> <xsl:number count="METACHART" level="multi"/> <xsl:text> MetaChart "</xsl:text> <xsl:value-of select="METADATAS/METADATA[@type='title']"/> <xsl:text>"</xsl:text> </fo:block> <fo:block margin-left="from-parent(margin-left)+1cm" font-family="monospace" font-size="8"> <xsl:text> (</xsl:text><xsl:value-of select="@mcid"/><xsl:text>)</xsl:text> <xsl:apply-templates select="METADATAS"/> </fo:block> <xsl:apply-templates select="ATTRIBUTES"/> <xsl:apply-templates select="CHILDREN"/> </xsl:template> <xsl:template match="CHILDREN"> <fo:block margin-left="from-parent(margin-left)+1cm"> <xsl:apply-templates select="METACHART"/> </fo:block> </xsl:template> <xsl:template match="ATTRIBUTES"> <fo:block margin-left="from-parent(margin-left)+1cm"> <xsl:apply-templates select="ATTRIBUTE"/> </fo:block> </xsl:template> <!-- layout attributes --> <xsl:template match="ATTRIBUTE"> <fo:block padding-top="7mm" font-family="sans-serif" font-size="18pt" font-weight="bold"> <xsl:text>Attribute "</xsl:text> <xsl:value-of select="METADATAS/METADATA[@type='title']"/> <xsl:text>"</xsl:text> </fo:block> <fo:block margin-left="from-parent(margin-left)+1cm" font-family="monospace" font-size="8"> <xsl:text>(</xsl:text><xsl:value-of select="@attrid"/><xsl:text>)</xsl:text> <xsl:apply-templates select="METADATAS"/> <fo:block padding-top="7mm" margin-left="from-parent(margin-left)+1cm" font-family="serif" font-size="10"> <xsl:apply-templates select="VALUE"/> </fo:block> </fo:block> </xsl:template> <xsl:template match="METADATAS"> <fo:block margin-left="from-parent(margin-left)+0cm" padding-top="4mm" font-family="serif" font-weight="normal" font-size="10"> <xsl:apply-templates select="METADATA"/> </fo:block> </xsl:template> <!-- layout metadatas --> <xsl:template match="METADATA"> <fo:block font-weight="normal"> <fo:inline font-weight="bold"> <xsl:value-of select="@type"/><xsl:text>: </xsl:text> </fo:inline> <xsl:value-of select="."/> </fo:block> </xsl:template> <!-- layout attributes.value --> <xsl:template match="VALUE"> <fo:block font-weight="normal"> <fo:inline font-weight="bold"> <xsl:value-of select="@type"/><xsl:text>: </xsl:text> </fo:inline> <!-- distinguish attributes.types --> <xsl:choose> <xsl:when test="@type='assoziation'"> <fo:block> <fo:inline font-weight="bold"> <xsl:text>From: </xsl:text> </fo:inline> <xsl:value-of select="@srcMCId"/> <xsl:text>, </xsl:text> <xsl:value-of select="@srcId"/> </fo:block> <fo:block> <fo:inline font-weight="bold"> <xsl:text>To: </xsl:text> </fo:inline> <xsl:value-of select="@dstMCId"/> <xsl:text>, </xsl:text> <xsl:value-of select="@dstId"/> </fo:block> </xsl:when> <!-- embeddable graphix --> <xsl:when test="starts-with(@type, 'image/')"> <xsl:variable name="bild" select="../METADATAS/METADATA[@type='title']"/> <fo:block> <fo:external-graphic src="{$bild}"/> </fo:block> </xsl:when> <!-- standard attributes.value --> <xsl:otherwise> <fo:block> <xsl:value-of select="."/> </fo:block> </xsl:otherwise> </xsl:choose> </fo:block> </xsl:template> </xsl:stylesheet>
XML-Darstellung als PDF
XML als PDF formatiert
<acronym>XML</acronym> <foreignphrase>Topic Maps</foreignphrase>
XSL Stylesheet (<wordasword>MetaChart</wordasword>-XML nach LTM) <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="text" indent="no"/> <xsl:template match="METACHARTS"> [mc = "MetaChart"] [relationship = /child "is child of"] [relationship = /parent "is parent of"] <!-- ... --> </xsl:template> <xsl:template match="METACHART"> [<xsl:value-of select="@mcid"/> : mc = "<xsl:value-of select="@mcid"/>"; ; <xsl:value-of select="METADATAS/METADATA[@type='title']"/> ] <!-- ... --> </xsl:template> <xsl:template match="CHILD"> relationship([<xsl:value-of select="@mcref"/>] : child, [<xsl:value-of select="../../@mcid"/>] : parent) </xsl:template> <xsl:template match="ATTRIBUTE"> {<xsl:value-of select="@attrid"/>, <xsl:value-of select="VALUE/@type"/>, [[<xsl:value-of select="VALUE"/> ]]} </xsl:template> <!-- ... --> </xsl:stylesheet>
XSL Stylesheet (<wordasword>MetaChart</wordasword>-XML nach XTM) <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <xsl:output method="xml" indent="yes" encoding="iso-8859-1"/> <xsl:template match="METACHARTS"> <topicMap id="mcexport" xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink"> <!-- name the topic map --> <topic id="mctm"> <subjectIdentity> <subjectIndicatorRef xlink:href="#mcexport"/> </subjectIdentity> <baseName> <baseNameString>MetaChart TopicMap</baseNameString> </baseName> </topic> <!-- some topic types --> <topic id="mc"> <baseName> <baseNameString>MetaChart</baseNameString> </baseName> </topic> <topic id="parent"> <baseName> <baseNameString>Parent</baseNameString> </baseName> </topic> <topic id="child"> <baseName> <baseNameString>Child</baseNameString> </baseName> </topic> <topic id="title"> <instanceOf> <topicRef xlink:href="#ot.metadata"/> </instanceOf> <baseName> <baseNameString>Title</baseNameString> </baseName> </topic> <topic id="ot.metadata"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://psi.ontopia.net/xtm/occurrence-type/metadata"/> </subjectIdentity> <baseName> <baseNameString>metadata</baseNameString> <variant> <parameters><topicRef xlink:href="#sort"/></parameters> <variantName><resourceData>metadata</resourceData></variantName> </variant> </baseName> </topic> <!-- some association types --> <topic id="at_parentchild"> <baseName> <scope> <topicRef xlink:href="#parent"></topicRef> </scope> <baseNameString>is parent of</baseNameString> </baseName> <baseName> <baseNameString>Parent-Child relation</baseNameString> </baseName> <baseName> <scope> <topicRef xlink:href="#child"></topicRef> </scope> <baseNameString>is child of</baseNameString> </baseName> </topic> <xsl:apply-templates select="METACHART"/> </topicMap> </xsl:template> <!-- get the single metacharts as instance --> <xsl:template match="METACHART"> <topic> <xsl:attribute name="id"><xsl:value-of select="@mcid"/></xsl:attribute> <!-- ... --> <xsl:apply-templates select="METADATAS"/> </topic> <xsl:apply-templates select="CHILDREN"/> <xsl:apply-templates select="ATTRIBUTES"/> </xsl:template> <xsl:template match="CHILDREN"> <!-- routines for children/child and children/metachart --> <xsl:for-each select="CHILD"> <association> <!-- ... --> </association> </xsl:for-each> <xsl:for-each select="METACHART"> <association> <instanceOf> <topicRef xlink:href="#at_parentchild"></topicRef> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#parent"/> </roleSpec> <topicRef> <xsl:attribute name="xlink:href"> <xsl:text>#</xsl:text> <xsl:value-of select="../../@mcid"/> </xsl:attribute> </topicRef> </member> <member> <roleSpec> <topicRef xlink:href="#child"/> </roleSpec> <topicRef> <xsl:attribute name="xlink:href"> <xsl:text>#</xsl:text> <xsl:value-of select="@mcid"/> </xsl:attribute> </topicRef> </member> </association> </xsl:for-each> <!-- catch child-metacharts here --> <xsl:apply-templates select="METACHART"/> </xsl:template> <xsl:template match="ATTRIBUTES"> <xsl:apply-templates select="ATTRIBUTE"/> </xsl:template> <xsl:template match="ATTRIBUTE"> <xsl:choose> <!-- catch edges/assoziationen --> <xsl:when test="VALUE/@type='assoziation'"> <xsl:apply-templates select="VALUE"/> </xsl:when> <!-- attach normal metachart-attributes via association --> <xsl:when test="not(VALUE/@type='assoziation')"> <association> <!-- ... --> </association> <!-- create the attribute topic --> <topic> <!-- ... --> <!-- get their metadata --> <xsl:apply-templates select="METADATAS"/> <!-- not being an edge/assoziation, include the attributes.value as occurrence or link depending on type --> <xsl:choose> <xsl:when test="not(starts-with(VALUE/@type, 'text/'))"> <!-- ... --> <occurrence> <instanceOf> <topicRef xlink:href="#attributeValue"></topicRef> </instanceOf> <resourceRef> <xsl:attribute name="xlink:href"> <xsl:value-of select="METADATAS/METADATA[@type='title']"/> </xsl:attribute> </resourceRef> </occurrence> </xsl:when> <xsl:otherwise> <occurrence> <instanceOf> <topicRef xlink:href="#attributeValue"></topicRef> </instanceOf> <resourceData><xsl:value-of select="VALUE"/></resourceData> </occurrence> </xsl:otherwise> </xsl:choose> </topic> </xsl:when><!-- endif:assoziation--> </xsl:choose> </xsl:template><!-- end:attribute --> <xsl:template match="METADATAS"> <xsl:apply-templates select="METADATA"/> </xsl:template> <!-- include metadata as occurrence --> <xsl:template match="METADATA"> <xsl:choose> <xsl:when test="@type='title' or @type='createDate'"> <occurrence> <instanceOf> <topicRef> <xsl:attribute name="xlink:href"> <xsl:text>#</xsl:text> <xsl:value-of select="@type"/> </xsl:attribute> </topicRef> </instanceOf> <resourceData><xsl:value-of select="."/></resourceData> </occurrence> </xsl:when> <xsl:otherwise> <!-- ... --> </xsl:otherwise> </xsl:choose> </xsl:template> <!-- create an association for edges/assoziationen --> <xsl:template match="VALUE"> <!-- variables for roleplayers --> <xsl:variable name="role-src"> <xsl:choose> <xsl:when test="starts-with(@srcId, 'attr')">attribute</xsl:when> <xsl:otherwise>mc</xsl:otherwise> </xsl:choose> </xsl:variable> <xsl:variable name="role-dst"> <xsl:choose> <xsl:when test="starts-with(@dstId, 'attr')">attribute</xsl:when> <xsl:otherwise>mc</xsl:otherwise> </xsl:choose> </xsl:variable> <!-- special association type --> <topic> <xsl:attribute name="id"> <xsl:text>at_</xsl:text> <xsl:value-of select="@title"/> </xsl:attribute> <!-- ... --> </topic> <!-- association as instance of this ass.type w/ matching role types --> <association> <instanceOf> <topicRef> <xsl:attribute name="xlink:href"> <xsl:text>#at_</xsl:text> <xsl:value-of select="@title"/> </xsl:attribute> </topicRef> </instanceOf> <!-- ... --> </association> </xsl:template> </xsl:stylesheet>
XTM-Beispielinstanz aus <wordasword>MetaChart</wordasword>-Export <?xml version="1.0" encoding="iso-8859-1"?> <topicMap xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink" id="mcexport"> <topic id="mctm"> <subjectIdentity> <subjectIndicatorRef xlink:href="#mcexport" /> </subjectIdentity> <baseName> <baseNameString>MetaChart TopicMap</baseNameString> </baseName> </topic> <topic id="mc"> <baseName> <baseNameString>MetaChart</baseNameString> </baseName> </topic> <topic id="parent"> <baseName> <baseNameString>Parent</baseNameString> </baseName> </topic> <topic id="child"> <baseName> <baseNameString>Child</baseNameString> </baseName> </topic> <topic id="attribute"> <baseName> <baseNameString>Attribute</baseNameString> </baseName> </topic> <topic id="title"> <instanceOf> <topicRef xlink:href="#ot.metadata" /> </instanceOf> <baseName> <baseNameString>Title</baseNameString> </baseName> </topic> <topic id="ot.metadata"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://psi.ontopia.net/xtm/occurrence-type/metadata" /> </subjectIdentity> <baseName> <baseNameString>metadata</baseNameString> <variant> <parameters> <topicRef xlink:href="#sort" /> </parameters> <variantName> <resourceData>metadata</resourceData> </variantName> </variant> </baseName> </topic> <topic id="mc1841561650"> <instanceOf> <topicRef xlink:href="#mc" /> </instanceOf> <baseName> <baseNameString>Student(in)</baseNameString> </baseName> <occurrence> <instanceOf> <topicRef xlink:href="#createDate" /> </instanceOf> <resourceData>20020318022440</resourceData> </occurrence> <occurrence> <instanceOf> <topicRef xlink:href="#title" /> </instanceOf> <resourceData>Student(in)</resourceData> </occurrence> </topic> <association> <instanceOf> <topicRef xlink:href="#at_parentchild" /> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#parent" /> </roleSpec> <topicRef xlink:href="#mc1841561650" /> </member> <member> <roleSpec> <topicRef xlink:href="#child" /> </roleSpec> <topicRef xlink:href="#mc1196092215" /> </member> </association> <association> <instanceOf> <topicRef xlink:href="#at_parentchild" /> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#parent" /> </roleSpec> <topicRef xlink:href="#mc1841561650" /> </member> <member> <roleSpec> <topicRef xlink:href="#child" /> </roleSpec> <topicRef xlink:href="#mc87292200" /> </member> </association> <topic id="mc1196092215"> <instanceOf> <topicRef xlink:href="#mc" /> </instanceOf> <baseName> <baseNameString>Jenny Doe</baseNameString> </baseName> <occurrence> <instanceOf> <topicRef xlink:href="#createDate" /> </instanceOf> <resourceData>20020318022622</resourceData> </occurrence> <occurrence> <instanceOf> <topicRef xlink:href="#title" /> </instanceOf> <resourceData>Jenny Doe</resourceData> </occurrence> </topic> <topic id="attr653056631"> <instanceOf> <topicRef xlink:href="#attribute" /> </instanceOf> <baseName> <baseNameString>Seminararbeit</baseNameString> </baseName> <occurrence> <instanceOf> <topicRef xlink:href="#createDate" /> </instanceOf> <resourceData>20020318022751</resourceData> </occurrence> <occurrence> <instanceOf> <topicRef xlink:href="#title" /> </instanceOf> <resourceData>Seminararbeit</resourceData> </occurrence> <occurrence> <instanceOf> <topicRef xlink:href="#attributeValue" /> </instanceOf> <resourceData>When "foo" is used in connection with "bar" it has generally traced to the WWII-era Army slang acronym FUBAR (Fucked Up Beyond All Repair), later modified to foobar.</resourceData> </occurrence> </topic> <topic id="at_studiert-in"> <baseName> <baseNameString>studiert in relation</baseNameString> </baseName> <baseName> <scope> <topicRef xlink:href="#mc" /> </scope> <baseNameString>studiert in</baseNameString> </baseName> <baseName> <scope> <topicRef xlink:href="#mc" /> </scope> <baseNameString>1 / studiert in</baseNameString> </baseName> </topic> <association> <instanceOf> <topicRef xlink:href="#at_studiert-in" /> </instanceOf> <member> <roleSpec> <topicRef xlink:href="#mc" /> </roleSpec> <topicRef xlink:href="#mc1196092215" /> </member> <member> <roleSpec> <topicRef xlink:href="#mc" /> </roleSpec> <topicRef xlink:href="#mc2137864275" /> </member> </association> <topic id="attr1768538671"> <instanceOf> <topicRef xlink:href="#attribute" /> </instanceOf> <baseName> <baseNameString>private</baseNameString> </baseName> <occurrence> <instanceOf> <topicRef xlink:href="#createDate" /> </instanceOf> <resourceData>20020318031431</resourceData> </occurrence> <occurrence> <instanceOf> <topicRef xlink:href="#title" /> </instanceOf> <resourceData>private</resourceData> </occurrence> <occurrence> <instanceOf> <topicRef xlink:href="#attributeValue" /> </instanceOf> <resourceData>John and Jane are nobody.</resourceData> </occurrence> </topic> <!-- ... --> </topicMap>
Darstellung der <foreignphrase>Topic Map</foreignphrase> in einem <foreignphrase>Topic Map</foreignphrase>-Browser
Ontopias Omnigator
<foreignphrase>Resource Description Framework</foreignphrase>
<wordasword>MetaChart</wordasword> RDF-Modell <rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:dc='http://purl.org/dc/elements/1.0/' xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#' > <rdf:Description rdf:about='http://dayf.de#mc2137864275'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318022513</dc:date> <dc:title>Weimar</dc:title> <rdf:value rdf:resource='http://dayf.de#mc2137864275_bag'/> <rdf:value rdf:resource='http://dayf.de#mc2137864275_vi1810827710_view'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc556206654'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc804971150_bag'> <rdf:type rdf:resource='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/> <rdf:_1 rdf:resource='http://dayf.de#attr245993684'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#attr653056631'> <rdf:type rdf:resource='http://dayf.de#attribute'/> <dc:format>text/plain</dc:format> <rdf:value>When "foo" is used in connection with "bar" it has generally traced to the WWII-era Army slang acronym FUBAR (F***** Up Beyond All Repair), later modified to foobar. </rdf:value> <dc:date>20020318022751</dc:date> <dc:title>Seminararbeit</dc:title> <rdf:value rdf:resource='http://dayf.de#attr653056631_vi1109138964_view'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc1196092215'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318022622</dc:date> <dc:title>Jenny Doe</dc:title> <dc:relation.references.studiert-in rdf:resource='http://dayf.de#mc2137864275'/> <rdf:value rdf:resource='http://dayf.de#mc1196092215_bag'/> <dc:relation.references.studiert rdf:resource='http://dayf.de#mc522272996'/> <rdf:value rdf:resource='http://dayf.de#mc1196092215_vi1109138964_view'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc1841561650'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318022440</dc:date> <dc:title>Student(in)</dc:title> <rdf:value rdf:resource='http://dayf.de#mc1841561650_vi1536071023_view'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc1196092215'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc804971150'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc87292200'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#attr1768538671'> <rdf:type rdf:resource='http://dayf.de#attribute'/> <dc:format>text/plain</dc:format> <rdf:value>Jane and John are nobody.</rdf:value> <dc:date>20020318031431</dc:date> <dc:title>private</dc:title> <rdf:value rdf:resource='http://dayf.de#attr1768538671_vi1109138964_view'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc522272996'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318022458</dc:date> <dc:title>Architektur</dc:title> <rdf:value rdf:resource='http://dayf.de#mc522272996_bag'/> <rdf:value rdf:resource='http://dayf.de#mc522272996_vi694640503_view'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc1937120584'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318022336</dc:date> <dc:title>Studium</dc:title> <rdf:value rdf:resource='http://dayf.de#mc1937120584_vi1112029776_view'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc502589505'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc1564127045'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc1841561650'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc556206654_bag'> <rdf:type rdf:resource='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/> <rdf:_1 rdf:resource='http://dayf.de#attr675063415'/> <rdf:_2 rdf:resource='http://dayf.de#attr724849265'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc1564127045'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318022431</dc:date> <dc:title>Studiengang</dc:title> <rdf:value rdf:resource='http://dayf.de#mc1564127045_vi915070974_view'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc522272996'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc169350985'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc87292200'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318022645</dc:date> <dc:title>Jane Doe</dc:title> <rdf:value rdf:resource='http://dayf.de#mc87292200_bag'/> <rdf:value rdf:resource='http://dayf.de#mc87292200_vi164241980_view'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#attr675063415'> <rdf:type rdf:resource='http://dayf.de#attribute'/> <dc:format>text/plain</dc:format> <rdf:value></rdf:value> <dc:date>20020318023146</dc:date> <dc:title>Goethehaus</dc:title> <rdf:value rdf:resource='http://dayf.de#attr675063415_vi775898276_view'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc502589505'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318022422</dc:date> <dc:title>Ort</dc:title> <rdf:value rdf:resource='http://dayf.de#mc502589505_vi577615540_view'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc2137864275'/> <dc:relation.hasPart rdf:resource='http://dayf.de#mc443199914'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc1425722723_bag'> <rdf:type rdf:resource='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/> <rdf:_1 rdf:resource='http://dayf.de#attr1159770409'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#view'> <rdf:type rdf:resource='http://www.w3.org/2000/01/rdf-schema#Class'/> <rdfs:label>View</rdfs:label> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc556206654'> <rdf:type rdf:resource='http://dayf.de#metachart'/> <dc:date>20020318023136</dc:date> <dc:title>Sights</dc:title> <rdf:value rdf:resource='http://dayf.de#mc556206654_bag'/> <rdf:value rdf:resource='http://dayf.de#mc556206654_vi775898276_view'/> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#attribute'> <rdf:type rdf:resource='http://www.w3.org/2000/01/rdf-schema#Class'/> <rdfs:label>Attribute</rdfs:label> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#metachart'> <rdf:type rdf:resource='http://www.w3.org/2000/01/rdf-schema#Class'/> <rdfs:label>MetaChart</rdfs:label> </rdf:Description> <rdf:Description rdf:about='http://dayf.de#mc2137864275_bag'> <rdf:type rdf:resource='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/> <rdf:_1 rdf:resource='http://dayf.de#attr1529644663'/> </rdf:Description> <!-- ... --> </rdf:RDF>
RDF Visualisierung
Graph der RDF-Instanz
RDF innerhalb XTM <?xml version="1.0" encoding="iso-8859-1" standalone="yes"?> <topicMap xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.0/" xmlns:db="http://www.oasis-open.org/docbook/xmlschema/4.1.2.3/" > <!-- ... --> <topic id="attr653056631"> <instanceOf> <topicRef xlink:href="#attribute"/> </instanceOf> <baseName> <baseNameString>Seminararbeit</baseNameString> </baseName> <occurrence> <instanceOf> <topicRef xlink:href="#attributeValue"/> </instanceOf> <resourceData> <rdf:RDF> <rdf:Description> <dc:creator>Jenny Doe</dc:creator> <dc:creator rdf:parseType="Resource"> <rdf:type rdf:paresType="Resource"> <rdf:type rdf:resource= "http://www.w3.org/2000/01/rdf-schema#Class"/> <dc:title>Student(in)</dc:title> </rdf:type> <dc:title>Jenny Doe</dc:title> </dc:creator> <dc:title>Bauhaus Hausbau</dc:title> <dc:description> Eine Seminarbeit in Architektur </dc:description> <dc:date>2002-03-28</dc:date> <rdf:value rdf:parseType="Literal"> When <db:wordasword>foo</db:wordasword> is used in connection with <db:wordasword>bar</db:wordasword> it has generally traced to the WWII-era Army slang acronym <db:acronym>FUBAR</db:acronym> (Fucked Up Beyond All Repair), later modified to <db:emphasis>foobar</db:emphasis>. </rdf:value> </rdf:Description> </rdf:RDF> </resourceData> </occurrence> </topic> <!-- ... --> </topicMap> <wordasword>MetaChart</wordasword>-Export Reference Being a Java novice, the implementation is pretty much on a procedural basis. The export-module is being incorporated into the MetaChart-project via Enterprise Java Beans (EJB), therefore the EJB container manages the transaction on the database automatically.
Package de.fhg.iao.metachart.export
Class MCEntry Java Reference MCEntry Classes MCEntry Instanciate XML. Get starting mc_ids; evaluate these MetaCharts. Create Element METACHARTS.
Members
Method enter(Connection) Java Reference enter Methods enter
Synopsis: public String enter(java.sql.Connection conn);
Parameters java.sql.Connection conn JDBC connection handle return java.lang.String
Class RDFEntry Java Reference RDFEntry Classes RDFEntry Instanciate the RDF XML. Get starting mc_ids; evaluate these MetaCharts.
Members
Constructor RDFEntry() Java Reference RDFEntry Methods RDFEntry
Synopsis: public RDFEntry();
Constructor for the RDFEntry object
Method enter(Connection) Java Reference enter Methods enter
Synopsis: public String enter(java.sql.Connection conn);
Parameters java.sql.Connection conn JDBC connection handle return java.lang.String
Class StartMeUp Java Reference StartMeUp Classes StartMeUp
Members
Constructor StartMeUp() Java Reference StartMeUp Methods StartMeUp
Synopsis: public StartMeUp();
Constructor for the StartMeUp object
Method main(String[]) Java Reference main Methods main
Synopsis: public static void main(java.lang.String[] args);
Parameters java.lang.String[] args The command line arguments; none needed. return void The main program for the StartMeUp class
Class XTMEntry Java Reference XTMEntry Classes XTMEntry Instanciate XML Topic Map, reify its BaseName, create basic topic types. Get starting mc_ids; evaluate these MetaCharts.
Members
Method enter(Connection) Java Reference enter Methods enter
Synopsis: public String enter(java.sql.Connection conn);
Parameters java.sql.Connection conn JDBC connection handle return java.lang.String
Method xtmCreateTopix(TopicMapFactory) Java Reference xtmCreateTopix Methods xtmCreateTopix
Synopsis: public TopicHash xtmCreateTopix( org.tm4j.topicmap.TopicMapFactory tmf);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory return de.fhg.iao.metachart.export.xtm.TopicHash Hashtable containing the basic topic and association types. Create the basic topic types and association types. Put them into the TopicHash topix Hashtable.
Package de.fhg.iao.metachart.export.dom
Class DocCreator Java Reference DocCreator Classes DocCreator Serialize the document instance and write it to file.
Members
Constructor DocCreator() Java Reference DocCreator Methods DocCreator
Synopsis: public DocCreator();
Constructor for the DocCreator object
Method closeDoc(Document) Java Reference closeDoc Methods closeDoc
Synopsis: public String closeDoc(org.w3c.dom.Document doc);
Parameters org.w3c.dom.Document doc Document instance return java.lang.String String
Class DOMAttributes Java Reference DOMAttributes Classes DOMAttributes Generate elements METACHART/ATTRIBUTES
Members
Method createElementValue(Document, AttributeType, Element) Java Reference createElementValue Methods createElementValue
Synopsis: public Element createElementValue(org.w3c.dom.Document doc, de.fhg.iao.metachart.export.tables.AttributeType type, org.w3c.dom.Element el_attribute);
Parameters org.w3c.dom.Document doc Document instance de.fhg.iao.metachart.export.tables.AttributeType type AttributeType-object containing attributes.type from database org.w3c.dom.Element el_attribute Element to append sub-elements to return org.w3c.dom.Element type-specific VALUE-Element Generate element ATTRIBUTE/VALUE depending on type.
Method processAttributes(Connection, String, Document, Element) Java Reference processAttributes Methods processAttributes
Synopsis: public void processAttributes(java.sql.Connection conn, java.lang.String mcId, org.w3c.dom.Document doc, org.w3c.dom.Element el_mc);
Parameters java.sql.Connection conn JDBC connection handle java.lang.String mcId Current mc_id org.w3c.dom.Document doc Document instance org.w3c.dom.Element el_mc Element to append sub-elements return void
Class DOMChildren Java Reference DOMChildren Classes DOMChildren Generate elements METACHART/CHILDREN
Members
Method processChildren(Connection, String, Document, Element, Hashtable) Java Reference processChildren Methods processChildren
Synopsis: public void processChildren(java.sql.Connection conn, java.lang.String Id, org.w3c.dom.Document doc, org.w3c.dom.Element insertpoint, java.util.Hashtable metacharts);
Parameters java.sql.Connection conn JDBC connection handle java.lang.String Id Current mc_id org.w3c.dom.Document doc Document instance org.w3c.dom.Element insertpoint Element to append sub-elements to java.util.Hashtable metacharts Hashtable containing all MetaChart-objects by mc_ids return void
Class DOMMetaChart Java Reference DOMMetaChart Classes DOMMetaChart Generate elements METACHART elements. Call methods to generate sub-elements METADATAS, ATTRIBUTES, CHILDREN, VIEWS
Members
Method processMetaChart(Connection, String, Document, Element, Hashtable) Java Reference processMetaChart Methods processMetaChart
Synopsis: public void processMetaChart(java.sql.Connection conn, java.lang.String Id, org.w3c.dom.Document doc, org.w3c.dom.Element elem, java.util.Hashtable metacharts);
Parameters java.sql.Connection conn JDBC connection handle java.lang.String Id Current mc_id org.w3c.dom.Document doc Document instance org.w3c.dom.Element elem Element to append sub-elements to java.util.Hashtable metacharts Hashtable containg all MetaChart-objects by mc_ids return void
Class DOMMetaDatas Java Reference DOMMetaDatas Classes DOMMetaDatas Generate elements METACHART/METADATAS or METACHART/ATTRIBUTES/METADATAS
Members
Method processMetaDatas(Connection, String, Document, Element) Java Reference processMetaDatas Methods processMetaDatas
Synopsis: public void processMetaDatas(java.sql.Connection conn, java.lang.String Id, org.w3c.dom.Document doc, org.w3c.dom.Element insertpoint);
Parameters java.sql.Connection conn JDBC connection handle java.lang.String Id Current id, mc_id or attr_id org.w3c.dom.Document doc Document instance org.w3c.dom.Element insertpoint Element to append sub-elements to return void
Class DOMViews Java Reference DOMViews Classes DOMViews Generate elements METACHART/VIEWS or METACHART/ATTRIBUTES/VIEWS
Members
Method processViews(Connection, String, Document, Element) Java Reference processViews Methods processViews
Synopsis: public void processViews(java.sql.Connection conn, java.lang.String Id, org.w3c.dom.Document doc, org.w3c.dom.Element insertpoint);
Parameters java.sql.Connection conn JDBC connection handle java.lang.String Id Current id, mc_id or attr_id org.w3c.dom.Document doc Document instance org.w3c.dom.Element insertpoint Element to append sub-elements to return void
Package de.fhg.iao.metachart.export.rdf
Class RDFAttributes Java Reference RDFAttributes Classes RDFAttributes Generate RDF for MetaChart/Attribute-associations
Members
Method processAssoziation(Connection, Model, String) Java Reference processAssoziation Methods processAssoziation
Synopsis: public void processAssoziation(java.sql.Connection conn, com.hp.hpl.mesa.rdf.jena.model.Model m, java.lang.String attrId);
Parameters java.sql.Connection conn JDCB connection handle com.hp.hpl.mesa.rdf.jena.model.Model m RDF Model java.lang.String attrId attr_id return void
Method processAttribute(Connection, Model, RDFTools, String, Hashtable, Resource) Java Reference processAttribute Methods processAttribute
Synopsis: public void processAttribute(java.sql.Connection conn, com.hp.hpl.mesa.rdf.jena.model.Model m, de.fhg.iao.metachart.export.rdf.RDFTools grammar, java.lang.String Id, java.util.Hashtable attributes, com.hp.hpl.mesa.rdf.jena.model.Resource metachartInstance) throws com.hp.hpl.mesa.rdf.jena.model.RDFException;
Parameters java.sql.Connection conn JDBC connection handle com.hp.hpl.mesa.rdf.jena.model.Model m RDF Model de.fhg.iao.metachart.export.rdf.RDFTools grammar basic Resources java.lang.String Id Current attr_id java.util.Hashtable attributes com.hp.hpl.mesa.rdf.jena.model.Resource metachartInstance Current MetaChart-instance as Resource return void Exceptions RDFException RDFException MethodDescription
Method processAttributeValue(Connection, Model, String, AttributeType, Resource) Java Reference processAttributeValue Methods processAttributeValue
Synopsis: public void processAttributeValue(java.sql.Connection conn, com.hp.hpl.mesa.rdf.jena.model.Model m, java.lang.String attrId, de.fhg.iao.metachart.export.tables.AttributeType type, com.hp.hpl.mesa.rdf.jena.model.Resource attributeInstance);
Parameters java.sql.Connection conn JDBC connection handle com.hp.hpl.mesa.rdf.jena.model.Model m RDF Model java.lang.String attrId Current attr_id de.fhg.iao.metachart.export.tables.AttributeType type attributes.type as AttributeType-object com.hp.hpl.mesa.rdf.jena.model.Resource attributeInstance Attribute-instance as Resource return void attribute value wird auf type untersucht. vom speziellen bis zum allgemeinen...
Class RDFChildren Java Reference RDFChildren Classes RDFChildren Generate RDF nodes for children of the current MetaChart
Members
Method processChildren(Connection, Model, RDFTools, Hashtable, String, Hashtable, Resource) Java Reference processChildren Methods processChildren
Synopsis: public void processChildren(java.sql.Connection conn, com.hp.hpl.mesa.rdf.jena.model.Model m, de.fhg.iao.metachart.export.rdf.RDFTools grammar, java.util.Hashtable metacharts, java.lang.String Id, java.util.Hashtable attributes, com.hp.hpl.mesa.rdf.jena.model.Resource metachartInstance) throws com.hp.hpl.mesa.rdf.jena.model.RDFException;
Parameters java.sql.Connection conn JDBC connection handle com.hp.hpl.mesa.rdf.jena.model.Model m RDF Model de.fhg.iao.metachart.export.rdf.RDFTools grammar Hashtable containing basic RDF classes java.util.Hashtable metacharts Hashtable containing all MetaChart -objects by mc_ids java.lang.String Id Current mc_id java.util.Hashtable attributes Hashtable com.hp.hpl.mesa.rdf.jena.model.Resource metachartInstance Current Resource to append children to return void Exceptions RDFException RDF-Exception
Class RDFMetaChart Java Reference RDFMetaChart Classes RDFMetaChart Generate RDF nodes for MetaCharts. Call methods to generate sub-nodes for MetaDatas, Attributes and child-MetaCharts.
Members
Method processMetaChart(Connection, Model, RDFTools, Hashtable, String, Hashtable) Java Reference processMetaChart Methods processMetaChart
Synopsis: public Resource processMetaChart(java.sql.Connection conn, com.hp.hpl.mesa.rdf.jena.model.Model m, de.fhg.iao.metachart.export.rdf.RDFTools grammar, java.util.Hashtable metacharts, java.lang.String Id, java.util.Hashtable attributes) throws com.hp.hpl.mesa.rdf.jena.model.RDFException;
Parameters java.sql.Connection conn Database Connection handle com.hp.hpl.mesa.rdf.jena.model.Model m RDF Model de.fhg.iao.metachart.export.rdf.RDFTools grammar Basic MetaChart RDF Nodes as Hashtable java.util.Hashtable metacharts Hashtable containing all MetaChart -objects by mc_id java.lang.String Id Current mcId java.util.Hashtable attributes Hashtable containing all Attribute- -objects by attr_id return com.hp.hpl.mesa.rdf.jena.model.Resource MetaChart-instance as RDF-Resource Exceptions RDFException RDF Exception
Class RDFMetaDatas Java Reference RDFMetaDatas Classes RDFMetaDatas Generate nodes for MetaChart- or Attribute-MetaDatas.
Members
Method processMetaData(Connection, Model, String, Resource) Java Reference processMetaData Methods processMetaData
Synopsis: public void processMetaData(java.sql.Connection conn, com.hp.hpl.mesa.rdf.jena.model.Model m, java.lang.String Id, com.hp.hpl.mesa.rdf.jena.model.Resource instance) throws com.hp.hpl.mesa.rdf.jena.model.RDFException;
Parameters java.sql.Connection conn JDBC connection handle com.hp.hpl.mesa.rdf.jena.model.Model m RDF Model java.lang.String Id Current mc_id or attr_id com.hp.hpl.mesa.rdf.jena.model.Resource instance Current MetaChart- or Attribute-instance as RDF Resource return void Exceptions RDFException RDF Exception
Class RDFTools Java Reference RDFTools Classes RDFTools Hashtable for basic RDF classes and generating method for this grammar
Members
Constructor RDFTools() Java Reference RDFTools Methods RDFTools
Synopsis: public RDFTools();
Field mainURI Java Reference mainURI Fields mainURI
Synopsis: public static java.lang.String mainURI
Absolute URI
Method appendURI(String) Java Reference appendURI Methods appendURI
Synopsis: public static String appendURI(java.lang.String localname);
Parameters java.lang.String localname Localname of URI of current RDF node return java.lang.String Absolute URI Generate absolute URIs
Method createGrammar(Model, RDFTools) Java Reference createGrammar Methods createGrammar
Synopsis: public void createGrammar(com.hp.hpl.mesa.rdf.jena.model.Model m, de.fhg.iao.metachart.export.rdf.RDFTools grammar) throws com.hp.hpl.mesa.rdf.jena.model.RDFException;
Parameters com.hp.hpl.mesa.rdf.jena.model.Model m RDF Model de.fhg.iao.metachart.export.rdf.RDFTools grammar Hashtable containing basic RDF classes return void Exceptions RDFException RDF Exception Create basic RDF classes and put it into Hashtable grammar
Class RDFViews Java Reference RDFViews Classes RDFViews
Members
Method processView(Connection, Model, RDFTools, String, Resource) Java Reference processView Methods processView
Synopsis: public void processView(java.sql.Connection conn, com.hp.hpl.mesa.rdf.jena.model.Model m, de.fhg.iao.metachart.export.rdf.RDFTools grammar, java.lang.String Id, com.hp.hpl.mesa.rdf.jena.model.Resource instance);
Parameters java.sql.Connection conn JDBC connection handle com.hp.hpl.mesa.rdf.jena.model.Model m RDF Model de.fhg.iao.metachart.export.rdf.RDFTools grammar Hashtable containing basic RDF classes java.lang.String Id Current mc_id or attr_id com.hp.hpl.mesa.rdf.jena.model.Resource instance Current MetaChart- or Attribute- instance as Resource return void Generate nodes for MetaChart- or Attribute- Views.
Package de.fhg.iao.metachart.export.tables
Class Attribute Java Reference Attribute Classes Attribute Attribute-object, contains DB-attributes of the attributes-table
Overview public class Attribute implements Serializable { // Public Constructors public Attribute(java.lang.String attrId, java.lang.String mcId, java.lang.String type, java.lang.String value, // Public Methods public void setAttrId(java.lang.String mcId); public void setMcId(java.lang.String mcId); public void setType(java.lang.String type); public void setValue(java.lang.String value); public String getId(); public String getMcId(); public String getType(); public String getValue(); }
Class AttributeType Java Reference AttributeType Classes AttributeType AttributeType-object, contains DB-attribute:value of the attributes-table
Overview public class AttributeType implements Serializable { // Public Constructors public AttributeType(java.lang.String type); // Public Methods public void setType(java.lang.String type); public String getType(); public boolean isAssoziation(); public boolean isBase64(); public boolean isPlain(); public boolean isProspector(); public boolean isStLink(); public boolean isUserPreferences(); }
Class MetaChart Java Reference MetaChart Classes MetaChart MetaChart-object, contains DB-attributes of the meta_chart-table
Overview public class MetaChart implements Serializable { // Public Constructors public MetaChart(java.lang.String mcId, java.lang.String type, java.lang.String owner, java.lang.String parent, // Public Methods public void setMcId(java.lang.String mcId); public void setOwner(java.lang.String owner); public void setParent(java.lang.String parent); public void setType(java.lang.String type); public String getId(); public String getMcId(); public String getOwner(); public String getParent(); public String getType(); }
Class MetaData Java Reference MetaData Classes MetaData MetaData-object, contains DB-attributes of the meta_datas-table
Overview public class MetaData implements Serializable { // Public Constructors public MetaData(java.lang.String Id, java.lang.String type, java.lang.String value); public MetaData(java.lang.String mcId, java.lang.String attrId, java.lang.String type, java.lang.String value); // Public Methods public void setAttrId(java.lang.String attrId); public void setId(java.lang.String mcId); public void setMcId(java.lang.String mcId); public void setType(java.lang.String type); public void setValue(java.lang.String value); public String getAttrId(); public String getId(); public String getMcId(); public String getType(); public String getValue(); }
Class View Java Reference View Classes View View-object, contains DB-attributes of the views- or attribute_views -tables
Overview public class View implements Serializable { // Public Constructors public View(java.lang.String viewId, java.lang.String mcId, java.lang.String grUsId, java.lang.String type, java.lang.String value); // Public Methods public void setGrUsId(java.lang.String attrId); public void setMcId(java.lang.String attrId); public void setType(java.lang.String type); public void setValue(java.lang.String value); public void setViewId(java.lang.String viewId); public String getGrUsId(); public String getMcId(); public String getType(); public String getValue(); public String getViewId(); }
Package de.fhg.iao.metachart.export.tools
Class AsciiEncoder Java Reference AsciiEncoder Classes AsciiEncoder Base64-ASCII-Encoder
Members
Constructor AsciiEncoder() Java Reference AsciiEncoder Methods AsciiEncoder
Synopsis: public AsciiEncoder();
Constructor for the AsciiEncoder object
Method encode2ascii(byte[]) Java Reference encode2ascii Methods encode2ascii
Synopsis: public String encode2ascii(byte[] buffer);
Parameters byte[] buffer Byte Array to encode to Base64 return java.lang.String Base64-encoded String
Class Service Java Reference Service Classes Service Methods to query the database
Overview public class Service { // Protected Fields protected Connection conn; // Public Constructors public Service(java.sql.Connection conn); // Public Methods public Hashtable getAllAttributes(); public Hashtable getAllMetaCharts(); public Vector getAttributeIds(java.lang.String mcId); public String getAttributeValue(java.lang.String attrId); public Edge getAttributeValueAsEdge(java.lang.String attrId); public Hashtable getAttributeValueAsHashtable(java.lang.String attrId); public Vector getAttributeValueAsMetaChartLink(java.lang.String attrId); public String getAttributeValueAsPlain(java.lang.String attrId); public Vector getChildren(java.lang.String mcId); public String getCurrentTimestamp(); public Vector getMetaData(java.lang.String Id); public Vector getStartingMetaChartIds(); public Vector getStartingMetaChartIds(java.lang.String Id); public String getTest(); public String getTitle(java.lang.String Id); public Vector getViewIds(java.lang.String Id); public Vector getViews(java.lang.String Id, java.lang.String viewId); public Vector getViewsByAttr(java.lang.String attrId, java.lang.String viewId); public Vector getViewsByMC(java.lang.String mcId, java.lang.String viewId); public String makeTitle(java.lang.String Id); public static void outln(java.lang.String message); public static void outln(int level, java.lang.String message); }
Members
Constructor Service(Connection) Java Reference Service Methods Service
Synopsis: public Service(java.sql.Connection conn);
Parameters java.sql.Connection conn JDBC connection handle Constructor for the Service object
Field conn Java Reference conn Fields conn
Synopsis: protected java.sql.Connection conn
JDBC connection handle
Method getAllAttributes() Java Reference getAllAttributes Methods getAllAttributes
Synopsis: public Hashtable getAllAttributes();
SQL query string: SELECT attr_id, mc_id, type, value FROM attributes
Method getAllMetaCharts() Java Reference getAllMetaCharts Methods getAllMetaCharts
Synopsis: public Hashtable getAllMetaCharts();
SQL query string: SELECT mc_id, type, owner, parent FROM meta_charts
Method getAttributeIds(String) Java Reference getAttributeIds Methods getAttributeIds
Synopsis: public Vector getAttributeIds(java.lang.String mcId);
Parameters java.lang.String mcId Current mc_id return java.util.Vector Vector containing all attrIds referenced by a specific mc_Id SQL query string: SELECT attr_id FROM attributes WHERE mc_id = ?
Method getAttributeValue(String) Java Reference getAttributeValue Methods getAttributeValue
Synopsis: public String getAttributeValue(java.lang.String attrId);
Parameters java.lang.String attrId Current attr_id return java.lang.String Attribute-Value as String, base64-encoded SQL query string: SELECT type, value FROM attributes WHERE attr_id = ?
Method getAttributeValueAsEdge(String) Java Reference getAttributeValueAsEdge Methods getAttributeValueAsEdge
Synopsis: public Edge getAttributeValueAsEdge(java.lang.String attrId);
Parameters java.lang.String attrId Current attr_id return de.fhg.iao.MetaChart.Edge (MetaChart-)Edge-object, containing source- and destination-IDs SQL query string: SELECT type, value FROM attributes WHERE attr_id = ? AND type='assoziation'
Method getAttributeValueAsHashtable(String) Java Reference getAttributeValueAsHashtable Methods getAttributeValueAsHashtable
Synopsis: public Hashtable getAttributeValueAsHashtable( java.lang.String attrId);
Parameters java.lang.String attrId Current attr_id return java.util.Hashtable Hashtable containing Attribute-Value (as ObjectInputStream) by attr_id SQL query string: SELECT type, value FROM attributes WHERE attr_id = ?
Method getAttributeValueAsMetaChartLink(String) Java Reference getAttributeValueAsMetaChartLink Methods getAttributeValueAsMetaChartLink
Synopsis: public Vector getAttributeValueAsMetaChartLink( java.lang.String attrId);
Parameters java.lang.String attrId Current attr_id return java.util.Vector MetaChartLink-object SQL query string: SELECT type, value FROM attributes WHERE attr_id = ? AND type='stLink'
Method getAttributeValueAsPlain(String) Java Reference getAttributeValueAsPlain Methods getAttributeValueAsPlain
Synopsis: public String getAttributeValueAsPlain(java.lang.String attrId);
Parameters java.lang.String attrId Current attr_id return java.lang.String Attribute-Value as String, plain-text SQL query string: SELECT type, value FROM attributes WHERE attr_id = ?
Method getChildren(String) Java Reference getChildren Methods getChildren
Synopsis: public Vector getChildren(java.lang.String mcId);
Parameters java.lang.String mcId Current mc_id return java.util.Vector Vector containing all mc_ids, having mcId as parent Get all mcIds of all embedded MetaCharts SQL query string: SELECT mc_id FROM meta_charts WHERE parent = ?
Method getCurrentTimestamp() Java Reference getCurrentTimestamp Methods getCurrentTimestamp
Synopsis: public String getCurrentTimestamp();
Gets the current timestamp
Method getMetaData(String) Java Reference getMetaData Methods getMetaData
Synopsis: public Vector getMetaData(java.lang.String Id);
Parameters java.lang.String Id Current attr_id return java.util.Vector Hashtable containg MetaData-objects by attr_id or mc_id SQL query string: SELECT attr_id, mc_id, type, value FROM attributes
Method getStartingMetaChartIds() Java Reference getStartingMetaChartIds Methods getStartingMetaChartIds
Synopsis: public Vector getStartingMetaChartIds();
SQL query string: SELECT mc_id FROM meta_charts [WHERE parent is null]
Method getStartingMetaChartIds(String) Java Reference getStartingMetaChartIds Methods getStartingMetaChartIds
Synopsis: public Vector getStartingMetaChartIds(java.lang.String Id);
Retrieve all dependant Ids.
Method getTest() Java Reference getTest Methods getTest
Synopsis: public String getTest();
Just a test-query
Method getTitle(String) Java Reference getTitle Methods getTitle
Synopsis: public String getTitle(java.lang.String Id);
Parameters java.lang.String Id Current mc_id or attr_id return java.lang.String String Get the name of this MetaChart OR Attribute SQL query string: SELECT value FROM meta_datas WHERE mc_id / attr_id = ? AND type = 'title' Distinction of ID done in Java rather than querying for (mc_id = ? OR attr_id = ?) – would be nicer though.
Method getViewIds(String) Java Reference getViewIds Methods getViewIds
Synopsis: public Vector getViewIds(java.lang.String Id);
Parameters java.lang.String Id Current mc_id or attr_id return java.util.Vector Vector with unique view_ids for either one MetaChart-View or one Attribute-View SQL query string: SELECT DISTINCT view_id FROM (attribute)views WHERE attr_id / mc_id = ?
Method getViews(String, String) Java Reference getViews Methods getViews
Synopsis: public Vector getViews(java.lang.String Id, java.lang.String viewId);
Parameters java.lang.String Id Current mc_id or attr_id java.lang.String viewId Current view_id return java.util.Vector Resulting vector of wrapped method Gets a Vector of View-objects Wrapper method for methods getViewBy??, where ?? is MC or Attr
Method getViewsByAttr(String, String) Java Reference getViewsByAttr Methods getViewsByAttr
Synopsis: public Vector getViewsByAttr(java.lang.String attrId, java.lang.String viewId);
Parameters java.lang.String attrId Current attr_id java.lang.String viewId Current view_id return java.util.Vector Vector with View-objects SQL query string: SELECT view_id, attr_id, type, value FROM attribute_views WHERE attr_id = ? AND view_id = ?
Method getViewsByMC(String, String) Java Reference getViewsByMC Methods getViewsByMC
Synopsis: public Vector getViewsByMC(java.lang.String mcId, java.lang.String viewId);
Parameters java.lang.String mcId Current mc_id java.lang.String viewId Current view_id return java.util.Vector Vector containing View-objects SQL query string: SELECT view_id, mc_id, gr_us_id, type, value FROM views WHERE mc_id = ? AND view_id = ?
Method makeTitle(String) Java Reference makeTitle Methods makeTitle
Synopsis: public String makeTitle(java.lang.String Id);
Parameters java.lang.String Id mc_id or attr_id return java.lang.String Title as String Add a String as title (XTM only); for making nicer titles, i.e. not just Ids
Method outln(int, String) Java Reference outln Methods outln
Synopsis: public static void outln(int level, java.lang.String message);
Parameters int level verboselevel java.lang.String message String to output return void System.out.println triggered by verboselevel
Method outln(String) Java Reference outln Methods outln
Synopsis: public static void outln(java.lang.String message);
Parameters java.lang.String message String to output return void System.out.println
Package de.fhg.iao.metachart.export.xtm
Class TMWriter Java Reference TMWriter Classes TMWriter Serialize Topic Map and write to file
Members
Method writeTopicMap(TopicMap) Java Reference writeTopicMap Methods writeTopicMap
Synopsis: public String writeTopicMap(org.tm4j.topicmap.TopicMap tm);
Parameters org.tm4j.topicmap.TopicMap tm TopicMap return java.lang.String String
Class TopicHash Java Reference TopicHash Classes TopicHash Hashtable for all generated Topics to access Topic Types and to check for dublicate IDs
Overview public class TopicHash extends Hashtable { // Public Constructors public TopicHash(); // Public Methods public Association createAssociation(org.tm4j.topicmap.TopicMapFactory tmf, java.lang.String Id, org.tm4j.topicmap.Topic ass_type, org.tm4j.topicmap.Topic topic_one, org.tm4j.topicmap.Topic topic_type_one, org.tm4j.topicmap.Topic topic_two, org.tm4j.topicmap.Topic topic_type_two); public Topic createAssociationTopic(org.tm4j.topicmap.TopicMapFactory tmf, java.lang.String association_type, org.tm4j.topicmap.Topic topic_one, java.lang.String at_sentence_one, org.tm4j.topicmap.Topic topic_two, java.lang.String at_sentence_two); public TopicHash createAssociationTopicWithNewTopics( org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String at_name, java.lang.String t1, java.lang.String s1, java.lang.String t2, java.lang.String s2); public Topic createNewTopicType(org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String topic_type); public Topic createNewTopicType(org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String topic_type, java.lang.String name); public Topic createTopic(org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String Id, java.lang.String topic_type); public Topic createTopic(org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String Id, java.lang.String topic_type, java.lang.String title); public void xtmSecondBasename(org.tm4j.topicmap.TopicMapFactory tmf, java.util.Hashtable topix, java.lang.String topicname, java.lang.String basename); }
Members
Constructor TopicHash() Java Reference TopicHash Methods TopicHash
Synopsis: public TopicHash();
Constructor for the TopicHash object
Method createAssociation(TopicMapFactory, String, Topic, Topic, Topic, Topic, Topic) Java Reference createAssociation Methods createAssociation
Synopsis: public Association createAssociation( org.tm4j.topicmap.TopicMapFactory tmf, java.lang.String Id, org.tm4j.topicmap.Topic ass_type, org.tm4j.topicmap.Topic topic_one, org.tm4j.topicmap.Topic topic_type_one, org.tm4j.topicmap.Topic topic_two, org.tm4j.topicmap.Topic topic_type_two);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory java.lang.String Id Association ID org.tm4j.topicmap.Topic ass_type Association Type org.tm4j.topicmap.Topic topic_one Topic org.tm4j.topicmap.Topic topic_type_one Topic Type org.tm4j.topicmap.Topic topic_two Topic org.tm4j.topicmap.Topic topic_type_two Topic Type return org.tm4j.topicmap.Association Generated Association Create an Association with Id, as Association Type ass_type between topic_one (as Topic Type topic_type_one) and topic_two (as Topic Type topic_type_two)
Method createAssociationTopic(TopicMapFactory, String, Topic, String, Topic, String) Java Reference createAssociationTopic Methods createAssociationTopic
Synopsis: public Topic createAssociationTopic( org.tm4j.topicmap.TopicMapFactory tmf, java.lang.String association_type, org.tm4j.topicmap.Topic topic_one, java.lang.String at_sentence_one, org.tm4j.topicmap.Topic topic_two, java.lang.String at_sentence_two);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory java.lang.String association_type Association Type org.tm4j.topicmap.Topic topic_one Topic java.lang.String at_sentence_one BaseName org.tm4j.topicmap.Topic topic_two Topic java.lang.String at_sentence_two BaseName return org.tm4j.topicmap.Topic Association Type Topic Generate an Association Topic Type between Topic Type topic_one and Topic Type topic_two with BaseNames at_sentence_one and at_sentence_two respectively. This topic then is referenced by applicable associations.
Method createAssociationTopicWithNewTopics(TopicMapFactory, TopicHash, String, String, String, String, String) Java Reference createAssociationTopicWithNewTopics Methods createAssociationTopicWithNewTopics
Synopsis: public TopicHash createAssociationTopicWithNewTopics( org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String at_name, java.lang.String t1, java.lang.String s1, java.lang.String t2, java.lang.String s2);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable containing Topic Types and generated Topics java.lang.String at_name Association Type Name to put as key in Hashtable java.lang.String t1 Topic Type java.lang.String s1 BaseName java.lang.String t2 Topic Type java.lang.String s2 BaseName return de.fhg.iao.metachart.export.xtm.TopicHash Hashtable with added Association Type Topic Generate Association Type Topic. Generate associated Topic Types if not in Hashtable topix. Checks if there are already topics of that type in topix, if not generates them (createNewTopicType) and puts them into topix. Then starts createAssociationTopic.
Method createNewTopicType(TopicMapFactory, TopicHash, String) Java Reference createNewTopicType Methods createNewTopicType
Synopsis: public Topic createNewTopicType( org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String topic_type);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable java.lang.String topic_type Topic Type return org.tm4j.topicmap.Topic Topic Type Topic Generate Topic Type Topic with BaseName topic_type. Thus having not a nice BaseName.
Method createNewTopicType(TopicMapFactory, TopicHash, String, String) Java Reference createNewTopicType Methods createNewTopicType
Synopsis: public Topic createNewTopicType( org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String topic_type, java.lang.String name);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable java.lang.String topic_type Topic Type java.lang.String name String for BaseName return org.tm4j.topicmap.Topic Topic Type Topic Generate Topic Type Topic with BaseName name. Thus having a nicer, specific BaseName.
Method createTopic(TopicMapFactory, TopicHash, String, String) Java Reference createTopic Methods createTopic
Synopsis: public Topic createTopic(org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String Id, java.lang.String topic_type);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable java.lang.String Id Id java.lang.String topic_type Topic Type return org.tm4j.topicmap.Topic Topic Generate Topic if not in Hashtable topix and put generated Topic in topix under key Id.
Method createTopic(TopicMapFactory, TopicHash, String, String, String) Java Reference createTopic Methods createTopic
Synopsis: public Topic createTopic(org.tm4j.topicmap.TopicMapFactory tmf, de.fhg.iao.metachart.export.xtm.TopicHash topix, java.lang.String Id, java.lang.String topic_type, java.lang.String title);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable java.lang.String Id Id java.lang.String topic_type Topic Type java.lang.String title BaseName return org.tm4j.topicmap.Topic Topic Generate Topic with Basename title if not in Hashtable topix and put generated Topic in topix under key Id.
Method xtmSecondBasename(TopicMapFactory, Hashtable, String, String) Java Reference xtmSecondBasename Methods xtmSecondBasename
Synopsis: public void xtmSecondBasename(org.tm4j.topicmap.TopicMapFactory tmf, java.util.Hashtable topix, java.lang.String topicname, java.lang.String basename);
Parameters org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory java.util.Hashtable topix Hashtable java.lang.String topicname Key in Hashtable java.lang.String basename BaseName return void Add a second Basename
Class XTMAttributes Java Reference XTMAttributes Classes XTMAttributes Generate Attribute Topics and Occurrences for Attribute-Values
Members
Method processAttributes(Connection, String, TopicMapFactory, TopicMap, Topic, TopicHash) Java Reference processAttributes Methods processAttributes
Synopsis: public void processAttributes(java.sql.Connection conn, java.lang.String mcid, org.tm4j.topicmap.TopicMapFactory tmf, org.tm4j.topicmap.TopicMap tm, org.tm4j.topicmap.Topic topic, de.fhg.iao.metachart.export.xtm.TopicHash topix);
Parameters java.sql.Connection conn JDBC connection handle java.lang.String mcid Current mc_id org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory org.tm4j.topicmap.TopicMap tm Topic Map org.tm4j.topicmap.Topic topic Current Topic de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable return void
Class XTMChildren Java Reference XTMChildren Classes XTMChildren Generate child MetaChart Topics and create Associations to parent MetaCharts
Members
Method processChildren(Connection, String, TopicMapFactory, TopicMap, Topic, TopicHash) Java Reference processChildren Methods processChildren
Synopsis: public void processChildren(java.sql.Connection conn, java.lang.String mcId, org.tm4j.topicmap.TopicMapFactory tmf, org.tm4j.topicmap.TopicMap tm, org.tm4j.topicmap.Topic topic, de.fhg.iao.metachart.export.xtm.TopicHash topix);
Parameters java.sql.Connection conn JDBC Connection handle java.lang.String mcId Current mc_id org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory org.tm4j.topicmap.TopicMap tm Topic Map org.tm4j.topicmap.Topic topic Current MetaChart-Topic de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable return void
Class XTMMetaChart Java Reference XTMMetaChart Classes XTMMetaChart Generate MetaChart Topics. Call methodes to process MetaDatas, Views and Children.
Members
Method processMetaChart(Connection, String, TopicMapFactory, TopicMap, TopicHash) Java Reference processMetaChart Methods processMetaChart
Synopsis: public void processMetaChart(java.sql.Connection conn, java.lang.String mcid, org.tm4j.topicmap.TopicMapFactory tmf, org.tm4j.topicmap.TopicMap tm, de.fhg.iao.metachart.export.xtm.TopicHash topix);
Parameters java.sql.Connection conn JDBC connection handle java.lang.String mcid Current mc_id org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory org.tm4j.topicmap.TopicMap tm Topic Map de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable return void
Class XTMMetaDatas Java Reference XTMMetaDatas Classes XTMMetaDatas Generate MetaDatas for MetaChart or Attributes, depending on Id .
Members
Method processMetaData(Connection, String, TopicMapFactory, TopicMap, Topic, TopicHash) Java Reference processMetaData Methods processMetaData
Synopsis: public void processMetaData(java.sql.Connection conn, java.lang.String Id, org.tm4j.topicmap.TopicMapFactory tmf, org.tm4j.topicmap.TopicMap tm, org.tm4j.topicmap.Topic topic, de.fhg.iao.metachart.export.xtm.TopicHash topix);
Parameters java.sql.Connection conn JDBC connection handle java.lang.String Id Current mc_id or attr_id org.tm4j.topicmap.TopicMapFactory tmf TopicMapFactory org.tm4j.topicmap.TopicMap tm Topic Map org.tm4j.topicmap.Topic topic Current MetaChart or Attribute Topic de.fhg.iao.metachart.export.xtm.TopicHash topix Hashtable return void
Verzeichnis verwendeter Akronyme ASCII American Standard Code for Information Interchange CGI Common Gateway Interface CSS Cascading Style Sheets DAML Darpa Agent Markup Language DOM Document Object Model DSSSL Document Style Semantics and Specification Language DTD Document Type Definition EJB Enterprise Java Beans ERD Entity Relationship Diagram ERM Entity Relationship Model FK Foreign Key FO Formatting Objects HTML HyperText Markup Language HyTM Hypermedia/Time-based Structuring Language ISO International Organization for Standardization JDBC Java Database Connectivity KI Künstliche Intelligenz LTM Linear Topic Map Notation MIME Multipurpose Internet Mail Extension OIL Ontology Inference Layer PDF Portable Document Format Perl Practical Extraction and Report Language PK Primary Key PSI Public Subject Indicator RDF Resource Description Framework RTF Rich Text Format SGML Standard Generalized Markup Language SQL Structured Query Language SVG Scaleable Vector Graphics URI Uniform Resource Indicator URL Uniform Resource Locator W3C World Wide Web Consortium WWW World Wide Web XHTML Extensible HTML XML Extensible Markup Language XML Extensible Markup Language XSD XML Schema Document XSL Extensible Stylesheet Language XTM XML Topic Maps Adler01 Sharon Adler et al Extensible Stylesheet Language (XSL) Version 1.0 W3C Recommendation Oktober 2001 , letzter Zugriff 03.03.2002 Ahmed02 Kal Ahmed The TM4J Project 2002 , letzter Zugriff 03.03.2002 Berners98 Tim Berners-Lee Interpretation and Semantics on the Semantic Web , letzter Zugriff 23.03.2002 Berners01 Tim Berners-Lee, James Hendler, Ora Lassila Semantic Web , letzter Zugriff 02.02.2002 Berners01a Tim Berners-Lee, James Hendler, Ora Lassila The Semantic Web A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities Scientific American Mai 2001 , letzter Zugriff 23.03.2002 BernersQA Tim Berners-Lee Press FAQ , letzter Zugriff 03.03.2002 Biron01 Biron, Paul V. / Malhorta, Ashok XML Schema Part 2 Datatypes W3C Recommendation Mai 2001 , letzter Zugriff 03.03.2002 Bos98 Bert Bos Håkon Wium Lie Chris Lilley Ian Jacobs Cascading Style Sheets, level 2 CSS2 Specification W3C Recommendation Mai 1998 , letzter Zugriff 02.02.2002 Bray99 Bray Tim Dave Hollander Andrew Layman Namespaces in XML W3C Recommendation Januar 1999 , letzter Zugriff 23.03.2002 Bray00 Bray Tim Jean Paoli C. M. Sperberg-McQueen Eve Maler Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation Oktober 2000 , letzter Zugriff 03.03.2002 Brickley00 Brickley Dan Guha R. V. Resource Description Framework (RDF) Schema Specification 1.0 W3C Candiate Recommendation März 2000 , letzter Zugriff 23.03.2002 Brockhaus01 Der Brockhaus multimedial 2002 Bibliographisches Institut F. A. Brockhaus AG 2001 Champin01 Pierre-Antoine Champin RDF Tutorial 2001 , letzter Zugriff 02.02.2002 Cover98 Robin Cover XML and Semantic Transparency The XML Cover Pages 1998 , letzter Zugriff 03.03.2002 Cover02 Robin Cover SGML/XML: Using Elements and Attributes The XML Cover Pages 2002 , letzter Zugriff 02.02.2002 Dalheimer98 Matthias Kalle Dalheimer LATEX - kurz & gut O’Reilly-Verlag
Köln
1998 Decker02 Stefan Decker, Michael Sintek The FRODO Project Homepage TRIPLE Homepage The Semantic Web Foundation for Open Source Software (SFO) 2002 , letzter Zugriff 23.03.2002 DeckerSW Stefan Decker, Michael Sintek The Semantic Web Community Portal , letzter Zugriff 02.02.2002 Diestel00 Diestel Reinhard Graphentheorie Springer-Verlag
Heidelberg
2000 ISBN 3-540-67656-2 Eckstein99 Robert Eckstein XML Pocket Reference O’Reilly-Verlag
Sebastopol, CA
1998 Fallside01 David C. Fallside et al XML Schema W3C Recommendation Mai 2001 , letzter Zugriff 03.03.2002 Fensel00 Dieter Andreas Fensel et al The Ontology Inference Layer OIL Vrije Universiteit Amsterdam 2000 , letzter Zugriff 23.03.2002 Fensel00a Dieter Andreas Fensel Relating Ontology Languages and Web Standards Vrije Universiteit Amsterdam 2000 , letzter Zugriff 23.03.2002 Fensel01 Dieter Andreas Fensel Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce Vrije Universiteit Amsterdam 2001 , letzter Zugriff 03.03.2002 Fensel01a Dieter Andreas Fensel The Semantic Web and its Languages Vrije Universiteit Amsterdam 2001 , letzter Zugriff 23.03.2002 Gaschke02 Gaschke Susanne Tatort Schule Trotz Pisa-Schock: Die Politiker dösen in der letzten Bank Die Zeit
Hamburg
Ausgabe 10/2002, S. 1 Gruber93 Gruber Tom R. A translation approach to portable ontologies Academic Press
June
1993 Harold99 Elliote Rusty Harold XML Bible IDG Books Worldwide
Foster City
1999 ISO13250 O. A. ISO/IEC 13250 Topic Maps Joint Technical Committee 1 JTC1, Information Technology, Subcommittee SC34 1999 , letzter Zugriff 23.03.2002 Johnson00 Don H. Johnson Basics of Information Processing Rice University
Houston
2000 , letzter Zugriff 02.02.2002 Klemm02 Lessmöllmann Annette Information Horizont der Erkenntnis Die Zeit
Hamburg
Ausgabe 02/2002, S. 33 Korbmann01 Korbmann Rainer Die Macht des Wissens natur media gmbh
München
natur & kosmos Ausgabe 10/2001 ISSN 0723-5038 S. 56-58 Krüger00 Krüger Guido Go To Java 2 Handbuch der Java-Programmierung Addison-Wesley 2000 Kunzmann99 Kunzmann Peter Burkard Franz-Peter Wiedmann Franz Weiß Axel dtv-Atlas Philosophie Deutscher Taschenbuch Verlag
München
19998 ISBN 3-423-03229-4 S. 13 Lassila99 Lassila Ora Swick Ralph Resource Description Framework (RDF) Model and Syntax Specification W3C Recommendation Februar 1999 , letzter Zugriff 03.03.2002 Lenat98 Lenat Doug The Dimensions of Context-Space 1998 , letzter Zugriff 23.03.2002 Lessmöllmann02 Lessmöllmann Annette Die Wunderformeln der Grammatik Die Zeit
Hamburg
Ausgabe 09/2002, S. 32 Lipinski99 Lipinski Klaus Lexikon der Datenkommunikation DATACOM Buchverlag GmbH
Bergheim
1999 ISBN 3-89238-168-2 Magerkurth01 C. Magerkurth T. Prante <quote>Metaplan</quote> für die Westentasche Mobile Computerunterstützung für Kreativitätssitzungen. Teubner Verlag 2001 McBride02 Brian McBride et al The jena semantic web toolkit HPL Semantic Web activity 2002 , letzter Zugriff 03.03.2002 Mertz01 David Mertz XML Matters #8 Putting XML in context with hierarchical, relational, and object-oriented models developerWorks April 2001 , letzter Zugriff 23.03.2002 Meyer92 Meyers Taschenlexikon B. I. Taschenbuchverlag
Mannheim
1992 ISBN 3-411-11612-9 MIME IANA Official list of all MIME media-types assigned by the Internet Assigned Number Authority (IANA) IANA 2001 Moore01 Graham Moore RDF and TopicMaps An Exercise in Convergence Empolis GmbH 2001 , letzter Zugriff 03.03.2002 mttwz01 Meier Doris Tautz Carsten Traphöner Ralph Wissen Michael Ziegler Jürgen Building Ontologies for Knowledge Management Applications in Group Sessions Fraunhofer IAO
Stuttgart
2001 Ogbuji00 Uche Ogbuji An introduction to RDF Exploring the standard for Web-based metadata developerWorks Dezember 2000 , letzter Zugriff 02.02.2002 Palmer01 Sean B. Palmer et al TimBL's Closed World Machine 2001 , letzter Zugriff 23.03.2002 Palmer02 Sean B. Palmer et al Eep Very small things make Eep 2002 , letzter Zugriff 23.03.2002 Pemberton00 Steven Pemberton et al XHTML 1.0: The Extensible HyperText Markup Language A Reformulation of HTML 4 in XML 1.0 W3C Recommendation Januar 2000 , letzter Zugriff 02.02.2002 Pepper99 Steve Pepper Navigating haystacks and discovering needles Introducing the new topic map standard 1999 , letzter Zugriff 03.03.2002 Pepper00 Steve Pepper The TAO of Topic Maps finding the way in the age of infoglut Infostream, Oslo Norway 2000 , letzter Zugriff 02.02.2002 Pepper00a Steve Pepper Topic maps and RDF: A first cut Ontopia AS 2000 , letzter Zugriff 03.03.2002 Pepper01 Steve Pepper Graham Moore XML Topic Maps (XTM) 1.0 TopicMaps.Org Specification TopicMaps.Org Authoring Group 2001 , letzter Zugriff 23.03.2002 perlre O. A. perlre - Perl regular expressions , letzter Zugriff 23.03.2002 Pepper01a Steve Pepper Graham Moore XTM 1.0 Core Published Subject Indicators (PSIs) TopicMaps.Org 2001 , letzter Zugriff 03.03.2002 Peirce93 Charles Sanders Peirce Syllabus of Certain Topics of Logic In: Pirner01 1993 Pirner01 Hans J. Pirner The Semiotics of <quote>Postmodern</quote> Physics In: M. Ferrari et al: Symbol and Physical Knowledge – On the Conceptual Structure of Physics Springer-Verlag Berlin Heidelberg 2001 S. 210-229 Rath99 Hans Holger Rath Mozart oder Kugel Mit Topic Maps intelligente Informationsnetze aufbauen Verlag Heinz Heise
Hannover
Ausgabe 12/1999 S. 149 ff Rath01 Holger Rath empolis template Published Subject Indicators empolis GmbH 2001 , letzter Zugriff 23.03.2002 RFC2045 Network Working Group N. Freed, N. Borenstein Request for Comments 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies IETF 1996 , letzter Zugriff 03.03.2002 RFC2396 Network Working Group T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter Request for Comments 2396 Uniform Resource Identifiers (URI): Generic Syntax IETF 1998 , letzter Zugriff 03.03.2002 RFC2413 Network Working Group S. Weibel, J. Kunze, C. Lagoze, M. Wolf Request for Comments 2413 Dublin Core Metadata for Resource Discovery IETF 1998 , letzter Zugriff 03.03.2002 Reimann00 Prof. Peter Reimann Katja Müller Philipp Starkloff Kognitiv kompatibel? Wissensmanagement: Brückenschlag zwischen Technik und Psyche Verlag Heinz Heise
Hannover
Ausgabe 04/2000 S. 274 ff Reimer91 Ulrich Reimer Einführung in die Wissensrepräsentation B. G. Teubner
Stuttgart
1991 Anderson00 Richard Anderson, Mark Birbeck, Michael Kay u. a. XML Professionell MITP-Verlag
Bonn
2000 bpv00 Rupp Rainer Meidinger Heinz-Peter Gymnasium - Baustein für die Zukunft Wir brauchen eine neue Bildungsgesellschaft Bayerischer Philologenverband (bpv)
München
Presseerklärung vom 18.11.2000 Schmidt00 Ingrid Schmidt, Carolin Müller Zaubernetz Inhaltsstrukturen und Topic Maps als Potenzial neuer Informationstechnik Verlag Heinz Heise
Hannover
Ausgabe 11/2000 S. 100 ff , letzter Zugriff 02.02.2002 Scholles98 Dr. Frank Scholles, Magrit Putschky Gesellschaftswissenschaftliche Grundlagen Planungsmethoden Institut für Landesplanung und Raumforschung
Hannover
1998 , letzter Zugriff 23.03.2002 Sowa01 John F. Sowa Conceptual Graphs 2001 , letzter Zugriff 02.02.2002 Strassmann02 Strassmann Burkhard Wissensmanagement Schürfen in der Datenhalde Die Zeit
Hamburg
Ausgabe 04/2002 Schirdewan97 Schirdewan Roland Der Einsatz von Conceptual Graphs im Rahmen automatischer Akquisition von Objektbeschreibungen aus Texten Eine Machbarkeitsstudie am Beispiel einer Ölabscheiderdokumentation Universität
Hamburg
Diplomarbeit 1997 Thompson01 Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn XML Schema Part 1 Structures W3C Recommendation Mai 2001 , letzter Zugriff 03.03.2002 Vachenauer97 Vachenauer Peter Rade Lennart Westergren Bertil Springers Mathematische Formeln Springer-Verlag
Heidelberg
19972 ISBN 3-540-62829-0 S. 33-36 Vossen00 Vossen G. Datenbankmodelle, Datenbanksprachen und Datenbankmanagementsysteme Oldenbourg-Verlag
München
20004 Walsh99 Norman Walsh L. Muellner DocBook: The Definitive Guide O’Reilly & Associates, Inc. 1999 , letzter Zugriff 23.03.2002 Wrightson01 Ann Wrightson Topic Maps and Knowledge Representation Ontopia AS 2001 , letzter Zugriff 02.02.2002