グラフエッジのリレーションを持つタグ階層の実装はありますか？
情報を整理するときは、階層またはタグを使用するのが一般的です。階層内の要素は、事前定義されたカテゴリ内で順序付けされ、上、下、または同じレベルで他の要素に関連付けられます。階層内の要素間の直接のリンクは、そのすぐ上の要素と下位の要素のみです。
一方、タグは、要素に割り当てられた非階層的なキーワードです。タグ間にリンクはなく、要素は異なる階層レベルのタグを持つことができますが、厳密な階層では不可能です。
Paul Heymann とHector Garcia-Molinaは、2006年に「 ソーシャルタグシステムにおける共同階層分類の共同作成 」というタイトルのタグ階層トピックに関する技術レポートを書きました。彼らは、トップレベルの接続とノイズの多いエッジによってリンクされた いくつかの階層のタグ間の関係 を持つことが可能であるという結論に達しました（彼らの論文の画像を参照）：
図1：潜在的な階層的分類法。ヘイマンとガルシア-モリーナ2006
一見すると、これはグラフ表現であり、どのタグ付けシステムのタグにも非常によく使用できます。異なる階層間のリレーショナルをリンクするときに、タグを厳密な階層（適切な場合）に配置し、ノイズの多いエッジまたは最上位の接続を提供します。
私の観点からは、標準の階層ナビゲーションやタグを使用するだけでなく、タグ階層を使用してナビゲーションを改善するためにも使用できます。これは、タグをコンテキスト内に配置し、ユーザビリティの観点から、ユーザーが情報を見つける能力を向上させることができます。
しかし、私が知っていることから、このモデルまたは同様のモデルの実装はまだ行われていません。グラフエッジのリレーションを持つタグ階層の実装はありますか？
私の会社の製品は、タグのように機能し、例のようにグラフのようなツリー構造を形成するいくつかのエンティティを使用しています。 （この製品は公開されていないため、詳細を取得できません。申し訳ありません。）
UXの観点から見た場合の主なメリットは、システムが非常に柔軟であり、フラットタグリストや単純なタグツリーよりも複雑な主題を記述できることが多いことです。
ただし、この洗練されたシステムの短所はかなりあります。（実際、私は常に複雑さを取り除く方法を理解しようとしていますユーザーの混乱のb/c。）ユーザーはフラットリストを自動的に、少し努力してツリーを、さらに努力してgraphy-tree-thingiesを理解します。
いくつかの重要なポイント：
- あなたは私たちとの関係を説明するために図が必要でした
- @yitznewtonによると、ライブラリ（および関連するメタデータ仕様）は、数十年にわたってこの種のシステムで牽引力を得るために苦労してきました。
- 単純に複雑です。参照： プログラムモデルが自明でない場合は、おそらくユーザーモデルではありません 。
つまり、ユーザーのデータ構造を制御し、ユーザーがそれを使用するためにそれがどのように機能するかを理解する必要がない場合は、邪魔するだけでなく、ユーザーを支援している可能性があります。 。反対に、user managedであることが予想される場合は、大きな問題が予想されます。
分類法が複雑になると、検索、並べ替え、および/またはフィルター処理にユーザーを集中させる方がよいことに私はよく気づきます。
司書によって生成された本のメタデータには、主題の見出しが含まれています。これは、階層的に制御されたタグのようなシステムです。メインの実装（米国議会図書館の件名、またはLCSH）は不格好ですが、図書館コミュニティはこの分野で何十年も働いています。チェックアウト http://id.loc.gov/
視覚化を行うためのツールを求めているかどうかはわかりませんが、おそらくここに答えがあります。
まあ、 JSのInfoViz/TheJitライブラリ は、まさにあなたが求めていることを実行します。階層的なJSONフィードを受け取ります。
分類の視覚的表現を描画する実装例については、何が求められているのか理解できません。
そうは言っても、私の製品はまさにこれを行います。それはdata-model-builderに物理的な線（私の場合は isa-95.com を参照）に沿って情報を整理するように要求しますが、システムを使用する人は機能的な線に沿って比較を見たいと思うことがよくあります。この例は、「ポンプ」（階層内のオブジェクト）を要求するか、「フロー」変数を含むオブジェクトを要求するか（ポンプ、バルブ、パイプラインなどを含む）の違いになります。
これら2つの一般的な使用法のため、階層別とタグ別の両方のナビゲーションを許可しています。