Plots2: 모든 태그의 태그 시각화

안녕하세요, Liz - 저는 우리의 영구 코드베이스에 이와 같은 정적 그래픽을 넣는 것을 약간 꺼려하지만, 아마도 페이지 상단에 "기능"(예: 배너)을 표시한 다음 관리자에게 그들이 원하는 것을 거기에 표시할 수 있습니다. 그게 효과가 있을까요?

다음 줄 위 또는 아래로 이동합니다. https://github.com/publiclab/plots2/blob/master/app/views/tag/index.html.erb#L4

그리고 다음과 같이 보입니다.

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

글쎄, 나는 "한눈에 통찰"을 추가하고 싶기 때문에 그 페이지를 꾸미고 싶지 않습니다.
다른 요점이지만 그래픽 시각화를 추가하는 것을 제안하는 이유와 관련하여 아마도 이 태그 페이지에는 지역별로 둘 중 하나를 보기 위해 훨씬 적게 "최근" 또는 "인기"를 볼 수 있는 정렬 기능이 없다는 것입니다.

실제로 동적으로 생성하는 데 사용할 수 있는 python gephi 바인딩이 있습니다. 저는 실제로 지금 자바스크립트 네트워크 시각화 작업을 하고 있으므로 어떻게 작동하는지 보겠습니다. 잘 되면 데이터 구조를 생성한 다음 자바스크립트로 시각화할 수 있는 파이썬 스크립트로 내가 한 일을 번역할 수 있습니다.

안녕하세요, 제 생각에는 생성된 그래프가 훌륭할 것이며 영구 코드에 넣을 수 있는 것입니다.

@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 문제가 될 수 있습니다!

이 문제에 대한 기본 사항으로 돌아가 보겠습니다. :)
태그 시각화의 목표는 무엇입니까?

나에게 태그 시각화는 연결된 태그, 예를 들어 동일한 콘텐츠에 함께 나타나는 태그를 시각적으로 묘사하는 방법입니다. 좋은 예는 위의 @skillfullycurled 의 시각화에서 색상으로 구분된 클러스터를 참조하세요. 클러스터링 태그는 커뮤니티 활동에 대한 웹사이트의 프레젠테이션을 _closer_ 공공 연구소 커뮤니티가 문화적으로 "연구 영역" 또는 아마도 "주제"라고 부르는 것과 시각적으로 연결하기 때문에 중요합니다. --> 이것이 이 전체 문제에 대한 저의 실제 목표입니다.

