Syntax Prosody in Optimality Theory (SPOT) app tutorial

SPOT (Syntax Prosody in Optimality Theory app; http://spot.sites.ucsc. edu) automates candidate generation and evaluation for work on the syntax-prosody interface. SPOT is intended to facilitate the creation and comparison of multiple versions of an analysis, in service of refining constraint definitions and theory development. The codebase is available at https://github.com/ syntax-prosody-ot. This paper briefly explains the motivation for the SPOT app, then walks through the process of creating an analysis in SPOT. We show how to create input syntactic trees, either manually or automatically; how to select a constraint set; and how to generate tableaux with candidates, constraints, and violation counts. Finally, we show how to use the output of SPOT to calculate rankings and typologies using an OT application.

[+Exhaustive] grey lines). When prosodic recursion is also allowed (Ito & Mester 2013), the number of trees increases even faster (compare [-Nonrecursive] solid lines to [+Nonrecursive] dashed lines of the same color).
When both level-skipping and level-repeating are allowed, there are already eight possible parses of two terminals (depicted in Figure 2). With six terminals, over twenty-five thousand weakly layered parses become possible (Figure 1). Most of these candidates will ultimately be harmonically bounded, yet all must be considered lest an omitted candidate invalidate the final analysis (Bane & Riggle 2012, Karttunen 2006. These huge numbers of candidates demand an automated tool for candidate generation and evaluation in syntax-prosody analyses. Obviously it is impractical to build and evaluate thousands of prosodic trees by hand. It is also impossible to do this automatically using OTWorkplace (Prince et al. 2020) or other existing OT software, because their GEN capacity is limited to regular expressions, which cannot handle recursion. This is where SPOT comes in. SPOT stands for Syntax-Prosody in Optimality Theory. It is a JavaScript application under development since 2015 (Bellik, Bellik, & Kalivoda 2015-2021 that automates candidate generation (GEN) and constraint evaluation (CON) for work on the syntax-prosody interface. SPOT news and information are available at the SPOT website (http://spot.sites.ucsc.edu), which links to the webapp and codebase. SPOT was designed specifically to handle tree structures. It produces violation tableaux which can be viewed in the browser, or imported into the OT tool of your choice for further analysis.
This paper explains, step by step, how to use SPOT to build a simplified version of a system that analyzes syntax-prosody matches and mismatches, inspired by data from Japanese. We will call this system Msp.Asp, which stands for Match(Syntax→Prosody), Align(Syntax→Prosody). We also explain how to begin analyzing SPOT's violation tableaux in OTWorkplace.

Getting to the SPOT interface.
To use SPOT online, navigate to the SPOT web interface by opening the SPOT website, preferably in Chrome or Firefox: spot.sites.ucsc.edu. At the top of the page, click "SPOT webapp." There is also a link at the bottom of all pages on the website. This will take you to the SPOT web interface.
It is also possible to install SPOT locally so that it can be used without an internet connection later. To take this route, click "SPOT codebase" on the website to navigate to the Github repository, where you can follow the instructions in README.md to download the codebase from Github, build locally, and access the app in your browser from your local copy of the SPOT interface. 3. Defining inputs. The inputs to Msp.Asp are abstracted from data on Japanese phrasing in Kubozono 1989 (Table 1). Of the five possible binary-branching syntactic trees with four words, four are mapped to matching prosodic structures in Japanese, while one, the fully left-branching input, is rebracketed into a balanced prosodic structure. These structures are diagnosed by %LH rises in pitch at the left edge of the φ, and by downstep that applies to non-initial rises throughout the maximal φ. In the mismatching prosody in (b), an unexpected rise appears on the third word, indicating that it is at the left edge of a φ that does not correspond to any XP in the input. No such rebracketing occurs in its mirror image, the fully right-branching syntax in (a), which features rises on the first three words. If (a) were also rebracketed, it would have the same pitch contour as the left-branching input (b) and the symmetrically-branching input (e).

Syntax
Prosody  Table 1. Inspirational data on Japanese phrasing (abstracted from Kubozono 1989) We include the five four-word trees from Table 1 in the set of inputs for our system Msp.Asp (1). Msp.Asp.GEN will also include two three-word syntactic trees. (For the full set of inputs, see the appendix.) (1) Msp.Asp.GEN Inputs = Binary-branching syntactic trees a. on terminal strings of 3-4 nodes, b. where terminal nodes are syntactic words X 0 and non-terminal nodes are syntactic phrases XP. c. The orthographic representation of the bracketing structure imposes a linear order on the leaves.
As it turns out, the trees in (2) form a support for this system, meaning that as long as those three inputs are included in the calculation of the typology, it will contain the exact same languages as it would with the inclusion of all or some additional trees drawn from the set in (1). Thus, to analyze this system, we must build at least the trees 4wR, 4wM, and 4wL in (2), although we can also build the other trees specified by (1). The labels of the words are arbitrary, but must be distinct. We will give arbitrary labels to the XPs as well, simply so SPOT can distinguish them. Table 2 shows traditional tree depictions of 4wR, 4wM, and 4wL, as well as the graphical depictions that SPOT's tree builder uses.
(2) A universal support for the system Msp Input trees in SPOT can be constructed in two different ways. We will first cover the manual approach, which allows the analyst to decide exactly what trees to include, and provides a graphical tree depiction, rather than only a bracketed representation of the trees. To use this approach, start in the Manual tab under GEN: Input parameters. Type "a b c d" into "String of terminals" and click on the button "Build syntax." This will open the tree builder, with the seed of the syntactic tree ( Figure 3).
In SPOT's graphical tree representation, every node has two attributes, a category and an identifier. If the node is to be visible to the syntax-prosody mapping constraints, its category, shown with a grey background, must be "cp" (complementizer phrase), "xp" (syntactic phrase) or "x0" (syntactic head). The identifier can be any alphanumeric string (no spaces or hyphens, please), and must be unique. We use the notational convention cat-id to refer to specific nodes. The root node of this tree currently has the identifier "CP1" and the category "cp." We need to change these to "XP_7" (or some other identifier of your choosing) and "xp," respectively. To do this, click in the text fields for cat and id and change the text there.
Next, to create the XP containing x0-b, x0-c, and x0-d, hover over the space immediately surrounding node x0-b, and click on the grey area. This area will then turn light blue, indicating that you have selected that node. Now do the same to select x0-c and x0-d. Finally, click "Add Mother." This will create the node xp-XP_5. The tree should now look like Figure 4.
Next, create an XP above x0-c and x0-d by selecting those nodes and clicking "Add Mother" again. This XP will be labelled XP_6, and will complete the tree. It should look like 4wR in Table 2. When the tree is complete, click the button labeled "Done! Add trees to analysis" under the tree-builder. A message will appear next to it, saying, "The trees in the analysis are up-todate." This means SPOT has translated that graphical tree representation into a JavaScript tree object. Its code can be viewed using the "Show code" toggle switch below the "Done!" button.
To create another tree, put the terminal string for your tree in the "String of terminals" box, and click on "Build syntax" again. The seed of a second tree will appear below the one you already built. Add additional structure using the same procedures as above, to create the other two trees (4wM and 4wL).
It is also possible to add additional information to the trees, such as labeling some nodes as being functional projections, having silent heads, being accented, or bearing semantic focus. Click on the info button immediately above the tree builder, next to the "Clear selection" button, to access information about how to add these features to a tree you have created.
Another feature available in this part of the SPOT interface is "Trim syntactic tree," which will prune an elaborated syntactic tree down to only the structure that is visible to the mapping constraints in the version of MATCH proposed by Elfner (2012). Further details about this can be accessed on the SPOT interface using the info button next to "Trim syntactic tree" immediately above the tree-builder. Trimming will not alter the trees in Msp.Asp, however, since they do not contain any phonologically empty elements.
3.2. BUILDING SYNTACTIC TREES AUTOMATICALLY IN SPOT. Input syntactic trees can also be created algorithmically, instead of manually. This is much quicker-an obvious practical advantage. The primary theoretical advantage to this approach is that the analyst can be sure of having formally defined the space of inputs. However, algorithmically generating input trees offers less fine-grained control over input representations, since it is not possible to adjust individual trees, nor is it possible to label projections as functional or silent.
To use SPOT's automated syntactic tree generation, click on the Automatic tab under GEN: Input parameters. Leave everything under Syntax Parameters on its default settings for this Figure 4. With XP_5 containing x0-b, x0-c, and x0-d system. These parameters can be adjusted to exclude adjunction structures, root syntactic trees in the CP level rather than XP, restrict head alignment, and so on.
Click on Visibility to phonology to expand it, and check "Treat non-branching XPs as X 0 s." This excludes non-branching XPs from the syntactic representation as an analytical simplification; it is not meant as a theoretical claim. It is equivalent to generating the subset of a system without this assumption in which BINMIN-φ >> MATCHXP.
Next, under Specify terminals, type "a b c" in the box labeled "String of terminals 1." Then click Add terminal string and type "a b c d" in the box labeled "String of terminals 2." Finally, click the orange button marked Generate trees. In the text area below, a table that looks like Figure 5 should appear.  (3) Msp.Asp. GEN Outputs = All possible phonological phrases φ for which a. Every syntactic word X 0 in the input is mapped to an output phonological word ω. Linear order is preserved. b. All non-terminal nodes are of category φ (represented by parentheses). c. Output representations are trees with ordered leaves. d. The child of a unary-branching φ must be a ω.
This set of prosodic trees can be generated in SPOT by adjusting the settings in the next section, GEN: Output parameters. Leave the first checkbox for "No prosodic recursion" unchecked, to allow recursive prosodic structures. (You can check "Enforce headedness" and/or "No level-skipping (enforce exhaustivity)" if you like, but these will be rendered redundant by the next step.) Next, click Prosodic categories to show additional GEN options. This allows the user to determine the prosodic category labels for the root, intermediate, and terminal nodes. For Msp.Asp, we will select φ in the first row, under "Root prosodic tree in." This will ensure that all output prosodic trees are rooted in φs (phonological phrases), rather than the default ι (intonational phrase). 4 Leave "Intermediate nodes are" and "Prosodic terminals are" at their default values. These should be φ and ω, respectively. With these settings, only two prosodic categories (φ and ω) are included in each tree, so all structures will necessarily satisfy EXHAUSTIVITY, since every word will be parsed into a phonological phrase. Likewise, all candidates will necessarily satisfy HEADEDNESS, because every φ will certainly contain at least one ω.
The prosodic trees whose characteristics can be determined in this section will not be viewable until the final violation tableaux are visible, unlike the syntactic trees produced in GEN: Input Parameters. That is because the prosodic trees are so numerous (see Figure 1).

Selecting constraints.
Because of the asymmetries in Japanese phonological phrasing, which were noted in the discussion of Table 1 (see Bellik et al. to appear), we define CON in Msp.Asp as in (4). This CON includes both MATCH and ALIGN constraints, as well as three constraints on BINARITY.
(4) Msp.Asp.CON a. Mapping constraints (i) MATCH(XP,φ) Assign one violation for every node of category XP in the syntactic tree such that there is no node of category φ in the prosodic tree that dominates all and only the same terminal nodes. (ii) ALIGN(XP,L,φ,L) Assign a violation for every syntactic node of category XP whose left edge is not aligned with the left edge of a prosodic node of category φ. (iii) ALIGN(XP,R,φ,R) Assign a violation for every syntactic node of category XP whose right edge is not aligned with the right edge of a prosodic node of category φ. b. Markedness constraints: (i) BINMIN(φ,branches) Assign one violation for every node of category φ in the prosodic tree that has less than two children. (ii) BINMAX(φ,branches) Assign one violation for every node of category φ in the prosodic tree that has more than two children. (iii) BINMAX(φ,ω) Assign one violation for every node of category φ in the prosodic tree that dominates more than two nodes of category ω.
In the Japanese phrasing pattern that this constraint set is designed to account for, a uniformly left-branching input syntax is rebracketed into a balanced, symmetric prosody (5a). This rebracketing has previously been analyzed with combinations of Match and Binarity constraints (Ishihara 2014, Ito and Mester 2013, Kalivoda 2018, Selkirk 2011. However, as detailed in Bellik et al. (to appear), existing analyses fall short when other four-word syntactic structures are admitted to the candidate set. Both MATCH and BINARITY constraints are symmetric, so they cannot distinguish between the uniformly left-branching input that should be rebracketed, and the uniformly right-branching input that should be matched (5b). a φ, rather than either a φ or an ι), and is equivalent to examining the subset of the typology in which MATCH-XP Max (Ishihara 2014) is undominated.
Existing asymmetric markedness constraints such as STRONGSTART cannot solve this problem, so we introduce asymmetric mapping constraints in the form of Alignment to resolve the matter. We refer the reader to Bellik et al. (to appear) for a full explanation of the typology and findings from this system. 5.1. SELECTING MAPPING CONSTRAINTS. To add the mapping constraints to Msp.Asp on the SPOT interface, scroll down to Mapping constraints, then click Match to view the Match Theory constraints. All constraint definitions can be seen on the interface by clicking on the info buttons next to each constraint name. Select "Match(Syntax→Prosody)." We will keep the default category, "XP." Although we will not use them in Msp.Asp, other MATCH constraints are available on SPOT, and can be accessed by clicking "Show more" at the bottom of the Match section.
Next, click Align/Wrap to view alignment constraints. Select two constraints: "Align-Left(Syntax→Prosody)," "Align-Right(Syntax→Prosody)." Keep the default category "XP" for these too. As with Match, other versions of Align become available by clicking "Show more." 5.2. SELECTING MARKEDNESS CONSTRAINTS. Markedness constraints can be added in the same manner. Under Markedness constraints, click Binarity to view the binarity constraints. Under ...counting branches, select "BinMin(branches)" and "BinMax(branches)." Under ...counting leaves, select "BinMax(leaves)." Leave the default category settings at "φ." Numerous other versions of both Binarity and other prosodic well-formedness constraints, such as EQUALSISTERS, STRONGSTART, and ACCENTASHEAD are available on SPOT as well, 5 but do not feature in Msp.Asp.CON. 6. Violation tableaux and typology. At this point, both GEN and CON are defined, so the system definition on SPOT is complete. Scroll to the bottom of the interface and click the Get results button to download and view the violation tableaux. A dialog box will appear asking if you want to save the VT as a .csv file; save it for importing into OTWorkplace or another OT tool of your choice.
Another option is to click on the Save button to download these settings as a .spot file, in case you want to load them again later. (Since .spot files are plain text, they can be viewed in any text editor.) You can use the "Load" button on SPOT to upload this analysis again at another time to regenerate the violation tableaux or revise the analysis.
Once you have downloaded the violation tableaux, then continue the investigation by opening OTWorkplace 6 and import the .csv into Excel. (Alternatively, open the .csv in Excel and then open OTWorkplace, or open the .csv in another editor, select all, and copy-paste to add it to OTWorkplace.) Click "Add ins" to display the OTWorkplace menu. Under OTWorkplace, click "Project start…" and name the new project. To calculate the factorial typology, under OTWorkplace, click "Factorial typology > FacType Calculate." OTWorkplace will generate the typology predicted by the Msp.Asp, which has fourteen languages; one contains the Japanese phrasing pattern shown in Table 1. For more on typologies and languages in OT, see Prince (2016), Alber et al. (2016). 7. Conclusion. SPOT makes it easy to quickly create complete violation tableaux for an OT analysis of syntax-prosody interactions. SPOT implements many of the commonly used constraints in syntax-prosody mapping, including constraints from both Match Theory and Align Theory, so that analyses couched in both frameworks can be created and compared directly. In fact, the system created here (Msp.Asp) is but one of several that we compared in Bellik et al. (to appear), a selection of which can be accessed via the Built-in systems menu at the top of the SPOT interface. Msp.Asp is represented there as "Japanese : MatchSP, AlignSP (Bellik, Ito, Kalivoda, & Mester to appear)"; selecting that menu item is a shortcut to bringing up the entire system. Others can also be selected to view alternative analyses that do () or do not () capture the asymmetric Japanese phrasing pattern.
The violation tableaux created by SPOT can be analyzed by hand, but ideally, they should be imported into other software for Optimality Theory analyses, such as OTWorkplace or OTSoft, which can quickly generate the typologies that those systems predict. By combining SPOT with OT software, syntax-prosody analysts can create more theoretically rigorous analyses of phenomena at the syntax-prosody interface.