--- a/paper/compare.tex	Mon Apr 01 07:39:34 2013 +0900
+++ b/paper/compare.tex	Mon Apr 01 08:35:43 2013 +0900
@@ -47,7 +47,7 @@
 だが, 今回私達が作成したWebアプリケーションではredmineのチケットは1つの主張ノードにあたる.
 そのため, 各関係がエッジで繋がっているため関連の確認が行いやすくなっている.
 
-%\subsection{時系列的なみかたによる}
+%\subsection{議論の様子の時系列的な味方}
 
 %また, あるノードができた流れも過去のバージョンをみることができるため比較的分かりやすいと思われる.
 実際にWebアプリケーション上でデータを入力してできた木構造を\figref{fig:webapp}に示す.

--- a/paper/conclusion.tex	Mon Apr 01 07:39:34 2013 +0900
+++ b/paper/conclusion.tex	Mon Apr 01 08:35:43 2013 +0900
@@ -1,10 +1,9 @@
 \section{まとめ}
 議論のモデルを考えWebアプリケーションとして合意形成支援ツールの実装を行い
 D-ADDにおける合意形成支援についての追求を行った.
-作成したWebアプリケーションに実際にデータを入力し, redmineと比較し考察した.
+木構造による議論のモデルの提案とGraphDBを用いた実装を行った.
+作成したWebアプリケーションに実際にデータを入力し, redmineに入力する場合と比較し考察した.
 時系列的に流れを見ることで, 合意までの流れがより分かりやすくなり, 合意全体の理解を支援できる可能性もみることができた.
-GraphDBを用いた合意形成支援を行うことができた.
-
 
 \subsection{今後の課題}
 本実装では主張同士の関係が反論・質問・提案だけであったが, 更に増やすことが可能である.
@@ -12,9 +11,10 @@
 例えば質問の関係を元にした回答という関係をつくれば, 合意されなければならない回答というエッジを作ることができる.
 どのような名前のエッジを用意したらより分かりやすいかは考えるべきである.
 
-また, 今回実装したWebアプリケーションには内容が同じノード同士の検出等が行われない.
+今回実装したWebアプリケーションには内容が同じノード同士の検出等が行われない.
 その点はユーザに任せてしまっている.
 しかし, D-ADDはそれら複数のデータ間で整合性を取らなければならない.
 また, 一度合意形成を行ったデータは変更されないとも限らない.
 変更された際にどこまで影響が及ぶのかといったことも検出するのが理想である.
 複数のデータ間での整合性と変更したことで影響を与える範囲の検出, これらの方法も考えていかなければならない.
+%合意形成以外のD-ADDに必要な機能との連携も考えていかなければならない.

--- a/paper/d_add.tex	Mon Apr 01 07:39:34 2013 +0900
+++ b/paper/d_add.tex	Mon Apr 01 08:35:43 2013 +0900
@@ -19,7 +19,7 @@
 
 
 \subsection{説明責任と合意形成}
-D-ADDは障害が発生した際, 説明責任を果たさなければならない.
+D-ADDはシステムに障害が発生した際, 説明責任を果たさなければならない.
 説明責任とはなぜその障害が発生したのか, 次からはその障害を起こさせない, もしくはしっかりと対応できることを示すことである.
 そして説明責任を果たすためにはまず, なぜそのようなシステムになったのかと言うことを
 説明できなければならないと考えられた.

Binary file paper/figure/d_add.pdf has changed

--- a/paper/model.tex	Mon Apr 01 07:39:34 2013 +0900
+++ b/paper/model.tex	Mon Apr 01 08:35:43 2013 +0900
@@ -11,7 +11,7 @@
 また, {\bf 主張}に対してどのように踏み込んだかという{\bf 関係}も発生する.
 よって{\bf 主張}から複数の{\bf 関係}と{\bf 主張}が派生し, その{\bf 主張}からさらに複数の
 {\bf 関係}と{\bf 主張}が派生することにより, 木構造を構成できる.
-これは木構造には閉路が含まれないため, 循環論法が生じさせないという狙いがある.
+これは木構造には閉路が含まれないため, 循環論法を生じさせないという狙いがある.
 
 %\begin{itemize}
 %\item 木構造にすることでいくつかの利点が得られる.
@@ -42,9 +42,9 @@
 
 
 \subsection{合意状況の計算}
-このモデルにおいて主張は一人以上のユーザに合意要求を出して合意してもらわなければならない.
-しかし, その主張に子となる主張(\figref{fig:tomodel0}での主張2,3)がある場合, つまり関係が張られた別の主張がある場合,
-子となる主張を合意もしくは否認させておかなくてはならない.
+このモデルにおいて主張を合意させるには, 合意要求を出している全員から合意を受けなければならない.
+しかし, その主張に子となる主張(\figref{fig:tomodel0}での主張2,3)がある場合,
+関係次第では子となる主張の合意状態も影響を与えることにした.
 自身の主張の合意を通すための各関係は以下のとおりとなる.
 \begin{itemize}
 \item 反論
@@ -61,9 +61,10 @@
   \end{itemize}
 \end{itemize}
 
-上記のように3種類の関係も主張の合意状態に影響を与える.
+上記のように3種類の関係にそって主張の合意状態は計算される.
 実際にどのように主張が立てられて合意がなされていくのか簡単なシナリオを
 記述して示したものが\figref{fig:tomodel2}となる.
+シナリオの議論の目的はアプリで使用するデータベースを決めることである.
 
 \figref{fig:tomodel2}の説明を行う.
 四角が主張を, 矢印が関係をそれぞれ表す.
@@ -104,7 +105,6 @@
 裏付けは根拠が正しいことを示し, 論駁には主張が成り立たなくなる例外の条件が入る.
 限定詞を使うことで主張が完全であるかないかを表すことができる.
 これらの情報をもった主張がトゥールミンモデルとなる.
-このトゥールミンモデルはGraphDB上の主張となるノードにプロパティとしてそれぞれ持たせられるようにする.
 トゥールミンモデルの概略図を示したのが\figref{fig:toulmin}となる.
 \begin{figure}[tb]
   \begin{center}

--- a/paper/omni/d_add.graffle	Mon Apr 01 07:39:34 2013 +0900
+++ b/paper/omni/d_add.graffle	Mon Apr 01 08:35:43 2013 +0900
@@ -237,7 +237,7 @@
 
 \f0\fs24 \cf0 D-Case\
 \'83\'67\'83\'44\'81\'5b\'83\'8b\'83\'7e\'83\'93\
-\'89\'ef\'8b\'63..etc...}</string>
+\'8b\'63\'98\'5f..etc...}</string>
 				<key>VerticalPad</key>
 				<integer>0</integer>
 			</dict>
@@ -489,7 +489,7 @@
 	<key>MasterSheets</key>
 	<array/>
 	<key>ModificationDate</key>
-	<string>2013-03-31 18:09:37 +0000</string>
+	<string>2013-03-31 23:20:37 +0000</string>
 	<key>Modifier</key>
 	<string>Nobuyasu Oshiro</string>
 	<key>NotesVisible</key>