Plots2: すべてのタグのタグの視覚化

こんにちは、リズ-このような静的なグラフィックを永続的なコードベースに配置するのは少し気が進まないのですが、そのページの上部に「機能」（バナーなど）を表示してから、管理者に表示することをお勧めします。彼らがそこに望むものは何でも表示することができます。 それはうまくいくでしょうか？

この行の上または下に移動します： //github.com/publiclab/plots2/blob/master/app/views/tag/index.html.erb#L4

そして次のようになります：

      <% cache('feature_tag-page-header') do %>
        <%= feature('tag-page-header') %>
      <% end %>

ええと、「一目でわかる洞察」を追加したいので、そのページをあまり飾りたくありません。
別のポイントですが、グラフィックの視覚化を追加することをお勧めする理由については、このタグページには、地理的に「最近」または「人気」のいずれかを表示するための並べ替え機能がまだないということです。

実際には、動的に生成するために使用できるpythongephiバインディングがあります。 私は実際に現在javascriptネットワークの視覚化に取り組んでいるので、それがどのように機能するかを見てみましょう。 うまくいけば、私が行ったことをPythonスクリプトに変換して、データ構造を生成し、JavaScriptで視覚化することができます。

こんにちは、すべて-生成されたグラフは素晴らしいと思います。これは永続的なコードに入れることができるものです。

@ebarryこれが装飾であり、コンテンツではないと言っているのではありません。これはすぐに古くなると言っています。また、私たちの目標は、/ no /コンテンツをコードベースに保存することです。インフラストラクチャのみです。 だから、これはそれを実装するための単なる方法です-私の提案されたソリューションは大丈夫ですか？

re this tag page still doesn't have any sorting capabilities to see "recent" or "popular" much less to see either of those by geography.それがあなたにとって優先事項であるならば、私はあなたと協力して、これを解決するために貢献者を構築させるためのいくつかの機能要求を考え出すことを嬉しく思います。 あなたがそれらをキューに入れるのを手伝うことができれば、いくつかの簡単なfirst-timers-only問題かもしれません！

この問題の基本に戻りましょう:)
タグを視覚化する目的は何ですか？

私にとって、タグの視覚化は、関連するタグ、たとえば同じコンテンツに一緒に表示されるタグを視覚的に表現する方法です。 優れた例については、上記の@skilfullycurledの視覚化で色分けされたクラスターを参照してください。 これは、この全体の問題と私の実際の目標です> -彼らは視覚的にWebサイトの公開ラボコミュニティが文化的に「研究分野」といいものに地域活動_closer_のプレゼンテーション、または多分「トピック」を接続するためのタグをクラスタリングすることが重要です。

背景情報は次のとおりです。タグページ（https://publiclab.org/tags）に、「タグを使用して研究をトピック別にグループ化する」と記述し、タグを閲覧するように促しています（現在は最近のアクティビティでのみ並べ替えられています）。 これは、人々がトピックを見つけて関与するように名前を付けたり、リンクしたり、宣伝したりするための重要な方法です。 ダッシュボード自体は最近のアクティビティを強調しています。 ダッシュボードに「最近使用したタグ」バーが追加されました。これは、「研究領域」または「トピック」を表示するという目標への重要ですが部分的なステップです。

先に進むために、私はグラフィックタグの視覚化による_ナビゲート_には興味がありません（2007年です！）が、アクティビティのクラスターは、トピックに接続/ナビゲートするための重要な追加の方法を提供します。 目標を達成するために、つまり、タグページが最も相互接続されたタグを表示し、研究領域内の接続されたトピックの幅を伝え、研究領域にナビゲート/接続し、適切にサブスクライブする機能を意味

言語をよりアクセスしやすくするために、publiclab.org / topicsでpubliclab.org/tagsをミラーリングすることも検討できます。

かっこいい、リズありがとう！

この目標に向けてより狭い機能を1回突き刺そうとすると、タグページ（新しい名前のフローティング：トピックページ...！？！）に「関連トピック」のリストが含まれている場合はどうなりますか。

関連トピック： water runoff wetlands turbidity

「関連」とは（これを測定するさまざまな方法があり、「計算効率の高い」方法が必要であることを認める）これらは、すでにプライマリタグがあるページに最も一般的に表示されるタグであることを意味します。 したがって、トピックonionsについては、 onionsタグ付けされたすべてのページを集計し、上位、たとえば5つを取得します。

上記が良さそうな場合の小さなフォローアップ-最新の20〜30ページだけでこれを行うのは大丈夫ですか？ これが単なる出発点であるとしても、それはそれが全体的なウェブサイトの速度低下を引き起こすことを心配することなくこれを実装することをより簡単にするでしょう。 これを回避するためのより複雑な方法がある可能性がありますが、これが開始する最も簡単な方法です。

私はhttps://publiclab.org/questions/tommystyles/10-20-2017/need-your-feedback-on-tag-pagesにクロスポストしました-特定の個別のものができるまで、そこに議論を移すことについてどう思いますかコーディング手順（コード寄稿者向けのミニプロジェクト）を作成できますか？

