Das Dokument beschreibt autonome Topic Maps zur dezentralen Erstellung von vernetzten Modellinstanzen in semantisch heterogenen Umgebungen. Es wird eine Lösung präsentiert, die die explizite und implizite Vernetzung von Topic Maps behandelt, um identische Beobachtungen konsistent zu dokumentieren und die vorliegende terminologische Heterogenität aufzulösen. Ziel ist es, durch die Nutzung kontrollierter Vokabulare und den Einsatz von semantischen Handshakes eine effektive Integration von Informationen zu gewährleisten.

1. Autonome Topic Maps – Zur dezentralen Erstellung von implizit und explizit vernetzten Topic Maps in semantisch heterogenen Umgebungen. Vortrag zur Verteidigung der Dissertation an der Universität Leipzig Lutz Maicher, Universität Leipzig [email_address]

2. Problem und Lösungskonzeption

3. Explizite und implizite Vernetzung von Topic Maps Topic Maps sind vernetzte Domänenmodelle explizite Vernetzung Beziehungen zwischen Topics verschiedener Aussagegegenstände innerhalb einer Topic Map Lutz Maicher Universität Leipzig Leipzig Topic Map A

4. Explizite und implizite Vernetzung von Topic Maps Topic Maps sind vernetzte Domänenmodelle explizite Vernetzung Beziehungen zwischen Topics verschiedener Aussagegegenstände innerhalb einer Topic Map implizite Vernetzung Topics des gleichen Aussagegegenstandes in verschiedenen Topic Maps bei impliziter Vernetzung zwischen zusammenführend abgefragten Topic Maps werden die lokal modellierten, expliziten Vernetzungen global gültig Lutz Maicher Lutz Maicher Topic Maps Universität Leipzig Leipzig Topic Map A Topic Map B Abfrage

5. Explizite und implizite Vernetzung von Topic Maps Topic Maps sind vernetzte Domänenmodelle explizite Vernetzung Beziehungen zwischen Topics verschiedener Aussagegegenstände innerhalb einer Topic Map implizite Vernetzung Topics des gleichen Aussagegegenstandes in verschiedenen Topic Maps bei impliziter Vernetzung zwischen zusammenführend abgefragten Topic Maps werden die lokal modellierten, expliziten Vernetzungen global gültig Universität Leipzig Leipzig Topic Map A Topic Map B Lutz Maicher Universität Leipzig Leipzig Lutz Maicher Topic Maps

6. Problemstellung als Beispiel Szenario: 10 Autoren bekommen die Dublin-Core-Terme und sollen Metadaten (als Topic Map) zu einem Dokument erstellen Werden identische Beobachtungen identisch dokumentiert? Werden die erstellen Topic Maps auf Typ und Individuenebene zusammenführbar sein? Wird es möglich sein, mit einer (parametrisierten) Abfrage z.B. die Ersteller einer beliebigen Ressource zu extrahieren? Ziel: dezentrale Erstellung implizit vernetzter Topic Maps bei inhärenter semantischer Heterogenität

7. Autonome Topic Maps Vorschlag: Verteilung kontrollierter Vokabulare identische Beobachtungen sollten identisch dokumentiert werden Problem: Modellierungsspielraum bei Nutzung von Termen aber: innerhalb einer Modellierungsmethode wird ein Vokabular konsistent genutzt Modellierungsmethode: Abfolge von Beobachtungen und entsprechend der Beobachtung parametrisierter Modifikationsstatements Modellierungsmethode und Vokabular muss verteilt werden Ziel: dezentrale Erstellung implizit vernetzter Topic Maps bei inhärenter semantischer Heterogenität

8. Autonome Topic Maps – ein Beispiel ATM Was ist der Name des Autors? ATM-Interpreter Was ist die URL des Dokuments? Erzeuge - Topic für Autor mit Benennung ATM Was ist der Name des Autors? ATM-Interpreter Was ist die E-Mail-Adresse des Autors? Erzeuge - Topic für Autor mit Benennung - Topic für Dokument - Beziehung mit Dublin-Core-Vokabular - Topic für Dokument - Beziehung mit Dublin-Core-Vokabular

