A bug in WordNet-QueryData-1.48 perl model

[kido]

I found an abnormal situation during using WordNet-QueryData-1.48 perl
model and don't know whether it is a bug.

The sentence in perl

print join(", ", $wn->querySense("are")), "\n";

Only returns "are#n", I assume it should return "are#n, are#v".

Since both online wordnet and my local database show that the word
"are" is none and verb.

I am not sure if this is a bug, does it impact the other word queries.

My system is:
This is perl, v5.8.8 built for darwin-thread-multi-2level
(with 2 registered patches)
Mac OS 10.5.5
Wordnet 3.0
WordNet-QueryData-1.48 perl model

[Jason Rennie]

In fact, "are" doesn't appear in WN as a verb.  Try the web interface:

http://wordnetweb.princeton.edu/perl/webwn

and it returns "are" as a noun and "be" as a verb.  QueryData doesn't support all of the translations that regular WN does.  It appears that verb.exc specifies that "are#v" should be mapped to "be#v".  Anyone interested in adding this functionality?

Jason

--
Jason Rennie
Research Scientist, ITA Software
http://www.itasoftware.com/

[Ted Pedersen]

Hi Jason,

I suspect this functionality could be pretty useful to us in the
context of our word sense disambiguation module
(http://search.cpan.org/dist/WordNet-SenseRelate-AllWords/), so we'll
take a look and see how hard/easy it would be to incorporate.

Cordially,
Ted

--
Ted Pedersen
http://www.d.umn.edu/~tpederse

[Ted Pedersen]

Hmmm...this also seems to be an issue for
http://search.cpan.org/dist/WordNet-Similarity/

Note in the example below that when we don't specify the part of
speech, we don't seem to be able to realize that 'are' is a verb, but
that when we specify the part of speech as 'are#v' we find it...

marimba(7): similarity.pl --type WordNet::Similarity::wup are be
Loading WordNet... done.
Loading Module... done.
Warning (WordNet::Similarity::wup::parseWps()) - are#n and be#v belong
to different parts of speech.
Warning (WordNet::Similarity::wup::parseWps()) - are#n and exist#v
belong to different parts of speech.
Warning (WordNet::Similarity::wup::parseWps()) - are#n and equal#v
belong to different parts of speech.
Warning (WordNet::Similarity::wup::parseWps()) - are#n and
constitute#v belong to different parts of speech.
Warning (WordNet::Similarity::wup::parseWps()) - are#n and embody#v
belong to different parts of speech.
Warning (WordNet::Similarity::wup::parseWps()) - are#n and cost#v
belong to different parts of speech.
are#n#1 be#n#1 0.352941176470588

marimba(8): similarity.pl --type WordNet::Similarity::wup are#v be#v
Loading WordNet... done.
Loading Module... done.
be#v#1 be#v#1 1

This is pretty inconsistent - I would have hoped that we'd report the
same result in both cases since this command should return the max
similarity regardless of pos (and 1 is clearly greater than .35 so the
first version is missing something important).

So, I think we need to look into this. :) We'll keep you posted!
(Thanks to kido, btw, for noticing this...)

Thanks,
Ted

[Jason Rennie]

Unfortunately, I don't have time to work on QueryData any more, but I'm happy to incorporated patches and release updated versions.

Jason

[Ted Pedersen]

Absolutely understood. We are sometimes in the same situation where we
get fixes or suggestions for some of our packages but just don't have
the time to really test and incorporate them (at least not quickly).
So, if we are able to figure this out we'll provide something that
will be tested and ready to go.

Thanks!
Ted

[Jason Rennie]

Actually, I'm happy to accept and release patches which aren't polished, as long as they don't break existing functionality.  But, I don't have the continuous periods of time needed for new development esp. since I haven't used WN/QD in years...

Jason

[Ted Pedersen]

Greetings all,

We've spent a little time looking at this, and realized that we aren't
having a problem with this because we always call validForms before
calling querySense, so I *think* we are getting all the forms that are
available. While this doesn't "fix" querySense, it might be a
reasonable workaround...or am I missing something by thinking that?

Cordially,

Ted

On Tue, Apr 14, 2009 at 8:53 AM, Ted Pedersen<dulu...@gmail.com> wrote:

[Jason Rennie]

That makes sense to me.  validForms will give you too many variations.  querySense will only give results for the truly valid ones.  You'll still miss some special cases, but I think you'll get better results than trying querySense directly.

Cheers,

Jason

617-714-2645
http://www.itasoftware.com/