UNIXシステムの特徴として単一のファイルシステムと多数のプロセスが強調して動作していることが挙げられる。

単一のファイルシステムはリソースの一元管理を可能とする。
ただし、UNIXのファイルシステムの欠陥として全ての資源が等価に扱われてしまうという欠陥を持つ。
恒久的なデータと一時的なデータは分離して保存されるべきであり、システム更新時または置換時にどのデータが恒久的なものか一時的なものかが判断できない状況となってしまう欠陥を持つ。
その点は、一時的なデータを/tmpディレクトリに置くことによって回避している側面を持つ。
これまでの技術ではネットワークの物理制限によってリソースの移動が制限されてきた関係もあり、本物をトランザクションの名の下で移動してきた経緯を持つが、
UNIXシステムを模倣するシステムを構築するためには
１．ファイルシステムを構築する。
２．複数のプロセスが同時に駆動できる機構を準備する。
必要がある。
ファイルシステムとは数あるリソースを分離するための名前空間の付与の方法であり、

１．一義的な名前の付与規則
２．プロセスに対する一義的なリソースアクセス方法

であるとファイルシステムを定義することが可能である。
これをネットワークシステムに応用したのがURIであり、URIはURLと等価であると思われがちである。
ところがURIの定義中にはURNというものもありこれは場所を特定せずにコンテンツのみを指し示す名前空間である。

また、UNIXシステムはファイルへのアクセス方法をシステムコール一本に絞っており、libc等はシステムコールの組み合わせによってさらに高度なアクセス方法を提供している。

システムコールを一本化することのメリットとしてファイルシステムとライブラリ及びプロセスの動作を分離することができることがあげられる。

分離することにより、ファイルシステムのデバックが容易となり、規定されたシステムコールを以下に早く実装するかに専心すればよいことになる。

つまり、アクセス方法を単純化し資源を一元管理することがシステムとしての見通しをよくすることにつながってきたと考えられるし、UNIX系のOSはファイルシステムに依存した構成でなく、用途に応じ様々なファイルシステムを置換することによって運用されてきた歴史を持つ。

ネットワーク上の大規模システムを構築するに当たり、以上の点に留意しアクセス方法を単純化したネットワークファイルシステムを提供することがひとつの命題として挙げられる。

また、ネットワーク上の協調作業としてよく問題になるのはアクセスコントロール及び版管理である

これらの作業は多種多様に生成されるデータのうちいったいどれが自分の要求する正しいデータであるのかがわからない点により発生した機能であると考えられる。

アクセスコントロールは誰がそのデータは修正及び参照できるかを規定する機能であり、
修正の点では重要なデータを失う可能性を包含するため、アクセスコントロールの機能を実装するためにLDAP、ACL等の機能が実装されてきたといってもかまわない。

版管理機能の方は、削除及び変更されたときに、過去に重要なデータが包含されていた可能性からデータを復旧させるための機能であると定義可能である。

つまり、ネットワーク上で行われる協調作業として必要なものは
１．情報を追加する権限をリソースの作成者が保持しているかどうか？
２．過去のデータを掘り出すことができるか？
の2点を実装しているかどうかである。

これらを解決するためのひとつの解決手段として追記型のファイルシステムが挙げられる。
なぜなら版管理機能は一種の追記型のファイルシステムであると考えられるからである。

光ディスク等が出現したときの状況として、ファイルを消すことができないという物理的な制約があったことが挙げられる。
この物理的な制約の為に、追記型のファイルシステムはファイルの削除・変更時に新規の領域にファイルを作成し、昔のファイルが無かったことにするという手法をとっていた。

このため、追記型のファイルシステムはそのファイルの以前の状態を物理的に保持することができ、その気になればリカバリーすることができる状態であった。

ただし、このような構成のため、記憶容量は大きくなる傾向を持つ欠点がある。