大丈夫！ その議論に行き、私たちができたら戻ってきましょう
実行可能な手順。

-

+1 336-269-1539 / @lizbarry http://twitter.com/lizbarry / lizbarry.net

21:54の水曜日、2017年11月15日には、ジェフリー・ウォーレン[email protected]
書きました：

https://publiclab.org/questions/tommystyles/10-20-にクロスポストしました
2017 / need-your-feedback-on-tag-pages-引っ越しについてどう思いますか
特定の個別のコーディングステップ（ミニ
コード寄稿者のためのプロジェクト）私たちは作ることができますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/1502#issuecomment-344799932 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAJ2n8PdvpH0GQ_wBU-Utp4xfL7XDmuJks5s26PpgaJpZM4OOvLP
。

@ jywarren 、 @ ebarry 、上のグラフの「エッジ」を知るためのAPI（またはドキュメント）はありますか？ つまり、ノードはどのように接続されていますか？
ありがとう😄！

ねえ@ sagarpreet-chadha！

視覚化は単なる画像であるため、APIはありません（まだ！ウィンク）が、その特定のグラフからエッジのリストを提供できます。 最も「生の」ファイル形式はcsvとjsonです。 どちらの形式も、「プログラムで」（ iGraph 、 networkx 、 d3.js ）またはGUI（ Gephi 、 Cytoscape ）のいずれかでグラフを操作する必要があります。

どうやらあなたはgithubにファイルをアップロードすることはできません。 それらをパブリックラボのリサーチノートにアップロードしようとしましたが、機能しません。 @jywarrenファイルをリサーチノートにアップロードする方法はありますか？ そうでない場合は、@ sagarpreet-chadha、 plots-dev googlegroupに投稿できますか（いない場合は、@jywarrenが言うことを見るのを待ちましょう。なぜなら、それらをリサーチノートに直接入れるのは素晴らしいことだからです。

ただし、楽しみにできることは次のとおりです。

plots_tag_communities_edges_w_props_9_16.csv ::計算されたプロパティ、特にエッジの重みを持つ一意のエッジのリスト。 重みは、タグが一緒に発生した回数に変換されます。

plots_tag_communities_nodes_w_props_9_16.csv：計算されたプロパティを持つノードのリスト。 Webサイトの画像に最も関連するのは、各ノードがどのコミュニティに属しているかを示す「モジュラリティクラス」です。

plots_tag_communities_9_16.json：jsonは役に立たないと思いますが、一部の人はそれを好むことを知っています。 jsonファイルには、Webサイトにある視覚化のプロパティ（つまり、各ノードのRGBカラー）も含まれていると思います。

更新：上記のファイルのリストからplots_tag_communities_edgelist_9_16.csvを削除しました。 重複するエッジはすでに重み付きの一意のエッジにマージされているため、このファイルの使用は制限されています。 プロパティがないと、このエッジリストでは、エッジの重みが1のグラフしか作成できません。重複している元のファイルを探します。

返信ありがとうございます@skilfullycurled ！

私は実際に、javascriptライブラリ（d3.jsまたはvis.js ）を使用して視覚化グラフを作成し、publiclab.orgWebサイトに簡単に追加できるようにしようとしていました。 これらのライブラリには、次の形式のデータが必要です。