9. Anforderungen an dezentral erstelle Topic Maps Identische Beobachtungen werden identisch dokumentiert eine Abfragephrase für einen Typ von Informationen ? ? ?

10. Anforderungen an dezentral erstellte Topic Maps Identische Beobachtungen werden identisch dokumentiert eine Abfragephrase für einen Typ von Informationen implizite Vernetzung auf Typ- und Individuenebene

11. Autonome Topic Maps Formalisierung der Modellierungsmethode durch generische Interpreter ausführbar Verteilung von Vokabular und Modellierungsmethode Ergebnis: dezentrale Erstellung implizit vernetzter Topic Maps Eine ATM ist eine Topic Map, die die notwendigen Informationen beinhaltet, dass gegeben ein generischer Interpreter, in beliebigen Situationen bestmöglich implizit vernetzte Modellinstanzen desselben Modelltyps erstellt werden. Autonome Topic Maps legen alle Informationen über die angewandte Modellierungsmethode offen und dokumentieren diese somit. Die erstellten Modellinstanzen sind Topic Maps, welche die zur Erstellung genutzte ATM referenzieren sollten.

12. Exkurs: Topic Maps

13. Modellierungskonstrukte von Topic Maps "reale" Welt Nikolaikirche variant St. Nicholas Church St. Nikolai basename English scope 1165 internal occurence foundation type www.nikolaikirche -leipzig.de/ external occurence website type Modell

14. Modellierungskonstrukte von Topic Maps St. Nikolai Leipzig Modell association container-containee container ass. role role player containee role type "reale" Welt

15. Integrationsmodell von Topic Maps Die Identität eines Topics wird bestimmt durch Menge von Subject Identifiers … http://de.wikipedia.org/wiki/Leipziger_Nikolaikirche http://en.wikipedia.org/wiki/St._Nicholas%27_Church%2C_Leipzig http://www.nikolaikirche-leipzig.de/ St. Nikolai

16. Integrationsmodell von Topic Maps … wenn zwei Topics mind. einen gemeinsamen Subject Identifier haben, werden sie automatisch zusammengeführt ( merging) . http://de.wikipedia.org/wiki/Leipziger_Nikolaikirche http://en.wikipedia.org/wiki/St._Nicholas%27_Church%2C_Leipzig http://www.nikolaikirche-leipzig.de/ Saint-Nicolas http://en.wikipedia.org/wiki/St._Nicholas%27_Church%2C_Leipzig St. Nikolai

17. Integrationsmodell von Topic Maps Zusammenführen von Topics: neues Topic ist Vereinigungs-menge der Eigenschaften der Ausgangstopics und ersetzt diese: alle Subject Identifiers alle Benennungen alle Belegstellen alle Beziehungen http://de.wikipedia.org/wiki/Leipziger_Nikolaikirche http://en.wikipedia.org/wiki/St._Nicholas%27_Church%2C_Leipzig http://www.nikolaikirche-leipzig.de/ Saint-Nicolas und alle Belegstellen und Roles Played beider Topics … St. Nikolai

18. Integrationsmodell von Topic Maps … ist Schema-frei Entscheidung über das Zusammenführen wird nur über die Subject Identifier jedes einzelnen Topics entschieden … erlaubt große terminologische Flexibilität alle Statements über die Aussagegegenstände (Bennenungen, Belegstellen, Roles Played) können mit beliebigem Vokabular typisiert sein … kann terminologische Heterogenität auflösen siehe Semantic Handshake … integriert automatisch alle Informationen über den selben Aussagegegenstand an einem Topic

19. Topic Maps-Standards

20. Autonome Topic Maps

21. Autonome Topic Maps Verteilung von Vokabular und Modellierungsmethode zur dezentralen Erstellung von implizit vernetzten Topic Maps Formalisierung der Modellierungsmethode durch generische Interpreter ausführbar Petrinetz-Datenmodell (PNDM) und Petrinetz-Prozessmodell (PNPM) MWP-PNPM ist Prozessmodell (Basis von Autonomen Topic Maps) ATM = als Topic Maps repräsentierte PNDM-Instanz, die entsprechend des MWP-PNPM durch den Interpreter ausgeführt wird Eine ATM ist eine Topic Map, die die notwendigen Informationen beinhaltet, dass gegeben ein generischer Interpreter, in beliebigen Situationen bestmöglich implizit vernetzte Modellinstanzen desselben Modelltyps erstellt werden. Autonome Topic Maps legen alle Informationen über die angewandte Modellierungsmethode offen und dokumentieren diese somit. Die erstellten Modellinstanzen sind Topic Maps, welche die zur Erstellung genutzte ATM referenzieren sollten.

