Talk:Community structure

Towards a more quality article[edit]

I am a student who has spent some time with community structure research lately and would like to take this opportunity to say a few words in the spirit of making this article considerably more valuable to the community of Wikipedia browsers and persons wanting to know more on this subfield of complex networks.

Though I did not initiate this article, I noticed its existence a while back, and feel it's time we talk about getting it to a much better state of existence. I appreciate whoever took the time to add the page as it is a valuable area of research that has grown in recent years. That said, I will soon begin a draft of a considerably revised page and post its meat in this section. I thought I'd post this initial discussion-starter for anyone who has placed this page on their watch list and would be interested in posting some thoughts as to how to proceed. Looking forward to it,

Geetduggal 03:03, 29 April 2007 (UTC)[reply]

Needs a lot of work[edit]

This article is very out of date now (July 2011). There is insufficient mention of overlapping community detection, and too much attention is given to one particular method (modularity maximization) which is known to be somewhat problematic among the research community. I think I'd prefer a page that didn't try to enumerate all the methods, but which focussed on a general introduction to the field. Also, the claims about the prevalence of scale-free networks do not stand up, and are not relevant to this article. Any thoughts? Aaron McDaid (talk - contribs) 10:40, 16 July 2011 (UTC)[reply]

Remove Surprise[edit]

The Surprise method was published in PLoS ONE and there have been many other methods for determining community structure that have been published in much more reputable journals, including Science, PNAS, Nature. These should have precedent over the PLoS ONE method. Was it added by the authors? — Preceding unsigned comment added by 123.243.19.20 (talk) 11:10, 3 June 2012 (UTC)[reply]

I agree. This method is very new, and there is no indication it has gathered wide acceptance. There are hundreds of methods of community detection, only very few of which are widely adopted. I don't think 'surprise' should be mentioned here. executive_override (talk) 14:41, 28 February 2013 (UTC)[reply]

- Actually, surprise-based algorithms have been in use since 2005. See new edit of the Surprise article. — Preceding unsigned comment added by 161.111.219.29 (talk) 11:38, 1 March 2013 (UTC)[reply]
  - This is a paper from one of the same authors. How about providing some reference of _other_ authors using this measure, and attesting to its importance? I haven't found much in the literature. executive_override (talk) 12:28, 5 March 2013 (UTC)[reply]

- - The 'Surprise' edits are getting a bit silly. This sentence is exactly the sort of unconstrained bold claim that Wikipedia should stay clear of: "a recent article has shown in synthetic benchmarks that Surprise maximization is the best strategy currently available". I do not want this article to become a Usenet forum with a bunch of academics pissing on each others methods. Academic papers always overhype their methods, and Wikipedia should be more boring. Aaron McDaid (talk - contribs) 15:01, 4 March 2013 (UTC)[reply]

This is getting childish. 161.111.219.29 just undid all my edits without any discussion here in the talk page. Let's calm things down. There are a number of distinct issues with the Surprise section.

There is a major question as to whether Surprise should be included in any form. There will never be a shortage of recent papers that claim to be the best thing since sliced bread. Modularity really does need to be mentioned, even if only in a historical context, because there was a massive amount of research on it. But if we let Surprise in, then the floodgates will be open. We could simply have a short section that gives one short sentence describing a variety of recent methods.
The Surprise section is not the right place to attack modularity. And, with all due respect, the current Surprise section is quite inaccurate in its description of modularity. The claim that modularity ignores the number of nodes is just plain wrong.
'Beating modularity' is nothing to shout about. Modularity is really rubbish and easy to beat. We've all done it. It is not appropriate to claim imply that 'beating modularity' is sufficient to be seen as the leading method.

In short, Surprise does not deserve a section on its own. There are a variety of methods based on objective functions (let's not forget Infomap), and we shouldn't imply that Surprise is especially important. Aaron McDaid (talk - contribs) 16:50, 4 March 2013 (UTC)[reply]

It is obvious that you have not read the surprise papers at all. Please read them and get an objective opinion. Otherwise, it is not childish, it is anti-scientific. Those papers have shown that surprise maximization outperforms all the algorithms tested, which include almost all the best ever tested in complex benchmarks (actually ALL the best available when the surprise study started). Of course, it beats Infomap, so far considered probably the best of all them (please READ the paper). Second, modularity does not take into account the number of nodes in the communities, as you can easily check by yourself. Given a number of intracommunity links, no matter the sizes of the communities (i. e. how many nodes are in them), modularity produces exactly the same result. Third, you say modularity is rubbish, but please consider that this is your opinion, not a general view. Modularity is still the most widely used method (several papers/week) and several modularity maximizers (e. g. Louvain) are still considered among the best algorithms available. All that is basically untrue, but still it is widely thought. In summary, I will be happy to let your changes stand, as soon as they have something to do with reality. — Preceding unsigned comment added by 161.111.219.29 (talk) 17:09, 4 March 2013 (UTC)[reply]

It is not appropriate to expect everybody to read every paper. I will not be apologizing for not having read the Surprise papers. Also, it is clear that you are getting very distracted by modularity. Your comments on modularity should be kept in the modularity section. I understand modularity, and some other methods, very well as I studied them in the earlier parts of my PhD. I'm not going to allow you to imply that you're the only person with relevant expertise. Aaron McDaid (talk - contribs) 17:18, 4 March 2013 (UTC)[reply]

This is very arrogant and misses the point entirely. Regardless of how you evaluate the method to be, it is simply not well established in the field. The surprise papers cited in the article have a very low citation count (most of which are by the author themselves in later papers), at least when comparing to the other methods in the article. It is completely misleading to include this here. And for the record, I for one _have_ read the surprise papers, and I think its relevance is overstated. executive_override (talk) 12:24, 5 March 2013 (UTC)[reply]

So, we conclude that you want to change randomly a section that is about a topic you don't have a clue about. Please reconsider and read the papers before having an opinion. This, I think, is a safe advice. — Preceding unsigned comment added by 161.111.219.29 (talk) 17:24, 4 March 2013 (UTC)[reply]

It is really childish to "conclude" something in behalf of the others, not to mention incredibly arrogant. Remember: It is not the world which needs to prove to you that this method is not relevant, but it is the other way around. Arrogance will get you nowhere. executive_override (talk) 12:24, 5 March 2013 (UTC)[reply]

No reason to change the article — Preceding unsigned comment added by 95.62.136.224 (talk) 06:31, 6 March 2013 (UTC)[reply]

I think it is best to eliminate the surprise section until real value can be evaluated — Preceding unsigned comment added by 95.62.136.224 (talk) 06:49, 6 March 2013 (UTC)[reply]

Sorry for being arrogant. I also think best to delete Surprise until trolls forget about it. — Preceding unsigned comment added by 161.111.219.29 (talk) 09:18, 7 March 2013 (UTC)[reply]

This is a very poor article. Many important methods are not included and some of the included have either been demonstrated poor in standard benchmarks (e. g. modularity) or have not been properly tested. Also several minor works are included, while several milestones of the field are missing. I also see a very negative attitude by some of the editors in this talk page, which have led to the elimination of some methods for no particular reason. I suggest to change the structure of the article to include 1) Benchmarks used to test methods; 2) The best methods, according to those benchmarks. Also important is to coordinate what is written here with the "Graph partition" article, which seems to be a totally different topic if you read both. — Preceding unsigned comment added by Zombieanalytics (talk • contribs) 08:15, 12 June 2014 (UTC)[reply]