メモ (2019-06-01 カニチャット Cindychat で) クリックでオープン
はやて◆
現在Cindyにアクセスできないので、ここでメモ：
ラテシン本家問題を使用します：http://sui-hei.net/mondai/show/1 2019/06/01 19:57
はやて◆
kuromoji.js で問題文を形態素解析した結果です 2019/06/01 19:58
はやて◆
1 * 1 レストラン 1 一 1 勘定
1 口 1 呼ぶ 1 帰宅 1 彼
1 後 1 止める 1 注文 1 海
1 済ませる 1 自殺 1 見える 1 間違い
1 飲む 2 男 4 する 4 ウミガメ
6 スープ 2019/06/01 20:00
はやて◆
（名詞と動詞のみ摘出） 2019/06/01 20:01
はやて◆
以下は質問の結果 2019/06/01 20:03
はやて◆
１ 海 見える レストラン 選ぶ こと 男 自殺 する こと 関係 ある
２ 男 自殺 する 理由 ウミガメ スープ 飲む こと 原因
３ 男 借金 抱える いる
４ 男 自殺 する の スープ 飲む こと 原因
５ 話 現実 的 要素 含む れる
６ 死因 関係 ある 2019/06/01 20:07
はやて◆
７ 男 過去 何 ある
８ 過去 ウミガメ スープ 食べる 事 ある
９ 過去 食べる もの ウミガメ スープ 勘違い する いる
１０ 男 職業 船乗り
はやて◆
１１ 男 過去 遭難
１２ 物語 死人 でる くる
１３ 男 過去 遭難 飢える ため 人 食べる
１４ 他 乗組 員 ウミガメ スープ 言う れる 食べる
１５ 男 遭難 中 ウミガメ スープ 言う れる 食べる スープ 味 レストラン ウミガメ スープ 味 違う 事 遭難 中 食べる モノ 人 こと 気づく 絶望 する 2019/06/01 20:11
はやて◆
で、すべての問題と質問に出る単語を数えた結果です： 2019/06/01 20:13
はやて◆
('男', 9), ('スープ', 9), ('ウミガメ', 7), ('する', 6), ('食べる', 6), ('こと', 5), ('自殺', 4),
('ある', 4), ('過去', 4), ('飲む', 3), ('れる', 3), ('遭難', 3), ('海', 2), ('見える', 2),
('レストラン', 2), ('関係', 2), ('原因', 2), ('いる', 2), ('事', 2), ('人', 2), ('言う', 2),
('中', 2), ('味', 2), ('一', 1), ('勘定', 1), ('口', 1), ('呼ぶ', 1), ('帰宅', 1), ('彼', 1),
('後', 1), ('止める', 1), ('注文', 1), ('済ませる', 1), ('間違い', 1) 2019/06/01 20:15
はやて◆
('選ぶ', 1), ('理由', 1), ('借金', 1), ('抱える', 1), ('の', 1), ('話', 1), ('現実', 1), ('的', 1),
('要素', 1), ('含む', 1), ('死因', 1), ('何', 1), ('もの', 1), ('勘違い', 1), ('職業', 1),
('船乗り', 1), ('飢える', 1), ('ため', 1), ('他', 1), ('乗組', 1), ('員', 1),
('違う', 1), ('モノ', 1), ('気づく', 1), ('絶望', 1) 2019/06/01 20:16
はやて◆
問題リプレイ機能を作るなら、出現数が１以上の名詞・動詞を選んだほうがいいかな？ 2019/06/01 20:19
はやて◆
で、最初に出現されたキーワードリストはこうなる：
男 過去 他 海 話 死因
男を選んだ場合、二番目のキーワード：
自殺 借金 職業 過去 遭難 2019/06/01 20:21
はやて◆
遭難という単語が唐突だから、質問１０出る前に隠したほうが良いかな（質問１０依存キーワード） 2019/06/01 20:23
はやて◆
となると、プロポーザルに書かれている「問題文に出現したキーワードだけ最初のキーワードにする」というのは無意味になるね。「死因」は問題文に出ないけど、「自殺」を見て自然に思いつく言葉だし。 2019/06/01 20:26メモ (2019-06-02 カニチャット Cindychat で) クリックでオープン
はやて◆
「ウミガメ」と「スープ」を合併し、「ウミガメのスープ」キーワードを生成して、
それからキーワード「男」「ウミガメのスープ」「人」「食べる」
「自殺」「過去」「借金」「遭難」
「海」「レストラン」「関係」「原因」
「味」「注文」「現実」「重要」「職業」「死」
を選択した結果 2019/06/02 15:26
はやて◆
１ レストラン 男 自殺 関係
２ 男 自殺 ウミガメのスープ 原因
３ 男 借金
４ 男 自殺 原因
５ 現実
６ 死因 関係
７ 男 過去
８ 過去 ウミガメのスープ 食べる 2019/06/02 15:28
はやて◆
９ 過去 食べる ウミガメのスープ
１０ 男 職業
１１ 男 過去 遭難
１２
１３ 男 過去 遭難 人 食べる
１４ ウミガメのスープ 食べる
１５ 男 遭難 ウミガメのスープ 食べる レストラン ウミガメのスープ 遭難 食べる 人 2019/06/02 15:32
はやて◆
少し編集が必要になるね 2019/06/02 15:34
はやて◆
１OK レストラン 男 自殺 関係 → 「海の見えるレストラン」を選んだことは、男が自殺したことと関係がありますか？
２OK 男 自殺 ウミガメのスープ 原因 → 男が自殺した理由は、ウミガメのスープを飲んだことが原因ですか？
３OK 男 借金 → 男は借金を抱えていますか？
４OK 男 自殺 ウミガメのスープ 原因 → 男が自殺したのはスープを飲んだことが原因ですか？
５OK 現実 → この話に非現実的要素は含まれますか？
６EDIT男 死因 重要 → 男の死因は重要ですか？ （元：死因は関係ありますか？）
７OK 男 過去 → 男は過去に何かありましたか？
８＋ (+男) 過去 ウミガメのスープ 食べる → 過去にウミガメのスープを食べた事はある？ 2019/06/02 15:39
はやて◆
９OK？ 過去 食べる ウミガメのスープ → 過去に食べたものをウミガメのスープと勘違いしていた？
１０OK 男 職業 → 男の職業は船乗り？
１１OK 男 過去 遭難 → 男は過去に遭難した？
１２＋ (+人) (+死) → この物語で、男以外の死人がでますか？
１３OK 男 過去 遭難 人 食べる → 男は、過去に遭難で飢えたために人を食べた？
１４＋ (+男) ウミガメのスープ (+人) 食べる → 他の乗組員にウミガメのスープと言われ(+人を)食べた？
１５DEL 男 遭難 ウミガメのスープ 食べる レストラン ウミガメのスープ 遭難 食べる 人 2019/06/02 15:44作成必要なコンポーネント(開発用メモ 難しいことばかり書いてる) クリックでオープン
### 出題画面
#### ワークベンチ
1. キーワード編集ワークベンチ。キーワードの合併、リネーム、選出など。
1. リスト型問題編集ワークベンチ。実装は易いけど、特に問題が多い時は少し不便です。実験中に実装できます。フィルタリング機能とソート機能は工夫する必要がありそうだ。
- フィルタリング（質問内容、回答内容、キーワード、キーワードの位置）
- 質問のキーワード編集。キーワード追加、削除、位置の移動など。
- 質問（および回答）の編集、追加（基礎質のヒントあり）、削除など。
1. グラフ型問題編集ワークベンチ。（実装は遅くなる）
- キーワードツリー（画像を参照）
- 質問依存ツリー（２つのモード。ひとつは質問に依存する質問を編集するモード。もうひとつは質問が依存する質問を編集するモード）
#### キーワード自動的に選ぶフェイズ
1. 形態素解析して、キーワードを摘出する関数
1. どんな形態の単語を使用するパネル（デフォルト：名詞と動詞。変更は非推奨ですが、一応作る必要はあると思う）
1. キーワード出現数フィルター（または Tf-Idf に基づいたフィルター？）
1. キーワード依存ツリーを、回答文のキーワードに基づいて、自動的に生成する関数
1. 問題に使うキーワードを選定する。
このフェイズでキーワードを変更した場合、すべての質問に適用することになる。
キーワード操作フェイスになると、一つの質問に適用することになる。誤操作で変更点を上書きすることを防ぐため、このフェイズに戻ることはできない。
#### キーワード操作フェイズ
1. キーワード調整パネル（基本的はグローバルでキーワードを調整し、全ての質問に適用する機能）
- キーワードを合併される機能：男＋カメオ→カメオ
- キーワードを合併される機能（上と同じ？）：ウミガメ＋スープ→ウミガメのスープ
- キーワードを編集する機能（編集したキーワードはすべての質問に適用する）：男→カメオ
- キーワードを削除する機能
1. 質問調整パネル
- 質問のフィルタリング
- 質問の追加、編集または削除
- 質問のキーワードを変更する（追加または削除）機能
- キーワードが重複の質問をハイライト表示
1. ヒント調整パネル
- ヒントの追加、編集または削除
1. キーワード依存ツリーを調整するパネル
- キーワードを指定された質問に依存するように調整できる
### 質問画面
1. 質問キーワード選択のパネル
1. 質問状況をサーバーにアップロードし、コンティニューできるようにする機能
1. ヒントを見るボタン ヒント見るにはひらめきコインが必要とか？
1. 諦めてそのまま解説を見るボタン？ヒントのX番目をほぼ解説にする？
### その他
#### データベースデザインについてgraphql schema
One option is to use pure sql database:
```graphql
type Replay {
id: Int!
puzzle: Puzzle
user: User!
created_at: Timestamp!
updated_at: Timestamp!
#dialogues: [ReplayDialogue]
}
type ReplayKeyword {
id: Int!
keyword: String!
}
type ReplayDialogue {
id: Int!
replay_id: Int!
#replay: Replay!
question: String!
answer: String!
#depends_on: [ReplayQuestion]
#keywords: [ReplayKeyword]!
}
type ReplayDialogueDependency {
id: Int!
dialogue_id: Int!
#dialogue: ReplayDialogue!
depends_on_id: Int!
#depends_on: ReplayDialogue!
}
type ReplayDialogueKeyword {
id: Int!
dialogue_id: Int!
#dialogue: ReplayDialogue!
keyword_id: Int!
#keyword: ReplayKeyword!
}
type ReplayPlaygroundDialogue {
id: Int!
dialogue_id: Int!
#dialogue: ReplayDialogue!
playground_id: Int!
#playground: ReplayPlayground!
created_at: Timestamp!
}
type ReplayPlayground {
id: Int!
status: Int! # Whether the replay is finished for the current user.
created_at: Timestamp!
updated_at: Timestamp!
#dialogues: [ReplayPlaygroundDialogue]
#replay: Replay!
replay_id: Int!
#user: User!
user_id: Int!
}
```
Another option is to store keywords and questions in json fields.
```graphql
type Replay {
id: Int!
puzzle: Puzzle
user: User!
questions: Json!
created_at: Timestamp!
updated_at: Timestamp!
}
type ReplayPlayground {
id: Int!
replay: Replay!
user: User!
status: Int! # Whether the replay is finished for the current user.
data: Json!
}
```
画像のソースコード
@startuml
object Replay {
id: Int!
puzzle_id: Int
user_id: Int!
created_at: Timestamp!
updated_at: Timestamp!
}
object ReplayDialogue {
id: Int!
replay_id: Int!
question: String!
answer: String!
}
Replay "1" -- "0..n" ReplayDialogue
ReplayDialogue "0..n" -- "0..n" ReplayDialogue : ReplayDialogueDependency
object ReplayKeyword {
id: Int!
keyword: String!
}
ReplayDialogue "0..n" -- "0..n" ReplayKeyword : ReplayDialogueKeyword
object ReplayPlayground {
id: Int!
replay_id: Int!
user_id: Int!
status: Int!
created_at: Timestamp!
updated_at: Timestamp!
}
ReplayPlayground "0..n" -- "1" Replay
object ReplayPlaygroundDialogue {
id: Int!
dialogue_id: Int!
playground_id: Int!
created_at: Timestamp!
}
ReplayPlaygroundDialogue "0..n" -- "1" ReplayPlayground
ReplayPlaygroundDialogue "0..n" -- "1" ReplayDialogue
@enduml
#### キーワードツリーのデザインについて
暫定 react-d3-tree のフォーク＋react-dnd でツリー生成及びドラッグドロップ機能実現をします。
上記画像のコード（planetumlでコンパイルしてください）
@startmindmap * Root ** レストラン *** 男 **** 自殺 ***** 関係 ****** 「海の見えるレストラン」を選んだことは、男が自殺したことと関係がありますか？ ** 男 *** 自殺 **** ウミガメのスープ ***** 原因 ****** 男が自殺した理由は、ウミガメのスープを飲んだことが原因ですか？ ****** 男が自殺したのはスープを飲んだことが原因ですか？ ***** 人 ****** 食べる ******* 他の乗組員にウミガメのスープと言われ人を食べた？ *** 借金 **** 男は借金を抱えていますか *** 死因 **** 重要 ***** 男の死因は重要ですか？ *** 過去 **** 男は過去に何かありましたか？ **** ウミガメのスープ ***** 食べる ****** 過去にウミガメのスープを食べた事はある？ **** 遭難 ***** 人 ****** 食べる ******* 男は、過去に遭難で飢えたために人を食べた？ *** 職業 **** 男の職業は船乗り？ ** 現実 *** この話に非現実的要素は含まれますか？ ** 過去 *** 食べる **** ウミガメのスープ ***** 過去にウミガメのスープを食べた事はある？ ** 人 *** 死 **** この物語で、男以外の死人がでますか？ @endmindmap
2019 年 6 月 16 日追記（クリックで開く）
３８０問の問題を元にテストしましたが、予想以上に重かったのです。
そこで出題する流れを変えたいと思います。
＝＝＝＝＝＝＝＝＝
キーワード選出パネル（選択前）
＝＝＝＝＝＝＝＝＝
｜男｜レストラン｜・・・｜
＝＝＝＝＝＝＝＝＝
キーワード選出パネル（選択後）
＝＝＝＝＝＝＝＝＝
｜男｜レストラン｜・・・｜
｜ 変更点 ｜
｜1. 男は自殺しましたか？ 男 自殺 「変更する」｜
｜2. 男の職業は船員ですか？ 男 職業 船員 「変更する」｜
｜「すべて変更する」｜
キーワード合併パネルとキーワード編集パネルが上と同様、キーワードボタンと変更点２つの部分を含みます。
＝＝＝＝＝＝＝＝＝
質問個別編集パネル
＝＝＝＝＝＝＝＝＝
１．男は自殺しましたか？ 「男/」「自殺/」「＋」「ー」
２．ウミガメのスープはまずかったですか？ 「ウミガメ/」「スープ/」「＋」「ー」
ー：ゴミ箱アイコン
/ ：鉛筆アイコン
説明：キーワードを他のキーワードにドラッグすると位置移動、ゴミ箱にドラッグすると削除、＋ボタン押すとキーワード追加、鉛筆アイコン押すとキーワード編集
＝＝＝＝＝＝＝＝＝
質問依存編集パネル（提案１）
＝＝＝＝＝＝＝＝＝
｜依存される質問｜依存する質問｜
｜ー｜ー｜
｜[ ] 質問＆回答｜[ ] 質問｜
｜[x] 質問＆回答｜[ ] 質問｜
｜[ ] 質問＆回答｜[ ] 質問｜
｜[ ] 質問＆回答｜[ ] 質問｜
｜「すべて選択・解除」｜「すべて選択・解除」｜
｜キーワードに基づいて依存する質問を追加するアドバイスを展示｜依存される質問を追加するアドバイスを展示｜
＝＝＝＝＝＝＝＝＝＝
質問依存一覧パネル（依存する質問リスト）（提案１）
＝＝＝＝＝＝＝＝＝＝
- 男は自殺しましたか？
- 男の職業は船員ですか？
＞男は海で遭難しましたか？
＞男は海でウミガメのスープを飲みましたか？
＝＝＝＝＝＝＝＝＝
質問依存編集パネル（タグ追加パネル）（提案２）
＝＝＝＝＝＝＝＝＝
- 男は自殺しましたか？ YES
タグ：自殺
- 男の職業は船員ですか？
タグ：船員
- 男は海で遭難しましたか？
タグ：遭難
＝＝＝＝＝＝＝＝＝
質問依存編集パネル（タグ依存パネル）（提案２）
＝＝＝＝＝＝＝＝＝
- 男は自殺しましたか？ YES
タグ依存：
- 男の職業は船員ですか？
タグ依存：
- 男は海で遭難しましたか？
タグ：船員
説明：
提案１を簡単に説明すると、複数の質問を複数の質問を依存させる時、「依存する質問」と「依存される質問」２つの視点で編集することです。
提案２を簡単に説明すると、質問で得た情報を「タグ」という形式で表現し、「タグ」の情報でどんな質問を出せるかを編集することです。
個人的に提案２がよりわかりやすいと思います。
ただ、提案２の問題点は複数タグがあった場合です。
例（２タグ）：
- 男は海で遭難しましたか？
タグ：船員 海
この場合、２つの分岐があります
- OR：「海」と「船員」どれか一方のタグが出現したらこの質問は展示されます
- AND：「海」と「船員」両方のタグが出現したらこの質問は展示されます
このANDとORをどう組み合わせするか、どうやってUI内で編集するかが一番の問題です。
＝＝＝＝＝＝＝＝＝
ツリー展示パネル
＝＝＝＝＝＝＝＝＝
下記のツリー図を展示する
プレビュー画像(2019-06-05)
コメント
最新を表示する
>> 返信元
計算プログラムのバグかな？（linux の uniq 使ってます）
実際の数は ウミガメ４ スープ４ シェフ１ で間違いありません。
一応テスト用コードを提供します：
細かいことですみません。
kuromoji.jsで問題文を形態素解析した結果を見ていたのですが、疑問点があります。
・「シェフ」がオミットされているのは何故でしょう？
・「ウミガメ」と「スープ」の数は完全一致だと思うのですが、ちょっとズレているのは何故でしょう？
何らかの「重みづけ」があるのでしょうか？
今回の提案は、一応出題済みの問題が対象のシステムです。
ただし、公開していない問題でも、質問と回答をCindyのフォーマットで入力すれば、疑似的に出題済の形にすることは可能です。
それをシステムでリプレイさせるわけですから、要するに問題を考えるのも質問を考えるのも回答を考えるのも解説を考えるのも、みんな自分でやっちゃってリプレイとなれば……これは単なる自動出題システムとほとんど変わらないということになりますね。
ここでDEBONOの管理人さんに対して、礼儀的・著作権的に何かがあるかどうか……
うーん、よくわかりません。（わからないなら書くなという話ですが。）
>> 返信元
はやてさんが考えているのは、どちらかというと「問題作成の補助システム」のような気がします。
現状のDEBONOは完全に人力で問題を作成しているのですが、それを半自動化しちゃおうというのに似ています。
喩えるなら、DEBONOが冷凍庫なら、はやてさんが考えているのは自動製氷システム……いや、これはちょっと違うかな？
つまり、はやてさんのアイディアを丸ごとDEBONOに持っていくと、DEBONOで産業革命が起こりそうだな、と私は思っています。
交流はあるので自然な形の報告はあると思いますが、許可を取るというのはちょっと妙だな、と思いました。
私の認識が間違っていたら御指摘下さい。
>> 返信元
もちろん、はやてさんが全てのシステムをオリジナルで作るでしょうから、著作権ははやてさんに帰属すると思います。ただ、DEBONOから着想を得たのだったら、連絡をとった方がマナー的にいいのかな〜と思ったり。
全然こういったことに詳しくないので、完全な思いつきで言っています。すみません。
そもそもCindyがラテシンの後継として発足したので、何の問題もないと思いますが、ちょっと気になったのでお聞きしました。
>> 返信元
了解です。なんかおしゃれな名前がつくといいですね！（それまでWIPと仮称しますね〜）
あと、「DEBONO」を例に挙げたので、ちょっと失礼かもしれないですが、お聞きしたいことがあります。
著作権やマナーなどの関係から、この「WIP」を作成するにあたり、「DEBONO」の製作者様に報告をするor許可を取った方がよいでしょうか？
>> 返信元
了解です。質問の追加や編集はできますので、そのときに基礎質のヒントを加えますね。
>> 返信元
①と②＞ 基本は補助型ですね。すべての質問中の２－３割はマニュアルで編集する必要があるのですが、一から作るより便利になるんじゃないかと思います。
質問数の違い（総計２０問のウミガメのスープと、総計５００問の闇スープ）によって問題の複雑性も変わるのではないかと思います。
シミュレーション了解です！ありがとうございます！
PS: WIP は「ワーキング・イン・プロセス」の略で「現在作業中」という意味です。現在「DEBONO」のようなユニークの名をつけていませんｗ
はやてさんお疲れ様です。
これはチュートリアル問題の選定にも使えそうな！
いわゆる基礎質問の概念を導入することについてはいかがですか？
例えば本家ウミガメのスープの場合、重要人物を問う基礎質問はありませんが、「重要人物Yesになったら質問12のキーワードを解放する」という流れが作れます。
よくある基礎質は多数の問題に関わるものだし、問題文のキーワードから組み立てる質問以外の質問として標準装備しておくと、質問数水増しの役割も果たします。
おつかれさまです。実装できたら活気的なシステムですね。
①WIPは、DEBONOのようなリプレイを、システムが完全に作成する機能ですか？（完全自動型）
②WIPは、出題者がDEBONOのようなものを作成するときに、システムが作成を補助する機能ですか？（補助型）
①だとしたら、「問題文の情報量」と、「回答までにかかった質問数のログ」によって、WIPのクオリティが変わるとおもいました。具体的にいえば、「スナイプされた問題」と、「40質問くらいかかった問題」では、リプレイ機能に差はでるのでしょうか？ 最後に、シミュレーションするにあたり、もし必要でしたら、私の問題を遠慮なく使ってください
リクエスト・フォー・コメント
これはDEBONOに比べてすごく複雑な機能になるようですｗ
意見があれば言ってくださいね。実装したあとのデバッグが難しくなるから、できれば実装する前にいろんな状況を考えてほしいです。
逆に意見がなければ途中でやめそうだｗ
NG表示方式
NGID一覧