22. Petrinetze Modellierungs methode ist ein Prozess / Workflow Abfolge von Beobachtungen und entsprechend der Beobachtung parametrisierter Modifikationsstatements Petrinetze existiert Vielzahl an Petrinetztypen (z.B. Stellen-Transitionen-Netze, gefärbte Petrinetze, stochastische Petrinetze, etc.) für verschiedene Einsatzzwecke Petrinetze erlauben die Repräsentation von Workflows de facto alle Workflow Pattern [van der Aalst und ter Hofstede] können durch (high-level) Petrinetze ausgedrückt werden beliebige Typen von Petrinetzen können durch eine festgelegte Menge von standardisierten Elementtypen repräsentiert werden [Weber] Grundlage für das Petrinetz-Datenmodell

23. ATM - Beispiel pndm:workflow (P1 : pndm:start_place , P2: pndm:end_place) ~ myworkflow [myworkflow =”Hallo Welt Workflow”] {myworkflow, pndm:label, [[Hallo Welt]]} [P1 : pndm:place = "P1"] {P1 , pndm:label , [[Place 1]]} [T1 : pndm:transition ="T1"] {T1 , pndm:label , [[Transition 1]]} {T1 , pndm:operator , [http://psi.semports.org/mwp/ConsoleInformation]]} {T1 , pndm:operand1, [[Hallo Welt!]]} [P2 : pndm:place = "P2"] {P2 , pndm:label , [[Place 2]]} pndm:arc (P1 : pndm:arc_predecessor , T1 : pndm:arc_successor) pndm:arc (T1 : pndm:arc_predecessor , P2 : pndm:arc_successor)

24. PNDM – Petrinetz-Datenmodell Repräsentation beliebiger Petrinetze als Subject Map folgt der Konzeption von Weber und setzt diese im Kontext von Topic Maps um Metamodell des PNDM ist das Metamodell des TMDM (bzw. des XML Information Set) PNDM-Instanz ist Menge von typisierten Informationseinheiten jeder Informationseinheitentyp hat eine Menge von Eigenschaften Schlüssel-Werte-Paare PNDM definiert Bedingungen zu Werten PNDM-QL: Adressierung von Bereichen innerhalb einer PNDM-Instanz

25. Informationseinheitentypen des PNDM Petri Net Item repräsentiert ein Petrinetz Place Item repräsentiert einen Platz innerhalb eines Petrinetzes Transition Item repräsentiert eine Transition innerhalb eines Petrinetzes Arc Item repräsentiert eine Kante innerhalb eines Petrinetzes Characteristic Item repräsentiert eine Eigenschaft eines Elementes eines Petrinetzes Token Item repräsentiert eine Marke Workflow Item repräsentiert einen Workflow Case Item repräsentiert einen Geschäftsfall (Instanz eines Workflows)

26. PNPM – Petrinetz-Prozessmodell Prozessmodell definiert den Petrinetz-Typ der PNDM-Instanz Weiterführende Bedingungen Beispiel MWP_PNPM: Petri Net Item muss Prozessmodell durch mwp:MWP_PNPM referenzieren Dynamisches Verhalten SEDA und SVA (Legende der Subject Map) eine PNDM-Instanz ist eine Subject Map Subject Equality Decision Approach (SEDA): es wird für jeden Informationseinheitentyp spezifiziert, wann zwei Informationseinheiten einer PNDM-Instanz den gleichen Aussagegegenstand repräsentieren Subject Viewing Approach (SVA): es wird spezifiziert, wie diese Informationseinheiten zusammengeführt werden

27. (De)Serialisierung von PNDM-Instanzen als Topic Maps Mapping: PNDM  TMDM Serialisierung einer ATM Mapping: TMDM  PNDM Deserialisierung einer ATM TMDM: Topic Maps Data Model PNDM  TMDM PNDM  TMDM

28. ATM – Beispiel

29. Referenzimplementierung fluidS - Screenshot

30. Zusammenfassung Autonome Topic Maps ermöglichen die Verteilung von Modellierungsmethoden (für Erstellung von Topic Maps) und Vokabularen als Topic Maps Ergebnis: dezentrale Erzeugung von Topic Maps identische Beobachtungen werden identisch dokumentiert eine Abfragephrase für einen Typ von Information implizite Vernetzung auf Typ- und Individuenebene ( in terminologisch statischen Domänen )

31. The Impact of Semantic Handshakes

32. Probleme der Impliziten Vernetzung Problem 1. Terme für unbekannte Aussagegegenstände Subject Identifier für (unbekannte) Typen und Individuen Problem 2. Homonymie von Subject Identifiern verschiedene Autoren nutzen gleichen Subject Identifier für unterschiedliche Aussagegegenstände Problem 3. Synonymie von Subject Identifiern verschiedene Autoren nutzen unterschiedliche Subject Identifier für den gleichen Aussagegegenstand Lösung a): Durchsetzung eines global gültigen Vokabulars Lösung b): Semantic Handshakes

