This is a blog examining the use of signaling in applications that provide recommendations as a use case for graph databases.

After reading books like “Freakonomics,” written by pop economic superstars Stephen Dubner and Steven Levitt, and “Outliers,” written by acclaimed New Yorker magazine columnist Malcolm Gladwell, you realize that economic theory can help you see the world from a different perspective. New insights using economic principles are helping to address questions that have previously seemed unanswerable. In his book, “Who Gets What and Why: The New Economics of Matchmaking and Market Design,” Alvin Roth designs successful matching markets where desperate organ recipients find compatible organ donors or needy job seekers find companies looking for candidates with their skillset. Roth is opening up a new way of solving matching problems.

Roth discusses the need for natural signals of interest in successful market designs. This communication, which Roth calls “signaling,” is used to qualify potential matches and determine if the matches are desired (177). For example, bright displays of color are not an evolutionary advantage to avoiding predators for a male peacock, but his plumage certainly allows potential mates to identify him as strong and healthy. Similarly, a signal can be costly for the sender, but it can also help to qualify a match or determine the strength of a match. The value of signaling is seen clearly through use of online dating sites to meet people.

Exchange Market Blog Series,  Part 3: Enterprise Level Exchanges

Exchange Market Blog Series, Part 3: Enterprise Level Exchanges

This is the third and final installment in a blog series examining exchange markets and how they are a good use case for graph databases.

In college, I was in a student group that wrote a research paper about redesigning election systems, which were traditionally dominated by two parties, to include viable third-party candidates. This was inspired by the two consecutive failed presidential bids by third-party candidate Ross Perot in 1992 and 1996. We found that the simplest way to reasonably include third-party candidates was to allow voters to rank two or more candidates, instead of voting for a single candidate.

The problem though was that if most voters preferred the same second-rank candidate, then that second-rank candidate would likely be elected. You can imagine in this scenario that candidates might purposely pursue becoming the second-rank candidate in order to win. In a market design like this, most candidates and political strategists would attempt to exploit the weaknesses of the system to engineer the outcome.

Exchange Market Blog Series,  Part 2: Designing an Exchange Market with the Help of “My Little Pony”

Exchange Market Blog Series, Part 2: Designing an Exchange Market with the Help of “My Little Pony”

This is the second installment in a blog series examining exchange markets and how they are a good use case for using a graph database.

Civilization has designed exchange markets since the first early humans made stone tools and others recognized their value. In fact, non-monetary exchange markets predate all other markets by such a great deal of time that you might say that we are inherently predisposed towards them. Of course, transacting in exchange markets can be extremely difficult, because value is subjective, and we have a tendency to overvalue what we have. Successfully making a trade often involves tedious work to first find potential participants and then convince them to close the deal.

This challenge is well illustrated in an episode of the animated show, “My Little Pony: Friendship is Magic™,” titled “Trade Ya!” where one of the ponies named Rainbow Dash wants to trade for a rare book held by a book seller. In the Rainbow Falls Traders Exchange, no money is used. Instead, the ponies must trade only for goods or services. Rainbow Dash brings her most valuable possession, her lucky horseshoe, to trade for a first edition copy of the Daring Do book. Unfortunately, the book seller does not find her horseshoe valuable, so the rest of the episode involves Rainbow Dash going from vendor to vendor to enact a series of trades starting with her “valuable” horseshoe and ending with the rare book.

Exchange Market Blog Series,  Part 1: Kidney Exchanges

Exchange Market Blog Series, Part 1: Kidney Exchanges

This is the first installment in a series of blogs examining exchange markets and how they are a good use case for using a graph database.

Bartering may seem like an ancient practice, but we all grew up exchanging non-monetary goods in a marketplace. For me, it was baseball cards, but for many it was records or clothes. We all intuitively know how to transact in markets when we want or need something, and the supply is limited.

An exchange is a market in which non-monetary goods are traded. When you trade in exchange markets, the matching is typically very rare and the value of the goods is generally very subjective. For example, my “Wade Boggs” rookie card may not be valuable to me but may be very valuable to my cousin’s friend. Networking connections and attracting people who want to transact is key to what keeps exchanges alive. Finding matches to ensure transactions are happening is what attracts users to an exchange.

Making Spark Work for Next Generation Workflows

Making Spark Work for Next Generation Workflows


You know that you are dealing with “Big” data when you can no longer use general-purpose, off-the-shelf solutions for your problems. Big data technologies are all specialized for specific sets of problems. Apache Spark™ is uniquely designed for in-memory processing of data workflows at scale. Currently, it is the most active open-source project for big data processing. One key strategy for extracting the most value from large connected datasets is the use of graph analytics to derive business insights.

Distributed graph databases also support analytics at scale, but they are specifically designed to store complex graph data and perform fine-grained real-time graph analytics. By using Spark for expressing and executing your workflows in conjunction with a distributed graph database, you can design and execute workflows suitable for the next generation of applications that exploit insights derived from complex graph analytics.

Building a Recommendation Engine Using a Graph Database

Building a Recommendation Engine Using a Graph Database

Submitted by nquinn on April 6, 2015 - 12:51pm Introduction A very common use case for Graph Databases is to support client applications that provide suggestions for their customers or rate products or services based on user behavior or preference. For the InfiniteGraph 3.4 release, we built a Podcast Recommendation Sample using the features available in IG 3.4 and previous releases. A recommendation engine is typically built using a graph database for three reasons: Recommendations use multiple factors that have complex relationships Recommendations are given in real-time Recommendations utilize multiple levels of relationships For example, recommending purchases might involve looking at purchase event information and the many types of relationships between purchases, including customer preferences, website, store or brand loyalty, and general popularity. It also may be beneficial to look at relationships between customers, including trends within communities, socio-economic groups, etc. This type of relationship analytics is most successful after looking at multiple levels of depth to see how pervasive trends may be. This blog will look at complex relationships and multiple levels of relationship in graph data sets to see how they can be mined to develop an interesting and compelling recommendation algorithm. Design To create a successful recommendation service, care must be taken to determine what types of data are required to create a compelling recommendation engine. For example, if we recommend podcasts based only on popularity, then we would only be offering recommendations along one differentiating factor. All queries would return the same top set of podcast titles based on that one factor. Even two factors of differentiation is uninteresting. Consider using two factors like category...