text:
\documentclass[11pt,letterpaper]{article}

\usepackage[utf8]{inputenc}
\usepackage{latexsym}
\usepackage{amsmath}
\usepackage{mathptmx}
\usepackage{graphicx}
\usepackage{tikz-dependency}
\tikzset{/depgraph/.cd,/depgraph/.search also = {/tikz},
    baseline=-0.6ex, inner sep=-0.1cm, edge horizontal padding=3pt, edge unit distance=1.5ex}
\usepackage{natbib}
\bibpunct{(}{)}{,}{a}{}{;}
\usepackage{color}

\setlength{\textwidth}{16cm}
\setlength{\oddsidemargin}{-0.04cm}
\setlength{\topmargin}{-2cm}
\setlength{\textheight}{23.5cm}

\newcommand{\mystretch}{1.1}
\renewcommand{\baselinestretch}{\mystretch}

\def\url#1{\textsf{#1}}

\title{\textbf{Stanford typed dependencies manual}}
\author{Marie-Catherine de Marneffe and Christopher D. Manning}
\date{September 2008\\
%Revised for Stanford Parser v. 1.6.2 in February 2010
%Revised for Stanford Parser v.~1.6.5 in November 2010
%Revised for Stanford Parser v.\ 1.6.9 in September 2011
% Revised for Stanford Parser v.\ 2.0.4 in November 2012
% Revised for the Stanford Parser v.\ 2.0.5 in March 2013
% Revised for the Stanford Parser v.\ 3.2 in June 2013
% Revised for the Stanford Parser v.\ 3.3 in November 2013
% Revised for the Stanford Parser v.\ 3.3 in December 2013
%Revised for the Stanford Parser v.\ 3.5.1 in February 2015
%Revised for the Stanford Parser v.\ 3.5.2 in April 2015
Revised for the Stanford Parser v.\ 3.7.0 in September 2016
}

\begin{document}
\maketitle

\color{red}
Please note that this manual describes the original Stanford
Dependencies representation. As of version 3.5.2, the default representation
output by the Stanford Parser and Stanford CoreNLP is the new Universal Dependencies (UD)
representation, and we no longer maintain the original Stanford Dependencies representation. For a description of the UD
representation, take a look at the Universal Dependencies documentation at \textsf{http:/www.universaldependencies.org} and
the discussion of the \textit{enhanced} and \textit{enhanced++} UD representations by \citet{schuster2016enhanced}.
\color{black}
\section{Introduction}

The Stanford typed dependencies representation was designed to provide
a simple description of the grammatical relationships in a sentence
that can easily be understood and effectively used by people without
linguistic expertise who want to extract textual relations.  In
particular, rather than the phrase structure representations that have
long dominated in the computational linguistic community, it
represents all sentence relationships uniformly as typed dependency
relations. That is, as triples of a relation between pairs of words, such as ``the subject of
\emph{distributes} is \emph{Bell.}''  Our experience is that this simple,
uniform representation is quite accessible to non-linguists
thinking about tasks involving information extraction from text and is
effective in relation extraction applications.

Here is an example sentence:
\begin{quote}
\emph{Bell, based in Los Angeles, makes and distributes electronic, computer and building products.}
\end{quote}
For this sentence, the Stanford Dependencies (SD) representation is:
\begin{quote}
nsubj(makes-8, Bell-1) \\
nsubj(distributes-10, Bell-1) \\
vmod(Bell-1, based-3) \\
nn(Angeles-6, Los-5) \\
prep\_in(based-3, Angeles-6) \\
root(ROOT-0, makes-8)\\
conj\_and(makes-8, distributes-10) \\
amod(products-16, electronic-11) \\
conj\_and(electronic-11, computer-13) \\
amod(products-16, computer-13) \\
conj\_and(electronic-11, building-15) \\
amod(products-16, building-15) \\
dobj(makes-8, products-16) \\
dobj(distributes-10, products-16)
\end{quote}

These dependencies map straightforwardly onto a directed graph representation, in which words in the sentence are nodes in the graph and grammatical relations are edge labels. Figure~\ref{bell} gives the graph representation for the example sentence above.
\begin{figure}
\begin{center}
\includegraphics[width=3.2in, height=3.0in]{bell.pdf}
\end{center}
\vspace*{-0.6cm}
\caption{\label{bell} Graphical representation of the Stanford Dependencies for the sentence: \emph{Bell, based in Los Angeles, makes and distributes electronic, computer and building products.}}
\end{figure}