다음은 몇 가지 배경 정보입니다. 태그 페이지(https://publiclab.org/tags)에서 "우리는 태그를 사용하여 주제별로 조사 그룹화"를 작성하고 사람들이 태그를 탐색하도록 권장합니다(현재는 최근 활동으로만 정렬됨). 이것은 우리가 주제를 찾고 참여할 수 있도록 사람들에게 이름을 지정하고 연결하고 홍보하는 중요한 방법입니다. 대시보드 자체는 최근 활동을 강조합니다. 대시보드에는 이제 "최근에 사용한 태그" 표시줄이 있습니다. 이는 "연구 영역" 또는 "주제"를 보는 목표에 대한 중요하지만 부분적인 단계입니다.

앞으로 나아가기 위해 나는 그래픽 태그 시각화(2007년!)에 의한 _탐색_에 관심이 없지만, 활동 클러스터는 주제에 연결/탐색하는 중요한 추가 방법을 제공합니다. 가장 상호 연결된 태그를 표시하는 태그 페이지의 기능을 의미하는 목표를 달성하기 위해,

또한 publiclab.org/topics에서 publiclab.org/tags를 미러링하여 언어에 더 쉽게 접근할 수 있도록 할 수도 있습니다.

쿨, 고마워 리즈!

이 목표를 위해 더 좁은 기능을 한 번 찔러보기 위해 태그 페이지(부동 새 이름: 주제 페이지 ...!?!)에 다음과 같은 "관련 주제" 목록이 있다면 어떨까요?

관련 주제: water runoff wetlands turbidity

여기서 "관련된"은 (이를 측정하는 다양한 방법이 있으며 "계산적으로 효율적인" 방법을 원한다는 것을 인정) 이것이 이미 기본 태그가 있는 페이지에 가장 일반적으로 나타나는 태그임을 의미합니다. 그래서 주제를 onions , 우리는 집계 모든 페이지는 태그 onions 상단, 말, 다섯을.

위의 내용이 괜찮다면 소규모 후속 조치 -- 가장 최근의 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

2017년 11월 15일 수요일 오후 9시 54분, Jeffrey Warren [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에 파일을 업로드할 수 없습니다. Public Lab 연구 노트에 업로드하려고 했지만 작동하지 않습니다. @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: 계산된 속성이 있는 노드 목록. 각 노드가 속한 커뮤니티를 알려주는 "모듈화 클래스" 웹사이트의 이미지와 가장 관련이 있습니다.

plots_tag_communities_9_16.json: json이 유용하지는 않지만 선호하는 사람들도 있다는 것을 알고 있습니다. json 파일에는 웹사이트에 있는 시각화에 대한 속성도 포함되어 있다고 생각합니다(즉, 각 노드의 RGB 색상).

업데이트: 위의 파일 목록에서 plots_tag_communities_edgelist_9_16.csv를 제거했습니다. 이 파일은 중복된 가장자리가 이미 가중치가 있는 고유한 가장자리로 병합되었기 때문에 제한적으로 사용됩니다. 속성이 없으면 이 간선 목록을 사용하면 간선 가중치가 1인 그래프만 작성할 수 있습니다. 중복된 원본 파일을 찾아보겠습니다.

@skillfullycurled 답변 감사합니다!

실제로 publiclab.org 웹사이트에 쉽게 추가할 수 있도록 자바스크립트 라이브러리(d3.js 또는 vis.js )를 사용하여 시각화 그래프를 만들려고 했습니다. 이러한 라이브러리에는 다음 형식의 데이터가 필요합니다.

노드의 경우 nodes: [ { id: 1, shape: 'circle', label: 'Infrared } ] .

그리고 가장자리의 경우 :
edges: [ {from: 1, to: 2}, {from: 1, to: 3}]

글쎄요 json은 훌륭할 것입니다. 그렇지 않으면 생성하거나 Javascript 객체를 직접 생성할 수 있습니다.

더미 그래프를 만들었습니다(여기서 노드와 에지를 가지고 놀 수 있습니다 😄 ):

어떻게 생각하나요 ? @ebarry , @jywarren , @skillfullycurled

아. 그것은 굉장할 것입니다! 괜찮아. 이 대화를 더 진행하려면 "API 영역"에서 벗어나 Gephi의 시각화가 작동하는 방식과 이러한 기능을 자바스크립트로 변환하는 가장 좋은 방법으로 이동해야 합니다.

질문 으로 시작하는 것을 귀찮게 해도 될까요? "Gephi에서 생성된 태그 시각화를 자바스크립트 버전으로 어떻게 번역합니까?"와 같은 것입니다.

또한 benj에 이메일을 보내주세요. [email protected]로 파일을 공유할 수 있습니다. 일단 제 이메일을 삭제하겠습니다.

사실 우리는 API 랜드를 떠날 필요가 없다고 생각합니다. 기존 API는 요즘 꽤 강력합니다. @skillfullycurled 어떻게 그 가장자리를 생성했는지 궁금합니다.

모든 태그와 태그가 사용된 노드 목록에서 새로 생성할 수 있습니까? 캐시된 경우 생성할 수 있는 합리적인 쿼리입니다.

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 -land를 떠나지 않는 것에 동의합니다. :)

아르그! 괜찮아. 쌓아두지 맙시다. 나보다 API 영역에 더 머물고 싶어하는 사람은 아무도 없습니다(아마도 @ebarry 제외). 내 이해로는 API 랜드의 구축이 웹사이트 부진에 대한 우려로 인해 무기한 연기된 것 외에는 거의 없었습니다( 여기에서 대화 확장 참조 ). 그러나 이제 @jywarren 은 더 이상 큰 문제가 아니므로 좋은 시간이라고 말합니다.

Github를 사용하는 것은 접근 가능한 정보에 대한 장벽이 될 수 있기 때문에(모든 사람이 접근할 수 있는 것은 아니며 사용법을 알고 있음), 코드베이스에서 "일을 끝내는 것"이 ​​아닌 대화를 나누는 것이 더 낫다고 생각합니다. 모두가 배울 수 있는 웹사이트. 이것들은 내가 설정한 커뮤니티 규범이 아니지만( 위 의 @jywarren 자신의 의견 참조 ) 좋은 기준이라고 생각합니다.

죄송합니다 @skillfullycurled 해당 스레드에 대한 마지막 댓글을 기억하지 못했습니다 -- https://publiclab.org/questions/tommystyles/10-20-2017/need-your-feedback-on-tag-pages#answer - 556-comment-17709 -- 제안한 곳:

1. 상위 250개 태그에서만 실행
2. 매주 캐싱

그곳에서 다시 핑을 하겠지만, API, 코드 정리 및 지원에 대한 모든 작업을 통해 이러한 쿼리의 일일 또는 주간 캐시 버전을 수행할 수 있으며 총 계산 시간은 10-15초면 충분합니다. 주당 시간. 나머지는 브라우저에서 로컬로 실행됩니다. 거기에서 이것을 반복합니다.

@jywarren 몇 가지 질문에 대해 답변을 드리겠습니다. 내 jupyter 노트북을 나중에 게시할 것입니다. 그동안 태그 쌍에서 그래프가 생성되는 방법에 대한 간략한 설명은 여기 를 참조 여기를 참조

@sagarpreet-chadha(및 관심 있는 모든 사람)는 이 프로젝트의 영감을 준 tagoverflow에 대한 repo를 확인하여 태그 데이터에서 d3.js 그래프가 어떻게 생성되었는지 확인할 수 있습니다.

커뮤니티 감지와 관련하여 tagoverflow 저장소를 살펴보면 작성자가 자체 알고리즘을 구현했음을 알 수 있습니다. 그 이후로 jLouvain , netClustering CNM 구현( d3 예 )과 같은 다른 것들이 구현되었습니다. 태그가 256개로 제한되어 있어 브라우저에서 커뮤니티 감지가 잘 될 것입니다.

많은 데이터로 publiclab.org 토론을 압도하지 않기 위해 다음은 TagOverflow가 사용하는 데이터 형식에 대한 링크입니다.

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

주어진 태그와 관련된 태그를 가져오기 위해 15번의 호출을 합니다(위의 예에서 "python").

그래서 그것과 내가 위에서 생성한 데이터의 차이점은 내 쿼리가 노드 ID를 나열하지만 "관련성"을 설정하는 데 사용하지 않았다는 것입니다. 하지만 물론 @skillfullycurled 의 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/skillfullyshared/plots-tag-graph

폴더에는 내용을 설명하는 추가 정보 파일이 함께 제공됩니다.

공유실을 닫을 수 있도록 다운로드한 후에 알려주세요. 결국 다른 사람들이 위키에서 액세스할 수 있도록 내 github 계정에 게시할 것입니다.

추가 질문에 답변해 드리겠습니다.

@skillfullycurled 감사합니다!
파일을 다운받았어요 :-)

문제없어요 @sagarpreet-chadha!

추신: 나는 당신에게 wiki 질문에서 후속 생각을 남겼습니다.

루비 기반 태그 관련성 계산에 대한 훌륭한 업데이트: https://publiclab.org/questions/bsugar/01-25-2018/how-was-the-tag-graph-visualization-made

더 빨리!

https://github.com/publiclab/plots2/pull/4657 의 일부 진행 상황에서 매우 기본적이지만 Cytoscape.js(http://js.cytoscape.org/)의 라이브 인스턴스를 구현했습니다. 주간 캐시 컬렉션

사이트의 모든 태그에 대해 실행하는 데 50초 이상이 걸렸지만(매주 캐시될 수 있음) 8200개 이상의 태그와 31k 가장자리도 생성했습니다. 다음은 전체 세트입니다. 스팸 태그가 많이 포함되어 있다고 생각합니다. https://gist.github.com/jywarren/4b1f9a032092a8187dd802a375fcb700

다음과 같이 쿼리하려는 태그 수를 지정할 수 있습니다. https://stable.publiclab.org/tag/graph.json?limit=10 (완전히 게시되면 https://publiclab.org/tag/graph. json?limit=10)

현재 태그 이름당 5개의 "가장자리"로 제한되어 있으며 원래 태그와 함께 가장 자주 발생하는 5개의 태그를 나타냅니다.

이것은 이제 안정적인 테스트 서버에서 작동합니다(비록 이 브랜치는 꽤 자주 재구축되어 URL이 항상 온라인 상태는 아닙니다... 아이러니하게도) 여기:

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

limit=100 또는 250과 같은 더 큰 수는 일종의 오류를 표시하는 것 같으며 조금 더 추적해야 합니다. 그러나 이것은 꽤 좋은 시작입니다.

이를 개선하기 위해 추가할 수 있는 많은 구성(노드 크기, 링크 강도 등)이 있습니다. http://js.cytoscape.org 의 갤러리에서 몇 가지 가능성을 확인하십시오. 그리고 "가족"을 만드는 것도 가능할 수 있지만, 그러기 위해서는 조금 더 많은 정보가 필요합니다.

오, https://stable.publiclab.org/stats/graph?limit=300 도 작동하는 것 같습니다

여기에서 커뮤니티 감지! https://github.com/upphiminn/jLouvain/blob/master/README.md

@jywarren ,

또한 다양한 클러스터링 알고리즘이 있습니다. 이러한 알고리즘은 JavaScript 콘솔에서 테스트할 수 있습니다.

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

• eles.markovClustering()
• node.kMeans()
• node.kMedoids()
• node.fuzzyCMeans()
• node.hierarchicalClustering()
• node.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

좋아요, jlouvain 사용하여 커뮤니티 감지를 추가할 수 있었습니다: https://github.com/upphiminn/jLouvain

이것이 어떻게 작동하는지 확인할 테스트 데이터가 충분하지 않지만 #4679가 통과하면 병합하고 다음 위치에서 커뮤니티 감지와 함께 실행되는 것을 볼 수 있습니다.

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

(일단 빌드)

안녕 모두들! 멋져 보입니다. 죄송합니다. 답장을 드리지 못해 죄송합니다. 일이 있어서 오늘 나중에 다시 답변드리겠습니다.

그동안 다른 게시물에서 언급하지 않은 또 다른 요소는 레이아웃입니다. 내가 사용한 것과 가장 가까운 것은 아마도 force 레이아웃 일 것입니다. 기술적으로는 force 레이아웃 2라고 하는 것일 수 있습니다.

힘 레이아웃은 설정한 매개변수(즉, 반복 횟수, 인력/반발의 강도)를 기반으로 정상 상태에 도달하는 일종의 어닐링 인력/반발입니다. 여기 d3 데모가 있습니다.

커뮤니티 감지 및 에지 가중치에 관해서는 몇 가지 옵션이 있지만 이것이 참조하는 태그 그래프를 다시 생성하려면 행운이 있는 것처럼 cytoscape가 만드는 데 도움이 되는 기능이 있는 동시 발생이 필요합니다. 더 쉽게.

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

여기서 tag_count_AB = edge.parallelEdges()

그대로, 나는 먼저 태그 세트의 범위를 합리적인 수(예: 상위 512개)로 좁혔지만, 그 다음에는 관찰된 상위 n개 태그(아마도 64개?)만 포함하여 시각화에 사용한 태그의 범위를 좁혔습니다. 1 이상의 기대 비율에.

태그 오버플로 에서 자세한 내용을 읽을 수 있습니다. 이 방법은 에지 또는 노드 노드가 중요하지만 사용량이 적은 문제를 처리하는 한 가지 방법입니다. 예를 들어, 상점에서 100명의 사람들이 85%의 확률로 커피와 크림을 구입할 _가능성이 있습니다_. 그러나 그 중 5명은 _항상_ 커피, 크림, 계란을 구입합니다. 그래서 저는 확실히 5팩의 계란을 비축해 두고 싶습니다.

쉬운 대안은 두 노드 사이의 에지 가중치를 tag_count_AB로 만들고 주어진 임계값 이상의 에지/노드만 취하는 것입니다. 개인적으로 위와 같은 이유로 좋은 결과를 얻는 경우는 거의 없습니다.

다른 방법에 대해서는 pg 3. (2.2)에서 - pg에 관심이 있을 수 있습니다. 이 문서 의 7(3.1)(이 부분에 대한 수학 없음)에서는 다양한 유형의 커뮤니티 탐지 방법을 분류하려고 시도합니다. 이것은 내가 그래프를 구성한 방법과 그래프에서 알고 싶은 것을 고려할 때 가장 두드러진 결과를 제공하는 것을 선택하는 데 도움이 되었습니다. 예를 들어, 두 사람 간에 메시지가 전송되는 빈도를 기반으로 하는 일반적인 사회적 연결 커뮤니티와 커뮤니티입니다.

지금 안정적인 서버에서 작업 중입니다!

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

여기 w 상위 99개의 태그가 있습니다!

오늘 밤 늦게까지 라이브 사이트에서 실행되어야 하지만 일부 사용자가 태그를 "과도하게 사용"하여 우리가 이전에 인식한 방식으로 그래프가 왜곡되었다는 점에 주목하고 싶습니다. 나는 사용자 중 한 명이 사이트에서 조정을 받았다고 생각하며 사람들이 사이트에서 해당 태그를 삭제하거나 적어도 그래프에서 태그를 생략하는 것이 적절하다고 생각하는지 궁금했습니다. 그것들을 삭제하는 것이 더 쉬울 것이지만 우리는 그것들을 가리기 위해 무언가를 만들 수도 있습니다. 선호, @ebarry @skillfullycurled ?

그래도 가장자리 탄력성에 대한 설정이 여전히 약간의 조정이 필요하고 다른 레이아웃 유형이 더 잘 작동하더라도 이것은 멋지게 보입니다...

예! 우리는 확실히 이 문제에 직면했습니다. 불행히도, 해야 할 유일한 일은 특정 사용자를 이상값으로 제거하는 것이었습니다. 그렇게 많은 태그를 사용하는 사람은 그 자체로 이상치가 아닐 수 있지만 자신에게만 특정한 태그를 만들고 계속해서 사용하는 경우 실제로 데이터를 캡처하는 것이 아닙니다.

나는 심지어 본질적으로 "와아아아아아아아, 쉬웠어요! 거기에 많은 태그를 가지고 있는 것 같죠?"라는 경고를 표시하는 기능 요청으로 github 문제를 기록했다고 생각합니다.

오, 추신. 그나저나 멋진 모습!!

아아아아아아아아아아아아아아아아아아아아아아아아아아아아!!!!!!!!
수동으로 "특정 사용자를 이상값으로 제거"하려면 예

나는 그것이 얼마나 굉장하고 사물에 대해 생각하기 때문에 이 스레드로 계속 돌아가고 있습니다. 필터링을 고려할 수 있는 또 다른 항목은 전원 태그입니다(콜론이 있는 태그, 맞죠?). 태그 남용 문제가 수정되는 대로 레이아웃에 대해 더 많이 알게 될 것이라고 생각합니다.

참고 사항: 구현에 중요한 페이지가 포함된 커밋에 대한 링크가 있습니다.

안녕하세요 여러분, 열정에 반가워요! 나는 아팠지만 지금 회복하고 있으며 화요일에 집으로 돌아가는 비행기에서 이것에 대해 조금 일할 것입니다.

저는 묻고 싶었습니다. 제 구체적인 질문은 다음을 수행해야 하는지 여부입니다.

1. 실제로 이 중재된 사용자의 태그를 삭제하거나
2. 우리가 그것들을 보존하려고 노력하지만 걸러내야 한다면.

필터링은 코드와 데이터베이스 호출 모두에 대해 훨씬 더 많은 작업이 되지만 가능합니다.

검토로 인해 계정이 "비활성" 상태가 된 이와 같은 경우에는 데이터베이스에서 태그를 완전히 삭제하는 것이 좋다고 생각합니다. 특히 백업이 있는 경우. 당신이 그것을 복원하고 싶어하기 때문이 아니라, 내가 데이터를 영원히 잃어버릴까봐 불안하기 때문입니다. 건강에 좋지는 않지만 저렴한 공간은 불행한 조력자입니다. 이 계정이 선택에 의해 "비활성화"된 계정이라면 내 감정이 더 복잡할 것이지만 다른 시간(또는 지금)에 대해 논의할 수 있습니다.

예, 이것은 생각해 볼 큰 주제입니다. 이 사용자가 _only_ 사용한 태그가 있는지 검토한 후(예: aries city-point ) 실제로 이 사용자와 완전히 격리된 태그가 거의 없음을 발견했습니다( purelab 는 원래 Shan He가 DIY 정수 필터에 대해 사용했으며 research-notes 는 원래 웹사이트의 연구 노트 디자인을 논의하는 게시물에 사용되었습니다.

이 사용자는 검토 대상이므로 태그 시각화에서 검토 대상 사용자의 모든 콘텐츠를 제외할 수 있습니까? 더 나아가 해당 사용자의 콘텐츠에 사용된 태그는 다른 사람의 콘텐츠에 사용될 수 있으므로 일반적으로 해당 태그를 제외하지 않고 제외할 수 있습니까?

@ebarry , 명확히 해야 합니다(그렇지 않은 경우).

내가 말했을 때 :

데이터베이스에서 태그를 완전히 삭제

나는 당신이 닫은 것을 의미했습니다.

...[그것은] 우리의 태그 시각화는 [다른 사람들의 콘텐츠에 사용될 수 있기 때문에] 일반적으로 해당 태그를 제외하지 않고 중재된 사용자의 모든 콘텐츠를 제외합니다. ..

중재 사용자와 Shan He가 모두 "purelab" 태그를 사용한 경우 "purelab"은 삭제되지 않고 중재 사용자 또는 ITMU의 태그 인스턴스만 삭제됩니다.

나머지 질문(내가 @jywarren을 이해하고 있는 경우)은 이러한 ITMU를 데이터베이스에서 완전히 삭제할지 아니면 데이터베이스에 보관하지만 시각화를 위해 모든 태그가 요청될 때 ITMU를 필터링할지 여부입니다. 그것들을 삭제하면 시각화를 구현하는 사람들의 삶이 훨씬 쉬워지지만 보존에 대한 논쟁이 있을 수 있습니다.

개인적으로 콘텐츠가 사이트에 다시 돌아올 가능성이 없기 때문에 사용자가 중재되었을 때 전자가 괜찮다고 생각합니다. 그러나 사용자가 계정을 다시 활성화할 수 있는 기능이 있는지 여부에 따라 계정을 삭제하기로 선택한 경우에는 다를 수 있습니다. 나는 우리가 다른 시간 동안 그 상황을 떠날 수 있다고 생각하지만 기록을 위해 나는 단지 나의 사법적 견해가 범위에 제한적이라는 것을 말하고 싶었습니다.

네, 걱정 마세요 NodeTags는 태그를 삭제하지 않고 연결하는 링크만 삭제합니다.
노드와 작성자가 있는 태그. 나는 이미 그것을 실제로했지만 플러시해야합니다
주간 캐시(이것이 이 모든 것을 가능하게 한 것입니다) 및
오늘 방금 발생한 몇 가지 긴급한 버그를 먼저 해결해야 합니다. 죄송합니다!

2019년 1월 28일 (월)에, 3:24 오후 skilfullycurled < [email protected]
썼다:

@ebarry https://github.com/ebarry , 명확히 해야 합니다(그렇지 않은 경우).

내가 말했을 때 :

데이터베이스에서 태그를 완전히 삭제

나는 당신이 닫은 것을 의미했습니다.

...[그것은] 우리의 태그 시각화가 [조정된] 모든 콘텐츠를 제외할 것입니다.
사용자 및 확장하여 해당 사용자의 콘텐츠에 사용된 태그 없이
일반적으로 해당 태그는 제외합니다. [왜냐하면] 다른 사람의
콘텐츠...

중재된 사용자와 Shan He가 모두 "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
.

알겠습니다. 검토 대상 사용자가 만든 모든 태그를 삭제했습니다. 백업에 저장됩니다. 이것은 매우 쉬웠고 다른 솔루션과 달리 코드 진행에 영향을 미치지 않습니다.

이제 사용하려는 다른 레이아웃이 있을 수 있음을 제안하고 싶습니다. cose 레이아웃을 사용하고 있으며 변형( bilkent 및 기타)이 있지만 cola 레이아웃. 여기서 사용하기에 적절한 것은 잘 모르겠지만 일부는 링크를 덜 얽히게 하는 것 같습니다. http://js.cytoscape.org/에 있는 많은 데모에는 데이터 세트보다 인터링크가 더 적습니다. 어떤 의견이든 감사합니다!

http://js.cytoscape.org/#layouts의 내장 레이아웃에 대한 문서

다른 사람에게 테스트하고 처리하도록 요청할 수 있는 또 다른 문제는 커뮤니티 감지 문제입니다. 나는 그것이 어떻게 작동하는지 또는 여기에서 그룹을 인식하지 못하는 이유를 알아낼 수 없었습니다. 색상은 좋지만 커뮤니티당 하나의 노드입니다. 바.

따라서 이 문제는 이제 다음과 같이 나눌 필요가 있습니다.

1. 레이아웃 반복(현재 군중의 입력 환영)
2. 커뮤니티 감지
3. 추가 태그 필터링(스팸을 제거하기 위해 승인되지 않은 노드가 없는 태그를 필터링할 수 있습니까?)

또한 우리가 지금 지정된 태그 수를 보고 있다는 사실을 다시 확인하고 싶습니다(https://stable.publiclab.org에 있지 않는 한 이것을 한계까지 테스트하지 마십시오. 최대 1000개의 태그를 시도했는데 로드됩니다. 괜찮지만 그 이상은 프로덕션 서버에서 한 번이라도)

그리고 각 태그가 함께 발생한 최대 10개의 태그를 보고하는 링크로 제한됩니다. 이것은 포괄적이지는 않지만 최적화와 철저함의 실현 가능한 균형처럼 보였습니다.

https://github.com/cytoscape/cytoscape.js-콜라

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

@jywarren , 이것이 여전히 최신 커밋 입니까? /tag/graph.json 끝점에서 오는 json을 보고 싶었고 모든 태그를

@jywarren 은 신경쓰지 않습니다. 그래프가 현재 프로덕션 서버에 있다는 것을 깨닫지 못했습니다. 저는 stable.publiclab.org를 사용하고 있었습니다.

괜찮아. 나는 이것을 탐구하는 데 상당한 시간을 할애했고 그래프가 어떻게 작동하는지 더 잘 느끼고 있습니다.

이제 우리가 사용하고 싶은 다른 레이아웃이 있을 수 있다고 제안하고 싶습니다.

살펴보고 생각하겠습니다. 여기서 대답해야 할 질문은 그래프에서 무엇을 얻고자 하는 것입니까? 예를 들어 방문자가 어떤 태그가 어떤 태그와 연결되어 있는지 볼 수 있도록 하는 데 주로 관심이 있는 경우 원형 레이아웃 또는 동심원 이 가장 좋고 지루할 수 있습니다.

CoSE가 좋은 결과를 내지 못하는 이유에 대해 추측해야 한다면(정보를 받았지만 여전히 추측) 데이터를 볼 때 특정 노드 수에 도달하면 카운트가 시작되기 때문일 것입니다. 모두 비슷하도록. 따라서 CoSE가 노드 무게만을 기준으로 노드를 반발하는 경우 노드 간에 동일한 양의 반발이 있을 수 있습니다. 여기서 반발력을 사용한다는 것은 반발력으로 들어가는 모든 것을 의미합니다. 예를 들어 중력 설정도 마찬가지입니다. 이 경우 알고리즘의 반복이 충분하지 않거나 반발 요인이 충분한 확산을 일으키지 않거나 허용하지 않을 수 있습니다.

다른 사람에게 테스트하고 처리하도록 요청할 수 있는 또 다른 문제는 커뮤니티 감지 문제입니다.

시간이 되시면 최신 자바스크립트가 포함된 커밋을 알려 주시겠습니까? 브라우저를 통해 얻을 수 있지만 구조가 없고 한 줄만 있는 형식으로만 얻을 수 있습니다. 내가 하자마자 나는 더 많은 것을 볼 수 있다. jLouvain 예제를 보았는데 문제의 일부일 수 있는 원하는 커뮤니티 수에 대한 설정이 없는 것 같습니다. 일반적으로 Louvain은 "최고의 숫자"를 제공하지만 때로는 최고가 아닙니다. 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://github.com/publiclab/plots2/blob/master/app/views/tag/graph.html.erb#L263

그리고 여기 레이아웃 구성이 있습니다. 우리가 시도하기 위해 많이 조정할 수 있습니다.

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

먼저 코딩 쪽의 무거운 짐을 도와드리지 못해 죄송합니다. 사람이 제안하는 것은 쉽지만 사람들이 그것을 구현해야 한다는 것을 깨닫고 제가 도움을 주지 않는다는 사실을 잊지 않습니다.

jLouvain이 잘 수행되지 않는 이유에는 여러 가지 가능성이 있습니다. @jywarren , 나는 당신이 이미 그 중 하나를 해결하고 있다고 생각합니다. 그 중 하나는 색상이 충분하지 않다는 것입니다. 그래도 콘솔에서 커뮤니티를 확인했고 각 노드는 다른 커뮤니티이므로 알고리즘이 중지하기에 좋은 위치를 찾지 못하고 있음을 의미합니다. 일반적으로 원하는 커뮤니티/민감도/해상도에 대한 매개변수가 있으며, 적절한 것을 얻을 때까지 이를 가지고 놀게 됩니다.

jLouvain 저장소에서 이 문제 를 참조하십시오. 누군가 구현할 수 있는 매우 간단한 수정 사항을 작성했습니다. 나는 그것이 반환하는 측면에서 그것이 어떻게 작동하는지 잘 모르겠습니다. 이상적으로는 배열의 각 요소에 대한 전체 커뮤니티 탐지 결과를 반환합니까? 그것은 굉장할 것이고 아마도 각 노드가 자체 커뮤니티가 되는 문제를 해결할 것입니다.

더 늦게…

다른 채널에서 궁금했던 @shapironick 의 질문을

좋은 아이디어야. 이 시점에서 우리는 이것을 닫고 열어야한다고 생각합니다.
디스플레이에 대한 가능한 개선 사항의 체크리스트가 포함된 새로운 문제 및
신규 이민자에게는 훨씬 더 쉬울 것입니다(더 적은 맥락과 역사가 필요합니다.
참여)에 ​​참여하여 구현을 시작합니다. 나는 거의 유혹을 받는다
/단지 이 그래프/인 새로운 저장소로 그것을 스핀아웃하십시오.
그렇지 않으면 PL 코드베이스와 상호 연결되지 않지만
커뮤니티 응집력을 플롯2에 유지합시다.

Liz, 새 호를 시작하고 체크리스트로 시작해도 될까요?

2019년 2월 6일 수요일 오전 11:17 Liz Barry [email protected]에서 다음과 같이 썼습니다.

@shapironick https://github.com/shapironick 의 질문 중계
누가 다른 채널에서 미래 버전에
연결선의 얇음과 두께를 변경하여 얼마나 밀접하게
관련된 두 개의 특정 태그가 있습니까? 감사 해요!

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/publiclab/plots2/issues/1502#issuecomment-461083862 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AABfJ9nxysbBtCAYHEW2tA8UwNH9zelFks5vKv_hgaJpZM4OOvLP
.

야! @샤피로닉! 현재 데이터베이스 쿼리는 상위 n개 태그와 사이트 전체에 해당 태그 수만 보냅니다. 미래에는 에지 가중치를 가지기 위해 모든 태그를 프런트 엔드로 보내서 상호 연결 수를 집계할 수 있도록 백엔드에서 변경해야 합니다. 백 엔드. 또는 프런트 엔드에서 일부 네트워크 에지 속성(예: 일부 중심성: 정도, 근접성, 중간성 등)을 계산합니다.

아주 멋져! 새로운 문제를 시작하는 데 +1이라는 아이디어가 없습니다. 이것은 서사적이고 굉장합니다!

지금 우리가 그래프 코드에 전달하는 데이터에서 한 태그(예: 태그 A)가 태그 B에 연결된 경우를 보고 태그 B가 태그 A에 다시 연결되는 경우 두 번째 연결이 표시된다고 생각합니다. 하지만 그것은 우리에게 많은 것을 말해주지 않습니다. "가중치"를 제공하기 위한 리팩토링은 흥미롭습니다... 저도 이것을 하는 몇 가지 방법을 상상할 수 있습니다. 동의합니다. 각 태그에 있는 모든 node.ids 를 전달하고 이를 로컬에서 계산하거나 각 태그의 상위 5개 관련 태그를 수집하는 순간 미리 계산할 수 있습니다. (나는 이것을 최근에 10으로 변경했다고 생각하지만 어쨌든).

훌륭한 후속 개선. 체크리스트가 있으면 우선 순위를 조금 지정하고 점진적으로 개선할 수 있습니다. 감사 해요!

아 이거 역사적 기록으로 남았어요 ;) : https://publiclab.org/wiki/community-development#2019

다가오는 여름 코드의 가능한 여름이에 프로젝트를 보면서, 나는 미묘한이었다 커뮤니티 감지 버그를 발견 - 데이터가 같은 중첩 된 객체에 있었다 {data: { DATA }} 오히려보다는 다만 { DATA } . https://github.com/publiclab/plots2/pull/9169 에서 수정되었습니다!

그것은 바로 우리의 테스트 데이터입니다. 병합하고 다시 빌드하면 안정적인 서버에서 전체 수정 사항을 볼 수 있습니다. 아마 30m 정도.

우리가 간다:

https://stable.publiclab.org/tags (새로운 변경 사항을 병합할 때마다 10m 동안 감소한다는 것을 기억하십시오)