ノードの場合はnodes: [ { id: 1, shape: 'circle', label: 'Infrared } ] 。

そしてエッジの場合：
edges: [ {from: 1, to: 2}, {from: 1, to: 3}]

そうでなければ、jsonは素晴らしいでしょう、そうでなければ私はそれを作成することができます、あるいはJavascriptオブジェクトを直接作成することができます（この方法ではJSONファイルを解析する必要はありません）。

ダミーグラフを作成しました（ここでノードとエッジを操作できます😄）：

どう思いますか ？ @ ebarry 、 @ jywarren 、 @ skilfullycurled

ああ。 それは素晴らしいでしょう！ わかった。 この会話をさらに進めるには、「APIランド」を離れて、Gephiでの視覚化がどのように機能するか、およびそれらの機能をjavascriptに変換するための最良の方法に移る必要があります。

これを質問として始めるのに苦労してもいいですか？ 「Gephiで作成されたタグの視覚化をjavascriptバージョンに変換するにはどうすればよいですか？」のようなものです。

また、benjで私にメールを送ってください。 [email protected]なので、ファイルを共有できます。 削除したらメールを削除します。

実際、APIランドを離れる必要はないかもしれないと思います。既存のAPIは最近かなり堅牢です。 @skilfullycurledでこれらのエッジをどのように生成したのか興味があります-

それらは、すべてのタグとそれらが使用されたノードのリストから新たに生成できますか？ キャッシュされている場合、これは生成するのに妥当なクエリです。

https://github.com/publiclab/plots2/tree/master/app/api/srchでAPIに追加し、 ます。 /API.md

十分なデータがある場合、クエリは次のようになります。

r = []
Tag.select(:name, :tid).each do |t|
  nids = t.nodes.select(:nid, :status).where(status: 1).collect(&:nid)
  r << [t.name, nids] if nids.length > 0
end
r # later, r.to_json

私はそれを本番環境で実行したところ、約15秒かかりました。 それを毎日キャッシュすれば、管理しやすく、さらに改善できるかもしれません。

また、 http：//gist.github.comでファイルを共有することもでき

したがって、クエリから生成されたJSONを使用して、

• JavaScriptでは、タグが一緒に発生した回数を計算できました。
• 「コミュニティ」をどのようにグループ化/計算しましたか？

抜粋は次のとおりです。

["whitebalance", [12476, 13575]], ["wi", [12143, 13067]], ["wi-fi", [11123]], ["width-of-dvd-grating", [12838, 12875, 12895, 12899, 12902, 12926, 12990, 12991, 12995, 12999, 13006, 13014, 13019, 13037, 13046, 13057, 13062, 13069, 13077, 13088, 13089, 13094, 13103, 13117, 13125, 13131, 13133, 13136, 13152, 13154, 13157, 13159, 13169, 13178, 13181, 13183, 13188, 13226, 13248, 13283, 13302, 13305, 13308, 13315, 13316, 13340, 13349, 13355, 13366, 13401, 13402, 13409, 13414, 13423, 13429, 13432, 13434, 13437, 13439, 13440, 13443]], ["wiki", [9048, 10956]], ["wiki-gardening", [10956]], ["wild", [11707, 11711]], ["wildfires", [14803]], ["wildlife", [670]], ["wilkinson-bay", [220, 265, 280, 281, 282, 283, 284, 677]], ["wilkinsonbay", [606]], ["williamsburg", [10343, 10428, 10444]], ["willow", [9979]], ["wind", [9032, 10660, 12610, 13880, 14487, 14527, 14530, 14531, 14713, 14756]], ["wind-direction", [14527]], ["wind-sensor", [14713]], ["wind-speed-meter", [1962, 5837, 9032, 12103, 13064, 13165, 13231, 13880, 14527]], ["winder", [7717]], ["winders", [1900]], ["window", [147, 1759]], ["windows", [11434, 11677, 13037]], ["windows-7", [13037]], ["windows-7-ultimate", [13037]], ["windows-excel", [13037]], ["windspeed", [745]], ["windvane", [14527]], ["windy", [146]], ["wine", [706, 10955]], ["winter", [5161]], ["wintercamp", [5103]], ["wired", [10315]], ["wireframes", [10623]], ["wireless", [3908, 9940, 11123, 12175]], ["wisconsin", [10504, 10552, 10611, 10619, 11331, 11783, 12142, 12143, 12192, 12221, 12337, 12537, 12539, 12562, 12597, 12610, 12919, 13067, 13216, 13217, 13219, 13222, 13223, 13224, 13406, 13578, 13920, 13921, 13922, 14018, 14044, 14087, 14146, 14648]], ["with", [11772, 13742, 14728]], ["with:abdul", [13407, 13412, 13413, 13428, 13493]], ["with:adam-griffith", [11049]], ["with:amal", [12161]], ["with:amandaf", [11556]], ["with:amberwise", [12338, 13280]], ["with:ann", [12850]], ["with:basurama", [11699, 11705]], ["with:becki", [13571]], ["with:bronwen", [10952, 12480, 13493, 14587]], ["with:bsugar", [13449]], ["with:btbonval", [11789]], ["with:cfastie", [11688, 13493, 13980]], ["with:chrisjob", [10464]], ["with:cindy_excites", [11566, 11567, 14537]], ["with:damarquis", [12338]], ["with:danbeavers", [11417, 11567]],

FWIWこのようなさらに効率的なクエリがあるかもしれませんが、これはかなりまともですが、上記のものを完全には返しません。

Tag.select('term_data.tid, term_data.name, community_tags.nid, community_tags.tid')
   .includes(:node_tag)
   .references(:node_tag)

ただし、ノードにnode.statusを混在させない限り、ノードが公開されているかどうか（スパムに対して）はわかりません。 しかし、それは可能です！

こんにちは、私はここにいくつか質問があります、
1.）2つのタグが同じノードに属している場合、それらの間にエッジがありますか？
2.）異なる色は、質問、メモ、研究メモなどのノードの種類ごとに異なります。 ？

ありがとう😄！

また、APIランドを離れないことに同意します:)

Arg！ わかった。 積み上げないでください。 私以上にAPIランドに留まりたいと思う人は誰もいません（おそらく@ebarryを除いて）。 私の理解では、APIランドの構築は、Webサイトの停滞に対する懸念のために、ほとんど無期限に延期されていました（ここで会話の延長を参照してください）。 しかし今、 @ jywarrenは、それはもうそれほど大したことではないと言っているので、そのための良い時期です。

Githubを使用すると、アクセス可能な情報への障壁になる可能性があるため（誰もがアクセスできるわけではなく、使用方法を知っている）、コードベースで「物事を成し遂げる」こと以外の会話をする方が適切だと思います。誰もが彼らから学ぶことができるウェブサイト。 これらは私が設定したコミュニティの規範ではありませんが（上記の@jywarren自身のコメントを参照）、良いものだと思います。

-おっと、申し訳ありませんが、私はそのスレッド上のあなたの最後のコメント覚えていなかった@skilfullycurled https://publiclab.org/questions/tommystyles/10-20-2017/need-your-feedback-on-tag-pages#answerを- 556-コメント-17709-あなたが提案した場所：

1. 上位250個のタグでのみ実行
2. 毎週キャッシュ

あちらでpingを実行しますが、API、コードのクリーンアップ、アウトリーチに関するすべての作業を行うことで、このようなクエリのキャッシュバージョンを毎日または毎週実行でき、合計10〜15秒の計算で問題ないと思います。週あたりの時間。 残りはブラウザでローカルに実行されます。 あそこでこれを繰り返します。

@jywarrenいくつかの質問についておこちらをご覧ください。 正確なコードについては、こちらをご覧

@ sagarpreet-chadha（および興味のある他の人）は、このプロジェクトのインスピレーションとなったタグオーバーフローのリポジトリをチェックすることで、タグデータからd3.jsグラフがどのように作成されたかを確認できます。

コミュニティの検出に関して、tagoverflowリポジトリを見ると、作成者が独自のアルゴリズムを実装していることがわかります。 それ以来、 jLouvain 、 netClustering a CNM実装（ d3の例）などの他の実装が行われています。 タグの数は256に制限されているため、ブラウザではコミュニティの検出に問題がない可能性があります。

大量のデータでpubliclab.orgの議論を圧倒しないように、TagOverflowが使用するデータの形式へのリンクを次に示します。

https://api.stackexchange.com/2.1/tags/python/related/?site=stackoverflow&key=of3hmyFapahonChi8EED6g（（＆pagesize = 16

特定のタグ（上記の例では「python」）に関連するタグをフェッチするために、15回の呼び出しが行われます。

したがって、それと上記で生成したデータとの違いは、クエリにノードIDがリストされているが、それらを使用して「関連性」を確立していないことです。 しかしもちろん、 @ skilfullycurledのJupyterノートブックはこれを行います！ かっこいい、共有してくれてありがとう！

@ sagarpreet-chadha、上記の質問に答える質問を投稿しました。

https://publiclab.org/questions/bsugar/01-25-2018/how-was-the-tag-graph-visualization-made

私は自分の要求について「受動的攻撃的」になろうとはしていませんが、会話のこの側面が公開されていることで人々は恩恵を受けることができると思います。 だから私はそれが「アグレッシブアグレッシブ」になると思います。 ; ）

冗談はさておき、どんな質問にも喜んで答えます！

こんにちは、みなさん！

@ sagarpreet-chadha、必要なすべてのファイルをここに置きます：

https://spideroak.com/browse/share/skilfullyshared/plots-tag-graph

フォルダには、内容を説明するreadmeファイルが付属しています。

シェアルームを閉鎖できるように、ダウンロードしたらお知らせください。 最終的には、他の人がwikiでアクセスできるように、それらを自分のgithubアカウントに投稿します。

ご不明な点がございましたら、お気軽にお問い合わせください。

ありがとう@skilfullycurled ！
私はファイルをダウンロードしました:-)

