--- a/paper/implmodel.tex	Sun Mar 31 08:54:22 2013 +0900
+++ b/paper/implmodel.tex	Sun Mar 31 09:02:46 2013 +0900
@@ -1,5 +1,5 @@
 \section{実装}
-まず作成するアプリケーションのユースケース図を図\ref{fig:usecase}に示す.
+作成するアプリケーションのユースケース図を\figref{fig:usecase}に示す.
 \begin{figure}[tb]
   \begin{center}
    \includegraphics[scale=0.30]{figure/usecase.pdf}
@@ -24,7 +24,7 @@
 GraphDBはTinkerPop使用し, play frameworkによりREST APIを提供する.
 クライアントサイドはJavaScript/HTML/CSSを用いる.
 クライントサイドはサーバサイドが提供するREST APIを叩いて主にJSONデータを使用しブラウザへと表示をおこなう.
-実装の概略を図\ref{fig:arch}に示す.
+実装の概略を\figref{fig:arch}に示す.
 
 \begin{figure}[tb]
   \begin{center}
@@ -71,7 +71,7 @@
 そこでタイムスタンプをノードのプロパティとして新たに追加し, 更に主張同士の繋がりでできる木構造
 のデータのコピーを行うことにした.
 コピーされた木は最新の木に対してprevの関係となるエッジで繋げた.
-これにより, prevエッジを辿ることで前の合意状態を見ることができるようになった(図\ref{fig:temporal}).
+これにより, prevエッジを辿ることで前の合意状態を見ることができるようになった(\figref{fig:temporal}).
 
 \begin{figure}[tb]
   \begin{center}

--- a/paper/introduction.tex	Sun Mar 31 08:54:22 2013 +0900
+++ b/paper/introduction.tex	Sun Mar 31 09:02:46 2013 +0900
@@ -6,7 +6,7 @@
 DEOSプロジェクトは2006年に独立行政法人科学技術機構(JST)はCRESTプログラムの1つとして始まったプロジェクトである.\cite{d_add2012}
 DEOSプロジェクトは, 変化し続ける目的や環境の中でシステムを適切に対応させ, 継続的にユーザが求めるサービスを提供することができるシステムの構築法を
 開発することを目標としている.\cite{deos2012}
-DEOSプロジェクトではそれらの技術体系を「オープンシステムディペンダビリティ」として定義し, それをDEOSプロセスとしてまとめた.(図\ref{fig:deos_process})
+DEOSプロジェクトではそれらの技術体系を「オープンシステムディペンダビリティ」として定義し, それをDEOSプロセスとしてまとめた.(\figref{fig:deos_process})
 
 DEOSプロセスにおいて, 全てのデータを保持するD-ADD(DEOS Agreement Description Database)と呼ばれるデータベースがある.
 D-ADDで扱うデータにはステークホルダ間で合意された契約書等も含まれる.

--- a/paper/model.tex	Sun Mar 31 08:54:22 2013 +0900
+++ b/paper/model.tex	Sun Mar 31 09:02:46 2013 +0900
@@ -4,13 +4,13 @@
 %いくつか上げられたモデルのうちの1つが次のモデルとなる.
 
 \subsection{モデルの概要}
-提案する議論のモデルは, 合意形成を「主張」・「関係」・「ユーザ」の要素から構成される木と考える.
-合意を取りたい「主張」があり, その内容を深めて議論していくことでステークホルダ(「ユーザ」)
+提案する議論のモデルは, 合意形成を{\bf 主張}・{\bf 関係}・{\bf ユーザ}の要素から構成される木と考える.
+合意を取りたい{\bf 主張}があり, その内容を深めて議論していくことでステークホルダ({\bf ユーザ})
 に合意するよう説得していく.
-議論を深めていくことは, 「主張」から更に踏み込んだ内容の「主張」が複数派生すると考えられる.
-また, 「主張」に対してどのように踏み込んだかという「関係」も発生する.
-よって「主張」から複数の「関係」と「主張」が派生し, その「主張」からさらに複数の
-「関係」と「主張」が派生することにより, 木構造を構成できる.
+議論を深めていくことは, {\bf 主張}から更に踏み込んだ内容の{\bf 主張}が複数派生すると考えられる.
+また, {\bf 主張}に対してどのように踏み込んだかという{\bf 関係}も発生する.
+よって{\bf 主張}から複数の{\bf 関係}と{\bf 主張}が派生し, その{\bf 主張}からさらに複数の
+{\bf 関係}と{\bf 主張}が派生することにより, 木構造を構成できる.
 これは木構造には閉路が含まれないため, 循環論法が生じさせないという狙いがある.
 
 %\begin{itemize}
@@ -21,7 +21,7 @@
 %  \end{itemize}
 %\end{itemize}
 
-「ユーザ」・「主張」・「関係」は以下の用に定義される.
+{\bf ユーザ}・{\bf 主張}・{\bf 関係}は以下の用に定義される.
 \begin{itemize}
 \item ユーザ
   \begin{itemize}
