Extract Model

[haz]

So if we can get away with just having tarski objects created, I think that's what we should do. This may mean that src/extract/model.py goes away entirely. Any issue with this?

[haz]

Just finished going through #36 , and while I have a better sense of why we want something on the extraction side (e.g., to dynamically build up the action), I still think we should offload whatever functionality we can over to tarski.

Don't both ripping out what's there, but do add it as an agenda item for the next time we meet.

[haz]

Ok, settling on something a little clearer.

• Action class for the ground truth data -- might just be a thin wrapper around tarski.
• Observations don't house any objects outside of their own API (just strings, etc). They need to be serializable.
• LearnedAction class (and related subclasses) for things on the extraction side. These might be things that get incrementally added to.

One key feature is that a LearnableAction should come with (a forced) implementation on each subclass to .compare(orig_action). This way, we could have a measure of how accurate the learned action is with the ground truth.