Re: [Ag Meinungsfindungstool] komplexe Themenbäume mit wilden Querschnittsthemen ...

["marc" <marc AT merkstduwas.de>]

Hi Jakob,

das ist am besten mal in einer unserer dienstägigen Mumblesessions erläutert 
;o)

Nur soviel: die Ontologie liegt in der ersten Iteration vor, d.h. sie wird 
sich im Laufe der Zeit auf jeden fall noch weiterentwickeln.

Du fragtest:
> Habe ich das richtig verstanden, daß
> → die Implementierung ein Webinterface für eine ganz normale
> ontologiebasierte Datenbank ist,

Momentan haben wir leider noch keine Ontologie im RDF Format, welche wir mit 
SPARQL abfragen könnten (z.B. BrightstarDB).

Daher haben wir zur Zeit die Ontologie als ordinäres SQL Schema modelliert 
und greifen darauf über einen OData Endpoint als Web Interface zu.

> → ihr die Struktur dieser Datenbank in der Ontologie ablegt, die
> ich da im Link sehe,

Die verlinkte Grafik zeigt den (fast) aktuellen Stand des SQL Schemas, 
welches den aktuellen Stand der Ontologie repräsentiert.

> → die Knoten in unserem Baum "Posts" vom Typ "PostType" sind,
> also eines aus der Menge {"Topic", "General", "Question",
> "Proposal", "Information", "Quintessence"}

Ja. Die Einträge im Themenbaum sind Post Entitäten vom PostType 'Topic'.

> → die Links zwischen den Knoten "PostReferences" sind, vom Typ
> "PostRereferenceType", d.h. eines aus {"Child", "General",
> "Consequence", "Equivalence", "Evidence", "Objection",
> "Agreement", "Disagreement", "Alternative", "Context", "Part"}

Ja. Die Eltern-Kind-Beziehung wird über PostReference Entitäten mit dem 
PostReferenceType 'Child' abgebildet, die den RefersTo (der referenzierte 
Post ist das Child) und ReferredFrom (der referenzierte Post ist der Parent) 
Eigenschaften einer Post Entität zugewiesen werden.

> → das, worüber wir gerade reden (also wer wessen Kind ist usw)
> sich auf die Ontologie bezieht, insbesondere auf
> "PostReferenceType" und "PostType")?

Ja, und die RefersTo- und ReferredFrom-Eigenschaften der Post Entität. Daher 
würde ich gerne den PostReferenceType 'Child' in 'ParentChild' umbenennen, 
da je nach Lesart (RefersTo oder ReferredFrom) entweder die Eltern- oder 
Kind-Entität referenziert wird.

> Und da rede ich über das Einführen von einer zweiten Linkart.
> Es gibt es ja schon verschiedene Linkarten (sogar 11
> verschiedene), und verschiedene Knotenarten (6
> verschiedene). Meine erste Frage wäre:
> → Warum braucht man beides? Verschiedene Knotenarten
> *und* verschiedenen Linkarten? Reicht nicht eins? Die
> meisten Beziehungen (etwa einen Link vom Typ
> "Consequence" auf einen Knoten vom Typ "Proposal")
> scheinen mir nicht sinnvoll zu sein, oder wenigsten keinen
> großen Informationsmehrwert zu liefern. Sind bestimmte
> Kombinationen verboten? Wenn ja, finde ich das auch in
> der Ontologie, oder macht das das Web-Frontend?

Da wir momentan leider noch keine "richtige" Ontologie modelliert haben, 
sind auch diese Bedingungen noch nicht hart definiert (siehe oben).

Momentan kann (rein technisch) alles mit allem beliebig verknüpft werden. Es 
gibt bisher keine Validierung. Aber wir müssen ganz bestimmt irgendwann 
anfangen darüber zu diskutieren, welche Kombinationen von PostType und 
PostReferenceType semantisch sinnvoll sind und welche nicht. Das soll im 
Idealfall im engen Austausch mit den Plattform-Entwicklern passieren.

Warum sind es so viele Ausprägungen der PostType und PostReferenceType 
Entitäten?
Wir standen seiner Zeit vor der Frage, ob wir eine fix definierte Menge in 
die Ontologie aufnehmen, oder ob wir den Plattformen die Möglichkeit geben 
die Ausprägungen der PostType und PostReferenceType Entitäten selber zu 
definieren. Wir sind momentan der Auffassung, dass dies wenig hilfreich 
wäre, da es ja gerade Sinn und Zweck einer Ontologie ist die Semantik 
eindeutig zu beschreiben. Daher haben wir einige uns bekannte 
Diskussionstools betrachtet und die zur Abbildung der Inhalte unserer 
Meinung nach notwendigen Entitäten modelliert.

Natürlich ist unser bestreben, die Anzahl der Entitäten und ihrer konkreten 
Ausprägungen möglichst gering zu halten und ggf. sogar wieder zu reduzieren. 
Weniger ist hier definitiv mehr. Wir hoffen dies durch die Proof-of-Concept 
(PoC) Implementierungen validieren zu können. Daher ist es gut, wenn Thomas 
sagt, er braucht keine neue Ausprägung 'Related' der Entität 
PostReferenceType.

> → Was bedeuten die Typen "Child" und "General" bei den
> Links, und "General" bei den Knoten?

'General' bedeutet 'Sonstige' und ist immer dann anzuwenden, wenn eine 
Plattform keine dezidierte Semantik unterstützen möchte oder kann. Momentan 
ist es z.B. so, das die qKonsens Implementierung einer Referenz zwischen 
einer Kernaussage (PostType 'Quintessence') und einem dazu abgegebenen 
Kommentar (PostType 'General') den PostReferneceType 'General' verpasst. In 
d!scoArguments kann diese Referenz nun z.B. als 'Disagreement' spezialisiert 
werden. Somit kann es Plattformen geben, welche durch ihre Methodik die 
Daten anreichern (veredeln) können.

> → Können Typen mehrfach vergeben werden? D.h. kann
> ein Knoten gleichzeitig vom Typ "Topic" und vom Typ
> "Consequence" sein?

Nein. Aber momentan können mehrere Referenzen mit unterschiedlichen 
PostReferenceType Werten zwischen zwei Post Entitäten existieren. Ob das 
Sinn macht, müssen wir ausprobieren und können das gerne diskutieren.

> Das wirkt auf den ersten Blick extrem komplex. Wie seid Ihr
> da hingekommen? Sind die Typen auch für den Nutzer
> sichtbar (d.h. soll er sich entscheiden, ob er gerade eine
> Question, Proposal, oder Information tippt, und ob diese ein
> Disagreement, Alternative, oder Objection zu dem Text sind,
> den er gerade beantwortet)?

Einige Antworten stecken glaube ich schon in den obigen Antworten drin...
... aber der Benutzer eines speziellen Diskussionstools bekommt von alledem 
natürlich nix mit. Die Plattform-Entwickler müssen sich mit der Semantik der 
Ontologie auseinandersetzen und versuchen Ihre Methodik bestmöglich darin 
abzubilden. Dies ist im Interesse der Plattform, damit Inhalte in und aus 
anderen Plattformen möglichst aussagekräftige (wieder)verwendet werden 
können.

Cheers
Marc