しかし、この点は版管理システムと同じであると考えられる。ただし、版管理システムのほうは記憶容量を節約するために、差分情報を持つ等の工夫が見られるが、情報量的には追記型ファイルシステムと版管理ファイルシステムはほぼ等価であると考えられる。

ここで、追記型ファイルシステムと版管理システムと一般のファイルシステムの情報量を考えてみると
追記型ファイルシステム＝版管理システム＞一般のファイルシステム
であるということができる。
記憶容量の点では
追記型ファイルシステム＞版管理システム＞一般のファイルシステム
となる。

また、追記型ファイルシステムの特徴として情報量を落とさないための機能が備えられていると考えられる。これは、追記型ファイルシステムがファイルを削除しないため、書き込めたときにはトランザクションが成功している点である。

一般のトランザクション処理は、ファイルを呼び出し、変更し、書き込むという3つの作業を必要とするが、追記型ファイルシステムの場合書き込むだけである。
この点からも書き込みの速度向上を望むことが可能となる。

一方、追記型のファイルシステムのデメリットとして考えられる点として、読み込みが遅くなってしまう可能性がある。
追記型のファイルシステムは任意のファイルの状態を把握するために、ファイルシステムの記憶領域の先頭から検索して最後に行って初めてファイルの状態が理解できるという点である。

書き込み速度の向上が望めても、参照が遅ければ、最近の書き込みと参照のアクセス要求量から考えても時節に会わないと考えがちである。

しかし、答えは簡単で実は読み込みつまりファイルの最新状態を提供するキャッシュを用意すればいいだけである。

ファイルシステムとして考えてみると、ファイルシステムの記憶領域の最後尾に順次ファイルを追加する書き込みエージェントと、ファイルの最新状態をキャッシュするエージェントがあれば問題が解決することになる。

過去と異なり、文字情報の観点ではほぼ無尽蔵の記憶領域がある現在では追記型ファイルシステムと最新状態を表すキャッシュシステムを提供することは不可能ではない。

キャッシュシステムの記憶領域の観点からすると、キャッシュシステムは注目するファイルに対し先頭から眺めた情報を自身の中にまず保持しておき、追記型ファイルシステムの更新時に更新分をキャッシュシステムが情報としてマージすればよいだけであるので、キャッシュシステムのランニング中は版管理システム等とほぼ同じ速度を担保することができると推測できる。
ただし、キャッシュシステムの情報が一旦揮発すると、再構築に時間を必要とするのは明白である。この点はキャッシュシステムを不揮発性のものにすれば解決可能である。

また、キャッシュシステムの更新を高速化するために追記型ファイルシステムの更新部分のみをキャッシュシステムに報知する手法を作成する必要がある。
この点は追記型ファイルシステムの名前空間を管理するテーブルに時系列情報を包含させれば、キャッシュシステムが保持する最新更新時間との比較により更新部分をテーブルより演算にて得ることができる。

このような追記型ファイルシステムに必要な機能として、
１．これまで蓄積した全ての情報にアクセス可能なこと
２．データは削除せず追記のみであること（削除のときは削除のデータを生成する）
３．任意の時点からの更新ファイルの一覧を高速に得ることが可能なこと
の3点が挙げられる

以上を満たすための解決策の一例としてファイル名が生成順で高速にソート可能なことが挙げられる。例えば、ファイルシステムにかけるファイルは同時に一つであるとして、ファイル名をタイムスタンプにすることである。
この構成はファイルの一覧テーブルをソートすることが生成順に行うことであり、任意の時点からの更新分の演算を行い更新分の一覧を得ることも容易であることを意味する。

XMLデータとデータの可視性

昨今、コンピュータシステムがわかり辛い理由としては、基礎データが理解しづらい点が挙げられる。
本来計算機システムは、恒久的に保存される基礎データと、それを演算する主体、フィルタ等に代表されるプロセス、プロセスが一時的に利用する一時データと大きく3つの主体によって構成されるとモデル化することができる。

