With no Direction Home... Like a Complete Unknown

BioFabric does not like it when the direction home is a complete unknown! (Or something like that; apologies to Bob Dylan).

This posting will be a quick side trip into an undocumented BioFabric feature that can be useful. Whenever you import a SIF file, each link needs to be tagged with a relationship identifier, per the SIF format:

node1_ID [tab] linkTag [tab] node2_ID

BioFabric displays that link tag whenever you mouse over the link, as well as in the Network Magnifier and Network Tour displays. It also insists on knowing whether the relationship indicated by the tag is directed or not. So after a SIF file has been read in, you are confronted with a dialog box that insists that you identify whether each link tag identifies a directed or an undirected edge in the graph. For example, for this tiny little SIF file: 

foo UNDIR bar

foo DIR   baz

You are presented with this dialog box when you import it:

Click on picture to enlarge

In this case, since we wish the link tagged DIR to be directed, we would check the box on the right side of the row labeled  DIR and then hit the OK button to finish the import. When the number of link tags is small, it's not too onerous, and the benefit is that you can create a graph with an explicit mixture of directed and undirected edges.

However, things can start to get painful when the number of link tags starts to grow. The worst case is when you are tagging links with real numbers with a large number of significant digits, since the table in the above dialog will create a row for each one of those values. For that reason, it is best to truncate real-valued link tags to <= 2 digits to keep this from getting out of hand.

If you do have a lot of tags to deal with, you will note there are two buttons on the lower left that give you useful shortcuts. You can make every link either directed or undirected by using those buttons. But what do you do if there is a mixture?

On that count, there is good news and bad news. I'll give the good news first: the Load From File... button allows you to specify the whether link tags represent directed or undirected edges using an input file. Unfortunately, it has not actually been documented anywhere what the file format is... until now! It needs to be an attribute file that has a format similar to the node attribute file used to specify node layout order. The file suffix can be whatever you want, but the file chooser dialog will highlight files with an .rda suffix. (I guess I was thinking that it would stand for relation directed attribute?) The file contents has a required column header line, followed by one and only one row for each and every link tag. Provide true for directed links, and false for directed links.  An example for the given SIF file is:

Relation Directed

UNDIR = false

DIR = true

So, if you load in the above sample file, your SIF import will look like the picture below, with BioFabric using an arrowhead to show the direction of an edge.  But, at the moment, that's all it does to treat directed edges in a special fashion. Most notably, the layout algorithms completely ignore directionality in the current version.

Click on picture to enlarge (but why would you?)

That was the good news. The bad news is that there is a bug in the implementation. If you note, I wrote the two link tags out in all uppercase in this example That's because the Load from File... option is stuck at only recognizing all uppercase tags. If your SIF file is using lower- or mixed-case tags, the program will complain and reject the .rda file. That bug has just been added to the GitHub BioFabric Issues Page! That's the beauty of open source: you got no secrets to conceal (OK, more apologies to Bob Dylan).

Using Heads and Tails to Make Heads or Tails of Caltech Houses

I have previously introduced and discussed my BioFabric version of the Caltech Houses (i.e. dorms) network that I based on the data from Traud et. al. 2011, and I am going to talk about it a little further here. If you want to view the whole network, and you don't mind the 3.8 MB download, take a look at the scrollable version.

In this post I will discuss the structure of the network within one of the dorms. Again, as with previous posts, I'm just going to describe what features I am seeing by eyeballing the BioFabric visualization. I'm not going to back up these claims by using network tools to analyze the structure; I'll leave that an an exercise to the reader. My goal here is to help you to build up your visual "network fabric intuition".