33. Semantic Handshakes " It is the semantic handshake upon which shared emerging and dynamic ontologies can be established and exchange context can be constructed. In practice, the agreement can be over the real-world meaning of some model, as it is typically assumed in conceptual modeling, on schema mappings, on consistent data usage or on any other meta-data information relevant to the task at hand. " Aberer et al. (u.a. Staab, Studer): Emergent Semantics Principles and Issues . M. Bouzeghoub et al. (Eds.): ICSNW 2004, LNCS 3226, pp. 14–43, 2004.

34. Terminologische Heterogenität Zwei Autoren erzeugen einen Topic über Lutz Maicher mit unterschiedlichen Subject Identifiers. no equality (according TMDM) ns1:LutzMaicher ns2:MaicherLutz

35. Semantic Handshake – Auflösung der Heterogenität Ein Autor legt offen, dass "ns1:LutzMaicher" und "ns2:MaicherLutz" synonym sind … equality holds (according TMDM) ns2:MaicherLutz ns1:LutzMaicher ns2:MaicherLutz merging (according TMDM) ns1:LutzMaicher ns2:MaicherLutz

36. The Impact of Semantic Handshakes TM1 TM3 TM2 TM4 ns3:ML Lokale Integrationsentscheidung Lokale Integrationsentscheidung Lokale Integrationsentscheidung ns1:LutzMaicher ns2:MaicherLutz ns2:MaicherLutz ns3:ML ns4:Lutz ns3:ML

37. The Impact of Semantic Handshakes Anfrage: Ich bin interessiert an dem Aussagegegenstand „ns1:LutzMaicher“ oder „ns2:MaicherLutz“. Schritt 1 ns1:LutzMaicher ns2:MaicherLutz ns2:MaicherLutz ns3:ML ns3:ML ns4:Lutz ns3:ML

38. The Impact of Semantic Handshakes Anfrage: Ich bin interessiert an dem Aussagegegenstand „ns1:LutzMaicher“ oder „ns2:MaicherLutz“. ns2:MaicherLutz, ns3:ML ns2:MaicherLutz, ns1:LutzMaicher Schritt 1 ns1:LutzMaicher ns2:MaicherLutz ns2:MaicherLutz ns3:ML ns3:ML ns4:Lutz ns3:ML NO NO

39. The Impact of Semantic Handshakes Anfrage: Ich bin interessiert an dem Aussagegegenstand „ns1:LutzMaicher“ oder „ns2:MaicherLutz“ oder „ns3:ML“. Step 1 Schritt 2 ns3:ML ns4:Lutz ns3:ML ns1:LutzMaicher ns2:MaicherLutz ns3:ML ns1:LutzMaicher ns2:MaicherLutz ns3:ML

