Mercurial > hg > Papers > 2013 > nobuyasu-sigos
changeset 11:dbddf65dea63
added TOModel0_2
author | Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Sat, 30 Mar 2013 22:15:18 +0900 |
parents | f1ffd8e10d0b |
children | 079d3c43c5dd |
files | paper/d_add.tex paper/figure/TOModel0_2.bb paper/figure/TOModel0_2.pdf paper/implmodel.tex paper/introduction.tex paper/model.tex |
diffstat | 6 files changed, 31 insertions(+), 12 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/d_add.tex Sat Mar 30 21:23:19 2013 +0900 +++ b/paper/d_add.tex Sat Mar 30 22:15:18 2013 +0900 @@ -29,4 +29,3 @@ そこでD-ADD自身に合意形成の場を用意する機能が必要となってくる. -%\subsection{GraphDBを用いた合意形成支援}
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/paper/figure/TOModel0_2.bb Sat Mar 30 22:15:18 2013 +0900 @@ -0,0 +1,5 @@ +%%Title: ./TOModel0_2.pdf +%%Creator: extractbb 20110311 +%%BoundingBox: 0 0 605 309 +%%CreationDate: Sat Mar 30 22:12:46 2013 +
--- a/paper/implmodel.tex Sat Mar 30 21:23:19 2013 +0900 +++ b/paper/implmodel.tex Sat Mar 30 22:15:18 2013 +0900 @@ -1,10 +1,6 @@ \section{モデルの実装} -モデルの実装にはGraphDBを使う. -GraphDBはノードとエッジにより, 情報をグラフとして保持するデータベースである. -\subsection{GraphDB} - \section{Webアプリケーションとしての実装}
--- a/paper/introduction.tex Sat Mar 30 21:23:19 2013 +0900 +++ b/paper/introduction.tex Sat Mar 30 22:15:18 2013 +0900 @@ -15,7 +15,7 @@ そこで扱うデータにはステークホルダ間で合意された契約書等も含まれる. そのためD-ADDは基本ツールとして合意形成支援ツールを持っていると考えられている. -本研究ではD-ADDで行われる合意形成の1つの案としてモデルを提案する. +本研究ではD-ADDで行われる合意形成の1つの案としてモデルを提案しプロトタイプの実装を行う. また, 実際に例題を入力してみてD-ADDにおける合意形成支援のあり方についての追求を行う.
--- a/paper/model.tex Sat Mar 30 21:23:19 2013 +0900 +++ b/paper/model.tex Sat Mar 30 22:15:18 2013 +0900 @@ -3,6 +3,7 @@ そこで, 合意形成支援を行うための議論のモデルから考えてみた. いくつか上げられたモデルのうちの1つが次のモデルとなる. + \subsection{モデルの概要} このモデルは, 合意形成を「主張」・「関係」・「ユーザ」の要素から構成される木と考える. 合意を取りたい「主張」があり, その内容を深めて議論していくことでステークホルダ(「ユーザ」) @@ -38,18 +39,24 @@ \end{itemize} \end{itemize} -\subsection{合意状況の計算} -このモデルにおいて主張は一人以上のユーザに合意要求を出さなければならない. +\subsection{GraphDBを用いた合意形成支援} +今回, プロトタイプとなる合意形成支援Webアプリケーションを作るにあたり, GraphDBを用いる. +GraphDBはノードとエッジにより, データをグラフとして保持するデータベースである. +提案するモデルでいう「ユーザ」と「主張」がノードに, 「関係」がエッジで表されることになる. \begin{figure}[tb] \begin{center} - \includegraphics[scale=0.35]{figure/TOModel0.pdf} + \includegraphics[scale=0.35]{figure/TOModel0_2.pdf} \caption{主張からユーザへ伸びる合意要求} \label{fig:d-add} \end{center} \end{figure} + + +\subsection{合意状況の計算} +このモデルにおいて主張は一人以上のユーザに合意要求を出して合意してもらわなければならない. しかし, その主張に子となる主張がある場合, つまり関係が張られた別の主張がある場合, 子となる主張を合意もしくは否認させておかなくてはならない. 自身の主張の合意を通すための各関係は以下のとおりとなる. @@ -70,8 +77,21 @@ 上記のように3種類の関係も主張の合意状態に影響を与える. 実際にどのように主張が立てられて合意がなされていくのか簡単なシナリオを -記述した図を\ref{fig:tomodel2}に示す. +記述して示したものが図\ref{fig:tomodel2}となる. +図\ref{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} @@ -83,9 +103,8 @@ - +\subsection{時系列ごとにみられる合意状況} -\subsection{時系列ごとにみられる合意状況}