[Prev][Next][Index][Thread]
tactics (was: "Enough is enough!")
> Guys, I'm giving up! This is just too much information overload
> for my tiny brain: do you know how many exchanges we've had in
> the last couple of days!? And the latest mailings still contain
> things like "I thought this was ..." or "I though you wanted to ...".
> Too much email can damage one's view on an issue.
You may hate this, but ... I think email is an excellent way to
work out ideas on matters like this. Sylvain, you have Web browser
access? I'll pull together a thread of this three-way exchange and
put it in http://www.csi.uottawa.ca/tanka/threads for anyone to view.
Email forces each of us to write out exactly what we think, provides
a permanent record, and messages exchange quickly enough for us to
stay on topic but slowly enough for us to be really sure we're saying
(=typing) what we mean. Too often I've come out of a meeting with
good feelings and empty hands.
> What I mean by that is I see the (urgent?) need for a face-to-face
> discussion. I know that Ken has become a frequent Ottawa--T.-R.
> traveller recently (;-^), how about you Terry?!
I can go to Mtl or TR, but read on.
> The other, more serious, possibility is to wait till IJCAI in
> Montreal. In that case Terry, I would recommend that you suspend
> all programming activities and concentrate on paper work, in
> particular, write down the details and consequences of each of
> the few options or scenarios that we seem to have before ourselves.
Trying to fix the details of one particular instance of reattachment
is shining a light on the different way each of us sees matters.
So long as discussion continues to increase mutual understanding and
our thinking shifts towards a single view, I'm in favor of it continuing.
This morning's mails indicate that is still happening.
What I'd like to do--and it's along the lines of Sylvain's second
suggestion above--is to try to summarize the discussion as we go.
We need to have agreement on what role reattachment will play in the
larger project, mes amis, or someone will be let down. Of course,
everyone's own mail will correct me ...
To start. Sylvain yesterday indicated that reattachment should follow
DIPETT grammar strictly, retaining frames such as conj_pps() around
multiple PP structures. Ken had earlier proposed a nested model of
NP post-modification and I took the fact that DIPETT retuns its PPs
in conj_ lists to suggest that it prefers a flat model of NP post-
modification. Ken's reaction today is that nested post-modification
is legitimate DIPETT grammar.
There seem to be a couple of related underlying issues here.
1) what is correct DIPETT grammar? Is it what Sylvain, with input
from others, implements in DIPETT (ie the recent introduction of
noun(n(...),noun_modifiers(...)) ); or is it what one can conceive
of DIPETT outputting given its current DCG and terminals?
2) Should reattachment in fact hew to DIPETT grammar exactly? Or
should it move towards a more abstract representation of sentence
meaning? Ken today mentions his attribute/modifier scoper, which
produces an entirely flexible nested list of tokens, saying "until now,
I've considered that modifier list to be completely internal to NMRA.
But it would be interesting to have it appear like that in the final
*/4 structures. Now that would be something definitely DIPETT-illegal."
-o-O-o-
My own view is for an evolving representation, one that captures all
the enrichening and correcting accomplished by human interaction or
further processing. The tree represents the sentence syntax (=parse);
the */4 clauses, its semantics. If this is acceptable I would like
to install Ken's scoper in reattachment as part of the code dealing
with phrases. A couple of caveats: 1) the tree would remain available
to each subsequent user, keyed to the same number as the */4 clauses;
2) at present decomp is strictly conformant to DIPETT grammar, with
the possible exception of phrase token lists it constructs and extra
clause and phrase token lists it discards.
--
Terry Copeck (terry@csi.uottawa.ca)
References: