<div dir="ltr"><div>Re: fixed-aritiness per pred, if you look at core.smi for the erg, there are quite a few preds listed here with &quot;optional&quot; arguments. (At least that is what I assume &quot;[...]&quot; means around an argument position, and it is consistent with the behavior seen with &quot;_look_v_1_rel&quot;.)  I&#39;m not entirely certain under what the criteria are for using optional arguments vs creating a new pred for a particular form.  Perhaps there is some sort of &quot;implied&quot; argument in cases where an optional argument is omitted?  However, there seems to be some inconsistency here (or perhaps a consistency that I don&#39;t fully understand), as none of the arguments on &quot;_exaggerate_v_1_rel&quot;, &quot;_eat_v_1_rel&quot; or &quot;_drink_v_1_rel&quot; are optional (they always have ARG0, ARG1 and ARG2), but ARG2 on &quot;_look_v_1_rel&quot; is optional, and the different arity versions appear on &quot;look_v1&quot; and &quot;look_v4&quot;.  Any ideas what may be going on here?<br>
<br></div><div>Spencer<br></div><div><br></div><br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 30, 2013 at 3:24 PM, Woodley Packard <span dir="ltr">&lt;<a href="mailto:sweaglesw@sweaglesw.org" target="_blank">sweaglesw@sweaglesw.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">&gt; once we have unexpressed arguments, i would think there<br>
&gt; is no formal difference between [ ..., ARGn u, ... ] vs. just no<br>
&gt; mention of that ARGn role, or?<br>
<br>
</div>On the contrary, a formal difference is exactly what there is.  It may well be that by interpretation you mean to assign no difference in truth conditions (or whatever else) to those predicates, but their *form* is certainly different.<br>

<br>
On Francis&#39;s point, I believe he meant to recall the point that predicates in the underlying logical language are presumably fixed arity, and having multiple MRS-level predicates with the same name but different arities (or argument types) is opening the door to confusion (as for example happened when Agree was confused, starting this thread).  I will readily agree that being able to underspecify between target-language predicates may be a useful bit of functionality; however, the problem here seems perhaps to be *unintentional* underspecification.<br>

<br>
That brings up the related question of what the logical status of a &quot;u&quot; variable is?<br>
<span class="HOEnZb"><font color="#888888"><br>
Woodley</font></span></blockquote></div><br></div>