Recall that this Caltech dorm network was drawn by grouping the students using the provided information about which dorm each student lives in. So there are eight horizontal bands in the fabric that correspond to these eight dorms. Each dorm was separately laid out using the default BioFabric layout algorithm on just the intra-dorm links before they were combined into the full network. This means that the head (left end) of each dorm starts with the most popular student in that dorm (considering the dorm in isolation), followed immediately by that most popular student's Facebook friends. Meanwhile, the tail (right end) of the dorm is typically going to tend to show students with fewer friends in the dorm and/or more indirect connections to the most popular student. Keep in mind that this tendency towards low-degree students in the tail is broken by those students in the tail who do have many in-dorm friends, but who are several degrees of separation away from the "in crowd" at the head. That's the consequence of the breadth-first search used by the default layout.

Note, by the way, that the presentation I am using here is different from the one considered in the original paper, which showed how well the dorm assignment corresponded to the clustering they detected in the Caltech network via clustering algorithms. Instead, my approach here is to look at what we may be able to observe about the network given that it has been explicitly grouped using those dorm assignments; this presentation provides no insights into larger social groupings that cross dorm boundaries. 

Below are two figures showing portions of Dorm 4, which appears to be a pretty typical example of the dorms. Though you can pick out each dorm easily enough as you scan the network just by following the shape of the diagonal, I have added the red horizontal lines in these figures to clearly show the extent of Dorm 4 in these extracted segments. The first figure shows the head end, i.e. the popular students:

Click on picture to enlarge

So, the first thing to notice is that 623, on the far left (and the most popular student in the dorm), is pretty well connected within the dorm. His/her in-dorm edge wedge covers about 75% of the students in the dorm. (Remember, due to link grouping, the in-dorm edge wedge appears to the left of the out-of-dorm edge wedge for each student. Furthermore, the out-of dorm wedge appears as two wedges here, since it is split into above-node and below-node pieces.) Then, 623's most popular friends do a pretty good job of matching 623's friends in the dorm, since we can see that their in-dorm wedges very roughly approximate 623's. Those friends also do a good job of bringing in some more students, such that by the time we get to the ninth student on the right side of the head, at appears that well over 80% of the students in the dorm have been linked to.

It's also interesting to note that 623, while the most popular student in the dorm, has a majority (maybe greater than 67%?) of his/her friends outside the dorm. It appears that 633, the next in line, is almost as popular as 623 in-dorm, but is also much more inwardly focused on Dorm 4! 

Now look at the tail end of Dorm 4, again with the red lines to show the extent of the dorm:

Click on picture to enlarge

Note first that this short tail stretch actually shows the links for just over 50% of the students in the dorm (241, on the left, is not quite below the half-way point between the red lines). We can also see here what is going on with the 10% or so of the students who are not directly connected to the popular core; they start around the prominently labeled student 734 near the far right. Even at this scale, you can spot sort of a "phase change" in the edge wedge pattern as we get to just to the left of 734: the in-dorm edge wedges stop connecting to the popular students at the top of the Dorm 4 band. I'll discuss this group a little more below.

But turning back to the "typical" tail-end students in Dorm 4, we see that they are all connected to that central core at the head of the dorm, since they have links going to the top of the dorm band. Perhaps not surprisingly, most of the tail students are connected to social groups centered on the top core 50%, but not so much amongst each other. We can see that because the in-dorm edge wedges here typically show few edges below the diagonal (226 and 606 are notable exceptions). Another feature worth noting is that even these students with relatively few in-dorm connections almost all have at least a few out-of-dorm connections as well.

Finally, the isolated tail group starting around 734 is shown below in detail as an extracted submodel, again with red lines to indicate the bounds of Dorm 4. Note how 734, 722, 728, 738, and (to a lesser extent) 744 form a somewhat cohesive social unit, with many common social connections focused outside of the dorm:

Click on picture to enlarge

So that's my attempt to make "heads or tails" of one of the dorms in the network just by visual inspection of the fabric. I expect one more posting on this network: stay tuned!

New Kids in Town?

My attempts to keep the blog fresh and current this summer? EPIC FAIL! But I have a backlog of post topics, so I hope that this post marks the end of the dry spell.

