In this segment I'm going to show you that dependency syntax

is a very natural representation for relation extraction applications.

One domain in which a lot of work has been done on relation extraction is in the biomedical text domain.

So here for example, we have the sentence

“The results demonstrated that KaiC interacts rhythmically with SasA, KaiA, and KaiB.”

And what we’d like to get out of that is a protein interaction event.

So here’s the “interacts” that indicates the relation,

and these are the proteins involved.

And there are a bunch of other proteins involved as well.

Well, the point we get out of here is that if we can have this kind of dependency syntax,

then it's very easy starting from here to follow along the arguments of the subject and the preposition “with”

and to easily see the relation that we’d like to get out.

And if we're just a little bit cleverer,

we can then also follow along the conjunction relations

and see that KaiC is also interacting with these other two proteins.

And that's something that a lot of people have worked on.

In particular, one representation that’s being widely used for relation extraction applications in biomedicine

is the Stanford dependencies representation.

So the basic form of this representation is as a projective dependency tree.

And it was designed that way so it could be easily generated by postprocessing of phrase structure trees.

So if you have a notion of headedness in the phrase structure tree,

the Stanford dependency software provides a set of matching pattern rules

that will then type the dependency relations and give you out a Stanford dependency tree.

But Stanford dependencies can also be, and now increasingly are generated directly

by dependency parsers such as the MaltParser that we looked at recently.

Okay, so this is roughly what the representation looks like.

So it's just as we saw before,

with the words connected by type dependency arcs.

But something that has been explored in the Stanford dependencies framework

is, starting from that basic dependencies representation,

let’s make some changes to it to facilitate relation extraction applications.

And the idea here is to emphasize the relationships

between content words that are useful for relation extraction applications.

Let me give a couple of examples.

So, one example is that commonly you’ll have a content word like “based”

and where the company here is based—Los Angeles—

and it’s separated by this preposition “in”, a function word.

And you can think of these function words as really functioning like case markers in a lot of other languages.

So it’d seem more useful if we directly connected “based” and “LA”,

and we introduced the relationship of “prep_in”.

And so that’s what we do, and we simplify the structure.

But there are some other places, too,

in which we can do a better job at representing the semantics with some modifications of the graph structure.

And so a particular place of that is these coordination relationships.

So we very directly got here that “Bell makes products”.

But we’d also like to get out that Bell distributes products,

and one way we could do that is by recognizing this “and” relationship

and saying “Okay, well that means that ‘Bell’ should also be the subject of ‘distributing’

and what they distribute is ‘products.’”

And similarly down here,

we can recognize that they’re computer products as well as electronic products.

So we can make those changes to the graph,

and get a reduced graph representation.

Now, once you do this, there are some things that are not as simple.

In particular, if you look at this structure, it’s no longer a dependency tree

because we have multiple arcs pointing at this node,

and multiple arcs pointing at this node.

But on the other hand,

the relations that we’d like to extract are represented much more directly.

And let me just show you one graph that gives an indication of this.

So, this was a graph that was originally put together by Jari Björne et al,

who were the team that won the BioNLP 2009 shared tasks in relation extraction

using, as the representational substrate, Stanford dependencies.

And what they wanted to illustrate with this graph

is how much more effective dependency structures were

at linking up the words that you wanted to extract in a relation,

than simply looking for words in the linear context.

So, here what we have is that this is the distance

which can be measured either by just counting words to the left or right,

or by counting the number of dependency arcs that you have to follow.

And this is the percent of time that it occurred.

And so what you see is, if you just look at linear distance,

there are lots of times that there are arguments and relations that you want to connect out

that are four, five, six, seven, eight words away.

In fact, there’s even a pretty large residue here of well over ten percent

where the linear distance away in words is greater than ten words.

If on the other hand though, you are trying to identify,

relate the arguments of relations by looking at the dependency distance,

then what you’d discover is that the vast majority of the arguments

are very close-by neighbors in terms of dependency distance.

So, about 47 percent of them are direct dependencies and another 30 percent of distance too.

So take those together and that’s greater than three quarters of the dependencies that you want to find.

And then this number trails away quickly.

So there are virtually no arguments of relations that aren’t fairly close together in dependency distance

and it’s precisely because of this reason that you can get

a lot of mileage in doing relation extraction by having a representation-like dependency syntax.

Okay, I hope that’s given you some idea of why knowing about syntax is useful,

when you want to do various semantic tasks in natural language processing.