問題ありません@ sagarpreet-chadha！

PS： wikiの質問でフォローアップの考えを残し

ここでルビーベースのタグ関連性計算に関する素晴らしいアップデート： https ：

よりすぐ！

https://github.com/publiclab/plots2/pull/4657でいくつかの進歩があり、非常に基本的ですが、Cytoscape.js（http://js.cytoscape.org/）のライブインスタンスを実装しました。毎週キャッシュされたコレクション

サイト上のすべてのタグ（毎週キャッシュされる可能性があります）の実行には50秒以上かかりましたが、8200以上のタグと31kのエッジも生成されました...これはグラフ化するのに大変です。 これがフルセットです。 スパムタグがたくさん含まれていると思います： https ：

クエリするタグの数は、https： //stable.publiclab.org/tag/graph.json？limit = 10 （完全に公開されたら、https：

現在、タグ名ごとに5つの「エッジ」に制限されており、元のタグと一緒に最も頻繁に発生する5つのタグを表します。

これは現在、安定したテストサーバー上で稼働しています（ただし、このブランチはかなり頻繁に再構築されるため、URLが常にオンラインであるとは限りません...皮肉なことに）：

https://stable.publiclab.org/stats/graph?limit=75

limit = 100や250のような大きなカウントは、ある種のエラーを示しているようで、少し追跡する必要があります。 しかし、これはかなり良いスタートです。

これを改善するために追加できる構成はたくさんあります-ノードサイズ、リンク強度など-いくつかの可能性についてはhttp://js.cytoscape.orgのギャラリーをチェックしてください。 そして、「家族」を作ることも可能かもしれませんが、そのためにはもう少し入力が必要です。