@@ -35,15 +35,15 @@
 
 \item 関係
   \begin{itemize}
-%    \item 互いに異なる「主張」と「主張」がどのように踏み込んだかを示すのを「関係」という
-    \item ユーザと主張, もしくは互いにことなる主張と主張がどのように踏み込んだかを示すのを「関係」という
+%    \item 互いに異なる{\bf 主張}と{\bf 主張}がどのように踏み込んだかを示すのを{\bf 関係}という
+    \item ユーザと主張, もしくは互いにことなる主張と主張がどのように踏み込んだかを示すのを{\bf 関係}という
   \end{itemize}
 \end{itemize}
 
 \subsection{GraphDBによる表現}
 GraphDBを用いて上記のモデルを表現する.
-提案するモデルの「ユーザ」と「主張」がノードで, 「関係」がエッジにあたる.
-各主張とユーザとの関係を示したものが図\ref{fig:tomodel0}となる.四角がノードを, 矢印がエッジをそれぞれ表している.
+提案するモデルの{\bf ユーザ}と{\bf 主張}がノードで, {\bf 関係}がエッジにあたる.
+各主張とユーザとの関係を示したものが\figref{fig:tomodel0}となる.四角がノードを, 矢印がエッジをそれぞれ表している.
 
 \begin{figure}[tb]
   \begin{center}
@@ -54,13 +54,13 @@
 \end{figure}
 
 %主張が合意されたという状態になるのは, 合意要求をだしている相手から合意をもらえたときとなる.
-図\ref{fig:tomodel0}において主張2,3からユーザへのエッジは省略しているが、
+\figref{fig:tomodel0}において主張2,3からユーザへのエッジは省略しているが、
 各主張ノードからはそれぞれ作者と合意要求の関係となるエッジがユーザノードへと繋げられる.
 
 
 \subsection{合意状況の計算}
 このモデルにおいて主張は一人以上のユーザに合意要求を出して合意してもらわなければならない.
-しかし, その主張に子となる主張(図\ref{fig:tomodel0}での主張2,3)がある場合, つまり関係が張られた別の主張がある場合,
+しかし, その主張に子となる主張(\figref{fig:tomodel0}での主張2,3)がある場合, つまり関係が張られた別の主張がある場合,
 子となる主張を合意もしくは否認させておかなくてはならない.
 自身の主張の合意を通すための各関係は以下のとおりとなる.
 \begin{itemize}
@@ -80,16 +80,16 @@
 
 上記のように3種類の関係も主張の合意状態に影響を与える.
 実際にどのように主張が立てられて合意がなされていくのか簡単なシナリオを
-記述して示したものが図\ref{fig:tomodel2}となる.
+記述して示したものが\figref{fig:tomodel2}となる.
 
-図\ref{fig:tomodel2}の説明を行う.
+\figref{fig:tomodel2}の説明を行う.
 四角が主張を, 矢印が関係をそれぞれ表す.
 まず最初に主張1「アプリでGraphDBを利用すべきである」が立てられる.
 次にその主張に対して反論となる主張2「RDBを利用すべきである」が立てられる.
 この時, 最初にたてた主張は自身の合意を取るためには反論となる主張を否認させなければならない.
 そこで, 反論に対して反論を用意し,  主張3「データ構造がGraphDBに向いている」を立て主張2を否認する.
-2の主張の作成を行った人は3の主張で納得したため3に合意を行う.
-それにより2の主張は否認されることとなる.
+主張2の作成を行った人は主張3で納得したため主張3に合意を行う.
+それにより主張2は否認されることとなる.
 次に質問となる主張4「どのGraphDBを利用すべきでか？」が立てられる.
 これに対しては提案となる主張5「TinkerPopはどうか」をたてることで応える.
 質問者はその答えに納得し主張5に対して合意を行い, 他に反論や質問も無いため主張1に対しても合意する.
@@ -107,7 +107,7 @@
 
 \subsection{トゥールミンモデル}
 また, それぞれ個々の主張に対してもモデルを考えてみる.
-今回は, トゥールミンモデルと呼ばれるモデルを適用できるようにしておく.
+今回は, トゥールミンモデルと呼ばれるモデルを適用する.
 トゥールミンモデルは1つの主張には以下の5つの情報も必要であるとするモデルである.
 \begin{itemize}
   \item データ(Data)
@@ -122,7 +122,7 @@
 限定詞を使うことで主張が完全であるかないかを表すことができる.
 これらの情報をもった主張がトゥールミンモデルとなる.
 このトゥールミンモデルはGraphDB上の主張となるノードにプロパティとしてそれぞれ持たせられるようにする.
-トゥールミンモデルの概略図を示したのが図\ref{fig:toulmin}となる.
+トゥールミンモデルの概略図を示したのが\figref{fig:toulmin}となる.
 \begin{figure}[tb]
   \begin{center}
     \includegraphics[scale=0.30]{figure/toulmin.pdf}