まさしくその通りです！フラグメントの構造とは直交するコンセプトにタグを利用する、言い換えると、複数の構造（ネットワーク、あるいはツリー）を横断するものですね。横断しているということを示したいがためにタグという要素を別に用意している、と言ってもいいかもしれません。
EBtでも、タグとして機能しているX、Yを他のメモと区別できるように「タグ」というタイトルのメモで修飾すれば、同じようなことができます。Piggydbで言えば、一階層のタグセットとして認識できます。このように、EBtにおいて、タグとして機能しているメモを区別する必要があるのかないのか、あるとすれば何故なのかを考えれば、タグという概念の必要性について、ヒントを得られるのではないでしょうか。
そのメモ（あるいはフラグメント）を選択すれば、そこからつながる別のメモが見える、という機能に限って言えば、つながりはタグの代用になるわけですが、Piggydbにおいては、その他の機能で以下のような差別化を行っています。
つながりにページングが無いのは、それほど大きな数のつながりが作成されることを意図していないということですし、タグページにページングがあるのは、大量のデータを修飾の対象とすることを意図しているからです。 つながりの順序は以前話題になりましたけども（#208）、順序は空間上の配置を意味しますから、これはつながりが基本的には構造的な関係を表すということです。
ちょっと堅い言葉で言いますと、タグの修飾は「概念的包含関係」を表し、つながりは「構造的包含関係」を表しています。この二つの区別には常に混乱が付きまといます。
タイヤは自動車の下位概念ではない。タイヤは自動車の部品である。自動車事故は自動車の下位概念ではない。自動車事故は自動車に関連する概念ではある。

—

EBtでも、タグとして機能しているX、Yを他のメモと区別できるように「タグ」というタイトルのメモで修飾すれば、同じようなことができます。Piggydbで言えば、一階層のタグセットとして認識できます。このように、EBtにおいて、タグとして機能しているメモを区別する必要があるのかないのか、あるとすれば何故なのかを考えれば、タグという概念の必要性について、ヒントを得られるのではないでしょうか。
EBt 歴もまだそんなに長くない私がいうのが適当かどうか分かりませんが…。
EBt で「タグとして機能しているメモを区別する使い方」のユーザはいらっしゃるかもしれませんが、「タグとして機能しているメモを区別する必要」はないように思います。
私の例で言えば、
  1. もともとのつながりよりも、後で（Piggydb でいえばタグ的に）つけたつながりの方に意識のフォーカスが移ることが多々ある。
  2. 元々はノード（空メモ、Piggydb でいえばタグ的）だったものにメモコンテンツを加筆する場合があり、Piggydb でいえばフラグメント化することがある。
という状況ですので、こっちが「概念的包含関係」でそっちが「構造的包含関係」、というような意識をすることは EBt を使う限りに置いては全くありません。
要は私のいい加減な使い方に、EBt の自由度が高いことがずばりマッチングしているという感じですね。

— → ...

なるほど、おそらく普通に情報管理をする場合は、ほとんどの場合、構造的な関係なだけで十分で、後は必要に応じて、ユーザーの側で適当に関係の意味を読み替えればいいということなんでしょうね。
これは個人的な研究テーマなのでここで深入りするのは避けますが、「概念的包含関係」と「構造的包含関係」の二つの直行する軸は、人間の認知上、本質的な区別ではないかと考えていて、フラグメント、タグもそういった経緯で発想したものではないかと、まあ事後的に考えたりしているわけです。これはもうちょっと文献などを当たって掘り下げて行こうと思っているのですが。もうこれはPiggydbとは離れた話だと思って下さい (^_^;
しかし、これを読んだ人が混乱しないか、いささか心配です。これは大前提ですけど、こういった抽象的なコンセプトは全く気にせずに、今提供している機能だけに着目して、適当に自由に使って頂くのが一番だと思っています。
元々はノード（空メモ、Piggydb でいえばタグ的）だったものにメモコンテンツを加筆する場合があり、Piggydb でいえばフラグメント化することがある。
実はこれがとても重要ですね。Piggydbも将来的には、こういった滑らかな運用が出来るようにしたいです。