ああ、 https： //stable.publiclab.org/stats/graph = 300も機能しているようです

ここでコミュニティの検出！ https://github.com/upphiminn/jLouvain/blob/master/README.md

@jywarren 、超クール!!!

また、さまざまなクラスタリングアルゴリズムがあります。これらはJavaScriptコンソールでテストできます。

http://js.cytoscape.org/#collection/clustering

• eles.markovClustering（）
• nodes.kMeans（）
• nodes.kMedoids（）
• nodes.fuzzyCMeans（）
• nodes.hierarchicalClustering（）
• nodes.affinityPropagation（）

私はこれらに精通していませんが、それらはすべてノードまたはエッジの属性を使用して同様の要素のクラスターを作成しているようです。 では、類似性の基礎となる属性として何を与えるべきでしょうか？

ドキュメントの例を使用して、コンソールでこれらを試すことができます。

var clusters = cy.elements().hca({
  mode: 'threshold',
  threshold: 5,
  attributes: [
    function( node ){ return node.data('count'); }
  ]
});
clusters; // <= then inspect what this returns to see the clusters

OK、 jlouvainを使用して、コミュニティ検出を追加できました： https ：

これがどのように機能するかを確認するのに十分なテストデータがありませんが、＃4679が合格した場合はマージし、次の場所でコミュニティ検出を使用して実行されていることを確認できるはずです。

https://stable.publiclab.org/stats/graph?limit=101

（ビルド後）

こんにちは、みなさん！ 見栄えがします。 申し訳ありませんが、返信できず、何かに追いついてきました。本日遅くに返信します。

それまでの間、他のどの投稿でも言及しなかったもう1つの要素は、レイアウトです。 私が使用したものに最も近いものは、おそらく力のレイアウトです。 技術的には、フォースレイアウト2と呼ばれるものであった可能性があります。

力のレイアウトは、設定したパラメータ（つまり、反復回数、引力/反発の強さ）に基づいて定常状態に達する一種のアニーリング引力/反発です。 これがd3デモです。

コミュニティの検出とエッジの重みに関しては、いくつかのオプションがありますが、これが参照しているタググラフを再作成する場合は、幸運がそれを持っているように、cytoscapeが作成するのに役立つ機能を持っている共起が必要ですより簡単に。

oe_ratio =  (all_questions_count * tag_count_AB) / (tag_count_A * tag_count_B)

ここで、tag_count_AB = Edges.parallelEdges（）

それがそうであったように、私は最初にタグのセットをいくつかの妥当な数（たとえば、上位512）に絞り込みましたが、次に、観察された上位n個のタグ（おそらく64？）のみを含めることによって、視覚化に使用したタグを絞り込みました。 1を超える期待される比率に。

タグオーバーフローから詳細を読むことができます。 この方法は、エッジノードまたはノードノードが重要であるが使用率が低いという問題を処理する1つの方法です。 たとえば、ある店舗では、100人がコーヒーとクリームを購入する確率が85％である可能性がありますが、そのうち5人は常にコーヒー、クリーム、卵を購入しています。 だから私は間違いなく5カートンの卵を在庫に入れておきたいです。

簡単な代替方法は、2つのノード間のエッジの重みをtag_count_ABにし、指定されたしきい値を超えるエッジ/ノードのみを取得することです。 個人的には、上記の理由により、これで良い結果が得られることはめったにありません。

他の方法に関しては、3ページ（2.2）から-pgに興味があるかもしれません。 さまざまなタイプのコミュニティ検出方法を分類しようとするこのペーパーの7（3.1）（これらの部分の計算はありません）。 これは、グラフの構造とグラフから知りたいことを考慮して、最も顕著な結果を提供するものを選択するのに役立ちました。 たとえば、一般的な社会的つながりのコミュニティと、2人の間でメッセージが送信される頻度に基づくコミュニティ。

安定したサーバーで作業中です！

https://stable.publiclab.org/stats/graph?limit=99

ここに99個のトップタグがあります！

今夜遅くまでにライブサイトで実行されるはずですが、一部のユーザーによるタグの「使いすぎ」が、以前に認識した方法でグラフを歪めていることに注意したいと思います。 ユーザーの1人がサイトからモデレートされていると思いますが、これらのタグをサイトから削除するか、少なくともグラフから除外するのが適切だと思われるのではないかと思いました。 それらを削除する方が簡単ですが、それらを隠すために何かを作成することもできます。 好み、 @ ebarry @skilfullycurled ？

それでも、エッジの弾力性の設定にはまだ微調整が必​​要ですが、これは見栄えがよく、別のレイアウトタイプの方がうまくいくかもしれません...

うん！ 私たちは間違いなくこの問題に遭遇しました。 残念ながら、行うべき唯一のことは、その特定のユーザーを外れ値として削除することでした。 その数のタグを使用している人は、それ自体が外れ値ではない可能性がありますが、自分に固有のタグを作成して何度も使用している場合は、実際にはデータをキャプチャしていません。

