Paper:

	basic word order: Emily
	negation: Emily
	matrix yes-no questions -- particle, word order: Dan
	test cases: Emily/Dan
	Perl script?

Things to address:

	word order: "canonical", topicalization/extraposition, 
           lexical alternations

        highlight distinction with "P&P" -- data-driven, working
           up from phenomena, not trying to have one parameter
           handle lots of diverse phenomena

        not entirely bottom-up, but talk about how we'll deal
           with counterexamples

	OVS languages; debate about VPs or not -- how that affects
	   what we do with spurious ambiguity in free word order
           languages

Dan's schedule -- 
  off to PA/DC 12/22-12/30
  12/31 back in Germany
  back in the office 1/3 -- no class until 1/10

Emily's schedule -- 
  in Seattle until 1/6
  teaching starting 1/3

Talk next: 1/4 9am PST
Deadline: 1/14

Testing/evaluation:

1. Try loading all of the modules at once to make sure that
everything is at least consistent.  (For now, while everything
should be.)  If we get to building inconsistent modules, write
a Perl script to generate all the different script files, lisp
function to load them in succession and test them.

2. Find some specific languages (perhaps student projects
from 471 last year?) and see how far we can get on their test suite
coverage by using existing modules.  Might need to double check
quality of that data, though.

3. Morphologically complex languages?  Have to assume for
now that someone's done a morphological analyzer, and maybe
even get assume standardized morphological tags.  Try to test
on Slave as an example?

4. MT demo to show off semantic compatibility

Management:

Try writing a Perl script as a stand-in for a nicer-UI wizard.
It should ask a bunch of `typological' questions and output
a customized script file.  It could also ask for some vocabulary
and output a small lexicon file. 

One reason to do this as a script (or other interactive interface)
rather than having people edit the script file directly is
that the current set up requires all type files to be loaded
in one statement (cf. the call to clear-types in read-tdl-type-files-aux),
but many of the modules involve both type files and instance
files (rules).  This would require editing the script file
in two places, and I imagine it would be error-prone.
Furthermore, it seems that many interesting modules are going
to require tdl-creation rather than just selecting among modules,
another reason to go with an interactive set-up.

Later think about a user coming back to the wizard to refine 
the grammar based on further information.

I have a feeling that we're quickly going to get into a lot
of modules, and so an interactive Perl script is just not going
to be the way to go to building the grammars.  Maybe web-based
cgi so folks can poke around a form and find the things they
want to add?  With buttons for `export script' and maybe
even `test grammar against test suite'?

How to make sure that all of the words in the test suite 
are covered in the lexicon?

Maybe work in some `immediate gratification' steps where the
user can stop and see just some basic transitive/intransitive
sentences go, and then run another script to refine things
further, and then...

What about building a testsuite?  Imagine in the future asking
for sentences to illustrate particular phenomena, and annotate
them with phenomena for \itsdb consumption?

We need to think at some point about the optimal allocation of
information to files in the case that people want to generate
a starting grammar with the wizard and then go in and edit
it.  Having things scattered over lots of little modules might
not be ideal.  I tried to start an email exchange about this
in May (5/3/04) but don't see any responses.  Seem to remember
a phone or other conversation in the which the consensus was
go with the editing-the-script/lots of separate modules files
option.  Currently I'm thinking that the best bet would be to
compile the information used from modules in a file that is
separate from both matrix.tdl and my_language.tdl.  The idea would
be to put it all in one place so that the grammar writer could
easily look at it, but also to discourage people from editing
it directly.  The compiled file would include documentation indicating
which types are a consequence of which choices on the part of
the grammar writer.  `Sniffing' those choices and recompiling on
a matrix update shouldn't be too hard.

Word order:

Allow for languages that allow both head-comp and comp-head

 -- indiscriminately (Polish)
 -- depending on POS of the head
 -- depending on other head features of the head (e.g.,
    finite v. non-finite verbs)
 -- depending on POS/other of complement

	Some of these might require generating tdl on the fly
	based on user's answers.

Current word order solution has SVO, SOV, etc all as separate
files with some redundant constraints.  Consider pulling out
generalizations and `inheriting'?  For example, strict SOV
is the same as strict v-final with the additional constraint
on the COMPS value of the head-dtr in the head-subj phrase.  
But then we need to encode somewhere that you want both files --
this might work fine when it's all wrapped in a UI, but probably
best not to do it that way yet. 

OSV/SOV/V-final all share the same rules file.  Avoid
duplication in this case.
Likewise for VSO/VOS/V-initial.

What to do with strict head-comp first v. optional head-comp
first?  That is, what about languages that allow OSV and SOV?
Here's a first-pass typology:

