利用者

利用者（ユーザー）についての情報。権限情報（鍵側）の集まりでしかない。
ユースケースクラスでの権限判定に使われるくらい。
実体は利用者を表すページ。それをラッピングしたのが利用者クラス。このページを作れば利用者登録になるし、SisterWikiなどで参照可能になったユーザーはログイン可能。→ X/User[?]

と、利用者の役に立つような機能のためのデータ集。
と、ページの作成者としての役目。
と、代表見解と投票に関わるもの。
→ :/利用者クラスの高い依存性

利用者と権限を結び付ける際、引数の形式を考えるのが面倒なので、利用者をVisitorとしてページに渡す（コントロールクラスが）。で、ページから利用者を参照、利用者をたらい回し。

みんな最初はゲスト（お客様）。ゲストが認証（ログイン）を経て特定の利用者インスタンスと結び付く。

ログイン／認証
1. :i/ビルトインユーザー
グループ／ロール
権限（鍵）
利用者情報を必要とする機能
1. :i/検索履歴
2. :Done/ユーザーページではなくワークスペース
未分類
利用者/

ログイン／認証 †

:i/ビルトインユーザー †

グループ／ロール †

:/アカウントにロールは要らない †

利用者を上位ページでまとめればロールにあたる仕組みが不要。

:i/利用者をグループでまとめる[?] †

ページ/属性/継承を使ってグループ内メンバー全員の権限を設定。

:i/利用者のロールといえば †

（デフォルトで用意する）グループの候補に。

:i/ロールと権限の違い †

（デフォルトで用意する）グループの候補に。

:i/下位ロールを作れるロール[?] †

Wikiを構築するために。運用でロール作成。

権限（鍵） †

利用者情報を必要とする機能 †

要するにカスタマイズ。

:i/検索履歴 †

:Done/ユーザーページではなくワークスペース †

利用者が自分用に使うページ群（下位ページ含めて）ということ
これを作ることが参加／ユーザー登録になるということ

…を明確に表現する呼び方は？

「（利用者名）のワークスペース」
~~「（利用者名）のためのWiki」~~
~~「（利用者名）の作業用Wiki」~~
~~「（利用者名）の居場所」~~
~~「（利用者名）」~~

未分類 †

: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/利用者ページの見られ方 †

見られ方=見解。利用者の見られ方（側面、インターフェイス）といえばロール。利用者は複数のロールに属せるし、ロールは周囲から期待される役目のこと。利用者ページの見られ方=見解として良さそう。
でも見解は他の見解を隠すためのもの。~~汎用性がない。~~→「他を隠す」というより「代表的なものがある」と考えると問題ない。