githubの問題をログに記録して、機能リクエストで警告が表示され、本質的に「Whoaaaaaaaa、簡単です。タグがたくさんあるようですね」という警告が表示されたと思います。

ああ、PS。 ちなみにすごいですね！

AAAAAAHHHHHHHHMAYZINGGGGGGGGGG !!!!!!!!!!!!
はい、手動で「その特定のユーザーを外れ値として削除」します

それがどれほど素晴らしく、物事を考えているので（うまくいけば小さいので）、私はこのスレッドに戻り続けます。 フィルタリングを検討する可能性のあるもう1つのことは、パワータグです（コロンが付いているタグですよね？）。 タグの使いすぎの問題が修正され次第、レイアウトについて詳しく知ることができると思います。

自己メモ：実装にとって重要なページを含むコミットへのリンクは次のとおりです。

みなさん、こんにちは。熱意に感謝します。 私は病気になりましたが、今は回復しており、火曜日の帰りの飛行機でこれに少し取り組むつもりです。

私は聞きたかったのですが、私の具体的な質問は、次のことを行うべきかどうかです。

1. このモデレートされたユーザーから実際にタグを削除するか、
2. それらを保存しようとするが、それらを除外する必要がある場合。

フィルタリングは、コードとデータベース呼び出しの両方でかなり多くの作業が必要になりますが、可能です。

このように、モデレートのためにアカウントが「非アクティブ」になっている場合は、データベースからタグを完全に削除するだけで問題ないと思います。 特にバックアップがある場合。 データを永久に失うことを心配しているからといって、それを復元したいと思うかもしれないからではありません。 それは健康的ではありませんが、安いスペースは不幸なイネーブラーです。 これが選択によって「非アクティブ」にされたアカウントである場合、私の気持ちはより複雑になりますが、それについては別の機会（または今）で話し合うことができます。

ええ、これは熟考すべき大きなトピックです。 このユーザーが使用したタグ（例： aries city-point ）があるかどうかを確認したところ、実際には、このユーザーに完全に分離されたタグはほとんどないことがわかりました（ purelabは元々ShanHeがDIY浄水器について使用し、 research-notesは元々ウェブサイトの研究ノートのデザインについて議論する投稿に使用されていました）。

このユーザーはモデレートされているので、タグの視覚化により、モデレートされたユーザーからすべてのコンテンツを除外できますか？さらに、他の人のコンテンツで使用される可能性があるため、そのタグを一般的に除外せずに、その人のコンテンツで使用されるタグを除外できますか？

@ebarry 、明確にする必要があります（そうでなかった場合）。

私が言ったとき：

データベースからタグを完全に削除します

私はあなたが閉じたものを意味しました：

... [その]私たちのタグの視覚化は、モデレートされたユーザーからすべてのコンテンツを除外します。さらに、その人のコンテンツで使用されるタグは、他の人のコンテンツで使用される可能性があるため、一般的にそのタグを除外することはありません。 ..

モデレートされたユーザーとShanHeの両方がタグ「purelab」を使用した場合、「purelab」は削除されず、モデレートされたユーザーまたはITMUからのタグのインスタンスのみが削除されます。

残りの質問（@jywarrenを理解している場合）は、これらのITMUをデータベースから完全に削除するかどうか、またはデータベースに保持するが、すべてのタグが視覚化のために要求されたときにITMUを除外するかどうかです。 それらを削除すると、視覚化を実装する人の生活がはるかに楽になりますが、それらを保存するための議論があるかもしれません。

個人的には、前者は、コンテンツがサイトに戻る可能性がないため、ユーザーがモデレートされていれば問題ないと思います。 ただし、ユーザーがアカウントを再アクティブ化できる機能があるかどうかに基づいてアカウントを削除することを選択した場合、これは異なる場合があります。 私たちはその状況を別の機会に残すことができると思いますが、記録のために、私の司法意見は範囲が限られていると言いたかっただけです。

はいいいえ心配しますNodeTagsはタグを削除せず、リンクを関連付けるだけです
ノードと作成者のタグ。 私はすでに実際にそれをしましたが、フラッシュする必要があります
毎週のキャッシュ（これがこのすべてを可能にした理由です）そして
今日出てきたばかりの、最初に対処する緊急のバグがいくつかあります。ごめんなさい。

2019年1月28日月曜日、午後3時24分に巧みにカール< [email protected]
書きました：

@ebarry https://github.com/ebarry 、明確にする必要があり

私が言ったとき：

データベースからタグを完全に削除します

私はあなたが閉じたものを意味しました：

... [それ]私たちのタグの視覚化は[モデレートからすべてのコンテンツを除外します]
ユーザー（ひいてはその人のコンテンツで使用されるタグ）なし
そのタグを一般的に除外すると[他の人に使用される可能性があるため]
コンテンツ...

