利用者（ユーザー）についての情報。権限情報（鍵側）の集まりでしかない。
ユースケースクラスでの権限判定に使われるくらい。
実体は利用者を表すページ。それをラッピングしたのが利用者クラス。
実体は利用者を表すページ。それをラッピングしたのが利用者クラス。このページを作れば利用者登録になるし、SisterWikiなどで参照可能になったユーザーはログイン可能。→ X/User[?]
と、利用者の役に立つような機能のためのデータ集。
と、ページの作成者としての役目。
と、代表見解と投票に関わるもの。
→ :i/利用者クラスの高い依存性[?]
- ログイン／認証
- グループ／ロール
- 権限（鍵）
- 利用者情報を必要とする機能
- 未分類
- :i/ユーザーを個別化するには
- :i/管理アカウントは一般アカウント
- :i/メンテナンス要員
- :i/管理者は誰かという定義をページで
- :i/情報はページに
- :i/ページのauthor属性
- :i/投稿時の自動署名はない
- :i/ページ/属性/作成者
- :i/追加のみと書き換えの権限を分ける
- :i/著作権に基づいた権限設定
- :i/自分のサイトへトラックバック送信
- :i/利用者ページの見られ方
- :i/利用者名はニックネーム
- :i/利用者ページに書くこと
- :i/ロール別のビュー
- :i/利用者を何と結び付けるか
- :i/利用者をグループでまとめる[?]
- :i/オープン認証ではユーザーIDにサイトドメイン追加
- :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
- :i/アンケートは自分のページに回答を書く
- :i/アカウント削除予約
- :i/おかえりなさいメール
- :i/Wiki構築には2つの側面がある
- 利用者/
- tag:利用者
みんな最初はゲスト（お客様）。ゲストが認証（ログイン）を経て特定の利用者インスタンスと結び付く。
:Done/アカウントにロールは要らない[?] † 
- ログイン／認証
- グループ／ロール
- 権限（鍵）
- 利用者情報を必要とする機能
- 未分類
- :i/ユーザーを個別化するには
- :i/管理アカウントは一般アカウント
- :i/メンテナンス要員
- :i/管理者は誰かという定義をページで
- :i/情報はページに
- :i/ページのauthor属性
- :i/投稿時の自動署名はない
- :i/ページ/属性/作成者
- :i/追加のみと書き換えの権限を分ける
- :i/著作権に基づいた権限設定
- :i/自分のサイトへトラックバック送信
- :i/利用者ページの見られ方
- :i/利用者名はニックネーム
- :i/利用者ページに書くこと
- :i/ロール別のビュー
- :i/利用者を何と結び付けるか
- :i/利用者をグループでまとめる[?]
- :i/オープン認証ではユーザーIDにサイトドメイン追加
- :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
- :i/アンケートは自分のページに回答を書く
- :i/アカウント削除予約
- :i/おかえりなさいメール
- :i/Wiki構築には2つの側面がある
- 利用者/
- tag:利用者
ログイン／認証 †
:i/ビルトインユーザー †
グループ／ロール †
:/アカウントにロールは要らない †
利用者を上位ページでまとめればロールにあたる仕組みが不要。
:i/利用者をグループでまとめる[?] †
ページ/属性/継承を使ってグループ内メンバー全員の権限を設定。
:i/利用者のロールといえば †
（デフォルトで用意する）グループの候補に。
:i/ロールと権限の違い †
（デフォルトで用意する）グループの候補に。
:i/下位ロールを作れるロール[?] †
Wikiを構築するために。運用でロール作成。
権限（鍵） †
利用者情報を必要とする機能 †
要するにカスタマイズ。
:i/検索履歴 †
:Done/ユーザーページではなくワークスペース †
…を明確に表現する呼び方は？
未分類 †
:i/ユーザーを個別化するには †
アクティビティの収集など。個別化は自動的なカスタマイズにもなる。利便性向上に。
:i/管理アカウントは一般アカウント †
多重ログイン。複数セッション。
Atlassian Confluenceはこうなっている。
:i/メンテナンス要員 †
詳しい人を招いたときのロール。
:i/管理者は誰かという定義をページで †
最初の管理者はどう決めるか。管理者というより所有者（オーナー）を定義。
:i/情報はページに †
ページはデータベース。利用者もページ/要素と同じ方法で情報を記録。ページ/要素は要素間連携と同じ方法で利用者情報を参照できることになる。
:i/ページのauthor属性 †
セマンティックなWikiのために。TwitterCardsをURIあたり1つしか付けられないのなら、最優秀功労者を決めないと。その方法は？
→共著も表現できるはず。
:i/投稿時の自動署名はない †
投稿時のコメント欄（MediaWikiのような）があれば自動署名もあり。
:i/ページ/属性/作成者 †
利用者IDはページに記録される。どのページのどの版にも1つ。
:i/追加のみと書き換えの権限を分ける †
権限は雑多。重複がある。個別に考えなければならないし、判定は個別のコードで行なわないと。
:i/著作権に基づいた権限設定 †
権限のコンセプト。権限とはドキュメントに関する権利を守るためのもの。
:i/自分のサイトへトラックバック送信 †
利用者情報に「トラックバック先」。他にもTwitterアカウントとかあってもいいかも。
Twitterとの連携でリプライの連鎖をwikiに取り込むTogetterクローンみたいな機能を使えるなら、発言はTwitter側でもwiki側でもいいことになる。
:i/利用者ページの見られ方 †
見られ方=見解。利用者の見られ方（側面、インターフェイス）といえばロール。利用者は複数のロールに属せるし、ロールは周囲から期待される役目のこと。利用者ページの見られ方=見解として良さそう。
でも見解は他の見解を隠すためのもの。
側面は見る側が選ぶというのは星。
多くの人か選んだ見解がゲスト向けのデフォルト見解になるというのも星。
見解ごとにそのロールで役立つような機能やフォーム（管理者なら連絡用フォームとか）を用意しておけば有意義。
:i/利用者名はニックネーム †
利用者情報に「利用者名」または「ニックネーム」を設けて。Twitterでのdisplay_nameになるのはニックネーム？ID？IDは認証に使ったサイト名を含んでいる。
†:i/OAuth+ID+表示名
→重複していいので利用者自身が自由に設定。一部でもシステムが決めるのなら非公開に。本人が決めたものではないので。
:i/利用者ページに書くこと †
設計のコンセプト。利用者ページのページ/裏のほうはシステムが書き込むものなので設定項目用かも。
:i/ロール別のビュー †
利用者を分けたときの一番の効果。モード変更なので、他のロールと切り替えて（例えば閲覧者と編集者）使用できないと。切り替えするのは利用者自身。
実装方法は…
†:i/二重ログイン可能[?]
†:i/パスワードを複数設定
ログイン／ログアウトだけ？切り替えUIは不要？
→ログイン後のログインで。途中のログアウトは不要。
:i/利用者を何と結び付けるか †
認証方法の考え方。既存の所有権と関連付けることが認証。
:i/利用者をグループでまとめる[?] †
†:i/ロールと権限の違い
†:i/利用者のロールといえば
†:/ロールをページ化、利用者を下位ページ化
まとめて管理。まとめて権限設定。設定時に権限を要するがまとめておけば利用者ページごとの権限判定にはならない。判定対象はグループページと管理者の間だけ。
†:Done/属性継承時の権限判定は？
:i/オープン認証ではユーザーIDにサイトドメイン追加 †
アカウントの区別に。IDをグローバルなものにする。
このグローバルなIDは何度アカウントを作り直しても再利用できなければならない。WikiでのIDは使い捨て（再利用しようとすると二世になる）。ここにずれは生じないか？
†:i/アカウント削除予約
:i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク †
フレームワークを分けてはいけない例。基礎は使われて当然なので、フレームワーク/WikiEngine側とみなしていいかも。
:i/アンケートは自分のページに回答を書く †
利用法。他人のための権限設定とページ名。大勢を対象にしてそれを行うには？権限設定とページ名はかみ合ってなくてはならない。
:i/アカウント削除予約 †
ページの削除と同じ。ページが消えれば利用者情報も消える。
:i/おかえりなさいメール †
「たまには来てよねメール」も。メールアドレスの登録が残っていることを警告しながら存在確認。
:i/Wiki構築には2つの側面がある †
管理者向けの説明にはコンテンツに応じたシステムの使い方を。