Capturing Relationships: 5-Minute Interview with Forrest Swope


“If I take information from 50 of my relational databases, I can build an interesting graph and learn what makes some kids do better than others,” said Forrest Swope, Manager of Data Operations, University of Virginia.

In this week’s five-minute interview (conducted at GraphTour DC 2019), we discuss how Forrest Swope and his team at UVA are moving beyond using relational databases and using Neo4j‘s graph technology to answer complex questions.



How did you get started with graph technology?


Swope: I was working prior to this job for a company that did semantic processing of medical content of for clients like the AMA and the APA. We had a 500,000-element taxonomy that we hand-curated over the last 20 years and we were doing in-house and processing of AMA articles against this thesaurus and then assigning various different topic categories.

I was working with the director of semantic processing on some point of care products for physicians to help with diagnoses. Say I’m a physician who is going in to see a patient who may have kidney failure. I don’t want to just pull up content that is about kidney failure. I might want to know what symptoms I’m looking for, what is diagnostic should I be using or what some treatment options are.

The thesaurus got us to the point of how knowing that things were related, but it didn’t describe the nature of the relationship.

We started looking into graph database technology as a way to relate all of this content. We realized that the important part of the relationship is the meaning of the relationship, not just that it exists, and graph technology would help us capture that.

How are you using Neo4j at the University of Virginia?



Our interest in pursuing the technology came about because we have some very complex problems that we want to solve, and my experience in working with data is that relational databases are very highly structured, and because of their grid-like nature, they’re great for pulling transactions back or creating long tabulations, but they’re not great for accessing more complex relationships.

As an example, the State of Virginia has an interest in supporting Community College students who maintain a B average over the first two years of college in transferring to the public schools in Virginia, so, we had a lot of third-year students who were incoming who are community college students who might not have been accepted as first-year students.

They represent a very different cohort that we’re just beginning to learn about, and they have a lot of challenges. For example, they tend not to live on campus, they request access to student services more than other students, they don’t have an established network of friends, they don’t join fraternities at the same rate.

We’d like to explore the successful cohort of students in that group and then figure out what it is that they’re doing so that we can help the less successful students. Are they more connected? Are they doing these activities? How are they choosing to interact with the university and thrive? We want to compare them with the students who appear to be struggling more and using more services, because we want everybody to be successful.

This is not the kind of question I can go to a relational database and try and answer, but if I took the information from 50 of my relational databases, I can build an interesting graph and maybe learn what makes some of these kids do better than others. I think the idea of adjacency and being able to unearth the meaning of relationships that will be hard to expose versus relational technologies is really the key to it for me.

What do you think is in store for the future of graphs?


Swope: I think the idea of adjacency and being able to unearth the meaning of relationships that would be hard to expose versus relational technologies is really the key to it for me.

The relational structure just tends to say, X is a Y, but it doesn’t tell me what type of Y, or what the character of that relationship is, and that’s the part that’s important to us for solving this exercise.

I think the ability to not know all of the questions you’re gonna ask, and be able to answer them anyway is really powerful because with relational we tend to need to know the questions we’re asking before we structure the build. With Neo4j, we don’t have to.

Want to share about your Neo4j project in a future 5-Minute Interview? Drop us a line at content@neo4j.com


Curious about using graphs in your business?
Download this white paper, The Top 5 Use Cases of Graph Databases, and discover how to tap into the power of graphs for the connected enterprise.


Read the White Paper