モデレートされたユーザーとShanHeの両方がタグ「purelab」、「purelab」を使用した場合
モデレートされたユーザーからのタグのインスタンスだけが削除されます
または、必要に応じてITMUの。

残りの質問（@jywarrenを理解している場合
https://github.com/jywarren ）は、これらのITMUを削除するかどうかです
データベースから完全に削除しますか、それともデータベースに保持しますがフィルタリングしますか
すべてのタグが視覚化のために要求されると、ITMUは停止します。

それらを削除すると、実装者の生活がはるかに楽になります
視覚化、しかしそれらを保存するための議論があるかもしれません。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/1502#issuecomment-458244753 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABfJzTXlk18FzlER4PQyoomFE5VTFcrks5vH0AqgaJpZM4OOvLP
。

OK、モデレートされたユーザーによって作成されたすべてのタグを削除することができました。 それらはバックアップに保存されます。 これは非常に簡単で、他のソリューションとは異なり、コードの進行に影響を与えることはありません。

ここで、使用したい別のレイアウトがある可能性があることを提案したいと思います。 coseレイアウトを使用しており、バリエーション（ bilkentなど）がありますが、 colaレイアウト。 ここで使用するのに適切なものは本当にわかりませんが、リンクの絡みが少ないように見えるものもあります。 http://js.cytoscape.org/のデモの多くは、データセットよりも相互リンクが少ないですが。 どんな入力でも大歓迎です！

http://js.cytoscape.org/#layoutsにある組み込みレイアウトのドキュメント

誰かにテストして取り上げてもらうように試みることができるもう1つの問題は、コミュニティの検出の問題です。 それがどのように機能するのか、なぜここでグループを認識しないのか理解できませんでした。 色は素晴らしいですが、コミュニティごとに1つのノードです。 ああ。

したがって、この問題は次のように分割する必要があります。

1. レイアウトの反復（現在の群衆からの入力歓迎）
2. コミュニティの検出
3. 追加のタグフィルタリング（スパムを取り除くために、未承認のノードがないタグを除外する可能性がありますか？）

また、指定された数のタグが表示されていることを再確認したいと思います（https://stable.publiclab.orgにない限り、これを制限までテストしないでください-最大1000個のタグを試し、ロードされます結構ですが、本番サーバーでは一度でもそれ以上はしないでください）

また、それらの間のリンクに制限されており、各タグは、同時に発生した最大10個のタグを報告します。 これは包括的ではありませんが、最適化と徹底性の実現可能なバランスのように見えました。

https://github.com/cytoscape/cytoscape.js-cola

http://js.cytoscape.org/#demos

@jywarren 、これはまだ最新のコミットですか？ エンドポイント/tag/graph.jsonから来るjsonを見たかったので、すべてのタグが送信されました。 そのコミットのコードに基づいて、私は250がハード制限になると予想していました（私のRuby可読性ノートは耐えられます）。

@jywarrenは気にしないでください。グラフが本番サーバーにあることに気づかず、stable.publiclab.orgを使用していました。

わかった。 私はこれを調査するのにかなりの時間を費やしました、そしてグラフがどのように機能しているかについてより良い感覚を得ています。

今、私たちが使用したい別のレイアウトがあるかもしれないことを提案したいと思います-私たちはコースを使用しています

見て考えてみます。 ここで答える必要のある質問は、グラフから何を収集したいのかということだと思います。 たとえば、訪問者がどのタグがどのタグに関連付けられているかを確認できることに主に関心がある場合は、円のレイアウトまたは同心円が最適であり、退屈である可能性があります。

CoSEがそれほど大きな結果をもたらさない理由について推測する必要がある場合（情報に基づいていますが、それでも推測です）、データを見ると、特定のノード数に達すると、数が始まります。すべてが似ている。 したがって、CoSEがノードの重みのみに基づいてノードを反発している場合、ノード間に同じ量の反発がある可能性があります。 ここで反発を使用する場合、反発に入るすべてのものを意味します。たとえば、重力の設定も同様です。 その場合、アルゴリズムの反復が十分でないか、反発係数が十分な拡散を引き起こさない/許可しない可能性があります。

誰かにテストして取り上げてもらうように試みることができるもう1つの問題は、コミュニティの検出の問題です。

少し時間があれば、これに関する最新のJavaScriptを使用したコミットを教えていただけますか？ 私はそれをブラウザを通して得ることができますが、それが構造を持たず、たった1行であるその形式でのみです。 私がそうするやいなや私はもっと見ることができます。 jLouvainの例を見ましたが、問題の一部である可能性のあるコミュニティの数を設定していないようです。 通常、ルーバンは「最良の数」を提供しますが、最良ではない場合もあります。 jLouvainが基づいているPython実装にはこのパラメーターがありますが、それが終わっていない可能性があります。

あります：

ああ、私は別のコメントを残したと思いました...それはどこに行きましたか？ ちょっとまって...

とにかく、私はレイアウトの問題のいくつかを理解したと思いますが、自分で判断すると言うつもりでした：

