We should not use remote resources. A remote service adds severe limits to
the WSD component. A remote resource will be slow to query (compared to
disk or memory), queries might be expensive (pay per request), the license
might not allow usage in a way the ASL promises to our users. Another issue
is that calling a remote service might leak the document text itself to
that remote service.
Please attach a patch to the jira issue, and then we can pull it into the
sandbox.
Jörn
On Wed, Jun 3, 2015 at 1:34 PM, Anthony Beylerian
anthonybeyler...@hotmail.com wrote:
Dear Jörn,
Thank you for the reply.===
Yes in the draft WSDisambiguator is the main interface.
===
Yes for the disambiguate method the input is expected to be tokenized, it
should be an input array.
The second argument is for the token index. We can also make it into an
index array to support multiple words.
===
Concerning the resources, we expect two types of resources : local and
remote resources.
+ For local resources, we have two main types :
1- training models for supervised techniques.
2- knowledge resources
It could be best to make the packaging using similar OpenNLP models for #1.
As for #2, it will depend on what we want to use, since the type of
information depends on the specific technique.
+ As for remote resources ex: [BabelNet], [WordsAPI], etc. we might need
to have some REST support, for example to retrieve a sense inventory for a
certain word.Actually, the newest semeval task [Semeval15] will use
[BabelNet] for WSD and EL (Entity Linking).[BabelNet] has an offline
version, but the newest one is only available through REST.Also, in case it
is needed to use a remote resource, AND it typically requires a license, we
need to use a license key or just use the free quota with no key.
Therefore, we thought of having a [ResourceProvider] as mentioned in the
[draft].
Are there any plans to add an external API connector of the sort or is
this functionality already possible for extension ?
(I noticed there is a [wikinews_importer] in the sanbox)
But in any case we can always start working only locally as a first step,
what do you think ?
===
It would be more straightforward to use the algorithm names, so ok why not.
===
Yes we have already started working !
What do we need to push to the sandbox ?
===
Thanks !
Anthony
[BabelNet] : http://babelnet.org/download
[WordsAPI] : https://www.wordsapi.com/
[Semeval15] : http://alt.qcri.org/semeval2015/task13/
[draft] :
https://docs.google.com/document/d/10FfAoavKQfQBAWF-frpfltcIPQg6GFrsoD1XmTuGsHM/edit?pli=1
Subject: Re: GSoC 2015 - WSD Module
From: kottm...@gmail.com
To: dev@opennlp.apache.org
Date: Mon, 1 Jun 2015 20:30:08 +0200
Hello,
I had a look at your APIs.
Lets start with the WSDisambiguator. Should that be an interface?
// returns the senses ordered by their score (best one first or only 1
in supervised case)
String[] disambiguate(String inputText,int inputWordposition);
Shouldn't we have a tokenized input? Or is the inputText a token?
If you have resources you could package those into OpenNLP models and
use the existing serialization support. Would that work for you?
I think we should have different implementing classes for different
algorithms rather than grouping that in the Supervised and Unsupervised
classes. And also use the algorithm / approach name as part of the class
name.
As far as I understand you already started to work on this. Should we an
initial code drop into the sandbox, and then work out things from there?
We strongly prefer to have as much as possible source code editing
history in our version control system.
Jörn
