kowey / geni Goto Github PK
View Code? Open in Web Editor NEWSurface realiser (part of a Natural Language Generation system) using Tree Adjoining Grammar
License: GNU General Public License v2.0
Surface realiser (part of a Natural Language Generation system) using Tree Adjoining Grammar
License: GNU General Public License v2.0
The lexicon and test suite have no business using a custom ad-hoc format. Now that I know a perfectly acceptable lightweight standard language exists for this this thing (JSON), I should just use it to make life simpler for everybody.
Backward compatibility would be nice. I guess we'll have to support both, maybe even extend geniconvert?
Macros file probably unchanged. No real gain from JSON-ifying that.
Feature structures may be tricky. We'll have to think about this a bit
Both unique and overall.
The code
{{{
main =
do print $ head $ unify left right
print $ head $ unify right left
where
left = map (GVar . show) [1..3]
right = drop 1 left ++ [GConst ["X"]]
}}}
The output
{{{
([?1,?1,X],fromList [("1",X),("2",X),("3",X)])
([?2,?3,X],fromList [("1",X),("2",X),("3",X)])
}}}
I think it should be
The output
{{{
([X,X,X],fromList [("1",X),("2",X),("3",X)])
([X,X,X],fromList [("1",X),("2",X),("3",X)])
}}}
The fix is probably simple: just replace after unify
The morphological realisation (built-in) is dumb in that it unifies each pre-terminal node of the derived tree independently with the morphological lexicon.
This is not good, because it does not allow for mutually exclusive realisations:
he hold_s_ the apple vs you hold the apple
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.
What on earth did I mean by this?
The "optimisation" is a now baked-in (probably always was)
Probably a wxHaskell issue :-(
We need to replace our sorting strategy with something that works with proper data structures instead of strings.
Eva would also like to display the morph-realised outputs in the debugger or to somehow have a situation where you get the final output, you click on it and you get the tree.
Should be (""), was ()
This affects geniconvert on the surface, but it's really a problem with the core printing code.
I'll have to see what Carlos thinks about it.
No idea why this happens.
Yikes!
geni: Bug in GenI!
prependToSubst: Eric broke unification. Prepending K-t-73 twice
geni -m dist/build/grammar/valuation-sem.geni -l dist/build/lexicon/lemmas.glex -s suite/verbs --testcase=t110 --batchdir=/tmp/b
The index accessibility filtering code is not being maintained.
It should just be removed to reduce cruft.
I don't understand what this is about :-(
Not just the arguments, but the relations themselves.
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.
What may be annoying is having to write a monad transformer and slip it into our current MT stack.
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).
Right now you have to cabal clean if you switch back and forth between the GUI and text geni.
That's stupid. The library should be independent of the compilation mode
Make it really a separate program
The idea is for the SFG based system to generate inputs to GenI
And not just in configuration window...
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.
The bracketed output is a compromise between a full parse tree and a plain string.
Parse tree:
{{{
S(NP(somebody),VP(VP(V(saw),NP(something)),PP(somewhere)))
}}}
Bracketed output:
{{{
somebody ((saw something) somewhere)
}}}
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
Make it a required flag/input instead
Fixed by kicking it out and making it a standalone module.
MacOSX wxWidgets 2.8.10, wxHaskell 0.11.x
I could have sworn I kept seeing something like this happen.
See geni -m dist/build/grammar/valuation-sem.geni -l dist/build/lexicon/lemmas.glex -s suite/verbs --testcase=t110 and skip 140 steps
Luciana Benotti asked:
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).
If you run GenI and just naively use the GUI to try and load a grammar or lexicon, nothing happens.
This was because we were using the old version of the state on reload.
The bigger problem is that my GUI code is a big pile of spaghetti :-(
The square brackets should either be optional, or mandatory but enforced. Right now they are silently accepted and ignored.
The point is to make it so that you can never build GConst []
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.
See also #43
(foo (x y)) will give the linear order y x...
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).
Would only be really useful if multi-adjunction happens a lot
This should make it easier to figure out what GenI is doing and why.
Right now you can only do morphological realisation on the server side.
It would be nice if geniserver could somehow return feature structures so that clients can do morphological realisation themselves.
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).
So something like
feature(m,person:2)
in the input semantics
Hmm, now I have a better idea about the argument for separating test logic from business logic.
Right now in Leopard, I have to run geni with open geni.app, which means no command line arguments, ARGH!
At least some sort of workaround would be good
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.
Right now literate GenI only shows constants in the example.
{{{
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 [].
}}}
Now that we have geni --version, this should be easy enough...
We don't have the resources to deal with multiple encodings, so let's just standardise on a Unicode-friendly one and hope for the best.
This may induce some pain though, because we have legacy resources that are in ISO-8859-1
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.
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.
Also note that substitution sites with disjunctive or variable indices would just have to look at all chart items.
See: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaLeX
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
Right now we have our own custom format. Could making the format XML-based be useful? Actually, I have a prejudice against XML, but if we could use something lighterweight like JSON or YAML, maybe...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.