一般にプログラムとは、プロセスが基礎データから一時データを経過し、人間に提示し、人間が結果を判断し、人間が入力し、基礎データとして保存するプロセスを指すと考えられる。
ここで、人間への提示、人間からの入力等は状況によって省略されることがあり、これがプログラムによる自動化であると定義することができる。

一旦プログラムによってシステム化された場合、時間の経過によってシステムを取り巻く状況が変化した際、プログラムに入力される一時データの質の変化によりプログラムの修正、もしくはシステムの再構築、再構成を必要とする。

ここで、古から言われていることであるが、システム化する際に作成されたプログラムは再構築時の人間にとって理解しづらいものである。その為、構造化、オブジェクト化等様々な手法がとられてきたわけであるが、これは結局、後にプログラミングする人間に対し入出力データのわかりやすさ、プログラムが行っているブラックボックスの理解の向上を目指したものであるといえる。つまり、入出力が人間にとって理解しやすいほうがプログラミングが容易であることは明らかであるといえる。

しかし、人間にとって理解しやすいデータは逆に計算機にとっては理解しづらいものであり、計算機の能力に妥協した形でデータ構造は規定されてきたといえる。

最近までのトレンドとして、データ構造は表構造が採用されてきたわけであるが、これは常に表全体の正規化をしなくてはならない命題を持つデメリットを保持するため、入出力データの拡張の際、表の構造全体を見直さなければならないという結果を導き出してきた。
ところが、巨大なシステムを構築する時には任意の表に依存するプログラム全てに手を加えてしまう結果となってしまい。表の再構築がシステム全体の再構築を意味してしまい、結果として表のコピーを拡張し、そこに新しい構造を導入し、どれがいったい真正なデータであるのかわからなくなったり、表のフィールドを拡張して新しいフィールドには過去のデータにまでnull値を設定し、結果として入出力データに対する人間の可視性を下げてしまうという本末転倒な事態を導いたり、巨大な表により計算機の性能自身を落としてしまうという最悪な結果さえ導いてしまうこととなった。

つまり、表構造のデータ構造は定期的に再構築ができなければそもそもシステムの再構築をも不可能であることを意味すると言明しても過言ではないといえる。
ただし、これまで人間はこの技術に対し、様々な技術を投入しているため、検索の速度は最も速いシステムであることも付け加えておく。
いい加えておくが、あくまで表構造が定期的に再構築、もしくは再検討されるのであれば現時点での技術では最も計算機効率の良いシステムであることを認識しておいてほしい。

問題となるのは、表構造の見直しに対するコストである。
データ構造を最初に規定する者が恒久的にメンテナンスする体制が担保されていれば問題はないのであるが、それができない場合、入出力データの肥大化は避けられないこととなってしまう。

では、このような状況下ではどうすればいいのであろうか。

大事なのは、入出力データに対する人間の可視性と計算機が高速に扱うことのできる構造との折衝点を探すことであるといえる。

もともとUNIX系の考え方として、テキストデータならば人間も計算機も取り扱うことができるため採用されてきた背景がある。ところが、単なるテキストデータではテキストデータ内に記録されたデータの構造がデータ作成者の思惑により左右されるため、昨今XMLというメタキャラクタを利用した構造化テキストが注目されている。
XMLはデータ構造を木構造として表現しており、人間にとって理解しやすいものとなっている。
また、表構造と異なるため、繰り返し項目、不定形データ等にも耐えやすい構造となっている。

所詮XMLもデータの構造の変化への追従はテキストとそう大差は無いのかもしれないが、計算機からの扱いは若干の速度の違いがあるのではない方と考えられる。

入出力データの還元性・再帰性