https://publiclab.org/stats/graph?limit=50

https://publiclab.org/stats/graph?limit=100

https://publiclab.org/stats/graph?limit=250

https://publiclab.org/stats/graph?limit=500

コミュニティ検出用のJSは次のとおりです： https ：

そして、これがレイアウト構成です。これを試してみるために多くの調整を行うことができます。

https://github.com/publiclab/plots2/blob/e26c6a3c7031d75259a3adc1cdbe0f85c3dba401/app/views/tag/graph.html.erb#L95 -L179

まず、コーディング側の手間のかかる作業を手伝うことができないことをお詫びしたいと思います。 提案するのは簡単ですが、それも人がやらなくてはいけないことを実感しており、その点で手伝っていないことも忘れられません。

jLouvainがうまく機能しない理由については、いくつかの可能性があります。 @jywarren 、あなたはすでにそれらの1つを解決していると思います。それは、十分な色がなかったということです。 それでも、コミュニティのコンソールをチェックインしました。各ノードは異なるコミュニティであり、アルゴリズムが停止するのに適した場所を見つけていないことを意味します。 通常、必要なコミュニティ/感度/解像度の数に関するパラメーターがあり、適切に見えるものが得られるまでそれを試してみます。

jLouvainリポジトリでこの問題を参照してください。 誰かが実装できる非常に簡単な修正を書きました。 何が返されるかという点でどのように機能するかはよくわかりません。理想的には、配列内の各要素のコミュニティ検出結果全体を返しますか？ それは素晴らしいことであり、おそらく各ノードがそれ自身のコミュニティであるという問題を解決するでしょう。

もっと後で…

別のチャネルで疑問に思っていた@shapironickからの質問を中継して、将来のエディションで接続線の薄さと太さが変化して、2つの特定のタグがどれほど密接に関連しているかを示しますか？ ありがとう！

それは素晴らしい考えです。 この時点で、これを閉じて開く必要があると思います
ディスプレイの可能な改良点のチェックリストに関する新しい問題、および
初心者にとってははるかに簡単です（必要なコンテキストと履歴が少なくて済みます）
参加）参加して、それらの実装を開始します。 私はほとんど誘惑されます
/このグラフだけ/である新しいリポジトリにスピンアウトします。
それ以外の場合はPLコードベースと相互接続しませんが、
コミュニティの結束はそれをplots2に保ちましょう。

リズ、あなたは新しい問題を始めて、チェックリストで始めることができますか？

11:17リズバリーの水、2019年2月6日に[email protected]書きました：

@shapironickhttps ：//github.com/shapironickからの質問の中継
将来の版であるかもしれないかどうか別のチャンネルで疑問に思っていた人
接続線の薄さと太さを変えて、どれだけ近いかを示します
関連する2つの特定のタグはありますか？ ありがとう！

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/1502#issuecomment-461083862 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABfJ9nxysbBtCAYHEW2tA8UwNH9zelFks5vKv_hgaJpZM4OOvLP
。

わーい！ @shapironick！ 現在、データベースクエリは、上位n個のタグとそれらのタグの数のみをサイト全体に送信します。 将来的には、エッジの重みを設定するために、バックエンドで変更を加えて、すべてのタグをフロントエンドに送信し、相互接続カウントを集計できるようにするか、タグをフロントエンドで集計する必要があります。バックエンド。 または、フロントエンドで、ネットワークエッジプロパティを計算します（たとえば、中心性：次数、近さ、中間性など）。

とてもかっこいい！ 新しい問題を開始するためのそのアイデア+1のプレッシュはありませんこれは壮大で素晴らしいです！

現在、グラフコードに渡すデータでは、1つのタグ（たとえば、タグA）がタグBにリンクされていることを確認し、タグBがタグAにリンクしている場合は2番目の接続を確認していると思います。それは私たちに多くを教えてくれません。 「重み」を提供するためのリファクタリングは興味深いです...私もこれを行うためのいくつかの方法を想像することができます。 私は同意します。各タグが持つすべてのnode.idsを渡してローカルで計算するか、各タグの最も関連性の高い上位5つのタグを収集するときにこれを事前計算することができます。 （最近これを10に変更したと思いますが、とにかく）。

素晴らしいフォローアップの改良。 チェックリストができたら、少し優先順位を付けて、徐々に改善することができます。 ありがとう！

ああ、これは歴史的な記録になりました;）： https ：

来たる夏のSummerof Codeプロジェクトの可能性についてこれを調べていると、コミュニティ検出のバグが微妙であることがわかりました。データは、 { DATA }だけでなく、 {data: { DATA }}ようなネストされたオブジェクトにありました。 https://github.com/publiclab/plots2/pull/9169で修正されました！

これは私たちのテストデータだけです。 完全な修正は、サーバーをマージして再構築すると、安定したサーバーに表示されます。 おそらく30メートルかそこら。

いいですね：

https://stable.publiclab.org/tags （新しい変更をマージするたびにこれが10mダウンすることを忘れないで