\subparagraph{Document overview:} This manual provides documentation for the set of dependencies defined
for English.  There is also a Stanford Dependency representation
available for Chinese, but it is not further discussed here.  Starting
in 2014, there has been work to extend Stanford Dependencies to be
generally applicable cross-linguistically. Initial work appeared in
\citet{marneffe14universal}, and the current guidelines for Universal Dependencies (UD) can be found at
\url{http://www.universaldependencies.org}.
For SD, Section~\ref{def} of the manual defines the grammatical relations and the taxonomic hierarchy over
them appears in section~\ref{hierarchy}.  This is then followed by a description of the several variant
dependency representations available, aimed at different use cases
(section~\ref{types}), some details of the software available for
generating Stanford Dependencies (section~\ref{in_practice}), and
references to further discussion and use of the SD representation (section~\ref{refs}).

\section{Definitions of the Stanford typed dependencies}\label{def}

The current representation contains approximately 50 grammatical
relations (depending slightly on the options discussed in section~\ref{types}). The dependencies are all binary relations: a grammatical relation holds between a \emph{governor} (also known as a \emph{regent} or a \emph{head}) and a \emph{dependent}. The grammatical relations are defined below, in alphabetical order according to the dependency's abbreviated name (which appears in the parser output). The definitions make use of the Penn Treebank part-of-speech tags and phrasal labels.

\bigskip

\noindent\textbf{\emph{acomp}: adjectival complement}\\
An adjectival complement of a verb is an adjectival phrase which functions as the complement (like an object of the verb).
\begin{quote}
\begin{dependency}[column sep=0.2em, edge unit distance=2.25ex]
  \begin{deptext}
    She \& looks \& very \& beautiful \\
  \end{deptext}
  \depedge{2}{1}{nsubj}
  \depedge{2}{4}{acomp}
  \depedge{4}{3}{advmod}
\end{dependency}
\end{quote}

% \begin{tabbing}
% \hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
% \> ``She looks very beautiful'' \>\> \emph{acomp}(looks, beautiful)\\
% \end{tabbing}

\noindent\textbf{\emph{advcl}: adverbial clause modifier}\\
An adverbial clause modifier of a VP or S is a clause modifying the
verb (temporal clause, consequence, conditional clause, purpose
clause, etc.).
% should a purpose clause now really be regarded as a vmod = nfmod
\begin{tabbing}
	\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\> ``The accident happened as the night was falling'' \> \> \emph{advcl}(happened, falling)\\
\> ``If you know who did it, you should tell the teacher'' \> \> \emph{advcl}(tell, know)\\
\> ``He talked to him in order to secure the account'' \>  \> \emph{advcl}(talked, secure)\\
\end{tabbing}

\noindent\textbf{\emph{advmod}: adverb modifier}\\
An adverb modifier of a word is a (non-clausal) adverb or adverb-headed phrase that serves to modify the meaning of the word.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\>  ``Genetically modified food'' \> \> \emph{advmod}(modified, genetically)\\
\> ``less often'' \> \> \emph{advmod}(often, less)\\
\end{tabbing}

\noindent\textbf{\emph{agent}: agent}\\
An agent is the complement of a passive verb which is introduced by the preposition ``by'' and does the action.
This relation only appears in the collapsed dependencies, where it can
replace \emph{prep\_by}, where appropriate. It does not appear in
basic dependencies output.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\>  ``The man has been killed by the police'' \> \> \emph{agent}(killed, police)\\
\> ``Effects caused by the protein are important'' \> \> \emph{agent}(caused, protein)\\
\end{tabbing}

\noindent\textbf{\emph{amod}: adjectival modifier}\\
An adjectival modifier of an NP is any adjectival phrase that serves to modify the meaning of the NP.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\> ``Sam eats red meat'' \> \> \emph{amod}(meat, red)\\
\> ``Sam took out  a 3 million dollar loan'' \> \> \emph{amod}(loan, dollar)\\
\> ``Sam took out  a \$ 3 million loan'' \> \> \emph{amod}(loan, \$)\\
\end{tabbing}

\noindent\textbf{\emph{appos}: appositional modifier}\\
An appositional modifier of an NP is an NP immediately to the right of
the first NP that serves to define or modify that NP. It includes
parenthesized examples, as well as defining abbreviations in one of
these structures.
\begin{quote}
\begin{dependency}
   \begin{deptext}[column sep=0.2em]
      Sam \&, \& my \& brother \& , \& arrived \\
   \end{deptext}
   \depedge[edge unit distance=0.5ex]{1}{4}{appos}
\end{dependency}
\hspace*{1in}
\begin{dependency}
   \begin{deptext}[column sep=0.2em]
      Bill\& ( \& John \& 's \& cousin \& ) \\
   \end{deptext}
   \depedge[edge unit distance=0.5ex]{1}{5}{appos}
\end{dependency}

\medskip

\begin{dependency}
   \begin{deptext}[column sep=0.2em]
      The \& Australian \& Broadcasting \& Corporation \& ( \& ABC \& ) \\
   \end{deptext}
   \depedge[edge unit distance=1ex]{4}{6}{appos}
\end{dependency}
\end{quote}

\noindent \textbf{\emph{aux}: auxiliary}\\
An auxiliary of a clause is a non-main verb of the clause, e.g., a
modal auxiliary, or a form of ``be'', ``do'' or ``have'' in a periphrastic tense.
\begin{quote}
\begin{dependency}
   \begin{deptext}[column sep=0.25cm]
      Reagan \& has \& died \\
   \end{deptext}
   \depedge{3}{2}{aux}
\end{dependency}
\hspace*{1in}
\begin{dependency}
   \begin{deptext}[column sep=0.25cm]
      He \& should \& leave \\
   \end{deptext}
   \depedge{3}{2}{aux}
\end{dependency}
\end{quote}

\noindent \textbf{\emph{auxpass}: passive auxiliary}\\
A passive auxiliary of a clause is a non-main verb of the clause which contains the passive information.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\> ``Kennedy has been killed''  \> \> \emph{auxpass}(killed, been)\\
\> \> \> \emph{aux}(killed,has)\\
\> ``Kennedy was/got killed'' \> \> \emph{auxpass}(killed, was/got)\\
\end{tabbing}

\noindent\textbf{\emph{cc}: coordination}\\
A coordination is the relation between an element of a conjunct and the coordinating conjunction word of the conjunct.  (Note: different dependency grammars have different treatments of coordination.  We take one conjunct of a conjunction (normally the first) as the head of the conjunction.)
A conjunction may also appear at the beginning of a sentence.  This is also called a cc, and dependent on the root predicate of the sentence.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``Bill is big and honest'' \hspace{1cm} \> \> \emph{cc}(big, and)\\
\hspace{1cm} \> ``They either ski or snowboard'' \> \> \emph{cc}(ski, or)\\
\> ``And then we left.'' \> \> \emph{cc}(left, And)\\
\end{tabbing}

\noindent\textbf{\emph{ccomp}: clausal complement}\\
A clausal complement of a verb or adjective is a dependent clause with an internal subject which functions like an object of the verb, or adjective.  Clausal complements for nouns are limited to complement clauses with a subset of nouns
 like ``fact'' or ``report''.  We analyze them the same (parallel to the
 analysis of this class as ``content clauses'' in Huddleston and Pullum 2002). Such clausal complements are usually finite (though there are occasional remnant English subjunctives).
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``He says that you like to swim'' \> \> \emph{ccomp}(says, like)\\
\hspace{1cm} \> ``I am certain that he did it'' \> \>  \emph{ccomp}(certain, did)\\
\hspace{1cm} \> ``I admire the fact that you are honest'' \>\> \emph{ccomp}(fact, honest)\\
\end{tabbing}

%% todo: put in a for-to infinitive example
%% Would it be best for me for my kids to finish college?
%1       Would   _       MD      MD      _       4       aux _       _
%2       it      _       PRP     PRP     _       4       nsubj 4       expl
%3       be      _       VB      VB      _       4       cop _       _
%4       best    _       JJS     JJS     _       0       root _       _
%5       for     _       IN      IN      _       8       mark 4       prep
%6       me      _       PRP     PRP     _       8       nsubj 5       pobj
%7       to      _       TO      TO      _       8       aux _       _
%8       finish  _       VB      VB      _       4       advcl 4       xcomp
%9       college _       NN      NN      _       8       dobj _       _
%10      ?       _       .       .       _       4       punct _       _

\noindent\textbf{\emph{conj}: conjunct}\\
A conjunct is the relation between two elements connected by a coordinating conjunction, such as ``and'', ``or'', etc.  We treat conjunctions asymmetrically: The head of the relation is the first conjunct and other conjunctions depend on it via the \emph{conj} relation.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``Bill is big and honest'' \> \> \emph{conj}(big, honest)\\
\hspace{1cm} \> ``They either ski or snowboard'' \> \>  \emph{conj}(ski, snowboard)\\
\end{tabbing}

\noindent\textbf{\emph{cop}: copula}\\
A copula is the relation between the complement of a copular verb and the copular verb.  (We normally take a copula as a dependent of its complement; see the discussion in section~\ref{types}.)
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\> ``Bill is big'' \hspace{1cm} \> \> \emph{cop}(big, is)\\
\hspace{1cm} \> ``Bill is an honest man'' \>  \> \emph{cop}(man, is)\\
\end{tabbing}

\noindent\textbf{\emph{csubj}: clausal subject}\\
A clausal subject is a clausal syntactic subject of a clause, i.e., the subject is itself a clause. The governor of this relation might not always be a verb: when the verb is a copular verb, the root of the clause is the complement of the copular verb. In the two following examples, ``what she said'' is the subject.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\> ``What she said makes sense'' \> \> \emph{csubj}(makes, said)\\
\hspace{1cm} \> ``What she said is not true'' \> \>  \emph{csubj}(true, said)\\
\end{tabbing}

\noindent\textbf{\emph{csubjpass}: clausal passive subject}\\
A clausal passive subject is a clausal syntactic subject of a passive clause. In the example below, ``that she lied'' is the subject.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\>  ``That she lied was suspected by everyone'' \> \> \emph{csubjpass}(suspected, lied)\\
\end{tabbing}

\noindent\textbf{\emph{dep}: dependent}\\
A dependency is labeled as \emph{dep} when the system is unable to determine a more precise dependency relation between two words.  This may be because of a weird grammatical construction, a limitation in the Stanford Dependency conversion software, a parser error, or because of an unresolved long distance dependency.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``Then, as if to show that he could, \ldots'' \> \> \emph{dep}(show, if)\\
\end{tabbing}

\noindent\textbf{\emph{det}: determiner}\\
A determiner is the relation between the head of an NP and its determiner.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``The man is here'' \> \> \emph{det}(man, the)\\
\> ``Which book do you prefer?'' \> \> \emph{det}(book, which)\\
\end{tabbing}

\noindent\textbf{\emph{discourse}: discourse element}\\
This is used for interjections and other discourse particles and
elements (which are not clearly linked to the structure of the
sentence, except in an expressive way). We generally follow the
guidelines of what the Penn Treebanks count as an INTJ.  They
define this to include: interjections (\emph{oh}, \emph{uh-huh},
\emph{Welcome}), fillers (\emph{um}, \emph{ah}), and discourse
markers (\emph{well}, \emph{like}, \emph{actually}, but not \emph{you know}).
\begin{quote}
\begin{dependency}
   \begin{deptext}[column sep=0.25cm]
      Iguazu \& is \& in \& Argentina \& :) \\
   \end{deptext}
   \depedge[edge unit distance=0.4ex]{2}{5}{discourse}
\end{dependency}
\end{quote}

\noindent\textbf{\emph{dobj}: direct object}\\
The direct object of a VP is the noun phrase which is the (accusative) object of the verb.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``She gave me a raise'' \> \> \emph{dobj}(gave, raise)\\
\hspace{1cm} \> ``They win the lottery'' \> \>  \emph{dobj}(win, lottery)\\
\end{tabbing}

\noindent\textbf{\emph{expl}: expletive}\\
This relation captures an existential ``there''. The main verb of the clause is the governor.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\> ``There is a ghost in the room'' \>\> \emph{expl}(is, There)\\
\end{tabbing}

\noindent\textbf{\emph{goeswith}: goes with}\\
This relation links two parts of a word that are separated in text
that is not well edited. We follow the treebank: The GW part is the
dependent and the head is in some sense the ``main'' part, often the
second part.
\begin{quote}
\begin{dependency}
   \begin{deptext}[column sep=0.2em]
      They \& come \& here \& with \& out \& legal \& permission \\
   \end{deptext}
   \depedge[edge unit distance=2.5ex]{5}{4}{goeswith}
\end{dependency}
\end{quote}

\noindent\textbf{\emph{iobj}: indirect object}\\
The indirect object of a VP is the noun phrase which is the (dative) object of the verb.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
 \> ``She gave me a raise'' \> \> \emph{iobj}(gave, me)\\
\end{tabbing}

\noindent\textbf{\emph{mark}: marker}\\
A marker is the word introducing a finite clause subordinate to another clause.
For a complement clause, this will typically be ``that'' or ``whether''.
For an adverbial clause, the marker is typically a preposition like ``while'' or ``although''.
The mark is a dependent of the subordinate clause head.
\begin{quote}
\begin{dependency}
   \begin{deptext}[column sep=0.2em]
      Forces \& engaged \& in \& fighting \& after \& insurgents \&  attacked
% \& \hspace*{3em}\emph{mark}(attacked, after)
\\
   \end{deptext}
   \depedge[edge unit distance=1ex]{7}{5}{mark}
\end{dependency}

\begin{dependency}
   \begin{deptext}[column sep=0.2em]
      He \& says \& that \& you \& like \& to \& swim
%  \& \&  \hspace*{3em} \emph{complm}(like, that)
\\
   \end{deptext}
   \depedge[edge unit distance=0.5ex]{7}{3}{mark}
\end{dependency}
\end{quote}

\noindent\textbf{\emph{mwe}: multi-word expression}\\
The multi-word expression (modifier) relation is used for certain multi-word idioms
that behave like a single function word.  It is used for a closed set
of dependencies between words in common multi-word expressions for which
it seems difficult or unclear to assign any other relationships.  At
present, this relation is used inside the following expressions:
\emph{rather than, as well as, instead of, such as, because of, instead
  of, in addition to, all but, such as, because of, instead of, due to}.  The boundaries of this class are unclear; it could
grow or shrink a little over time.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``I like dogs as well as cats'' \> \> \emph{mwe}(well, as)\\
\>                                 \> \> \emph{mwe}(well, as)\\
\> ``He cried because of you'' \> \> \emph{mwe}(of, because)\\
\end{tabbing}

\noindent\textbf{\emph{neg}: negation modifier}\\
The negation modifier is the relation between a negation word and the word it modifies.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``Bill is not a scientist'' \> \> \emph{neg}(scientist, not)\\
\> ``Bill doesn't drive'' \> \> \emph{neg}(drive, n't)\\
\end{tabbing}

\noindent\textbf{\emph{nn}: noun compound modifier}\\
A noun compound modifier of an NP is any noun that serves to modify the head noun. (Note that in the current system for dependency extraction, all nouns modify the rightmost noun of the NP -- there is no intelligent noun compound analysis.  This is likely to be fixed once the Penn Treebank represents the branching structure of NPs.)
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``Oil price futures'' \> \> \emph{nn}(futures, oil)\\
\> \> \> \emph{nn}(futures, price)\\
\end{tabbing}

\noindent\textbf{\emph{npadvmod}: noun phrase as adverbial modifier}\\
This relation captures various places where something syntactically a noun phrase (NP) is used as an adverbial modifier in a sentence.   These usages include: (i)~a measure phrase, which is the relation between
the head of an ADJP/ADVP/PP and the head of a measure phrase modifying the ADJP/ADVP; (ii)~noun phrases giving an extent inside a VP which are not objects; (iii)~financial constructions involving an adverbial or PP-like NP, notably
the following construction \emph{\$5 a share}, where the second NP means ``per share''; (iv)~floating reflexives; and (v)~certain other absolutive NP constructions.
A temporal modifier (tmod) is a subclass of npadvmod which is distinguished as a separate relation.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``The director is 65 years old'' \> \> \emph{npadvmod}(old, years)\\
\> ``6 feet long'' \> \> \emph{npadvmod}(long, feet)\\
\> ``Shares eased a fraction'' \>\> \emph{npadvmod}(eased, fraction)\\
\> ``IBM earned \$ 5 a share'' \>\> \emph{npadvmod}(\$, share)\\
\> ``The silence is itself significant'' \>\> \emph{npadvmod}(significant, itself) \\
\>  ``90\% of Australians like him, the most of any country'' \>\> \emph{npadvmod}(like, most)
\end{tabbing}

\noindent\textbf{\emph{nsubj}: nominal subject}\\
A nominal subject is a noun phrase which is the syntactic subject of a clause. The governor of this relation might not always be a verb: when the verb is a copular verb, the root of the clause is the complement of the copular verb, which can be an adjective or noun.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``Clinton defeated Dole'' \> \> \emph{nsubj}(defeated, Clinton)\\
\hspace{1cm} \> ``The baby is cute'' \> \> \emph{nsubj}(cute, baby)\\
\end{tabbing}

\noindent\textbf{\emph{nsubjpass}: passive nominal subject}\\
A passive nominal subject is a noun phrase which is the syntactic subject of a passive clause.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\> ``Dole was defeated by Clinton'' \> \> \emph{nsubjpass}(defeated, Dole)\\
\end{tabbing}

\noindent\textbf{\emph{num}: numeric modifier}\\
A numeric modifier of a noun is any number phrase that serves to
modify the meaning of the noun with a quantity.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``Sam ate 3 sheep'' \> \>  \emph{num}(sheep, 3)\\
\>  ``Sam spent forty dollars'' \> \>  \emph{num}(dollars, 40)\\
\>  ``Sam spent \$ 40'' \> \>  \emph{num}(\$, 40)\\
\end{tabbing}

\noindent\textbf{\emph{number}: element of compound number}\\
An element of compound number is a part of a number phrase or currency
amount. We regard a number as a specialized kind of multi-word expression.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``I have four thousand sheep'' \> \> \emph{number}(thousand, four)\\
\>  ``I lost \$ 3.2 billion'' \> \> \emph{number}(billion, 3.2)\\
\end{tabbing}

\noindent\textbf{\emph{parataxis}: parataxis}\\
The parataxis relation (from Greek for ``place side by side'') is a relation between the main verb of a clause and other sentential elements, such as a sentential parenthetical, a clause after a ``:'' or a ``;'', or two sentences placed side by side without any explicit coordination or subordination.
\begin{tabbing}
	\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{2cm}\=  \kill