40. The Impact of Semantic Handshakes Anfrage: Ich bin interessiert an dem Aussagegegenstand „ns1:LutzMaicher“ oder „ns2:MaicherLutz“ oder „ns3:ML“. Step 1 Schritt 2 ns3:ML ns4:Lutz ns3:ML ns1:LutzMaicher ns2:MaicherLutz ns3:ML ns1:LutzMaicher ns2:MaicherLutz ns3:ML ns4:Lutz, ns3:ML ns1:LutzMaicher, ns3:ML, ns2:MaicherLutz, ns1:LutzMaicher, ns3:ML, ns2:MaicherLutz ns3:ML

41. The Impact of Semantic Handshakes Step 1 ns1:LutzMaicher ns2:MaicherLutz ns3:ML ns4:Lutz ns1:LutzMaicher ns2:MaicherLutz ns3:ML ns4:Lutz nach Schritt 2 globaler Term = Menge synonymer Subject Identifier ns1:LutzMaicher ns2:MaicherLutz ns3:ML ns1:LutzMaicher ns2:MaicherLutz ns3:ML

42. Simulation: The Impact of Semantic Handshakes Anzahl Terme pro globalem Terme Iteration of a in distributionNbrOfII=<{a,1.0},2> in [0.0,1.0] general parameters: card =100, nbrOfDifferentII =100 specific parameters exp04: distributionII =<{0.8,0.9,0.97,1.0}, 100>  100 Topics für selben AG  einige Terme sind dominant  hohe terminologische Diversität Anzahl globaler Terme 100 verschiedene Terme werden zu 10 globalen Termen aufgelöst, wenn nur 55% aller Topics eine lokale Integrationsentscheidung haben! (Ein globaler Term besteht aus mind. 75 verschiedenen Termen.) no semantic handshakes always a semantic handshake

43. Simulation: The Impact of Semantic Handshakes Iteration of nbrOfDifferentII in [0,100] general parameters: card =100, distributionII = {1.0} specific parameters exp05: distributionNbrOfII = {0.2,1.0}  100 Topics für selben AG  80% der Topics tragen lokale Integrations- entscheidung  alle Term sind gleich dominant Anzahl Terme pro globalem Terme Anzahl globaler Terme terminologische Diversität terminologische Uniformität 30 verschiedene Terme werden zu 1 einem globalen Term aufgelöst, wenn 80% aller Topics eine lokale Integrationsentscheidung haben!

44. Ergebnis: The Impact of Semantic Handshakes dezentrale, lokale Integrationsentscheidungen haben ähnlichen Effekt wie global durchgesetzte Vokabulare dezentraler bottom-up-Ansatz zum Umgang mit terminologischer Heterogenität implizite Vernetzung in terminologisch heterogenen Umgebungen Voraussetzung: Integrationsmodell und Kommunikationskanäle Authoring Guideline: immer zwei verfügbare Subject Identifier nutzen zwei populäre Subject Identifier nutzen Authoring Guideline soll durch ATMs verbreitet werden

45. DC4TM-ATM

46. Dublin Core und Topic Maps Szenario: 10 Autoren bekommen die Dublin-Core-Terme und sollen Metadaten (als Topic Map) zu Dokumenten erstellen die Nutzung des Dublin-Core-Vokabulars in Topic Maps ist bisher nicht standardisiert

47. Dublin Core und Topic Maps dc:title Lutz Maicher research. Titel: Repräsentation als Zeichenkette ( literal value surrogate ) oder als Referenz zu anderer description ( non-literal value surrogate )? dc:type dctype:Text Type: Repräsentation als Referenz zu anderer description ( non-literal value surrogate ) unter Nutzung eines kontrollierten Vokabulars. dc:creator mailto:maicher@informatik.uni-leipzig.de Creator: Repräsentation als Zeichenkette ( literal value surrogate ) oder als Referenz zu anderer description ( non-literal value surrogate )? dc:identifier http://www.informatik.uni-leipzig.de/~maicher/index.html DCAM Erzeuge description (= DCAM-Instanz). Was ist die described resource URI ?

