Codemotion Rome 2020: an overview of the companies involved

Before the COVID-19 emergency, Codemotion was in the process of organising the next big conference. The Call for Papers for Codemotion Rome 2020 had been closed with staggering numbers: 646 proposals submitted!

That Conference was then cancelled. But we can still peruse the past experience by having a look into those submissions.

If you want to know more about how modern technologies and tools can support you for – and during – the organisation of a virtual event, don’t miss this article showcasing the best tools we used to host our online conferences since the COVID-19 outbreak.

Deep dive into the data: Companies

In the first two posts of the series I analysed only a portion of the Codemotion Rome 2020 data imported into Neo4J, with a particular focus to Communities from different angles. But the data ingested contains more information, like Companies, where the author who submitted work for. In this third post of the series, I’m going to explore the relation between the companies and the other entities in the data to see if it is possible to find out interesting patterns.

To warm up a bit, let’s start with something simple, like “which is the most active company?”

Let’s remind the data model before implementing the query:

In order to find out this first information we can reuse one of the query I used in the previous posts to compute the degree of each company based on the paths in the database:

// Paper presentati per compagnia
MATCH (company:Company)
WHERE NOT company.name = ""
WITH company, size((company)<-[:WORKS_AT]-()-[:PRESENTED]->(:Paper)) as degree
ORDER BY degree DESC
RETURN company.name, degree

Showing the first 5 results we can identify a clear winner:

Submissions from IBM are about 2 times more compared to the second ones: all three companies are roughly from the same size, in terms of employees, so that’s interesting to see. 

Another interesting fact is that in the third position, before “Hotels.com” there’s “CodeValue”: a company that compared to the rest of the rankings is much smaller (~200 employee based on LinkedIn information), nevertheless they managed to submit a considerable number of talks to this conference edition.

What about the rest of the companies? How many submissions did they send?

Let’s use a visualization to answer this overview question:

// Companies -> Paper
MATCH (company)<-[:WORKS_AT]-()-[:PRESENTED]->(paper:Paper)
WHERE NOT company.name = ""
WITH company, paper, apoc.create.vRelationship(paper, "RELATED", {}, company) AS r1
RETURN company, paper, r1

Also in this case I’m using the virtual relation APOC feature to draw a direct link between a paper node (submission) to a company node:

As expected, the IBM cluster is the one in the center, where multiple yellow nodes (“Paper”/submissions)  are connected to the blue node (Companies):

The other clusters shown are those in the first ranking result: RedHat, Google, CodeValue, Hotels.com, Toptal and more…

The rest of the visualization looks mostly like a “snowstorm” plot, a bit like crystals of snow on the screen, which probably leads to the fact that each company submitted in general one or two talks.

Another interesting angle that this visualization offers is the opportunity to find talks with co-speakers from different companies.

A talk is usually delivered by a single person, but occasionally a couple or more people may want to present a particular topic. In this case the author can point to a co-speaker in the submission form, and the co-speaker information are saved in the platform.

At this point two scenarios may happen: the co-speaker is a colleague of the author (he/she belongs to the same company), or works for a different company.

In the former scenario the pattern in the visualization looks like the following:

While in the latter scenario, the pattern looks like the following:

Out of all the 646 submissions how many submissions include a co-speaker?

// Paper with co-speakers
MATCH (paper:Paper)
WHERE size((:Speaker)-[:PRESENTED]->(paper)) > 1
RETURN COUNT(paper)

There are 39 submissions with a co-speaker.

Of these, how many of these are from different company?

// Paper with co-speakers from different companies
MATCH (company:Company)<-[:WORKS_AT]-()-[:PRESENTED]->(paper:Paper),
     (company2:Company)<-[:WORKS_AT]-()-[:PRESENTED]->(paper)
WHERE NOT company.name = "" AND NOT company2.name = "" AND company <> company2
RETURN COUNT(DISTINCT paper)

Before giving the result, maybe it’s better to explain the query: in the MATCH clause I express 2 paths: one from a Paper to a Company, then from the same paper to another Company (company2), in the WHERE clause it is imposed then that “company” (the first one) and “company2” are not the same node.

The result of the query is 25: therefore in 25 submissions the authors are more than one and from different companies.

Sometimes what looks like a real collaboration is just an artifact coming from dirty data, (i.e. a typo in the same company name). That’s a reminder to always properly clean up your data before running any analysis, so be sure to always double check your data before jumping to conclusions!

Also visualizing the results can help to spot these wrong scenarios as well: either by a network visualization or with a table. A visualization sometimes, like the next one, can be much faster and more effective compared to preparing the right shape of the table to print.

// Paper co-speaker from different companies
MATCH (company:Company)<-[:WORKS_AT]-()-[:PRESENTED]->(paper:Paper),
     (company2:Company)<-[:WORKS_AT]-()-[:PRESENTED]->(paper)
WHERE NOT company.name = ""
 AND NOT company2.name = ""
 AND company <> company2
// this constraint is an implementation trick to avoid path duplicates
 AND id(company) < id(company2)
WITH company, paper, company2,
    apoc.create.vRelationship(paper, "RELATED", {}, company) AS r1,
    apoc.create.vRelationship(paper, "RELATED", {}, company2) AS r2
RETURN company, paper, r1, company2, r2

The query this time is a bit more complex than the previous one: when counting the submissions in the previous query statement it didn’t matter if there were duplicate paths, as at the end when returning the results were filtered by a “COUNT( DISTINCT paper )” which takes care of it.

In this case having duplicate paths means having for each pair of nodes a pair of “virtual Relationships” which will reduce the effectiveness of the visualization: imposing an artificial constraint on the id of the company will pick only a single version for each path returning the right result.

Codemotion Rome 2020: want to know more?

Do not lose the next post from the series where I’m going to analyse how companies relate to communities.

In the meanwhile, if you are interested in Codemotion Rome 2020, do not miss the opportunity to attend: tickets are still available!