「ハイパーメディア・アプリケーションをどう捉えればいいのか」において次のように書きました。
以上のような枠組みを使って状態遷移系を構成しているソフトウェアを、ハイパーメディア・アプリケーションと呼びたいと思います。この枠組みには、直接にはHTTPもURLも登場していません。しかし、実際上はWebシステムになることがほとんどでしょう。
現状において、ハイパーメディア・アプリケーションの大多数はWebシステムとして実現されています。これは否定しがたい事実です。しかし、だからといって「ハイパーメディア・アプリケーションがWebなしでは成立しない」というわけではありません。実際、World Wide Web の登場以前にもローカルで動くデスクトップ・スタイルのハイパーメディア・アプリケーションはありました（たぶん、今でもあるでしょう）。HTTPもURLも、ハイパーメディア・アプリケーションを実現する一手段に過ぎません。
まー、「実現する一手段」と言ってみても他の手段を利用しているケースがほとんど見当たらないので、「Webありき」の発想になってしまうのも仕方ないでしょう。ですが、今後は「Webが（直接は）見えない」ハイパーメディア・アプリケーションが多数派になるかも知れません。今まで「Webアプリケーション」というと、クライアントはWebブラウザーで、URLとHTMLが露骨に表に現れていましたが、HTTP通信をしていることがユーザーには隠蔽されるスタイルのアプリケーションが既にたくさんあります*1。
かつて World Wide Web が存在しなかった時代、ハイパーメディア・アプリケーションはローカルデータ内の小宇宙をナビゲートしていました（百科事典とか学習コースとかがありましたね）。World Wide Web の登場により、小宇宙は広大な宇宙に拡大し、ハイパーメディア・アプリケーションがナビゲートする範囲は全世界規模になりました。Webブラウザーなら、ユーザーはその広大な宇宙内の位置（ロケーション・アドレス）を意識／把握することが出来ます。
「Webが（直接は）見えない」ハイパーメディア・アプリケーションの場合、今見ている情報がローカルデータ由来なのか、インターネットから来たものか、ユーザーは判別できません。判別する必要もありません。その場合でも、「今見ている情報」から「次に見たい情報」へのナビゲーションは存在します。ユーザーとソフトウェアのインタラクションの構造は存在します。
インタラクションの構造の“良し悪し”の評価に絶対的な基準はありませんが、ある程度は評価可能でしょう。であるなら、「良いインタラクションの構造を設計しよう」という目標が生まれます。インタラクションの構造を、ハイパーメディアを利用して実現しようとすれば、「次に見たい情報」へのナビゲーションが問題になります。「次に見たい情報」はローカルにあるかも知れません； Webに取りに行く必要があるかも知れません。情報を「どんな方法でどこに取りに行くか」もアプリケーション設計のファクターになるでしょう。一方で、どんな方法でどこに取りに行こうが満たすべき要件もあるでしょう。
「ハイパーメディア・アプリケーションにおける「サバー vs. クライアント」の問題」で抽象的に述べた「問題設定」を、以上のような背景のもとでもう一度説明すると：
- 一連のインタラクションのなかで、ユーザーが経験する可能性があるすべての状態の集合がCです*2。
- ある状態において、ユーザーがなんらかの行為をすることにより起きる状態の移り変わりは、t:C→C で記述されます*3。
- その状態遷移（の一部）を、サーバーとの通信（リクエストqとレスポンスr）で実現するにはどうしたらいいでしょう。
ローカルデータを併用するようなハイパーメディア・アプリケーションでは、Webへのアクセス（リクエストqとレスポンスr）はとても少なくて、t:C→C の大部分がWebと無関係に実行されることもあるでしょう。そのような場合でも、「今見ている情報」から「次に見たい情報」へのナビゲーションの契機をハイパーリンクと呼んでもいいだろう、と僕は思います。
「そんな拡大解釈は許さん」というご意見もあるでしょうが、それは言葉の定義と使い方の議論となります。ソフトウェア的メカニズムとはまったく別な話題です。
実は、なんかめんどくさいから、「ハイパーリンク」の拡大解釈はやめようかと思います。となると、「ハイパー遷移」とか何か新しい用語を割り当てる必要があって、また頭が痛いですけどね。「クライアント状態」という言葉も、「対話状態」とか言ったほうが誤解が少ない気もします。「対話過程の一時点*4を表現する」以外にも、（概念的には）クライアントが保持すべき可変データはありますから。
余談：
ユーザーが経験する可能性がある状態遷移の時系列は、状態空間のパスとなります。「パス」という用語はやたらに多義的なので、僕は力学っぽい用語である軌道（trajectory）を使っています。可能な軌道の集合は、状態遷移系の振る舞いを完全に記述します。ソフトウェアシステムの意味を「軌道の集合」だとみなす意味論がありますが、このスタイルの意味論は、対話的なソフトウェアには向いていると思います。
ハイパーメディア・アプリケーションに“軌道集合”意味論を適用しようとすると、軌道が乗る状態空間が必要です。その状態空間は、ユーザー（アクター）が直接認識可能な状態の全体であるべきだ、と思います。それゆえに、サーバーとは切り離した「対話過程を記述するための表象としての状態」という概念をプライマリーなものと位置付けたいのです*5。
