GenI: http://trac.haskell.org/GenI/report/1
Trac Report - en-usGenIhttp://trac.haskell.org/GenI/chrome/site/100px-GeniIcon.pnghttp://trac.haskell.org/GenI/report/1
Trac v0.11.1#1: bracketed output (new command line argument)Sat, 17 Jan 2009 14:39:40 GMTSat, 17 Jan 2009 14:39:58 GMT<p>
The bracketed output is a compromise between a full parse tree and a plain string.
</p>
<p>
Parse tree:
</p>
<pre class="wiki">S(NP(somebody),VP(VP(V(saw),NP(something)),PP(somewhere)))
</pre><p>
Bracketed output:
</p>
<pre class="wiki">somebody ((saw something) somewhere)
</pre><p>
Notice that we try very hard to avoid excess parentheses. The point is to make it easier for grammar hackers to understand (for example), why we get different instances of the same output. So we want to keep things as readable as possible
</p>
http://trac.haskell.org/GenI/ticket/1
http://trac.haskell.org/GenI/ticket/1Report#2: replace automaton code with HaLeX?Sun, 18 Jan 2009 09:57:40 GMTThu, 02 Jul 2009 16:25:59 GMT<p>
See: <a class="ext-link" href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaLeX"><span class="icon">http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaLeX</span></a>
</p>
<p>
This may affect the polarity automaton performance, but (a) probably not by much and (b) it would only be overhead. The really important thing is to be fanatical about keeping GenI minimalistic
</p>
http://trac.haskell.org/GenI/ticket/2
http://trac.haskell.org/GenI/ticket/2Report#6: disjunctions of paraphrase selectorsThu, 19 Mar 2009 18:36:04 GMTThu, 19 Mar 2009 18:36:04 GMT<p>
Luciana Benotti asked:
</p>
<blockquote class="citation">
<p>
We know that in Geni you can select tree properties in the input
semantics by using square brackets next to a literal, for example,
runs(e,j)[Active]. Is there a way of indicating a disjunction of the
tree properties? Such as runs(e,j)[Active|Passive] in order to obtain
the active and passive realizations of runs(e,j).
</p>
</blockquote>
http://trac.haskell.org/GenI/ticket/6
http://trac.haskell.org/GenI/ticket/6Report#7: percolate features during morphological realisationTue, 31 Mar 2009 10:54:29 GMTTue, 29 Sep 2009 08:31:15 GMT<p>
The morphological realisation (built-in) is dumb in that it unifies each pre-terminal node of the derived tree independently with the morphological lexicon.
</p>
<p>
This is not good, because it does not allow for mutually exclusive realisations:
he hold*s* the apple vs you hold the apple
</p>
<p>
Right now, the workaround is to supply the necessary features via the input semantics (morphinfo file), but ideally you should be able to just make it work automatically.
</p>
http://trac.haskell.org/GenI/ticket/7
http://trac.haskell.org/GenI/ticket/7Report#8: alternative syntax for anchor (or other) features? generalisation of morphinfoTue, 31 Mar 2009 10:56:12 GMTTue, 31 Mar 2009 10:56:12 GMT<p>
The morphinfo file creates a maintenance problem -- too many files to keep track of and update. A better solution would be something that lets you supply similar information within the input semantics (test suite).
</p>
<p>
So something like
feature(m,person:2)
in the input semantics
</p>
http://trac.haskell.org/GenI/ticket/8
http://trac.haskell.org/GenI/ticket/8Report#10: root feature in main windowThu, 02 Jul 2009 16:22:39 GMTSun, 05 Jul 2009 19:13:07 GMT<p>
And not just in configuration window...
</p>
<p>
My idea for how this should work is that it be another field in the input semantics area. I think this would take some refactoring, some kind of function that goes from config to the input semantics area and back.
</p>
http://trac.haskell.org/GenI/ticket/10
http://trac.haskell.org/GenI/ticket/10Report#12: graphviz gets confused by multi-word lexical itemsThu, 02 Jul 2009 16:24:51 GMTThu, 02 Jul 2009 16:24:51 GMThttp://trac.haskell.org/GenI/ticket/12
http://trac.haskell.org/GenI/ticket/12Report#14: don't use root feature filtering if it's not specifiedFri, 03 Jul 2009 10:33:27 GMTMon, 28 Sep 2009 16:01:41 GMThttp://trac.haskell.org/GenI/ticket/14
http://trac.haskell.org/GenI/ticket/14Report#15: feeding non-existent test case to GenI causes it to say bug in GenIFri, 03 Jul 2009 10:38:39 GMTTue, 29 Sep 2009 08:29:38 GMThttp://trac.haskell.org/GenI/ticket/15
http://trac.haskell.org/GenI/ticket/15Report#16: possible polarity filtering bugFri, 03 Jul 2009 11:30:30 GMTFri, 03 Jul 2009 11:30:30 GMT<pre class="wiki">dist/build/geni/geni -m examples/chatnoir/macros -l examples/chatnoir/lexicon -s examples/chatnoir/suite --verbose --testcase="le_mechant_chat_noir_chasser_le_souris" --opts='pol' --rootfeat='cat:p'
Loading test suite examples/chatnoir/suite... 4 entries
Loading trees examples/chatnoir/macros... 11 entries
Loading lexicon examples/chatnoir/lexicon... 15 entries
Loading test suite examples/chatnoir/suite... 4 entries
Lexical items selected:
noir
chat
chasser
le
le
mechant
souris
Trees anchored (family) :
noir:adj_post
chat:nC
chasser:vArity2:rel1vn0
chasser:vArity2:rel0vn1
chasser:vArity2:qu1vn0
chasser:vArity2:qu0vn1
chasser:vArity2:n0vn1
chasser:vArity2:vinfn1
le:Det
le:Det
mechant:adj_pre
souris:nC
geni: [polarities] No instances of cat in [].
</pre>http://trac.haskell.org/GenI/ticket/16
http://trac.haskell.org/GenI/ticket/16Report#17: outsource to graphviz librarySat, 18 Jul 2009 15:16:00 GMTWed, 20 Jul 2011 18:32:17 GMT<p>
Note the graphviz is licensed under the EPL (sigh!) so we would have to create an exception in our GPL to allow people to distribute the two as one program.
</p>
http://trac.haskell.org/GenI/ticket/17
http://trac.haskell.org/GenI/ticket/17Report#18: unification monadWed, 22 Jul 2009 10:16:12 GMTWed, 22 Jul 2009 10:16:12 GMT<p>
OK, it doesn't have to be a monad. But I want to have some sort of abstraction that guarantees that when I do unification on something, the results from previous unification will be automatically propagated to that thing. Seems like it should be fairly straightforward. You could just model this as a state monad for example, and have the unification function get/put the substitutions state.
</p>
<p>
What may be annoying is having to write a monad transformer and slip it into our current MT stack.
</p>
<p>
The goal is to have something that makes our code easier to write, and less error-prone, while also staying cheap (we shouldn't be doing any needless traversals).
</p>
http://trac.haskell.org/GenI/ticket/18
http://trac.haskell.org/GenI/ticket/18Report#21: simple indexing mechanismTue, 28 Jul 2009 17:47:25 GMTTue, 28 Jul 2009 17:50:50 GMT<p>
This should reduce generation time somewhat. It occurred to me that there's actually a very simple way to index the generation chart: just use the semantic index or the category or even a tuple of the root node. For atomic disjunction and variables, just dump into a variable slot that we always have to look up.
</p>
<p>
Note that substitution would have to be changed so that items with open substitution sites go back at the end of the agenda instead of on the chart.
</p>
<p>
Also note that substitution sites with disjunctive or variable indices would just have to look at all chart items.
</p>
http://trac.haskell.org/GenI/ticket/21
http://trac.haskell.org/GenI/ticket/21Report#22: move NLP.GenI.Console regression testing code to test moduleFri, 04 Sep 2009 11:49:54 GMTFri, 04 Sep 2009 11:49:54 GMT<p>
Hmm, now I have a better idea about the argument for separating test logic from business logic.
</p>
http://trac.haskell.org/GenI/ticket/22
http://trac.haskell.org/GenI/ticket/22Report#24: lexical selection factorisation [old todo list]Tue, 08 Sep 2009 20:13:55 GMTTue, 08 Sep 2009 20:13:55 GMT<p>
I don't understand what this is about :-(
</p>
http://trac.haskell.org/GenI/ticket/24
http://trac.haskell.org/GenI/ticket/24Report#25: keep track of sets of adjunctions into the same node [old tracker]Tue, 08 Sep 2009 20:16:27 GMTTue, 08 Sep 2009 20:16:27 GMT<p>
This could be a form of packing where we try to store adjunctions into the "same" node as a set (that can happen in any order).
</p>
<p>
Would only be really useful if multi-adjunction happens a lot
</p>
http://trac.haskell.org/GenI/ticket/25
http://trac.haskell.org/GenI/ticket/25Report#26: RND: plugging GenI into a systemic grammar based generator [old tracker]Tue, 08 Sep 2009 20:17:48 GMTTue, 08 Sep 2009 20:17:48 GMT<p>
The idea is for the SFG based system to generate inputs to GenI
</p>
http://trac.haskell.org/GenI/ticket/26
http://trac.haskell.org/GenI/ticket/26Report#27: polarity precompilation [old tracker]Tue, 08 Sep 2009 20:18:17 GMTTue, 08 Sep 2009 20:18:17 GMT<p>
What on earth did I mean by this?
</p>
http://trac.haskell.org/GenI/ticket/27
http://trac.haskell.org/GenI/ticket/27Report#28: output to 3rd party morphological generator should include variablesFri, 11 Sep 2009 11:25:40 GMTFri, 11 Sep 2009 11:25:40 GMT<p>
This is just a TODO. Check the source code to see if GenI will output variables in feature structures to the third party morphological realiser.
</p>
<p>
Right now literate GenI only shows constants in the example.
</p>
http://trac.haskell.org/GenI/ticket/28
http://trac.haskell.org/GenI/ticket/28Report#34: include GenI version in manualFri, 25 Sep 2009 10:20:58 GMTFri, 25 Sep 2009 10:20:58 GMT<p>
Now that we have geni --version, this should be easy enough...
</p>
http://trac.haskell.org/GenI/ticket/34
http://trac.haskell.org/GenI/ticket/34Report#35: jsonify stupidmorph and tomorphFri, 25 Sep 2009 10:38:34 GMTTue, 29 Sep 2009 08:29:17 GMThttp://trac.haskell.org/GenI/ticket/35
http://trac.haskell.org/GenI/ticket/35Report#36: document basic flags in manualFri, 25 Sep 2009 10:44:35 GMTMon, 28 Sep 2009 16:01:19 GMThttp://trac.haskell.org/GenI/ticket/36
http://trac.haskell.org/GenI/ticket/36Report#38: empty strings should be quoted when producing geni outputSat, 10 Oct 2009 09:50:57 GMTSat, 10 Oct 2009 09:50:57 GMT<p>
Should be (""), was ()
</p>
<p>
This affects geniconvert on the surface, but it's really a problem with the core printing code.
</p>
http://trac.haskell.org/GenI/ticket/38
http://trac.haskell.org/GenI/ticket/38Report#40: geni: Prelude.foldr1: empty listMon, 07 Dec 2009 18:17:56 GMTMon, 07 Dec 2009 18:20:22 GMT<p>
No idea why this happens.
</p>
http://trac.haskell.org/GenI/ticket/40
http://trac.haskell.org/GenI/ticket/40Report#41: separate trash pile for last operation performedWed, 09 Dec 2009 14:32:50 GMTWed, 09 Dec 2009 14:32:50 GMT<p>
This should make it easier to figure out what GenI is doing and why.
</p>
http://trac.haskell.org/GenI/ticket/41
http://trac.haskell.org/GenI/ticket/41Report#43: support subsumption with unification variables in relationsWed, 09 Dec 2009 16:38:06 GMTWed, 09 Dec 2009 16:38:06 GMT<p>
Not just the arguments, but the relations themselves.
</p>
http://trac.haskell.org/GenI/ticket/43
http://trac.haskell.org/GenI/ticket/43Report#44: elementary tree semantics should be unification of tree schema and lemma semanticsWed, 09 Dec 2009 16:41:53 GMTWed, 09 Dec 2009 16:41:53 GMT<p>
See also <a class="new ticket" href="http://trac.haskell.org/GenI/ticket/43" title="enhancement: support subsumption with unification variables in relations (new)">#43</a>
</p>
http://trac.haskell.org/GenI/ticket/44
http://trac.haskell.org/GenI/ticket/44Report#48: display number of results found in GUI and console mode...Mon, 28 Dec 2009 18:11:38 GMTMon, 28 Dec 2009 18:11:38 GMT<p>
Both unique and overall.
</p>
http://trac.haskell.org/GenI/ticket/48
http://trac.haskell.org/GenI/ticket/48Report#49: results out of order when pre-terminals have more than one terminalMon, 04 Jan 2010 21:11:38 GMTMon, 04 Jan 2010 21:11:38 GMT<p>
(foo (x y)) will give the linear order y x...
</p>
http://trac.haskell.org/GenI/ticket/49
http://trac.haskell.org/GenI/ticket/49Report#51: avoid crashing if ViewTAG not foundThu, 28 Jul 2011 16:41:23 GMTThu, 28 Jul 2011 16:41:23 GMT<p>
GenI should not crash if ViewTAG is not found; it should do something friendlier like give a pop-up box.
</p>
http://trac.haskell.org/GenI/ticket/51
http://trac.haskell.org/GenI/ticket/51Report