「ハイパーリンクは何を繋ぐのか」と「ハイパーリンク設計をサーバーサイド設計に従属させるべきではない」では、既存の用語を使い、ある程度は現実っぽい例を出したりして説明をしました。
このようなスタイルの説明は諸刃の剣です。具体的で分かりやすく感じる反面、夾雑物〈きょうざつぶつ〉をイッパイ含んでいるので誤解と祖語齟齬のタネが満載。誤解と祖語齟齬を減らすには：
- 既存の用語を使わない。（新しい言葉を造るか、既存用語の意味をリセットしてから使う。）
- 抽象的な定式化をする。
当然に、これはこれで問題があるわけです。そもそも、聞き慣れない言葉を使い抽象的に語れば、興味を持つ人が誰もいなくなります（正確には、極端に少なくなる）。
まー、自分用のまとめと思って書いておきます。「ハイパーメディア・アプリケーションをどう捉えればいいのか」の後半で抽象的な定式化は書いておいたのですが、もう少し簡略化します。
前提となること
片方向の有向二部グラフ、または集合のあいだの関係については知っているとします。この2つの概念は同じものなので、どっちか片方を知っていれば十分です。一般的な有向グラフが、頂点集合を状態空間、有向辺を遷移とする状態遷移系（オートマトン）を表現しているという事実も前提します。辺ラベルが入力値（入力記号）ですが、ラベルがないときは入力値の集合が自明（シングルトン）だと解釈できます。
状態遷移系を考えたいのですが、話を簡単にするために、入力値の集合はシングルトンだとして、明示的に入力を考えることはしません。したがって、状態遷移系はラベルなしの有向グラフで記述できます。この状況で、Xが状態空間なら、有向辺＝遷移の集合tは X×X の部分集合です。t⊆X×X、これはtがX上の二項関係であることです。二項関係は、X×X 上で定義されたブール値の関数（特性関数）ともみなされるので、tはブール値係数の正方行列ともいえます。そしてその行列は、遷移グラフの隣接行列です。
有向二部グラフ
CとSを集合とします。気持ちとしては、「C」はクライアントのC、「S」はサーバーのSです。あくまで気持ちですが、集合Cはクライアント側の状態の全体で、集合Sはサーバーにアクセスするときのエンドポイントの全体です。CとSに共通部分はないとします。
頂点集合が C∪S である有向グラフで、辺の始点が必ずC内にあり、終点がS内にあるようなものを考えます。これは二部グラフですが、辺の方向性が C→S となっています。このような二部グラフは C×S の部分集合と同一視できるので、集合CとSのあいだの関係とも言えます。
今説明したような二部グラフqがあるとき、q:C→S と書きます。この書き方は単なる符丁だと思ってもいいし、関係圏の射だと解釈してもかまいません。qは、S行C列のブール値行列で表現できることにも注意してください。
qと逆の方向の有向二部グラフ s:S→C も考えます。sに属する辺の始点はS内、終点はC内にあります。
qの辺は、「ハイパーメディア・アプリケーションをどう捉えればいいのか」において「半遷移」と呼んだものです。正確には前半の半遷移です。sの辺が後半の半遷移を与えます。気持ちとしては、qがリクエスト、sがレスポンスです。気持ちですけどね。
構成される2つの有向グラフ
q:C→S と s:S→C があるとき、qの辺とsの辺をこの順で繋いでパイパスすれば、C→C という有向グラフができます。q, s を関係または行列と解釈するなら、この操作は“関係の結合（composition）”または“行列の掛け算”です。矢印の方向と同じ順序（diagrammatic order）でqとsを併置して q;s:C→C と書くことにします。記号「;」が結合または掛け算を表します。
「qの辺とsの辺をこの順で繋いでパイパスして」出来た有向グラフ q;s は、集合Cを頂点集合とする有向グラフです。つまり、（入力集合は自明な）状態空間C上の状態遷移系です。
同様にして、「sの辺とqの辺をこの順で繋いでパイパスして」出来た有向グラフ s;q は、状態空間S上の状態遷移系とみなせます。が、僕の気持ちとしては、こっちは単に有向グラフです（状態遷移系の表現という意味はない）。
気持ちとしては（と、前置きするのがシツコイけど）、C上の状態遷移系 q;s は、クライアント側に構成されるインタラクションの構造であり、S上の有向グラフ s;q は、サーバー側が公開しているエンドポイントのあいだの接続性です。
どういう問題を解くべきなのか
q:C→S と s:S→C が与えられたとき、q;s と s;q を求めることは単なる機械的計算問題で特に面白くはありません。
次の形をした問題は、もっと面白く意味があるように思えます。
- given: t:C→C という有向グラフ（関係、正方行列と解釈してもいい）
- find: q:C→S と s:S→C という片方向有向二部グラフ（関係、行列と解釈してもいい）
- condition: q;s = t
先に、t:C→C という形で、クライアント側のインタラクションの構造が与えられます。これが実現すべき目標です。「tを構成するために、適切な q, s を探しなさい」が問題の本質です。この問題の解は一意的ではないし、qだけ、sだけでは解答になりません。
qとsが求まれば、s;q:S→S も決まります。しかし、u:S→S を与えて、「u = s;q となる s, q を求めなさい」という問題設定はなんか違うんじゃないか、ということがここ最近僕が言っている事の実質的な内容です。
[追記]「u = s;q となる s, q を求めなさい」という問題設定をしている人がホントにいるかどうか分からないので、これは仮想的相手に対する仮想的批判です。僕自身は「クライアント側のインタラクションの構造」が求めるべきものであり、「サーバー側が公開しているエンドポイントのあいだの接続性」は副次的に、あるいは手段として得られるものだと捉えています -- これは事実です。[/追記]