Strict SVO -- English: head-comp, subj-head, hc first
Strict OVS -- comp-head, head-subj, hc first
Strict SOV -- comp-head, subj-head, hc first
Strict VOS -- head-comp, head-subj, hc first

Strict VSO -- head-subj, head-comp, hs first
Strict OSV -- subj-head, comp-head, hs first

Strict v-final (OSV, SOV) -- Japanese: comp-head, subj-head, no order
Strict v-initial (VSO, VOS) -- do these exist?: head-subj, head-comp, no order
Strict v-medial (SVO, OVS) -- do these exist? Just putting together
 SVO and OVS also gives SOV and VOS.

Completely free -- Polish (still need to rule out spurious ambiguity in
  order of application of head-comp and head-subj):
    comp-head, head-comp, subj-head, head-subj
    comp-head, subj-head in either order
    head-comp, head-subj in either order
    head-comp, subj-head: hc first
    comp-head, head-subj: hc first

  What really happens with 3arg clauses in Polish, Warlpiri, other languages?
  LFG "non-configurational" languages.

  What kind of elements attach low?
  Try abritrary constraint of right attachment before left attachment?
    (even in strict OVS languages)

  Two problems: -- spurious ambiguity when there's arguments on
                   either side of the head
                -- pragmatic effects

Strict SOV in matrix clauses, SVO embedded (German, Norwegian?)
similar variants

Strict VO or OV order, plus opposite head-comp order for
 (some) non-verbal heads

Auxiliary always in 2nd position -- but everything
else is free. (I think this is what the LFG crowd says
is going on in Warlpiri -- some other Australian languages.)

... How to tell when to count `inverted' orders as derived? ...
... What is our current thinking about olist?  Assuming for now
 that we are explicitly discharging all complements ...
... Semantics is currently a bit broken because the
head-subj rule is ready to be tied up with declarative
clause stuff. Maybe rethink whether that's an option we
want to support?  What's wrong with always using non-branching
productions for the introduction of messages?  Seems to work
better in languages where subject can (or must) attach
before object, since not all verbs have objects, but we
are assuming subjects (or at least pro-drop) everywhere.
... As the word order modules get fancier, we'll need to
make sure that the pro-drop modules are compatible with them
(specifically worried about spurious ambiguity).  It would
be nice to have just one set of pro-drop modules, but they
may have to be written relative to the word order module choice?...

Subcategorization:

Existing Matrix types underdetermine POS of complements.
Fill in when?  Need NP/PP distinction, possibly also case.

Relatively general modules:
 
 `basic word order'
 simple word classes
 determiners or lack thereof / gets messy quickly with
	indefinites
 pro-drop
 sentential negation
 modifiers
 matrix yes-no questions
 case
 intraclausal scrambling
 agreement (S-V, Det-N, Adj-N; for png, case, other? --
   might vary within a language as to how much agrees.
   Slavic depictives agree in number but not gender, or ...)
   syntactic v. semantic agreement
 ARG-ST to VAL mapping: ergative v. accusative
 complex predicates 
 complement reordering -- I'm implementing this for
   free word order languages as part of the word order
   module, but for more constrained languages it could
   presumably be separate. (?)  At least, it should be
   presented as a separate choice.    Need to consider
   which kinds of reordering are best handled by lexical
   rules, too.
 tense/aspect

Less universal modules:

 V2
 Romance clitics/pronoun incorporation
 real clitics (2nd position -- Avgustinova)
 serial verbs
 Hindi-style verb clusters
 numeral classifiers
 clausal embedding
 relative clauses
 possessives
 noun incorporation
 NP `splattering' (Warlpiri style)
 interclausal scrambling/argument composition
 single verbs as answers to yes-no questions (Mandarin, Cantonese);
   this is separate from other pro-drop/optional argument cases: 
   see email from erb->danf on 5/13/04
 A-not-A questions (Mandarin, Cantonese) -- do these recur frequently
   enough to make a module out of?
 
LKB wishlist
 
 ability to hide surplus types in the head hierarchy,  perhaps
 elsewhere

Transfer `modules'?

 If we're going to show off with an MT demo, we'll need the
 ability to construct transfer components on the fly that can
 handle differences in quantifier inventory, gender assignment
 (preferably on nouns, not pronouns), what else?

 This is not just for demo but also for practical application.
 It will be nice to allow people to play with their grammars
 by translating from a more familiar language.

Meeting with Dan 12/21/04

 Avgustinova -- working within in HPSG, thinking in terms of modules
 working on Slavic -- case, agreement, clitics; seems likely
 to be willing to work with someone who wanted to do implementation
 Notions about how the modularity works -- importing parts of
 hiearchies/subparts get further elaborated.

 Case marking -- as morphology or as adpositions (not requiring
 that all adpositions, even English to, are case markers).