\> ``The guy, John said, left early in the morning'' \> \> \emph{parataxis}(left, said)\\
\> ``Let's face it we're annoyed'' \>\> \emph{parataxis}(Let, annoyed)\\
\end{tabbing}

\noindent\textbf{\emph{pcomp}: prepositional complement}\\
This is used when the complement of a preposition is a clause or
prepositional phrase (or occasionally, an adverbial phrase).
The prepositional complement of a preposition is the head of a clause
following the preposition,
or the preposition head of the following PP.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{2cm}\=  \kill
\>  ``We have no information on whether users are at risk'' \> \> \emph{pcomp}(on, are)\\
\hspace{1cm} \> ``They heard about you missing classes'' \> \>  \emph{pcomp}(about, missing)\\
%\> ``It is warmer in Greece than in Italy'' \>\> \emph{pcomp}(than, in)
\end{tabbing}

\noindent\textbf{\emph{pobj}: object of a preposition}\\
The object of a preposition is the head of a noun phrase following the preposition, or the adverbs ``here'' and ``there''. (The preposition in turn may be modifying a noun, verb, etc.) Unlike the Penn Treebank, we here define cases of VBG quasi-prepositions like ``including'', ``concerning'', etc.\ as instances of \emph{pobj}. (The preposition can be tagged a FW for ``pace'', ``versus'', etc. It can also be called a CC -- but we don't currently handle that and would need to distinguish from conjoined prepositions.) In the case of preposition stranding, the object can precede the preposition (e.g., ``What does CPR stand for?'').
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``I sat on the chair'' \> \> \emph{pobj}(on, chair)\\
\end{tabbing}

\noindent\textbf{\emph{poss}: possession modifier}\\
The possession modifier relation holds between the head of an NP and its possessive determiner, or a genitive 's complement.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``their offices'' \> \> \emph{poss}(offices, their)\\
\> ``Bill's clothes'' \> \> \emph{poss}(clothes, Bill)\\
\end{tabbing}

\noindent\textbf{\emph{possessive}: possessive modifier}\\
The possessive modifier relation appears between the head of an NP and the genitive 's.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``Bill's clothes'' \> \> \emph{possessive}(John, 's)\\
\end{tabbing}

\noindent\textbf{\emph{preconj}: preconjunct}\\
A preconjunct is the relation between the head of an NP and a word that appears at the beginning bracketing a conjunction (and puts emphasis on it), such as ``either'', ``both'', ``neither'').
\begin{tabbing}
	\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\>  ``Both the boys and the girls are here'' \> \> \emph{preconj}(boys, both)\\
\end{tabbing}

\noindent\textbf{\emph{predet}: predeterminer}\\
A predeterminer is the relation between the head of an NP and a word that precedes and modifies the meaning of the NP determiner.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``All the boys are here'' \> \> \emph{predet}(boys, all)\\
\end{tabbing}

\noindent\textbf{\emph{prep}: prepositional modifier}\\
A prepositional modifier of a verb, adjective, or noun is any prepositional phrase that serves to modify the meaning of the verb, adjective, noun, or even another prepositon.  In the collapsed representation, this is used only for prepositions with NP complements.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``I saw a cat in a hat'' \> \> \emph{prep}(cat, in)\\
\> ``I saw a cat with a telescope'' \> \> \emph{prep}(saw, with)\\
\> ``He is responsible for meals'' \> \> \emph{prep}(responsible, for)\\
\end{tabbing}

\noindent\textbf{\emph{prepc}: prepositional clausal modifier}\\
In the collapsed representation (see section \ref{types}), a prepositional clausal modifier of a verb, adjective, or noun is a clause introduced by a preposition which  serves to modify the meaning of the verb, adjective, or noun.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``He purchased it without paying a premium'' \> \> \emph{prepc\_without}(purchased, paying)\\
\end{tabbing}

\noindent\textbf{\emph{prt}: phrasal verb particle}\\
The phrasal verb particle relation identifies a phrasal verb, and holds between the verb and its particle.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\>  ``They shut down the station'' \> \> \emph{prt}(shut, down)\\
\end{tabbing}

\noindent\textbf{\emph{punct}: punctuation}\\
This is used for any piece of punctuation in a clause, if punctuation is being retained in the typed dependencies. By default, punctuation is not retained in the output.
\begin{tabbing}
\hspace{1cm} \= xxxxxxxxxxxxxxxxxxxxxxxxxx\= \hspace{.5cm}\=  \kill
\> ``Go home!'' \> \> \emph{punct}(Go, !)\\
\end{tabbing}

\noindent\textbf{\emph{quantmod}: quantifier phrase modifier}\\
A quantifier modifier is an element modifying the head of a QP constituent.  (These are modifiers in complex numeric quantifiers, not other types of ``quantification''.  Quantifiers like ``all'' become det.)
\begin{tabbing}
	\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\>  ``About 200 people came to the party'' \> \> \emph{quantmod}(200, About)\\
\end{tabbing}

\noindent\textbf{\emph{rcmod}: relative clause modifier}\\
A relative clause modifier of an NP is a relative clause modifying the NP.  The relation points from the head noun of the NP to the head of the relative clause, normally a verb.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\>  ``I saw the man you love'' \> \> \emph{rcmod}(man, love)\\
\> ``I saw the book which you bought'' \> \> \emph{rcmod}(book,bought)\\
\end{tabbing}

\noindent\textbf{\emph{ref}: referent}\\
A referent of the head of an NP is the relative word introducing the relative clause modifying the NP.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\>  ``I saw the book which you bought'' \> \> \emph{ref}(book, which)\\
\end{tabbing}

% \noindent\textbf{\emph{rel}: relative}\\
% A relative of a relative clause is the head word of the WH-phrase introducing it.
% This analysis is used only for relative words which are not easily
% resolvable to a role in the relative clause. Relative words which act
% as the subject or object of a relative clause are analyzed as a
% \emph{nsubj} or \emph{dobj}.
% \begin{tabbing}
% \hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
% \> ``I saw the man whose wife you love'' \> \> \emph{rel}(love, wife)
% \end{tabbing}

\noindent\textbf{\emph{root}: root}\\
The root grammatical relation points to the root of the sentence. A fake node ``ROOT'' is used as the governor. The ROOT node is indexed with ``0'', since the indexation of real words in the sentence starts at 1.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\> ``I love French fries.'' \> \> \emph{root}(ROOT, love)\\
\> ``Bill is an honest man'' \>  \> \emph{root}(ROOT, man)\\
\end{tabbing}

\noindent\textbf{\emph{tmod}: temporal modifier}\\
A temporal modifier (of a VP, NP, or an ADJP is a bare noun phrase constituent that serves to modify the meaning of the constituent by specifying a time.  (Other temporal modifiers are prepositional phrases and are introduced as prep.)
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\> ``Last night, I swam in the pool'' \> \> \emph{tmod}(swam, night)\\
\end{tabbing}

\noindent\textbf{\emph{vmod}: reduced non-finite verbal modifier}\\
A reduced non-finite verbal modifier is a participial or infinitive
form of a verb heading a phrase (which may have some arguments,
roughly like a VP). These are used to modify the meaning of an NP or
another verb. They are not core arguments of a verb
or full finite relative clauses.
\begin{tabbing}
\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{2cm}\=  \kill
\>  ``Points to establish are \ldots'' \> \> \emph{vmod}(points, establish)\\
\> ``I don't have anything to say to you'' \> \> \emph{vmod}(anything, say)\\
\>  ``Truffles picked during the spring are tasty'' \> \> \emph{vmod}(truffles, picked)\\
\>  ``Bill tried to shoot, demonstrating his incompetence'' \> \> \emph{vmod}(shoot, demonstrating)\\
\end{tabbing}

\noindent\textbf{\emph{xcomp}: open clausal complement}\\
An open clausal complement (\emph{xcomp}) of a verb or an adjective is
a predicative or clausal complement without its own subject. The
reference of the subject is necessarily determined by an argument
external to the xcomp (normally by the object of the next higher
clause, if there is one, or else by the subject of the next higher clause.
These complements are always non-finite, and they are complements
(arguments of the higher verb or adjective) rather than
adjuncts/modifiers, such as a purpose clause.
The name \emph{xcomp} is borrowed from Lexical-Functional Grammar.
\begin{tabbing}
	\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\>  ``He says that you like to swim'' \> \> \emph{xcomp}(like, swim)\\
\hspace{1cm} \> ``I am ready to leave'' \> \>  \emph{xcomp}(ready, leave)\\
\> ``Sue asked George to respond to her offer'' \> \> \emph{xcomp}(ask, respond) \\
\> ``I consider him a fool'' \> \> \emph{xcomp}(consider, fool) \\
\> ``I consider him honest'' \> \> \emph{xcomp}(consider, honest) \\
\end{tabbing}

\noindent\textbf{\emph{xsubj}: controlling subject}\\
A controlling subject is the relation between the head of a open clausal complement (\emph{xcomp}) and the external subject of that clause.
This is an additional dependency, not a basic depedency.
\begin{tabbing}
	\hspace{1cm} \=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\= \hspace{1cm}\=  \kill
\> ``Tom likes to eat fish'' \> \> \emph{xsubj}(eat, Tom)\\
\end{tabbing}

\section{Hierarchy of typed dependencies}\label{hierarchy}
The grammatical relations defined in the above section stand in a hierarchy. The most generic grammatical relation, dependent (\emph{dep}), will be used when a more precise relation in the hierarchy does not exist or cannot be retrieved by the system.

\begin{tabbing}
xxxxx\= xxxxx\= xxxxx\= xxxxx\= xxxxx \kill
\emph{root} - root\\
\emph{dep} - dependent \\
 \> \emph{aux} - auxiliary \\
 \> \> \emph{auxpass} - passive auxiliary\\
 \> \> \emph{cop} - copula\\
 \> \emph{arg} - argument \\
   \> \> \emph{agent} - agent\\
    \> \> \emph{comp} - complement \\
	  \> \> \> \emph{acomp} - adjectival complement \\
	  \> \> \> \emph{ccomp} - clausal complement with internal subject \\
      \> \> \> \emph{xcomp} -  clausal complement with external subject\\
      \> \> \> \emph{obj} - object \\
        \> \> \> \> \emph{dobj} - direct object \\
        \> \> \> \> \emph{iobj} - indirect object \\
        \> \> \> \> \emph{pobj} - object of preposition \\
%      \> \> \> \emph{rel} - relative (word introducing a \emph{rcmod})\\
	\> \>  \emph{subj} - subject \\
	      \> \> \> \emph{nsubj} - nominal subject \\
	        \> \> \> \> \emph{nsubjpass} - passive nominal subject \\
	      \> \> \> \emph{csubj} - clausal subject \\
		  \> \> \> \> \emph{csubjpass} - passive clausal subject \\
 \> \emph{cc} - coordination \\
 \> \emph{conj} - conjunct \\
 \> \emph{expl} - expletive (expletive ``there'') \\
 \> \emph{mod} - modifier \\
    \> \> \emph{amod} - adjectival modifier \\
    \> \> \emph{appos} - appositional modifier \\
    \> \> \emph{advcl} - adverbial clause modifier \\
    \> \> \emph{det} - determiner \\
    \> \> \emph{predet} - predeterminer\\
    \> \> \emph{preconj} - preconjunct \\
    \> \> \emph{vmod} - reduced, non-finite verbal modifier \\
    \> \> \emph{mwe} - multi-word expression modifier \\
    \> \> \> \emph{mark} - marker (word introducing an \emph{advcl} or
    \emph{ccomp} \\
    \> \> \emph{advmod} - adverbial modifier \\
    \> \>  \> \emph{neg} - negation modifier \\
    \> \> \emph{rcmod} - relative clause modifier \\
    \> \> \emph{quantmod} - quantifier modifier\\
   \> \> \emph{nn} - noun compound modifier \\
    \> \> \emph{npadvmod} - noun phrase adverbial modifier\\
	\> \> \> \emph{tmod} - temporal modifier \\
    \> \> \emph{num} - numeric modifier \\
    \> \> \emph{number} - element of compound number \\
    \> \> \emph{prep} - prepositional modifier \\
    \> \> \emph{poss} - possession modifier \\
    \> \> \emph{possessive} - possessive modifier (\emph{'s}) \\
    \> \> \emph{prt} - phrasal verb particle \\
\> \emph{parataxis} - parataxis \\
\> \emph{goeswith} - goes with \\
\> \emph{punct} - punctuation\\
\> \emph{ref} - referent \\
\> \emph{sdep} - semantic dependent \\
    \> \> \emph{xsubj} - controlling subject \\
\end{tabbing}

\section{Different styles of dependency representation}\label{types}

Five variants of the typed dependency representation are available in the dependency extraction system provided with the Stanford parser. The representations follow the same format.  In the plain text format, a dependency is written as \emph{abbreviated\_relation\_name}(governor, dependent) where the governor and the dependent are words in the sentence to which a number indicating the position of the word in the sentence is appended.\footnote{In some cases, an apostrophe is added after the word position number: see section \ref{alteration} for more details.}  The parser also provides an XML format which captures the same information. The differences between the five formats are that they range from a more surface-oriented representation, where each token appears as a dependent in a tree, to a more semantically interpreted representation where certain word relationships, such as prepositions, are represented as dependencies, and the set of dependencies becomes a possibly cyclic graph.

\subsection{Basic}
The basic typed dependencies use the dependencies defined in section
\ref{def}, and form a tree structure. Each word in the sentence is the
dependent of exactly one thing, either another word in the sentence or
the distingushed ``ROOT-0'' token.
 For the sentence, ``Bell, a company which is based in LA, makes and distributes computer products.'', the basic typed dependencies will be:
\begin{verbatim}
nsubj(makes-11, Bell-1)
det(company-4, a-3)
appos(Bell-1, company-4)
nsubjpass(based-7, which-5)
auxpass(based-7, is-6)
rcmod(company-4, based-7)
prep(based-7, in-8)
pobj(in-8, LA-9)
root(ROOT-0, makes-11)
cc(makes-11, and-12)
conj(makes-11, distributes-13)
nn(products-15, computer-14)
dobj(makes-11, products-15)
\end{verbatim}

\subsection{Collapsed dependencies}

In the collapsed representation,
dependencies involving prepositions, conjuncts, as well as information about the referent of relative clauses are collapsed to get direct dependencies between content words.  This ``collapsing'' is often useful in simplifying patterns in relation extraction applications.
For instance, the dependencies involving the preposition ``in'' in the above example will be collapsed into one single relation:\\
\indent \texttt{prep(based-7, in-8)}\\
\indent \texttt{pobj(in-8, LA-9)}\\
will become\\
\indent \texttt{prep\_in(based-7, LA-9)}

\bigskip

\noindent Moreover, additional dependencies are considered, even ones that break the tree structure (turning the dependency structure into a \emph{directed graph}). So in the above example, the following relation will be added:\\
\indent \texttt{ref(company-4, which-5)}\\
That relation does not appear in the basic representation since it creates a cycle with the \texttt{rcmod} and \texttt{nsubjpass} relations. Relations that break the tree structure are the ones taking into account elements from relative clauses and their antecedents (as shown in this example), the controlling (\emph{xsubj}) relations, and the (\emph{pobj}) relation in the case of preposition stranding.

\bigskip

English has some very common multi-word constructions that function like prepositions.  These are also collapsed as prepositional relations. At the moment, the system  handles the multi-word prepositions listed in Tables \ref{2wp} and~\ref{3wp}.

\begin{table}
\begin{center}
\begin{tabular}{lllll}\hline
according to & as per & compared to & instead of & preparatory to  \\
across from & as to &  compared with & irrespective of & previous to  \\
ahead of & aside from & due to & next to & prior to \\
along with & away from & depending on & near to & pursuant to \\
alongside of & based on & except for & off of & regardless of \\
apart from & because of & exclusive of  & out of & subsequent to \\
as for & close by & contrary to & outside of & such as \\
as from & close to & followed by & owing to & thanks to \\
as of & contrary to & inside of & preliminary to & together with\\ \hline
\end{tabular}
\caption{List of two-word prepositions that the system can collapse.}\label{2wp}
\end{center}
\end{table}

\bigskip

\noindent The same happens for dependencies involving conjunction:\\
\indent \texttt{cc(makes-11, and-12)}\\
\indent \texttt{conj(makes-11, distributes-13)}\\
become\\
\indent \texttt{conj\_and(makes-11, distributes-13)}\\
A few variant conjunctions for ``and (not)'' are collapsed together in this representation as shown in Table~\ref{conjand}.

\bigskip

\noindent The information about the antecedent of the relative clause (\texttt{ref(company-4, which-5)}) will serve to expand the following dependency:\\
\indent \texttt{nsubjpass(based-7, which-5)}\\
becomes\\
\indent \texttt{nsubjpass(based-7, company-4)}

\bigskip

\noindent In the end the collapsed dependencies that the system gives you for the sentence are:
\begin{verbatim}
nsubj(makes-11, Bell-1)
det(company-4, a-3)
appos(Bell-1, company-4)
nsubjpass(based-7, company-4)
auxpass(based-7, is-6)
rcmod(company-4, based-7)
prep_in(based-7, LA-9)
root(ROOT-0, makes-11)
conj_and(makes-11, distributes-13)
nn(products-15, computer-14)
dobj(makes-11, products-15)
\end{verbatim}

\begin{table}
\begin{center}
\begin{tabular}{lllll}\hline
by means of & in case of & in place of & on behalf of & with respect to\\
in accordance with & in front of & in spite of & on top of & \\
in addition to & in lieu of & on account of & with regard to &\\
 \hline
\end{tabular}
\caption{List of three-word prepositions that the system can collapse.}\label{3wp}
\end{center}
\end{table}

\begin{table}
\begin{center}
\begin{tabular}{lllll}\hline
\textbf{Mapped to} & \\
\emph{conj\_and} & as well as & not to mention & but also & \& \\
\emph{conj\_negcc} & but not & instead of & rather than & but rather \\
\hline
\end{tabular}
\caption{Mapping of select conjunct relations in the collapsed representation.}\label{conjand}
\end{center}
\end{table}

\subsection{Collapsed dependencies with propagation of conjunct dependencies}
When there is a conjunction, you can also get propagation of the dependencies involving the conjuncts. In the sentence here, this propagation should add two dependencies to the collapsed representation; due to the conjunction between the verbs ``makes'' and ``distributes'', the subject and object relations that exist on the first conjunct (``makes'') should be propagated to the second conjunct (``distributes''):\\
\indent \texttt{nsubj(distributes-13, Bell-1)}\\
\indent \texttt{dobj(distributes-13, products-15)}\\
However, at present, our converter handles this imperfectly and only generates the first of these two dependencies (in general, it is hard to determine if object dependencies should be distributed or not in English).

Since this representation is an extension of the collapsed dependencies, it does not guarantee a tree structure.

\subsection{Collapsed dependencies preserving a tree structure}
In this representation, dependencies which do not preserve the tree structure are omitted. As explained above, this concerns relations between elements of a relative clause and its antecedent, as well as the controlling subject relation (\emph{xsubj}), and the object of preposition (\emph{pobj}) in the case of preposition stranding. This also does not allow propagation of conjunct dependencies. In our example, the dependencies in this representation are actually identical to the ones in the collapsed representation:
\begin{verbatim}
	nsubj(makes-11, Bell-1)
	det(company-4, a-3)
	appos(Bell-1, company-4)
	nsubjpass(based-7, which-5)
	auxpass(based-7, is-6)
	rcmod(company-4, based-7)
	prep_in(based-7, LA-9)
	root(ROOT-0, makes-11)
	conj_and(makes-11, distributes-13)
	nn(products-15, computer-14)
	dobj(makes-11, products-15)
\end{verbatim}

\subsection{Non-collapsed dependencies}\label{non-collapsed}
This representation gives the basic dependencies as well as the extra ones (which break the tree structure), without any collapsing or propagation of conjuncts. There are options to get the extra dependencies separated from the basic dependencies (see section \ref{in_practice}). At print time, the dependencies in this representation can thus look as follows:
\begin{verbatim}
nsubj(makes-11, Bell-1)
det(company-4, a-3)
appos(Bell-1, company-4)
nsubjpass(based-7, which-5)
auxpass(based-7, is-6)
rcmod(company-4, based-7)
prep(based-7, in-8)
pobj(in-8, LA-9)
root(ROOT-0, makes-11)
cc(makes-11, and-12)
conj(makes-11, distributes-13)
nn(products-15, computer-14)
dobj(makes-11, products-15)
======
ref(company-4, which-5)
\end{verbatim}

\subsection{Alteration of the sentence semantics}\label{alteration}
In some cases, collapsing relations introduces a slight alteration of the semantics of the sentence. In all the representation styles involving collapsing, the two following phenomena may appear.

\paragraph{Introduction of copy nodes marked with an apostrophe.}
A copy node will be introduced in the case of PP conjunction as in ``Bill went over the river and through the woods''. In this example, the two prepositions ``over'' and ``through'' are conjoined and governed by the verb ``went''. To avoid disjoint subgraphs when collapsing the relations (preposition and conjunction), sentences like this are transformed into VP coordination, which requires making a copy of the word ``went''. A copy node will be marked with one or more apostrophes in the plain text output or by a \texttt{copy} attribute in the XML output. This gives the following representation, which corresponds to a sentence like ``Bill went over the river and went through the woods'':\\
\indent prep\_over(went-2, river-5)\\
\indent prep\_through(went-2’, woods-10)\\
\indent conj\_and(went-2, went-2’)

\paragraph{Distortion in governors of preposition modifiers.}
Another instance where collapsing sacrifices some linguistic fidelity is the case of preposition modifiers. When turning the preposition into a relation, the preposition does not appear as a word of the sentence anymore. Therefore preposition modifiers become dependent on the head of the clause in which they appear, and not on the preposition itself. In \emph{He left his office just before lunch time}, \emph{just} will be an adverbial modifier of the verb \emph{left}. This induces some distortion in the exact semantics of the sentence.

\subsection{The treatment of copula verbs}
The design philosophy of SD has been to maximize dependencies between
content words, and so we normally regard a copula verb like \emph{be}
as an auxiliary modifier, even when its complement is an adjective or
predicative noun (see the references in section~\ref{refs} for more discussion and motivation).  However, some people do not like this because then the head of some sentences is no longer a verb.  In the dependency conversion software, you can ask for the copula to remain the head when its complement is an adjective or noun by giving the flag \texttt{-makeCopulaHead}.  Uses of the verb \emph{be} as in auxiliary in passives and progressives will still be treated as a non-head auxiliary.

\subsection{Comparison of the representation styles}
\noindent To facilitate comparison, the table below shows the dependencies for the four variants for the example sentence ``Bell, a company which is based in LA, makes and distributes computer products''. The ``non-collapsed'' variant (see section \ref{non-collapsed}) contains all the relations in the ``basic'' variant plus one extra dependency: ref(company-4, which-5).

\bigskip

{\scriptsize
\noindent
\begin{tabular} {@{}llll@{}} \hline
	\textbf{basic} & \textbf{collapsed} & \textbf{propagation} &\textbf{collapsed tree} \\ \hline
	nsubj(makes, Bell) & 	nsubj(makes, Bell) & 	nsubj(makes, Bell) & 	nsubj(makes, Bell)\\
	& & nsubj(distributes, Bell) & \\
	det(company, a) & det(company, a) & det(company, a) & det(company, a)\\
	appos(Bell, company) & appos(Bell, company) & appos(Bell, company) & appos(Bell, company)\\
	nsubjpass(based, which) & nsubjpass(based, company) & nsubjpass(based, company) & nsubjpass(based, which)\\
	auxpass(based, is) & auxpass(based, is) & auxpass(based, is) & auxpass(based, is-)\\
	rcmod(company, based) & rcmod(company, based) & rcmod(company, based) & rcmod(company, based)\\
	prep(based, in)  & & & \\
	& prep\_in(based, LA) & prep\_in(based, LA) & prep\_in(based, LA) \\
	pobj(in, LA)   &  &&\\
	root(ROOT, makes) & root(ROOT, makes) & root(ROOT, makes) & root(ROOT, makes)\\
	cc(makes, and) & & & \\
	&  conj\_and(makes, distributes) & conj\_and(makes, distributes) & conj\_and(makes, distributes)\\
	conj(makes, distributes) & & & \\
	nn(products, computer) & nn(products, computer) & nn(products, computer) & nn(products, computer) \\
	dobj(makes, products) & dobj(makes, products) & dobj(makes, products) & dobj(makes, products)\\ \hline
\end{tabular}}

\subsection{Graph-theoretic properties}

Dependency syntax representations are naturally thought of as ``directed graphs'',
but some of the precise formal properties of Stanford dependencies graphs can
surprise people, so here we summarize the main graph-theoretic
properties.
The unusual properties are all things that occur with relative clauses
and/or questions.
A summary of the properties is shown in table~\ref{graph-properties}.
To cover the collapsed representations, you need what is commonly referred to
as a labeled, directed multigraph.

\begin{table}
\begin{tabular}{llllll}
\hline
 & basic & collapsed & CCprocessed & collapsed tree & basic plus extras\\ \hline
Connected? & Yes & Yes & Yes & Yes & Yes \\
All tokens are nodes? & Yes & No & No & No & Yes \\
Rooted? & Yes & Yes & Yes & Yes & Yes \\
Acyclic & Yes & No & No & Yes & Yes \\
Multigraph & No & No & No & No & Yes \\
Tree & Yes & No & No & Yes & No \\
Self-loops? & No & No & No & No & No \\
Projective? & No & No & No & No & No \\ \hline
\end{tabular}
\caption{Graph-theoretic properties of different versions of SD graphs.}\label{graph-properties}
\end{table}

A non-standard property of graphs applicable to dependencies is
\emph{projectivity}, which arises from the fact that depedency tree
nodes possess a linear order, given by their order of occurrence in sentences. A
dependency tree is projective if all arcs are projective, and an arc
from head $w_i$ to dependent $w_j$ is projective if $w_i$ is an
ancestor of each word $w_k$ between $w_i$ and
$w_j$. Put more simply, if you draw the dependencies above a sentence
written out in the usual way, a non-projective dependency structure
will have one or more crossing lines. In current versions, no variant of Stanford Dependencies
always produces projective dependency trees.\footnote
 {The basic dependencies output by early versions of
   the Stanford Dependencies converter \emph{did} only produce
   projective trees. Starting with v.3.2, non-projective dependency
   trees are produced in appropriate places for questions and relative clauses.}
However, most trees are projective: Non-projective trees only occur
occasionally in English, in structure such as questions and relative clauses.

The collapsed and CCprocessed dependencies are not a DAG\@.
The graphs can contain small cycles between two nodes (only).
These don't seem eliminable given the current
representational choices.  They occur with relative clauses such as
\emph{the woman who introduced you}.  The cycles occur once you wish to represent the
referent of \emph{who}. In the basic plus extras
representation, you get \emph{rcmod}(woman, introduced), \emph{nsubj}(introduced, who),
and \emph{ref}(woman, who).\footnote
  {Arguably, that third dependency should already have been represented the
   other way around as \emph{ref}(who, woman), giving a three node cycle, but
   it wasn't.}
In the collapsing process, \emph{ref} arcs are collapsed, and so there is then
a two node cycle: \emph{rcmod}(woman, introduced) and \emph{nsubj}(introduced, woman).
These cycles can occur at the ``top'' of the graph when an NP is the head of the
sentence, given the treatment of copula verbs (as in \emph{She is the woman who introduced me.}). This used to
mean that the dependency graph didn't have a clear root. This was fixed after
version 1.6.8 by explicitly adding a \emph{root} arc to the representation.

There can be multiple arcs with the same label from a node.  For instance, this
occurs when a noun has several adjective modifiers, each of which gets an
\emph{amod} relation, as in \emph{its third consecutive monthly decline}.

% CDM Jun 2013: The rel case shouldn't happen any more. Are there other cases?
% Yes, it does, but only due to converter bugs, I think.
% There can be multiple arcs between two nodes with different labels in the basic
% plus extras representation.  A relative word can be labeled both as a \emph{rel}
% and as its effective grammatical relation.  For example, for \emph{the company
% which you founded}, using the basic plus extras style, you get both the arcs
% \emph{dobj}(founded-7, which-5) and
% \emph{rel}(founded-7, which-5).
In the basic plus extras representation, a word can be the dependent
of two different words. For example, a relative word will be a
\emph{ref} of the head of the noun phrase it modifies and will have a
role in the relative clause.  For example you might get both the arcs
\emph{ref}(researchers-5, who-6) and \emph{nsubj}(studied-7,
who-6). You can even get two arcs between the same pair of words,
though these normally result from bugs in the converter.

All graphs should be connected (if there are disconnected graphs, it's a bug!).
There are no self-loops in the graphs.

\section{In practice}\label{in_practice}

In practice, two classes can be used to get the typed dependencies of a sentence using the code in the Stanford parser (downloadable at \textsf{http://nlp.stanford.edu/software/lex-parser.shtml}).

\subsubsection*{$\star$ \textbf{edu.stanford.nlp.parser.lexparser.LexicalizedParser}}

If you need to parse texts and want to get different formatting options for the parse tree, you should use this class. To get the dependencies, add \texttt{typedDependencies} in the \texttt{-outputFormat} option. By default, this will give you collapsed dependencies with propagation of conjunct dependencies. If you want another representation, specify it in the \texttt{-outputFormatOptions} using the following commands according to the type of dependency representation you want:

\begin{description}
\item[\texttt{basicDependencies}] Basic dependencies.
\item[\texttt{collapsedDependencies}] Collapsed dependencies (not necessarily a tree structure).
\item[\texttt{CCPropagatedDependencies}] Collapsed dependencies with propagation of conjunct
dependencies (not necessarily a tree structure).  [This representation is the default, if no option is specified.]
\item[\texttt{treeDependencies}] Collapsed dependencies that preserve a tree structure.
\item[\texttt{nonCollapsedDependencies}]  Non-collapsed dependencies: basic dependencies as well as
 the extra ones which do not preserve a tree structure.
\item[\texttt{nonCollapsedDependenciesSeparated}] Non-collapsed dependencies where the basic dependencies
are separated from the extra ones (by ``======'').
\end{description}

\noindent You should also use the \texttt{-retainTmpSubcategories}
option to get best performance in recognizing temporal
dependencies. In the following command, \texttt{file.txt} contains
your input sentences.  (With this command-line, the parser will
attempt to tokenize and sentence-break them. There are options to the
parser to specify that this has already been done.) The \texttt{penn}
option will also give you the context-free phrase structure grammar
representation of the sentences.

\noindent Note that as of version 3.5.2 the default representation is the new Universal Dependencies representation.
Use the \texttt{-originalDependencies} option to obtain original Stanford Dependencies.

\bigskip

\noindent Command line example: \\
{\hangindent=0.4in
\raggedright\texttt{java -mx200m edu.stanford.nlp.parser.lexparser.LexicalizedParser -retainTmpSubcategories -originalDependencies -outputFormat "penn,typedDependencies" -outputFormatOptions "basicDependencies" englishPCFG.ser.gz file.txt}\\}

\begin{quote}
\hspace*{-0.375in}%
Java example: \\
\small\texttt{LexicalizedParser lp = LexicalizedParser.loadModel(\\
\hspace*{1.5in}"edu/stanford/nlp/models/lexparser/englishPCFG.ser.gz",\\
\hspace*{1.5in}"-maxLength", "80", "-retainTmpSubcategories"); \\
TreebankLanguagePack tlp = new PennTreebankLanguagePack(); \\
// Uncomment the following line to obtain original Stanford Dependencies\\
// tlp.setGenerateOriginalDependencies(true); \\
GrammaticalStructureFactory gsf = tlp.grammaticalStructureFactory();}

\bigskip

\noindent
\texttt{String[] sent = { "This", "is", "an", "easy", "sentence", "." }; \\
Tree parse = lp.apply(Sentence.toWordList(sent)); \\
GrammaticalStructure gs = gsf.newGrammaticalStructure(parse); \\
Collection$\langle$TypedDependency$\rangle$ tdl = gs.typedDependencies(); \\
System.out.println(tdl); }
\end{quote}

\subsubsection*{$\star$ \textbf{edu.stanford.nlp.trees.EnglishGrammaticalStructure}}
If you already have Penn treebank-style trees (whether hand-annotated or as output from another parser), you can use this class to get the Stanford dependencies.

\paragraph{Command-line usage.} Use the \texttt{-treeFile} option as shown in the command line example below. The options to get the different types of representation are as follows:
\begin{tabbing}
\hspace{.3cm} \= \texttt{-originalDependencies} \= \hspace{.3cm} \= \kill
\> \texttt{-basic} \>\> basic dependencies\\
\> \texttt{-collapsed} \>\> collapsed dependencies (not necessarily a tree structure)\\
\> \texttt{-CCprocessed} \>\> collapsed dependencies with propagation of conjunct \\
\> \> \> dependencies (not necessarily a tree structure)\\
\> \texttt{-collapsedTree} \>\> collapsed dependencies that preserve a tree structure\\
\> \texttt{-nonCollapsed} \>\> non-collapsed dependencies: basic dependencies as well as\\
\> 						 \>\> the extra ones which do not preserve a tree structure\\
\> \texttt{-conllx} \>\> dependencies printed out in CoNLL X (CoNLL 2006) format \\
\> \texttt{-originalDependencies} \>\> output the original Stanford Dependencies instead of \\
\>                                            \>\> the new Universal Dependencies.
\end{tabbing}

\noindent If you want the non-collapsed version of the dependencies where the basic ones are separated from the extra ones, add the flag \texttt{-extraSep}. This will print the basic dependencies, a separator (======) and the extra dependencies.
By default, punctuation dependencies are not printed.  If you want
them, give the option \texttt{-keepPunct}.

\bigskip

\noindent Command line example:\\
{\hangindent=0.5in\raggedright\texttt{java  edu.stanford.nlp.trees.EnglishGrammaticalStructure -treeFile
    file.tree -collapsedTree -CCprocessed -keepPunct} \\}

\vspace*{.4cm}
\noindent By default, the CoNLL format retains punctuation. When the
CoNLL format is used with collapsed dependencies, words of the
sentences which have been collapsed into the grammatical relations
(such as prepositions and conjunctions) still appear in the list of
words but are given an ``erased'' grammatical relation:

\bigskip

\begin{tabular}{llllllllll}
1 &	Bell&	\_ &	NNP	&NNP&	\_&	11&	nsubj&	\_&	\_ \\
2 &	, &	\_ &	, &	, &	\_ &	1 &	punct &	\_ &	\_ \\
3 &	a &	\_ &	DT &	DT &	\_ &	4 &	det &	\_ &	\_ \\
4 &	company	 & \_ &	NN &	NN &	\_ &	7 &	nsubjpass &	\_ &	\_ \\
5 &	which &	\_ &	WDT &	WDT &	\_ &	0 &	erased &	\_ &	\_ \\
6 &	is &	\_ &	VBZ &	VBZ &	\_ &	7 &	auxpass &	\_ &\_ \\
7 &	based &	\_ &	VBN &	VBN &	\_ &	4 &	rcmod &	\_ &	\_ \\
8 &	in &	\_ &	IN	 & IN &	\_ &	0 &	erased &	\_ &	\_ \\
9 &	LA &	\_ &	NNP	 & NNP &	\_ &	7 &	prep\_in	 & \_ &	\_ \\
10 &	, &	\_ &	, &	, &	\_ &	1 &	punct &	\_ &	\_ \\
11 &	makes &	\_ &	VBZ &	VBZ &	\_ &	0 &	root &	\_ &	\_ \\
12 &	and &	\_ &	CC &	CC &	\_ &	0 &	erased &	\_ &	\_ \\
13 &	distributes &	\_ &	VBZ	 & VBZ &	\_ &	11 &	conj\_and &	\_ &	\_ \\
14 &	computer &	\_ &	NN &	NN &	\_ &	15 &	nn &	\_ &	\_ \\
15 &	products &	\_ &	NNS	 & NNS &	\_ &	11 &	dobj &	\_ &	\_ \\
16 &	. &	\_ &	. &	. &	\_ &	11 &	punct &	\_ &	\_
\end{tabular}

\vspace*{.4cm}
\noindent This class can read files that contain Stanford dependencies
in the CoNLL format (i.e., the basic Stanford dependencies), and
transform them into another representation (e.g., the CCprocessed
representation). To do this, you need to pass the input file using the
option \texttt{-conllxFile}.

\bigskip

\noindent You can also use this class to parse texts, but  the input has to be formatted as strictly one sentence per line, and you will not be able to specify options for the parse tree output on the command line. You will only be able to specify the type of the dependencies. Use the option \texttt{-sentFile} instead of \texttt{-treeFile}. You will need to specify the parser file using the \texttt{-parserFile} option. You can print the parse tree by using the \texttt{-parseTree} option.

\bigskip

\noindent Command line example:\\
{\hangindent=0.5in\raggedright\texttt{java -mx100m edu.stanford.nlp.trees.EnglishGrammaticalStructure -sentFile file.txt -collapsedTree -CCprocessed -parseTree -parserFile englishPCFG.ser.gz}\\}

\paragraph{API usage.} Basic API usage was already
illustrated in the \texttt{LexicalizedParser} usage above.  If you
have a Tree object, the steps for converting it to dependencies are
like this:
\begin{quote}
\texttt{
// One time setup \\
TreebankLanguagePack tlp = new PennTreebankLanguagePack(); \\
// Uncomment the following line to obtain original Stanford Dependencies\\
// tlp.setGenerateOriginalDependencies(true); \\
GrammaticalStructureFactory gsf = tlp.grammaticalStructureFactory(); \\
// For each Tree \\
Tree parseTree; // assumed to come from a treebank or parser \\
GrammaticalStructure gs = gsf.newGrammaticalStructure(parse); \\
Collection$\langle$TypedDependency$\rangle$ tdl = gs.typedDependencies();
}
\end{quote}
The \texttt{PennTreebankLanguagePack} vends an
\texttt{EnglishGrammaticalStructureFactory}. The only common option
to pass in when creating one is a punctuation filter. Pass in a
\texttt{Filters.$\langle$String$\rangle$\discretionary{}{}{}acceptFilter()} to keep
punctuation dependencies. A \texttt{GrammaticalStructure} is created
for each \texttt{Tree}. The methods on a \texttt{GrammaticalStructure}
for each kind of dependencies is as follows:
\begin{quote}
\begin{tabular}{ll}
basic & \texttt{gs.typedDependencies()} \\
nonCollapsed & \texttt{gs.allTypedDependencies()} \\
collapsed & \texttt{gs.typedDependenciesCollapsed(true)} \\
CCPropagated & \texttt{gs.typedDependenciesCCprocessed()} \\
tree & \texttt{gs.typedDependenciesCollapsedTree()} \\
\end{tabular}
\end{quote}

\subsubsection*{$\star$ \textbf{GrammarScope}}
Bernard Bou has written \textsf{GrammarScope}, a GUI interface to the Stanford
Dependencies representation, which allows not only viewing
dependencies, but altering their definitions.  This is a separate download.  It is available at:
\url{http://grammarscope.sourceforge.net/}.

\subsubsection*{$\star$ \textbf{Other parsers}}

A number of dependency parsers have now been trained to parse directly
to the basic Stanford Dependencies, including MaltParser, DeSR,
MSTParser, and Stanford's Neural Network Dependency Parser.  Several of these parsers distribute models trained for
Stanford Dependencies parsing, including MaltParser, the Easy First
Parser, and the Stanford Neural Network Dependency Parser.  If desired, these parses can then be postprocessed to the collapsed or CCprocessed representation using the \texttt{-conllxFile} option of \texttt{EnglishGrammaticalStructure}, as discussed above.

Any Penn Treebank constituency parser can be used to produce Stanford
Dependencies by using our conversion tool to convert the output of other constituency parsers to the Stanford Dependencies representation.  For more information on other parser options, see:
\begin{quote}
\url{http://nlp.stanford.edu/software/stanford-dependencies.shtml}
\end{quote}

\section{Further references for Stanford Dependencies}\label{refs}

The Stanford Dependencies representation was first made available in
the 2005 version of the Stanford Parser.  Subsequent releases have
provided refinements to and corrections of the relations defined
in the original release.  The initial written presentation was
\citep{demarneffe06generating}.  A more thorough discussion of the
motivations behind the design of the representation appears in
\citep{demarneffe08stanford}.

\begin{sloppypar}
The SD representation has seen considerable use within the biomedical text
mining community.  It has been used to give a task relevant evaluation
scheme for parsers \citep{Clegg07,Pyysalo07} and as a representation
for relation extraction
\citep{Erkan07,Greenwood07,Urbain07,Fundel07,Clegg08,Pyysalo08,giles08large,ozgur08identifying,ramakrishnan08discovery,bjorne08how,Yarten10,Bjorne2011,Pyysalo11,Landeghem12}.
\citet{Pyysalo07} develops a version of the BioInfer corpus annotated
with (a slight variant of) the SD scheme.  It is available for
download at \url{http://mars.cs.utu.fi/BioInfer/}.
A small amount of SD gold standard annotated data was separately prepared for the
Parser Evaluation Shared Task of the Workshop on Cross-Framework and
Cross-Domain Parser Evaluation
(\url{http://lingo.stanford.edu/events/08/pe/}) and is discussed in
\citep{demarneffe08stanford}. This data is available from the Stanford
Dependencies page: \url{http://nlp.stanford.edu/software\discretionary{}{}{}/stanford-dependencies.shtml},
but the BioInfer corpus is the main source of gold-standard SD data which is currently available.
In the recent BioNLP 2009 Shared Task, many of the leading teams built their relation extraction systems over the Stanford Dependency representation \citep{kim09overview}.  It was used by the teams that came 1st, 3rd, 4th, and 5th in Task 1, by the team who came first in Task 2, and by the teams who came 1st and 2nd in Task 3. In the BioNLP 2011 shared task, every team used it \citep{BioNLP11}.
\end{sloppypar}

The SD representation has also been used in other domains.  It is a common representation for
extracting opinions, sentiment, and relations
\citep{Zhuang06cikm,Meena07sentiment,Banko07,Zouaq06tai,Zouaq07tel,chaumartin07knowledge,kessler08icwsm,Haghighi10,Hassan10,Joshi2010,Wu2010,Zouaq10}, as well as specific information (such as event, time or dialogue acts) \citep{Chambers11,McClosky12,Kluwer10}. The tool has been consistently used by several groups in the \textsc{Pascal}/NIST challenges targeting textual entailment \citep{adams-EtAl:2007:WTEP,blake:2007:WTEP,chambers-EtAl:2007:WTEP,harmeling:2007:WTEP,wang-neumann:2007:WTEP,Malakasiotis09,Mehdad09,Shivare2010,Glinos2010,Kouylekov2010,Pakray2011a}. It is also used for a variety of other tasks, such as unsupervised semantic parsing \citep{poon09unsupervised}, coreference resolution, disagreement detection and word sense induction \citep{Chen12,Abbott11,Lau12}, as well as being part of the preprocessing for machine translation systems by several groups \citep{xu09using,genzel10automatically,singh10statistical}.
The Stanford Dependencies representation
was also used to evaluate dependency parsers in the 2012 shared task on parsing the web \citep{Petrov12}.

The Stanford dependency representation has also served as a model for
developing dependency schemes for other languages. The Chinese Stanford
Dependencies are briefly described in
\citet{chang-tseng-jurafsky-manning:2009:SSST}. Representations
based on the Stanford dependency representation have been proposed for
Finnish \citep{Haverinen2010a,Haverinen2010b}, Thai \citep{Potisuk10},
Persian \citep{Seraji12}, and French \citep{Maarouf12}.
More recently, there has been increasing interest in defining a
consistent cross-linguistic set of relations in the style of Stanford
Dependencies
\citep{mcdonald-EtAl:2013:Short,tsarfaty:2013:Short}. The authors and
others initially proposed a reformulation as Universal Stanford
Dependencies \citep{marneffe14universal}. Further refinement with a
team of collaborators has led to a new synthesis spanning
tokenization, morphological features, parts of speech, and
dependencies, known as Universal Dependencies:
\url{http://www.universaldependencies.org}.  Since version 3.5.2
the default representation output by our parser is the Universal Dependencies
representation.

\section{Recent changes}

This section summarizes recent changes. This may help if you see old
versions of the dependencies, or need to update your code.

\begin{description}
\item[abbrev] was removed as a relation.  It is now a particular case
  of an \emph{appos}.
\item[attr] has been removed as a relation. \emph{attr} was a relation intended
for the complement of a copular verb such as ``to be'', ``to seem'', ``to appear''.
Mainly, it was used for WHNP complements.  (The relation \emph{attr}
was meant to stand for ``attributive'' but that was arguably a misuse
of the word.)
\item[complm] was removed as a relation. It is now a particular case of
  \emph{mark}. This follows HPSG-like usage, where the complementizer
  is a mark on the clause.
\item[discourse] was introduced. The lack of a dependency type for
  interjections was an omission even in the early versions, but it
  became more essential as we expanded our consideration of informal
  text types.
\item[goeswith] was introduced. It is useful on badly edited text.
\item[infmod] was remode as a relation. It has been generalized as a
  case of \emph{vmod}.
\item[partmod] was remode as a relation. It has been generalized as a
  case of \emph{vmod}.
\item[purpcl] was removed as a relation. It is now a particular case
  of an \emph{advcl}.
\item[rel] has been removed as a relation. \emph{rel} was the relation
  between the main verb of a relative clause and the head of the
  \emph{Wh-}phrase. Now, the converter resolves the grammatical
  relation (\emph{nsubj}, \emph{dobj}, or \emph{pobj}) for simple
  cases, and the rest are left unresolved as a \emph{dep} relation.
\item[vmod] has been introduced as a relation generalizing over
  non-finite verbal modifiers that are participial in form (formerly
  \emph{partmod}) or infinitival (formerly \emph{infmod}).
\end{description}

\bibliographystyle{plainnat}
\bibliography{StanfordDependenciesManual}

\end{document}


text:
% !TeX root = ../../documentation.tex

\section{Interview with Pirmin Rehm}

This paraphrase of the expert interview with Pirmin Rehm.
If any information of this is used in the thesis, its marked with \cite{Vogel.2020.Rehm}.
\textbf{V} is the abbreviation for \textit{Nico Vogel} and \textbf{R} for \textit{Pirmin Rehm}.

\setspeaker{PirminRehm}[R]

\begin{description}
    \NicoVogel Have you worked with micro frontends shell applications? I know you worked with micro frontends. Therefore, could you name which framework you used, what team's sizes, and some general facts about the structure?

    \PirminRehm I worked for two months in a micro frontend setup project. It is a one pizza size team project, and we used mainly Angular, but we also had some components which were built by Stencil. Not by us, but by another team, and we reused them in our application. The general team structure is full-stack. So, from UX, over design to deployment and infrastructure. From the team, 2 to 3 people worked full time on the frontend.

    \NicoVogel What do you think are suitable scenarios for micro frontends architecture?

    \PirminRehm If we want to use micro frontend architecture, we must heavily rely on its benefits. Because there are so many downsides and challenges, one aspect which indicates that micro frontend architecture is needed is a huge team, which is not capable of working on one application. Another scenario would be if cross-functional teams are required. For example, if the microservice architecture is used in the backend, then each team can be cross-functional, to ensure fast delivery of new features. This follows the actual Lean enterprise or DevOps culture.
    But as I said, using micro frontends comes with a lot of costs. I believe that for enterprise applications, it is mostly not needed. Two examples where it does not fit would be an application that is developed over a long time until something fresh is available or if the organization uses a waterfall project management practice.
    On the other hand, if the organization uses an agile practice, then micro frontends fit a lot better because an agile environment allows for cross-functional teams.

    \NicoVogel Could you outline the scenario you are working in?

    \PirminRehm It is a greenfield project, and the customer requested that we use micro frontends. IN the end, the project will consist of between 10 to 20 micro frontends. Each micro frontend has its own corresponding microservice. Furthermore, there are some third-party services and frontends which need to be included. All in all, the final development setup for the project will be 3 teams over 6 months of time. After that, the initial scope with the most important features should be covered.

    \NicoVogel Who is the end-user, and on which devices will it be used?

    \PirminRehm The application is only for employees of the customer. Also, the smallest device it will be used from an iPad. The application is for sails agents, and they are mostly on their PCs, and sometimes they show somethings to a customer via the iPad.

    \NicoVogel What are other suitable scenarios for the micro frontend's architecture in general?

    \PirminRehm So, micro frontends are a widely used term, and there are a lot of approaches. The approach we are using is client-side integration via a shell application. I believe this is a fitting approach for enterprise applications. In the case of non-enterprise applications, there are other approaches used. Also, in our case, a micro frontend represents one subdomain, which can cover 5 to7 pages. I have also seen other micro frontends, which are only one feature of one page, like a product cart or something similar. These are very tiny micro frontends. In this case, I do not think they use a shell application as we do.

    \NicoVogel What do you think of my requirements categories? Am I missing anything? Would you change the order of importance?

    \PirminRehm In the case of routing, it depends on the micro frontend size. For example, if each micro frontend is effectively a SPA on its own, then it is important that they provide some kind of sub routing on their own. When introducing such a capability, it is important to make bookmarks into consideration. Therefore, the URL must reflect the application state, so it can be saved as a bookmark or shared with someone. On the other hand, browser routing is not as important if the application consists of tiny micro frontends. In this case, the micro frontend does not need any kind of routing for itself. Performance is a good point. Shared state and micro frontend intercommunication techniques are something to tackle. Styling and developer experience are also good points.

    \NicoVogel Do you think the order of the requirement categories is correct, or would you change it?

    \PirminRehm No, the order is ok.

    \NicoVogel What are requirements for the named shell application scenario which you had from a customer? And if possible, add the approaches you took.

    \PirminRehm Our customer just gave us business requirements and not a single nonfunctional requirement.

    \NicoVogel Ok, then which nonfunctional requirements did you derive from the business requirements?

    \PirminRehm The application has to work on well-performing tablets and desktop browsers. Other things we want to achieve is to quickly release new features and keep the development speed up.

    \NicoVogel Do you also have requirements like, a micro frontend can be placed at multiple routes or can be used in multiple applications. Is there something like that?

    \PirminRehm Yeah. We had a requirement that maybe some micro frontends get reused in other applications. Therefore, we defined an interface that describes how to interact with a micro frontend. The shell needs to be able to handle the fact that some part of the routing is handled by the micro frontend. In our case, the shell only handles the top-level route. Another feature that our shell needs to cover is preloading micro frontends. Currently, the shell can only lazily load frontends.
    In general, our shell application is the glue between the micro frontends. A micro frontend feature, which complicates the shell's job, is that micro frontends can expose widgets. These widgets can be used by any other micro frontend, and it is possible that they are needed before the main micro frontend is displayed. Therefore, the shell needs to handle this edge case. Widgets are one of the most important features for us, and they are wrapped as a Web Component. A widget satisfies our cross-functional needs, and cross-functional pages are needed for a good UX.

    \NicoVogel How did you implement the widgets?

    \PirminRehm Our micro frontends are a single bundle Angular application which itself is exposed as a Web Component. This Web Component implements the interface I explained earlier, and it is used to pass the context to the micro frontend. Each micro frontend can expose Angular Elements that are also wrapped up via Web Components. Therefore, one JavaScript bundle can contain multiple Web Components.

    \NicoVogel What kind of communication requirements do you have?

    \PirminRehm First and foremost, loosely coupling between micro frontends is important for us. If you couple them tightly, then communication will be a mess. We use three communication channels in our application. The first one is the URL. The URL can contain simple state information like a customer ID.
    Next up are events. These can vary widely, but one example would be the navigation event. This event ensures that the shell and all micro frontends are in sync about the current URL. Another example would be notifications the shell should display as a popup. We defined that only the shell can show notifications so that they are identical. The last example of events is life cycle events. For example, a bootstrap event is published by a micro frontend, when it is currently bootstrapped.
    Finally, we pass context to a micro frontend via HTML attributes or properties. This is possible because each micro frontend is wrapped in a Web Component, and they provide the property API. The property API allows us to pass objects or even functions to a Web Component. Which context information and how it is passed to a micro frontend, is defined in the previously mentioned interface. This can be any context information, even what the base-route of the micro frontend is or what its backend URL is. Therefore, we have a very flexible setup.
    I also pointed out that we use widgets, and they also are Web Components. They cannot use the URL communication channel because it is not clear when or where they are included. Therefore, the only way to pass context into them is to use the property API. Events are not suited to exchange context. This leads us to one approach that each widget has a definition of which properties need to be passed for the context in order to use the widget.

    \NicoVogel Can you outline how you handle styling?

    \PirminRehm We have a two-way system. The first being that the customer provides a design system, which is used as a basis. The second way is a utility CSS file, which contains a spacing system, grid system, and similar style information. Later is available as CSS and SCSS, which also includes mixings. These two things ensure that the application has a consistent look and feel.
    Another aspect we need to use is a Web Component library from the customer. It is built up with Stencil. The Web Component library is included by the shell. Therefore, it is available for all micro frontends, but also there is only one version of it. In the case of a major version upgrade, all micro frontends need to use the new version as well. This could be resolved by adding the version number into the Web Component name, but we cannot do that, because it is owned by the customer.
    The design system, utility CSS and Web Component library do not provide everything we need. Therefore, we also create an Angular component library. We could upgrade it to a technology agnostic component library by building it with Stencil or wrapping each component in a Web Component, but for now, we use this approach. The upgrade would be no problem because our interface allows the use of other frameworks if it can be wrapped inside a Web Component. As far as I know, there are some limitations with React.
    Finally, our UX developer extended the customer design system with some smaller utility CSS classes. Because we rely on so much shared stuff, it should be easier to have the same look and feel.

    \NicoVogel What kind of requirements did you define to ensure developer experience?

    \PirminRehm I believe that our styling approach already adds value for the UX developer. This should make it easier for them to create a page. This is further enhanced by the tool Zepplin, which helps to visualize which components are used per page and sizings.
    Another tool we may use is Storybook, which simplifies creating a component in isolation and document it.
    It should also be easy for a developer to work on a single micro frontend. For this, we provide a standalone mode for each micro frontend. This is realized by adding a mock shell. It can be modified as needed, which simplifies end to end testing. But the mock shell is not part of the actual build. It is only for development. In our case, we use Angular for all micro frontends. This allows us to use the mock shell as the main application, and the child application is the actual micro frontend. When developing, the micro frontend is loaded via an import statement in the mock shell, to provide live reload. A second mode allows us to integrate the micro frontend in the same way as in production. This allows us to locally test if everything works as intended.
    Another convenient feature is to run the entire application locally. For this, each micro frontend is provided via another port, and using the Angular proxy configuration allows us to stitch it together. For the backend, we prepared three ways to provide it.
    The first is simply running the entire backend and making it available over one port. The next is a single packed backend, which starts the entire backend with one click. However, it is not capable of connecting to a Kafka cluster. And finally, the third and my favorite way is to forward the backend via Kubernetes port forwarding from a dev-cluster. We added one command into each micro frontend, which automatically sets this up.

    \NicoVogel Do you also mock the backend to allow for contract-driven testing?

    \PirminRehm We discussed if a micro frontend is an individual part, like a microservice, but we concluded that this is not the case. We develop one micro frontend in combination with one microservice, which is its counterpart on the server-side. Because of this decision, we do not implement contract-driven tests between the micro frontends and microservices.

    \NicoVogel Can you name any requirements which are needed for all shell application scenarios? And if possible, which approach would be used?

    \PirminRehm Some are individual deployments, individual testing, and performance optimization.

    \NicoVogel Do you mean loading performance?

    \PirminRehm Every performance aspect. Other requirements would be a unified UX, state handling, context handling, dynamic configuration of resources, loading strategies, independent deployments, and switching versions without rebuild or redeployment.

    \NicoVogel Can you maybe give some approach examples for these points?

    \PirminRehm Individual deployment is mainly achieved by providing a CI/CD pipeline for each micro frontend. Also, a versioned container, default routes, and versioned routes are important as well. An example of where this is helpful would be a rollback. Imagine that your micro frontend is upgraded to version 20, and you realize that there is a major bug that slipped through. In this case, we can quickly revert to version 19, by changing a Kubernetes environment variable.
    Next is individual testing. The first thing, which is different is the usage of the mock shell to host the application. Then each micro frontend is tested end to end individually. Lastly, are the integration test of all micro frontends in combination with the shell.
    Next is performance optimization. A must is that all dependencies are loading optimized. Other things to consider are caching, lazy loading, and maybe sharing dependencies. One approach here is the shared core, which shared the framework core between micro frontends. I am no fan of this approach because it introduces tight coupling between the micro frontends. But in the end, I don't know if it becomes a performance problem. For example, I never ran 15 Angular applications in one browser, but I believe it is like having 15 tabs open. Therefore, I think it is not a problem.

    \NicoVogel I think it depends if the micro frontends are mounted or not. In your example, to achieve 15 active cores, this implies that 15 Angular micro frontends are active on the same page.

    \PirminRehm Yes, but they mostly export widgets. Therefore, they are active. The question is if the change detection cycles drop.
    Back to the requirements. I already explained unified UX, state handling, context handling. Therefore, the next requirement is dynamic configuration.
    As I said, the backend runs on a Kubernetes cluster. Each micro frontend is provided by its own Nginx container. On the container startup, we dynamically create a configuration file based on Kubernetes environment variables. One entry in this configuration file is the backend URL. A practice we follow when releasing a new version is Blue-Green deployment. We leave the old version up for some time, so in case of a problem or increased number of error logs, we can rollback by changing the Kubernetes environment variables and restart the container.
    Next would be the loading strategy, but I already explained it in combination with performance. And I just explained switching versions too.

    \NicoVogel What are the most difficult requirements to archive, and why?

    \PirminRehm Lazy loading is difficult if you need a lot of widgets from the beginning. This can result in losing lazy loading because everything is needed form the start. Another uncertainty is that I do not know what will happen if we increase the number of Angular cores. In general, all requirements are complex and take effort, but in the end, everything can be solved. UX developer will ask for feature X, which is currently not possible with the shell, and so you might need to extend it. This also contains risk.

    \NicoVogel The last question is my thesis question. Do you think that there is a need for a generalized shell application?

    \PirminRehm Of course. I think there are some good approaches like Single-SPA. I did not have the time to take a deeper look at it. In our approach, everything is implemented as an Angular application, even the shell. So, we utilize the Angular router in the shell and in the micro frontends. Having an extension that handles this kind of routing and integrates itself with the Angular router would be great.

\end{description}

ext: tex

max_stars_repo_name: NicoVogel/ba-thesis

max_issues_repo_name: NicoVogel/ba-thesis

max_forks_repo_name: NicoVogel/ba-thesis


text:
\documentclass[main.tex]{subfiles}
\begin{document}

\marginpar{Monday\\ 2020-5-4, \\ compiled \\ \today}

% We are discussing resonance and cavities in order to study the LASERs used in GW interferometry.

We can have a lot of energy stored in the cavity, so that the power of the stored laser beam is much larger than the input power.

This does not violate conservation of energy: the energy is stored, but we cannot extract more power than what is coming in.

% As the reflectivity increases, the peaks of intensity become sharper and sharper.

We can treat the losses inside the cavity by introducing an intensity loss parameter, \(l_{I}\), which is the ratio of the lost power to the circulating power; then we can define
%
\begin{align}
r_{l} = 1 - l_{E} = \sqrt{1 - l_{I}}
\,,
\end{align}
%
% which is derived from \(r_l^2 + l_I = r_l^2 + t_l^2 = 1\).
and then each time \(r_2 \) appears we can substitute it by \(r_2 r_l\) --- this effectively amounts to attributing the power loss to the output coupler.

Then, the fields inside and outside will be given by
%
\begin{subequations}
\begin{align}
E_{c} &= E _{\text{in}} \frac{t_1 }{1 - r_1 r_2 r_{l} e^{-ik2L}}  \\
E_{r} &= - E _{\text{in}} \frac{r_1 - r_2 r_{l} e^{-ik2L}}{1 - r_1 r_2 r_{l} e^{-ik 2L}}
\,.
\end{align}
\end{subequations}

As we saw, the reflected electric field has a component which is due to the promptly reflected incoming field (\(E_{r, p}\)), and a component which is due to the loss of part of the circulating field (\(E_{r, l}\)): we can write this as \(E_r = E_{r, p} + E_{r, l}\).

These are of the same order of magnitude: the mirrors are very reflective, but inside the cavity the power is much greater than outside. Since they are comparable, the interference of these two contributions is interesting.

We can then distinguish three different behaviors by comparing the losses in the first mirror (described by \(r_1 \)) to the losses in the path and in the second mirror (described by \(r_2 r_l\)):
\begin{enumerate}
    \item the cavity is \textbf{overcoupled} when \(r_1 < r_2 r_{l}\) (mirror 1 does not reflect enough): then around resonance we will have \(E_{r, p } < E_{r, l}\);
    \item the cavity is \textbf{undercoupled} when \(r_1 >r_2 r_l\) (mirror 1 reflects too much): then around resonance we will have \(E_{r, p} > E_{r, l}\);
    \item the cavity is \textbf{impedence matched} when \(r_1 = r_2 r_{l}\), so that \(E_{r, p} = E_{r, l}\) around resonance.
\end{enumerate}

In this case the reflected intensity goes to zero, since by having the same intensity the two fields can destructively interfere --- they \emph{do} destructively interfere, since the phase difference is given by \(- e^{-ik2L} = -1\) if the cavity is tuned.
We also have a discontinuity in phase in the impedance matched case, but this is not an issue since the intensity goes to zero.

\subsubsection{Beams}

Let us define a \textbf{beam} properly: its electric field at a fixed time will be in the form
%
\begin{align}
\vec{E}(x, y, z) = u (x, y, z) e^{-ikz}
\,,
\end{align}
%
where the function \(u(x, y, z)\) is a complex amplitude, and \(k = \omega_{l} / c\) is the wavenumber.
We are assuming that the beam propagates along the \(z\) axis.

This must obey the wave equation \(\square E = 0\), which can be written as
%
\begin{align}
\qty(\nabla^2 + k^2) E \propto
\pdv[2]{u}{x} +
\pdv[2]{u}{y} +
\pdv[2]{u}{z} - 2 ik \pdv{u}{z} - k^2 u + k^2 u = 0
\,.
\end{align}

The term \(\pdv*[2]{u}{z}\)
has magnitude much smaller than the other terms: so, we neglect it.
This is called the \textbf{paraxial approximation} --- we are basically saying that as the wave propagates it diverges out in a fashion which is approximately linear in \(z\).
This allows us to rewrite the wave equation as
%
\begin{align}
\nabla^2_{t} u (\vec{s}, z) - 2ik \pdv{u(\vec{s}, z)}{z} = 0
\,,
\end{align}
%
where \(\nabla^2_t\) is the Laplacian operator only in the transverse directions, while \(\vec{s}\) are two coordinates such as \(x, y\) describing these directions.

An approximate solution to this differential equation is given by the \textbf{Gaussian beam}\footnote{Notice that there is no propagation term \(\exp(i k z)\) since we factored it out earlier! The expression for \(E\) will include it.}
%
\begin{align}
u(x, y, z) = E_0 \frac{w_0 }{w(z)} \exp(-\frac{x^2 +y^2}{w^2(z)} -i \qty(kz + k\frac{x^2+y^2}{2 R(z)} - \psi (z)))
\,,
\end{align}
%
where we define the \textbf{beam waist}
%
\begin{align}
w(z) = w_0 \sqrt{1 + \qty( \frac{z}{z_{r}})^2}
\,,
\end{align}
%
the \textbf{radius of curvature} of the wavefronts
%
\begin{align}
R(z) = z \qty(1 + \qty( \frac{z_{r}}{z})^2)
\,,
\end{align}
%
and the \textbf{Gouy phase}:
%
\begin{align}
\psi (z) = \atan(z / z_r)
\,,
\end{align}
%
where the \textbf{Rayleigh range} \(z_r\) defines the scale of the distortions of the beam: it is the length after which the beam has doubled in area, and it is  given by
%
\begin{align}
z_r = \frac{\pi w_0^2}{\lambda }
\,.
\end{align}

Qualitatively speaking, the beam is \emph{squeezed}: it is not a plane wave, its width can be made to be small in a certain region but the smaller it is there the faster it becomes wide outside it.

All the parameters can be determined if we give the width of the beam at the center \(w_0 \) and the wavelength of the light \(\lambda \).

% The radius of the beam can only be small in a certain region, as we go further it widens.

The Gouy phase means that passing through the narrow beam region gives   the beam a phase of \(\pi \).

The divergence angle of the beam is given by \(\theta = w (z) / z \), and since we can approximate \(w(z) \approx w_0 z/z_r\) we can write \(\theta \approx w_0 / z_r = \lambda / \pi w_0 \), which is a sort of uncertainty principle:
%
\begin{align}
w_0 \theta = \frac{\lambda}{\pi }
\,,
\end{align}
%
meaning that we have uncertainty between the width of the beam at its narrowest and its angle of dispersion.

Starting from the Gaussian beam, we can define orthonormal bases which describe any beam in the paraxial approximation: the Laguerre-Gauss (cylindrical, flower-looking) and Hermite-Gauss (rectangular, boxy-looking) bases.

These are eigenfunctions of the paraxial wave equation: they propagate without changing their shape (although they are scaled).
This is not the case for combinations of them, because of the Guoy phase.

For both bases, we have two ``quantum numbers'' \(l, m\) labelling the eigenfunctions.
We generally try to work with the 00 mode (which is a Gaussian in both bases), because it is easier.

Resonance in a cavity means constructive interference of the beam with itself after a round-trip: we must have resonance both in phase and in the transverse profile.

For the \textbf{phase} resonance, the round-trip length of the cavity must equal an integer times the wavelength, plus the Gouy phase.
Because of the latter effect, different eigensolutions will resonate at different frequencies.

For the \textbf{profile} resonance, the beam must come back from the round trip with the same spatial profile: this is selected through the geometry of the cavity.
As the beam spreads the wavefronts curve, we need to account for this: the mirrors must be exactly parallel to the wavefronts.
So, we need to make them curved.

What is the length scale of this curvature?
For LIGO-VIRGO we have a \emph{confocal} cavity, so the sum of the curvatures of the mirrors is of the order of the length of the cavity.
For the mirrors we use in the lab, their radii of curvature are from centimeters to meters.

If a gaussian beam is reflected on the mirror and comes back to itself, one might think that all the higher orders modes should come back to themselves as well: they do not do so because of the Gouy phase difference.
The very high order modes are also suppressed since they are more affected by the imperfections of the mirror.
These are desired effects, we try to clean the beam until there is almost only the fundamental frequency.

\subsection{Realistic GW interferometers}

We can do a back-of-the-envelope calculation for the sensitivity of a Michelson interferometer.

We want to detect a GW amplitude whose amplitude spectral density is of the order
%
\begin{align}
\frac{ \Delta L}{L} \approx \SI{e-21}{Hz^{-1/2}}
\,,
\end{align}
%
and since our interferometer is a few \SI{}{km} long this means that we must have
%
\begin{align}
\Delta L \approx \SI{e-18}{m / \sqrt{Hz}}
\,,
\end{align}
%
so, since the light we use is in the visible to near-infrared range \(\lambda \sim \SI{e-6}{m}\), or equivalently  we want an interferometric sensitivity of around
%
\begin{align}
\frac{\Delta L}{\lambda } \approx \SI{e-12}{Hz^{-1/2}}
\,.
\end{align}

The error in photon counting will be given by Poisson statistics, \(\Delta N \sim \sqrt{N}\); if we want it to be comparable to the signal then we must have
%
\begin{align}
\frac{\Delta L}{\lambda } \approx \frac{\Delta N}{N} = \frac{1}{\sqrt{N}} = \SI{e-12}{Hz^{-1/2}}
\,,
\end{align}
%
which means we must get a number of photons per second the order of
%
\begin{align}
N \approx \SI{e-24}{Hz}
\,.
\end{align}

This means we need a power of approximately
%
\begin{align}
P = N \hbar \omega \approx \SI{200}{kW}
\,.
\end{align}

This is a very large requirement for a laser.
Fortunately, Fabry-Perot cavities are the solution: they increase the power inside the cavity by a factor \(\mathcal{F} / 2 \pi \), the average number of bounces a photon makes before being lost; they also useful to increase the effective length: we want \(L _{\text{arm}} \approx \SI{750}{km} \qty( \SI{100}{Hz}  / f _{\text{gw}})\), while the real arm length is of the order \SI{3}{km}.

So, we have different reasons to introduce cavities: they increase power, they increase effective length.

\end{document}

max_stars_repo_name: jacopok/notes

max_issues_repo_name: jacopok/notes

max_forks_repo_name: jacopok/notes