In my last post, so very long ago, I introduced my BioFabric version of the Caltech Dorms Facebook Network, where nodes are students, edges are Facebook friend relationships, and the students have been grouped by dorm. Additionally, the edges for each student are grouped into two separate edge wedges: the first (left) one is for friend connections within a dorm, and the second (right) one is for connections between dorms. For a better view of that network, go to the scrollable version, but be warned that it is kinda big: 3.8 MB. 

There are a few interesting things in that network, so I'll be spending a couple of blog posts covering them. The first one is pretty simple, and you can spot it easily while scrolling across the network. It's at the tail end of the Dorm 5 cluster, and it shows up in the following figure. The figure shows two separate pieces of the network, divided by the vertical blue line, that are aligned so the nodes match up:

Click on picture to enlarge

Take a look at circled students 144 and 85, who are in Dorm 5; they are in the right half of the figure. What's interesting about them is that they look more like members of Dorm 4 than Dorm 5. For comparison, the left half of the figure shows some Dorm 4 students, and the horizontal red lines show the extent of the Dorm 4 cluster. Clearly, 144 and 85 have most of their friends in Dorm 4. And as the following detail shows, they don't know too many people at all in Dorm 5 (and they do know each other):

Click on picture to enlarge

So perhaps we can hazard a guess that 144 and 85 are recent arrivals to Dorm 5, both coming from Dorm 4?

Of course, this sort of visual analysis can also be done using adjacency matrices that have been ordered to show the dorm groups on the diagonal. However, I will argue that the visual cues provided by the two-dimensional edge wedges of BioFabric makes them stand out better than a one-dimensional column of the matrix. This is particularly true when the resolution of the adjacency matrix falls below the threshold of one pixel per student, as we would expect in larger networks. Furthermore, at such resolutions, I think it would be very difficult to spot that a single column has a set of pixels in one set of rows (Dorm 4) while simultaneously missing pixels in another set of rows (Dorm 5).

Now let's see if I can manage to get my rate of blog posts back up to speed...

I Guess Caltech Students Do Have Social Connections

OK, just kidding. But this post involves Caltech dorms, and I feel I have to take part in some old-fashioned school rivalry. There is, in fact, only one college dorm worth talking about.

Anyway, a few years ago, a paper came out that was studying the structure of Facebook social networks on some college campuses:

Traud, A., Kelsic, E., Mucha, P., and Porter, M. Comparing Community Structure to Characteristics in Online Collegiate Social Networks, SIAM Review, 2011, Vol. 53, No. 3: pp. 526-543

In 2011, this Facebook dataset was used in a visualization competition that Conrad Lee  described in a post on his blog Sociograph. You can see some of the results in the post; perhaps not surprisingly, the visualizations were hitting the hairball ceiling.  

In another posting on Sociograph in late 2012, Conrad used the Caltech portion of that Facebook dataset to illustrate how to visualize adjacency matrices in Python. With that dataset, I've visualized the Caltech Facebook network using BioFabric. With 769 nodes and 33312 16656* edges the network is very high aspect ratio (43:1). I have 15,000 pixel-wide version of the network that you can scroll back and forth with here on my blog, and in my initial iteration of this post, I embedded the file directly on this page. But at about 3.8 MB, it's a little hefty to have to download it when you first visit the blog. So I've included just a detail snapshot below, and you should go to the special scroll page to view it now:

Click on this caption to view the 15,000 pixel-wide version