48. Dublin Core und Topic Maps [id1 % &quot; http://www.informatik.uni-leipzig.de/~maicher/index.html &quot;] dc:title Lutz Maicher research. {id1 , dc:title, [[ Lutz Maicher research ]]} /lang:en-GB dc:type dctype:Text dc:type(id1 : iso29111:resource, dctype:Text : iso29111:value) dc:creator mailto:maicher@informatik.uni-leipzig.de dc:creator(id1 : iso29111:resource , id2 : iso29111:value) [id2 =&quot;Lutz Maicher&quot; @&quot;mailto:maicher@informatik.uni-leipzig.de&quot;] dc:identifier http://www.informatik.uni-leipzig.de/~maicher/index.html DCAM #PREFIX dc @&quot;http://purl.org/dc/elements/1.1/&quot; #PREFIX dctype @&quot;http://purl.org/dc/dcmitype/&quot; #PREFIX lang @&quot;http://www.topicmaps.org/xtm/1.0/language.xtm#&quot; #PREFIX iso29111 @ &quot; http://psi.topicmaps.org/iso29111/ &quot; Topic Map

49. DC4TM - Modellierungsmethode DC4TM – Modellierungsmethode erzeugt Topic Maps {id1 , dc:title, [[ Lutz Maicher research ]]} /lang:en-GB dc:type(id1 : iso29111:resource, dctype:Text : iso29111:value) dc:creator(id1 : iso29111:resource , id2 : iso29111:value) [id2 =&quot;Lutz Maicher&quot; @&quot;mailto:maicher@informatik.uni-leipzig.de&quot;] #PREFIX dc @&quot;http://purl.org/dc/elements/1.1/&quot; #PREFIX dctype @&quot;http://purl.org/dc/dcmitype/&quot; #PREFIX lang @&quot;http://www.topicmaps.org/xtm/1.0/language.xtm#&quot; #PREFIX iso29111 @ &quot; http://psi.topicmaps.org/iso29111/ &quot; [id1 % &quot; http://www.informatik.uni-leipzig.de/~maicher/index.html &quot;] Topic Map TMDM  DCAM RDF HTML XML dc:title Lutz Maicher research. dc:type dctype:Text dc:creator mailto:maicher@informatik.uni-leipzig.de dc:identifier http://www.informatik.uni-leipzig.de/~maicher/index.html DCAM

50. DC4TM - Modellierungsmethode stellt sicher, dass in den erzeugten Topic Maps non-literal value surrogates (als Assoziationen) und literal value surrogates (als Occurrences) konsistent zu dem TMDM  DCAM Mapping repräsentiert werden für alle Terme des Dublin-Core-Vokabulars konsistent entschieden wird, ob deren Werte als non-literal value surrogate (als Assoziationen) oder als literal value surrogate (als Occurrences) repräsentiert werden alle kontrollierten Terme des Dublin-Core-Vokabulars entsprechend ihrer Bedeutung korrekt genutzt werden auf Individuenebene – wenn verfügbar – kontrollierte Vokabulare genutzt werden (z.B. Sprachen, Länder, MIME-Typen, etc.) bzw. auf Individuenebene mind. zwei populäre Subject Identifier genutzt werden ist ausführbar durch Autonome Topic Map: DC4TM-ATM

51. DC4TM–ATM – Formalisierung der DC4TM-Modellierungsmethode

52. Zusammenfassung

53. Zusammenfassung: Autonome Topic Maps Autonome Topic Maps identische Beobachtungen erzeugen identische Modelle eine Abfragephrase pro Typ von Information implizite Vernetzung zwischen erzeugten Topic Maps auf Typ- und Individuenebne (in terminologisch statischen Domänen) Interpreter können in beliebige Anwendungskontexte integriert werden ATMs können leicht verteilt werden (Dezentralität der Erstellung) Duales, dezentrales Verfahren wo terminologische Normierung möglich, wird kontrolliertes Vokabular+Modellierungsmethode verteilt wo terminologische Normierung nicht möglich, wird dezentrales Bottom-Up Verfahren zum Umgang mit terminologischer Heterogenität genutzt PNDM / PNPM für Repräsentation beliebiger Workflows in Topic Maps PNDM / PNPM und Semantic Handshakes kann nicht nur für dezentrale Erstellung von Topic Maps genutzt werden …