Mercurial > hg > Papers > 2013 > nobuyasu-sigos
view paper/model.tex @ 69:059d1777fd53
added architecture.png
author | Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Wed, 24 Apr 2013 01:07:35 +0900 |
parents | 903cf43da389 |
children |
line wrap: on
line source
\section{提案するモデル} ある事柄に対して合意を取る場合, 議論が行われる. そこで, 合意形成支援を行うため, 議論のモデルから考えた. %いくつか上げられたモデルのうちの1つが次のモデルとなる. \subsection{モデルの概要} 提案する議論のモデルは, 合意形成を{\bf 主張}・{\bf 関係}・{\bf ユーザ}の要素から構成される木と考える. 合意を取りたい{\bf 主張}があり, その内容を深めて議論していくことで{\bf ユーザ}に合意するよう説得していく. 議論を深めるには, {\bf 主張}から更に踏み込んだ内容の{\bf 主張}が複数派生させていくことになる. このとき, {\bf 主張}に対してどのように踏み込んだかという{\bf 関係}も発生する. よって, {\bf 主張}から複数の{\bf 関係}と{\bf 主張}が派生し, その{\bf 主張}からさらに複数の {\bf 関係}と{\bf 主張}が派生することにより, 木構造が構成される. これは, 木構造には閉路が含まれないため, 循環論法を生じさせないという狙いがある. %\begin{itemize} %\item 木構造にすることでいくつかの利点が得られる. % \begin{itemize} % \item 木構造には閉路が含まれない. よって循環論法が生じない % \item 非破壊的な編集が可能である % \end{itemize} %\end{itemize} {\bf ユーザ}・{\bf 主張}・{\bf 関係}は以下の用に定義される. \begin{itemize} \item ユーザ \begin{itemize} \item 合意形成の参加者をユーザという. \end{itemize} \item 主張 \begin{itemize} \item ユーザが作成した合意をとりたい, 議論すべき内容を含むものを主張という. \end{itemize} \item 関係 \begin{itemize} % \item 互いに異なる{\bf 主張}と{\bf 主張}がどのように踏み込んだかを示すのを{\bf 関係}という \item ユーザと主張, もしくは互いにことなる主張と主張がどのように踏み込んだかを示すのを{\bf 関係}という. \end{itemize} \end{itemize} このモデルにおいて{\bf ユーザ}・{\bf 主張}はノード, {\bf 関係}はエッジとして扱われる. \subsection{合意状況の計算} このモデルにおいて主張を合意させるには, 合意要求を出している全員から合意を受けなければならない. しかし, その主張に子となる主張(\figref{fig:tomodel0}での主張2,3)がある場合, 関係次第では子となる主張の合意状態も影響を与えることにした. 自身の主張の合意を通すための各関係は以下のとおりとなる. \begin{itemize} \item 反論 \begin{itemize} \item 反論となる主張が合意されると親の主張は合意できない. 反論には別の反論を用意して相手を納得させることで合意を進める. \end{itemize} \item 質問 \begin{itemize} \item 質問となる主張は別の主張により答えが得られたら合意をする. 質問の関係で繋げられた主張を合意させなければ親の主張の合意は通らない. \end{itemize} \item 提案 \begin{itemize} \item 提案となる主張はどの状態であろうと親の合意状況に影響は与えない. \end{itemize} \end{itemize} 上記のように3種類の関係にそって主張の合意状態は計算される. 実際にどのように主張が立てられて合意がなされていくのか簡単なシナリオを 記述して示したものが\figref{fig:tomodel2}となる. シナリオの議論の目的はアプリで使用するデータベースを決めることである. \figref{fig:tomodel2}の説明を行う. 四角が主張を, 矢印が関係をそれぞれ表す. まず最初に主張1「アプリでGraphDBを利用すべきである」が立てられる. 次にその主張に対して反論となる主張2「RDBを利用すべきである」が立てられる. この時, 最初に立てた主張は自身の合意を取るためには反論となる主張を否認させなければならない. そこで, 反論に対して反論を用意し, 主張3「データ構造がGraphDBに向いている」を立て主張2を否認する. 主張2の作成を行った人は主張3で納得したため主張3に合意を行う. それにより主張2は否認されることとなる. 次に質問となる主張4「どのGraphDBを利用すべきか?」が立てられる. これに対しては提案となる主張5「TinkerPopはどうか」を立てることで応える. 質問者はその答えに納得し主張5に対して合意を行い, 他に反論や質問も無いため主張1に対しても合意する. これで主張1に対して反論の関係にある主張は否認にし, 質問となる主張の合意を取ることができたため, 主張1の合意はなされた. 以上が提案するモデルによる合意を取るまでの簡単な流れである. \begin{figure}[tb] \begin{center} \includegraphics[scale=0.30]{figure/TOModel2_2.pdf} \caption{主張1の合意が取られた状態} \label{fig:tomodel2} \end{center} \end{figure} \subsection{主張のモデル} また, それぞれ個々の主張に対してもモデルを考えた. そこで今回は, トゥールミンモデルと呼ばれるモデルを適用する. トゥールミンモデルは1つの主張に以下の5つの情報も必要であるとするモデルである. \begin{itemize} \item データ(Data) \item 根拠(Warrant) \item 裏付け(Backing) \item 論駁(Rebuttal) \item 限定詞(Qualifier) \end{itemize} 主張を後押しする客観的な資料となるデータがあり, 根拠はデータがなぜ主張を後押しするのかを示す. 裏付けは根拠が正しいことを示し, 論駁には主張が成り立たなくなる例外の条件が入る. 限定詞を使うことで主張が完全であるかないかを表すことができる. これらの情報をもった主張がトゥールミンモデルとなる. トゥールミンモデルの概略図を示したのが\figref{fig:toulmin}となる. \begin{figure}[tb] \begin{center} \includegraphics[scale=0.30]{figure/toulmin.pdf} \caption{トゥールミンモデル概略図} \label{fig:toulmin} \end{center} \end{figure} もちろんD-ADDにおける主張のモデルはトゥールミンモデルだけでなく, 別のモデルを用いても良い. D-ADDによる合意形成で扱う主張のモデルは熟考していく必要がある.