pasky
commented
8 years ago Awesome, thanks a lot for starting this as a github issue now. We certainly have a lot to talk about here, let me try to sort that out a little:
JBT Provider
We need to implement JBT RESTful microservice that does the heavy lifting, keeps stuff loaded in memory etc. I guess this at least partially should already exist within JBT as they offer a web interface, if we can just reuse that, it's the best option. In cz.brmlab.yodaqa.provider, we'll probably need a subpackage .jbt or something with classes that provide the access to this to the rest of YodaQA, possibly with some caching later on.
Overally, should be reasonably trivial? It's fine by me to just implement whatever we need for initial usage within the pipeline, we don't have to cover all the features all at once (might even not be 100% desirable from dead code perspective).
JBT for LATs
Equally importantly, we want to scout for ways to use JBT in YodaQA. I completely agree with you that using JBT for smarter type coercion is the best first application! It should be easy to do, it's a pretty well-defined task and could have a nice impact.
I'll elaborate in a followup comment.
JBT - other usages
Other ideas for using JBT, sorted roughly by difficulty I guess:
- Clue matching in properties - we now use the "propsel" word embedding based model to check how close a property is to the given LAT, it might be interesting to compare that to a JBT-based similarity model
- Context-aware entity linking - if we say "who directed ender's game?", we want to pick "ender's game" the movie, not the book - I think JBT ought to help us with that? we could look at the abstract of the entity "Ender's Game is a 2013 American science fiction action film based on the novel", we already to that now for a naive word embedding based classifier
- Query expansion - generate similar expressions to query esp. via solr ("What city in Australia has rain forests" we want to also look for "town" and "rainforest" or maybe "jungle" as alternatives)
- Clue matching in sentences - for picking answer-yielding sentences from fulltext solr results, we now require literal occurences of the clues, without allowing even for synonyms; we also use in-sentence relationship between the answer and matched clue as a feature for scoring answers. We could use JBT similarities, but maybe also contexts, to spot non-literal occurences.
There are surely some much more sophisticated uses for JBT, this is just initial ideas without still having a lot of experience with it.
k0105
vineetk1
Background
So, I've suggested to integrate Distributional Semantics into the YodaQA pipeline by using JoBim Text, a framework developed by TU Darmstadt (in Germany) and IBM that is also used for domain adaptation in Watson. It provides a way to acquire domain knowledge in an unsupervised way. For instance, UMLS, a huge ontology in medicine and frankly one of the most extensive ontologies I've worked with, covers most concepts in medicine, but still misses quite a few relations. With distributional semantics this ontology can be "completed", the need for knowledge engineering is heavily reduced and it even scales better than conventional triple stores.
Work already done
So I've looked into JBT and can now generate models for my own corpora, so I can compute similar terms, contexts and even labelled sense clusters based on Hearst patterns found by applying UIMA Ruta. Furthermore, Dr. Riedl, one of the main developers, has kindly agreed to provide their Wikipedia Stanford model, which saved us a lot of computation time. Additionally, we could use a web service they offer, which also features a Wikipedia trigram model.
Example
Let's for instance look up the word "exceptionally": The framework recognizes that "exceptionally#RB" is similar to terms like "extremely#RB", "extraordinarily#RB", "incredibly#RB", "exceedingly#RB", "remarkably#RB" etc. It can provide accurate counts for these terms and it can provide context to e.g. distinguish "cold", the disease, from "cold", the sensation. And finally we can group these interpretations, e.g. the trigram output actually distinguishes the meaning of the term as in "[extremely, unusually, incredibly, extraordinarily, ..." from the meaning "[attractive, intelligent, elegant, ...", which is quite clever imho.
What now?
So, there are a couple of things JBT can be used for. The most prominent example is TyCor: Expand the concept to infer type constraints and match those to the LAT. That's why I already asked whether it makes sense to add the functionality to cz.brmlab.yodaqa.analysis.tycor.LATMatchTyCor.java first.
But even more important than one particular use case might be to make JBT generally available to the pipeline. When we discussed scaling Yoda here: https://github.com/brmson/yodaqa/issues/21#issuecomment-170403540 Petr mentioned that he strives to encapsulate computationally intensive tasks behind REST interfaces (essentially microservices, I guess). Watson uses distributional semantics all over its pipeline and some benefits might only become visible once the pipeline is extended to domain knowledge. Hence, I suggest to make JBT available as another data backend just like Freebase, DBPedia and enwiki, before using it in any particular stage of the pipeline. We can then try using it in various places and see where we obtain better results. I would also write a detailed README, so people get up to speed quickly.
I started this thread a) to track progress and b) to ask for comments. Does anyone have additional ideas where or how to use JBT in YodaQA? Do my ideas make sense or can you think of a better approach?
Best wishes, Joe