古き良きUNIXと言われる機能の一つとしてパイプがある。
パイプはテキストを標準入力から入力された後、それを処理し、テキストにて出力するデータ処理モデルである。
パイプはデータの入力を無構造のテキストとした点に特徴がある。
それ故任意のプロセスをパイプによって接続する事が自由となり文字どおりパイプライン処理を実現できることとなった。
パイプの利点の一つとして、パイプラインによって表現される一連の処理の中にteeで代表される別の処理を挿入することが出来、パイプラインを構成するプロセスが意味的に独立しているならば、自由に処理を組み合わせることが出来る。

ネットワーク上のプログラムにおいてもこの機能は実施すべきである。

ネットワーク上でもパイプシステムは実装されてきたが、URIの考案以前のものであり、他のマシン中のリソースを一元的に指すことが出来ず、任意のセッションを張ったあとにサービスを提供するリモートプロシジャーコール等が実装されてきた。
またURI以後はapache等のサービスは単なるファイル閲覧システムとして機能しており、ファイル更新機能等はWebDAV等で現在実装中である。しかし、ネットワーク上でファイルシステムを提供しようとする観点は今後も続くであろう。

出力されるデータを入力データとするためにも現行の表構造データは不向きであることが言える。

コマンドの直交性は実装すべき課題である。

新システムの構成要素

１．シーケンサ（文書番号付与）
２．書き込みエージェント
３． URNリダイレクタ(例：squid)
４． Webサーバ(例：apache)
５．各種名前空間を生成するキャッシュとしてのFEDB

の４つである

シーケンサの機能は受付順に一意な番号生成し、付与した番号の一覧を保持することである。
書き込みエージェントの機能は書き込みデータの正当性をチェックし（正規化）、受付番号をシーケンサより受領し、ストレージに保存しURNリダイレクタに名前と場所のペアを登録することである。
URNリダイレクタは、ブラウザ（プログラム）からのURNをURLに変換し、ブラウザへの出力をリダイレクトする機能を持つ。
Webサーバは文字通りＵＲＬに対応するリソースをクライアントに提供する

文書とその定義

修正不可能な文書をここで文書と定義する。
修正可能文書の代表例として公文書・申請書等が挙げられる。
これらの文書は一旦提出された後修正することができない性質を持つ。
例えば、公文書偽造罪等の問われることもあり、一旦提出された後には修正することができない。
一般に、ファイルシステムに登録された文書（ファイル）は修正可能となってしまうため、認証等を付加する技術が昨今開発されている環境にある。
これらの技術を用いて読み込んだ後のファイルが真正かどうかを証明するすることは可能である。
ここで、仮にストレージしているファイルを変更することを認めないのならばより正確な修正不可能な文書保持空間として機能するファイルシステムを提供することができる。
当該ファイルシステムは単に全ての文書をそのままストレージに保持するだけのものとなる。
このとき問題になるのは、公文書・申請書類に対する○○書であると考えられる。
○○書は一旦提出されたものた書類に対し、上書きで情報を追加する性質を持つ。
○○書は、以前に保管された公文書\請書類の情報をマージして統合的に判断され受理される。
また、後になって○○書の内容を取り消す補正も可能であるので、○○書は計算機用語でいうところのパッチとして機能する。
紙であるところの公文書・申請書類・○○書は意味するところをマージして保存するわけでなく、それぞれを独立した紙のまま保存し、人間がそれらをマージして理解する性質もしくは制度をもつ。
ただし、これらを独立して保存するのは困難なので紙の場合は、一般的に包袋等に梱包して保存する。
ところが、事件が多数の局面を持ち・部署・担当が分割される場合があり、ひとつしかないオリジナルを分割するわけにもいかず、ひとつ以外にはコピーを入れるしか選択肢が無かった。
この点は計算機により担保できると考えられる。認証つきのコピーを渡せば申請であることが担保されるからである。
計算機の優れた点として、
１．真正性を担保した複製をいくらでも作ることができる。
２．関連する書類を簡単に検索することができる。
一方、デメリットとしては
１．視認性が悪い（もしくは人間が閲覧に慣れていないデバイスである）
等が挙げられる