(Note the students' names in the data were anonymized to numbers.)

Since this network needed to be preprocessed a bit to get the final layout, and since it uses a feature I have not yet talked about (link groups), I'll spend this post talking a little bit about I built it.

In addition to providing the links, the data set also indicates the House affiliation (i.e. dorm) of each student (there are eight dorms), and this turns out to be an important aspect of this network. So let's use that data and have BioFabric show the clusters. As I have pointed out before, it's not yet a built-in BioFabric 1.0 feature to automatically do clustered layouts, (though I am working on it!), so some basic scripting is needed. I'm not going to get into the low-level detail of showing the scripts, but just give a high-level description of the steps involved. 

First, using the dorm assignments, we identify which edges are in-dorm (Facebook friends in the same dorm), and which edges are between-dorm (Facebook friends in different dorms). Then, using just the in-dorm links, we create eight separate SIF files of in-dorm links, one per dorm. Separately loading each into BioFabric, we can get eight per-dorm BioFabric default layouts (i.e. we are going to use BioFabric to handle the default layout step, instead of scripting it as well). The resulting node orders, which we will use to create a single global ordering file, can be simply exported, just choose Select File->Export->Export Node Order:

Click on image to enlarge

(As a side note, the Export Link Order option in that menu is the best route to seeing how to create the edge attribute files you need to explicitly layout edges).

Since we want to order the dorms from biggest to smallest, number the eight dorm node order files in that fashion, e.g. dorm1.noa (biggest) to dorm8.noa (smallest). You'll also need to chop off the first line of each of these files, using e.g.:

tail -n +2 < dorm1.noa > dormr1.noa

Then, to create the single global node ordering file, just do this on the Unix command line:

cat dormr*.noa | awk '{print $1 " = " NR-1}' | sed '1 i Node Row' > globalOrdering.noa

That takes care of specifying the node ordering we will need. At the same time, we want to create the single full-network SIF file where each link is tagged with a suffix indicating whether is it in-dorm (tagged -ic, for in-cluster), or between-dorm (tagged -bc, for between-cluster). We were figuring that out above when we created the eight separate dorm-only networks, so also use that information to tag the links to write out the final single SIF input file. 

Then, import the global SIF file, and after the network is loaded, re-layout the whole network by specifying node order. Just select Layout->Layout Using Node Attributes..., use the globalOrdering.noa file you generated, and the network now has the eight separate dorms broken out.

When a network gets long and thin like this, I'm quick to turn on shadow links to get a better idea of what's going on. Just select Edit->Set Display Options... and check Display Shadow Links box. At the same time, I like to shade the node zones, so also check Node Zone Shading before clicking OK. This allows you to see all the Facebook connections for a student by just looking at the node zone for that student.  

There is now one more step. As it currently sits, each student has a single edge wedge for all his/her Facebook friends.  The tiny subnetwork of three students shown below illustrates that. Although the links going to the node lines right above and below these students correspond to the in-dorm links, that distinction is completely hidden:

Click on image to enlarge

So we want to separate the links into the in-dorm (-ic) and between-dorm (-bc) groups so we can see separate edge wedges for these two sets. Since we tagged the links in the SIF input with suffixes, we can easily use that information to create the two distinct edge wedges. Just go to Layout->Specify Link Groups...:

Click on image to enlarge

In the dialog, click Add New Entry... twice and enter in the two groups, -ic and -bc:

Click on image to enlarge

Click OK, and the network is laid out.  Because of the link grouping, we can now easily visualize the two -ic and -bc classes of links for each student. Compare this version below with the one above. The first diagonal for each student are the in-dorm -ic links, as that was the first link group we specified. As expected, those links end at the node rows near these students, i.e. the other nodes in the same dorm. The following single edge wedge of -bc links over on the right side of each node zone tends to look like two separate wedges, since they are connecting to both the dorms above and below this dorm:

Click on image to enlarge

Note how the grouping lets us instantly see which students are mostly in-dorm focused with their Facebook connections (e.g. 590), and which have more connections outside the dorm (e.g. 20).

That's it for details on building the network. So go back and have a look at the whole network in the 15,000 pixel-wide version up at the top of this post. You can see the eight separate runs of dorms, compare the two different types of connections, and get an idea of how the students interact.

My next post or two will cover a couple of interesting aspects of this network, but it will be awhile, as I'll be on the road next week to the ISMB/ECCB 2013 conference. If you happen to be there, come say hi at my BioFabric Birds of a Feather session on Monday, July 26th! 

* Correction: The original edge number of 33312 that I gave did not account for the equivalent reverse edges in the SIF file of the undirected graph getting thrown out on import to BioFabric. Though the view is actually showing 33312 edges in it since shadow links are turned on.

Big Data, Big Documents: The 100-Foot-Wide PDF

RBioFabric Version 0.3

I've just committed RBioFabric Version 0.3 on Github.  You can go take a look at it: 

https://github.com/wjrl/RBioFabric

You can install it directly from GitHub using the following command sequence and then start working with it:

# You need 'devtools':
install.packages("devtools")

# load it:
library(devtools)

# install 'RBioFabric' from GitHub:
install_github('RBioFabric',  username='wjrl')

And here's a screen shot of RBioFabric in action inside RStudio:

RBioFabric in action!

This new version has added a couple of necessary features to the very bare-bones first version:

• You can specify a node order via an ordered list of node names, or a supplied reordering function.
• You can display shadow links.

There's still lots to do, but RBioFabric actually provides some neat features that are not available in the Java version:

• You can easily read in a variety of graph formats, since RBioFabric operates on the graphs provided by the igraph package. 
• You can have BioFabric do a default layout that starts at a user-specified node, instead of the highest-degree node. This is shown in the example documentation for the defaultNodeOrder function. 
• You can create PDF files of your BioFabric network.

RBioFabric and PDF

It's true that RBioFabric is, for the moment, the only way to create a BioFabric PDF output. This is because the current Java BioFabric version can only directly export to PNG. While it is possible to print a network to a PDF target with Java BioFabric, I have found that the results for large networks are unacceptable, apparently due to precision issues. For example, the one time I tried it, the endpoint glyphs did not coincide with their corresponding link ends! So if the shortcomings of the current RBioFabric are not an issue (e.g. you cannot mix directed and undirected link types, there is no explicit edge ordering, etc.), you can use it for getting a PDF of your network.

But there are some caveats to be aware of when doing PDF outputs. First, some PDF viewers are better than others. Specifically, PDF viewers (or PNG viewers, for that matter) that cannot do antialiasing of line art are a terrible choice for viewing BioFabric networks. The closely spaced parallel lines of a BioFabric plot MUST be antialiased to get acceptable results when you are zoomed out to view the whole network. It's also useful for the viewer to have a decent maximum zoom level and a "Hand Tool" to be able to navigate by dragging the cursor over the image. I've tested a few viewers, and here is what I found. Note that all my computers are pretty old, so newer versions of these tools may do a better job:

• Evince on Linux (Document Viewer 2.30.3 tested): Antialiasing is always on, and the visuals are good. But there are a few problems. First, very tiny text below some size threshold explodes to a huge size.  Second, you cannot zoom above 400 percent, which is simply insufficient to explore your network. Finally, there is no hand tool to navigate by mouse dragging, which is essential. As a side note, for Postscript output, Evince does not antialias the image, giving very poor results.  
• Preview on Mac (Version 4.2 tested): Be sure that Anti-alias text and line art is checked on the PDF tab in Preferences, which gives adequate visuals (I feel they are way too dark at the full-network level). It has a very good maximum zoom level, and the Move cursor provides convenient mouse-drag navigation. You can also Select a rectangle and then zoom to it using command-* (i.e. command-shift-8).
• Adobe Reader on Mac (Version 9.5.5 tested): Be sure that Smooth line art is checked, and (VERY IMPORTANT) Enhance thin lines is NOT checked, on the Page Display Preferences. The Hand tool is available via Tools->Select & Zoom->Hand Tool, and the Marquee Zoom from the same Select & Zoom menu allows you to quickly zoom to a selected rectangle. The maximum 6400 percent zoom level is very good for exploration.

Sizing the PDF Document

It is important to make sure that your PDF document is large enough! If you don't set your PDF document height and width to a large enough value, the small text labels will not appear. My experiments show that both Adobe Reader and Mac Preview will no longer display the smallest node labels when the document gets smaller than about .0145 inches per link, which is about 69 links per inch. To get labels that are correctly proportioned, it appears to be best to actually stay above .0175 inches per link, i.e. 57 links per inch. So, for the yeastHighQuality.sif network displayed on the www.BioFabric.org home page, which contains 6888 links, you need to make a PDF file about 100 inches wide (i.e. 8 feet, 4 inches) to be just able to view it, and 120 inches wide (10 feet) to really do a decent job.

You read that last dimension correctly. To be able to explore a 6,888 link BioFabric network right down to the smallest detail, you need to make your PDF 10 feet wide! The implication is that a network with 69,000 links would need to be 100 feet wide. And that starts to limit what can be handled in the PDF viewer tools I tested, using the network from the Cytoscape HumanInteractomeMay.sif file, which has 61,263 links. Using the resolution guidelines I gave above, I made the PDF document 1200 inches wide by 240 inches high; that's 100 feet wide by 20 feet tall. The Adobe Reader just would not load it; it seems that it hits a limit at documents that are 200 inches square. The Mac Preview tool was able to load it, and you could zoom all the way in to view the labels. Unfortunately, the full-network view looks really bad.

The bottom line is that if you need to make a poster-sized (e.g. 48 inch-wide) image of a network with maybe 2,750 links or less, PDF can (in theory) provide a scalable, completely readable image. I say in theory, since your plotter driver rendering the PDF may have its own issues with tiny text and hairlines. If you have more links than that, a PNG file of 300 to 600 dpi will provide a decent image, though it will not have per-link resolution. I've been successful with the PNG route for the posters I have made so far.

So RBioFabric now provides a route to creating huge PDF documents for your network. But by far the best way to interactively explore a large network is to still use the BioFabric Java application, since the tool is designed to view large networks using the built-in interactive search, magnifier, touring, mouseover, submodeling, and view-tiling features.

Be sure to keep watching this blog for more announcements of future RBioFabric improvements! 

R you Ready for BioFabRic?

OK, this is going to be a very short post. After a marathon weekend hacking binge, I've created an initial version of BioFabric that is implemented in R.  The code for Version 0.01 is hosted on GitHub at:

https://github.com/wjrl/RBioFabric

At the moment, it's nothing fancy. For example, it only does the default layout, cannot do shadow links,  and so on. Right now, it just takes a graph in the  R igraph format and creates a static plot. I have done no benchmarking on how big you can go before everything starts to fall apart, but it seems to handle node and link counts in the hundreds without too much sweat. Here's an example of a network generated using barbasi.game(100, m=6, directed=FALSE): 

Click on image to enlarge

It's very rough at the moment, and is just a couple source files to start. But if you are the adventurous type, download bioFabric.R and then have a look at the TestHarness.R file to see how it can be used. I'll have more blog posts coming soon.

Happy R hacking!

"This only is the wedge-craft I have used."

OK, the title for this posting is not exactly what Shakespeare said (Othello, Act 1, Scene 3). But it's becoming clear to me as I continue to use BioFabric that putting lots of thought into creating informative edge wedge shapes (wedge-craft?) can pay off. It is well-known that many aspects of form (e.g. length, width, size, and curvature) are detected via preattentive processing, and this implies that BioFabric's edge wedges can take advantage of this perceptual "fast track" to enhance network visualizations.  

I expect this to be my final post on my World Bank network (phew!), and I want to use this to show how edge wedges allow the viewer to quickly extract information from a BioFabric network. If you've been following this blog for a couple months, the World Bank network should be familiar to you. But if not, I'll provide a quick summary of the posts. The network was introduced on April 11th, and explained further on April 13th. It was used as an example to describe how to build submodels on April 21st, and also how to use the Compare Multiple Nodes feature on May 20th. 

But the most important background for today's post is the May 11th Pitching Wedges post, where I talked about how the edge wedge for each borrower country is organized. Reading that post is a prerequisite for understanding this one! Finally, the post on May 22nd highlighted a network feature (thick vs. thin umbilicals to global player suppliers) that is closely related to today's topic, and is good background as well.

This post will show how the judicious organization of edge wedges can make it easy to quickly compare how each country contracts out to suppliers using its World Bank loans. I'm going to do that by showing four different countries, which are shown below together in a single view. From left to right, the countries are Nicaragua, Madagascar, Peru, and Ethiopia. Let's look at each one in turn, though in a different order.

Comparing all four countries at once

OK, last chance to go back and review the Pitching Wedges post, or the following is not going to make any sense, since I'm not going to redefine terms like "global players", nor review how the wedges are organized. Also, the images below (though you can click on them to make them larger) are low resolution, so loading up the network directly in BioFabric using the downloadable .bif file is the best way to explore these countries in detail.

First, look at Peru, which is shown in detail below. From the shape of the edge wedge, i.e. the slope changes along the bottom of the edge wedge, we can instantly see that maybe 90% (just eyeballing it here) of suppliers are in Peru, and maybe two thirds of suppliers have single contracts. There are a fair number of suppliers with two to three contracts, but there are very few super-suppliers with many contracts. A close look shows that there are only 11 suppliers with more than three contracts, with one supplier having seven, and the biggest supplier having 11. Finally, we see the tiny number of contracts with the global-player suppliers. Note: if you look closely at the Peru data inside BioFabric, you will see that half of those few global-player suppliers in this case are actually based in Peru, so it is important to keep in mind that "global player" is not synonymous with a contract out of a country, though that is almost always the case.

Peru: Almost all in-country, few super-suppliers

Quickly contrast this with Nicaragua, shown below. A much larger fraction are multi-contract suppliers; maybe half, with about 40% single suppliers. Furthermore, the very sharp point on the left instantly reveals some super-suppliers with many contracts, which is in stark contrast to Peru's profile. Close inspection reveals that there are nine suppliers with 14 or more contracts, and the biggest supplier has 37 contracts. Finally, just like Peru, and in fact just like most Latin American countries (see the May 22nd post), Nicaragua has very few contracts with the global player suppliers.

Nicaragua: Almost all in-country, some big super-suppliers

Next, let's look at Madagascar. It looks like about half the contracts go out of the country, and a big chunk (maybe 15 percent?) go to the global player suppliers. Most of the out-of-country contracts are to multi-contract suppliers. And, like Nicaragua, the sharply pointed left side indicates a few big super-suppliers.

Madagascar: About half to out-of-country suppliers

Finally, consider Ethiopia. Maybe 80% of all the contracts go to suppliers out of the country, and the large multi-contract suppliers are out of country as well. There are no in-country super-suppliers, which we can glean from the blunt angle on the left of Ethiopia's wedge. Finally, like other African countries (again, see the May 22nd post), Ethiopia has many contracts with the global player suppliers.

Ethiopia: 80% out of country, many global player suppliers

One caveat on this World Bank network example I need to acknowledge is that I have just been talking about the number of contracts, and not in any way accounting for the dollar amounts of each contract (you can see dollar amounts in the tag on each contract edge when you view it in BioFabric). One can argue that dollar amount is the relevant metric to be using here, and I won't disagree. But I've been trying to keep this example simple, and it is possible to address dollar amounts in another fashion that I will cover in a future blog post.

Finally, this particular network has the unusual feature that most nodes (the suppliers) are each uniquely connected to just one borrower country, which allows those supplier nodes to be ordered independently, and precisely, on a country-by-country basis. Thus, this network  lends itself to the compact, highly organized edge wedges that I have been showing. Most network topologies are not nearly as cooperative, but it is still possible to organize meaningful edge wedges. One powerful tool for doing that easily is link groups, which are mentioned in the BioFabric paper. I will cover those in a future blog post, as well.

I hope this example has shown that a careful and well-thought-out approach to organizing BioFabric edge wedges allows the viewer to rapidly extract and compare network features. With that, it's time to finally move past the World Bank network and onto other data sets I have in the pipeline for future blog posts, but keep this network in mind as you go forth and practice entrancing wedgecraft!