包袋の実現

一連の書類の塊をここで「包袋」であると定義する。
包袋内に格納されている書類は任意の目的を元に束ねられている。
○の場合は、△人が最初に提出した書類に関する書類と言ってもかまわないであろう。
計算機のストレージ上で包袋を実現するにはいくつかの手法が考えられる。
一貫して言えることは書類を何らかの形で関連付ける、つまり今時の言い回しであるリンクをつける必要があるということである。
公文書・申請書類・○○書等を提出された順序でストレージに保存し、別の場所でそれらのリンクを実現する方法、つまり現行の記録原本に相当する方法。
もうひとつはこれら書類に例えばURIのようなリンク情報を埋め込んだ後、保存する方法がある。
現行のHTMLヘML文書のようにもともとの書類にリンク情報が埋まっているならば、保存した書類全体をなめるだけで各文書のルート情報を売ることができるのであるが、現行の公文書等にはこれら情報が入っていない。
この問題はどう扱っていくかは今後の大きな課題となるであろう。

しかし、現行の紙の文化ではこれらがうまく機能している側面がある。
これは受け付けたときにナンバリングされているためであり、このナンバーを元にと申請人の意思疎通が図られているといえる。
このナンバリングが人間にとってもわかりやすいものでなくてはならないのはいけないことは明白であり、○で言うところの△番号がこれに相当することがわかる。
これは一般に言うところの番号問題を発生させる。
事件が単独で終了するのであるならば単一の番号で問題が無いのであるが、事件が分割された際、複雑性を増してしまう問題を持っている。
紙のシステムでは事件が分割、および次の段階に移行したとき最初の番号とは異なった番号を付与される傾向がある。
つまり、新しく付与された番号は以前の事件との関連性を以前の番号へのリンクとして内包して付与されるということである。
つまり、人間が書類でなく事件に対しナンバリングしている点で計算機の保持機構とのギャップを生じる問題を持つ。
このナンバリングを計算機と人間と両方にとって扱いやすい空間にする必要がある。
このナンバリングは計算機用語では一般に名前空間と呼ばれる。
人間にとって理解しやすいのは事件番号に枝番を付与することであろうし、これまでもそうしてきた。
もしくは、事件に新規に番号を付与し、関連のある番号を事件中に記載することでこの問題をクリアしてきた。
ここで問題になるのは計算機が逐次的にしか番号（名前）を付与することができないことである。
ここをいかに着陸するのかがシステム屋の本懐である（←本音）

ひとつの解決手段として人間が付与する番号ルールを計算機が理解しそれに則って書類に名前をつけていく方法がある。
番号体系が今後とも変化しないのであるならばまったく問題は無い。
しかし、人間の運用が変化した際に番号体系も変化した際に追従できないかもしれない問題を持つ。
妥協点として、人間の番号体系へのエイリアスを計算機に持たせるのが現実的な手段であろう。
ただし、このエイリアスを実現するシステムが将来的なシステム崩壊への目となる可能性は否めないことは述べておく。

ここで、整理すると着陸する方法として次のいずれかを採用しなくてはならない。
１．計算機になじみやすい新たな番号体系を人間に強いる（人間のシステムを再構築する）
２．計算機の番号体系と人間の番号体系への橋渡しシステムを用意する

前者の方は人間サイドの方にかなりの混乱を強いてしまうので現実的でなく、これまでもここは避けていた点である。ただし、あたらしい番号体系がシステムに携わる人間にとって十分理解しやすいとか更なる利点が存在するならば容易に変更できるであろう。

後者は橋渡しというかエイリアスを実現するシステムが常にシステム更改のボトルネックとして存在し続ける危険性があるということである。
ただし、このエイリアスを実現するアルゴリズムが極めて人間にとって理解しやすいのであれば差ほど問題にならないであろう。

では、この後者を採用したとしたときの書類間のリンク情報がどのように存在するのかという問題がある。