Wordnet 1.7 has recently been released. Has anyone used
QueryData with 1.7 - any problems?
I am not entirely clear on the nature of the changes in
1.7 so I'm not sure if there would be reason to expect problems.
Thanks!
Ted
http://www.d.umn.edu/~tpederse
> I need to look at the Query ( Not QueryDef) module that uses Wordnet
> WN to grab the output . The Link On
> "http://www.ai.mit.edu/~jrennie/WordNet/" fails !
My lab's web server was down for the last two days because of an
electricity outage. It's up again. You should be able to download
the module now.
Jason
I need to look at the Query ( Not QueryDef) module that uses
Wordnet WN to grab the output . The Link
On "http://www.ai.mit.edu/~jrennie/WordNet/" fails !
Is there any other place to download this module ?
Thanks
(NUTSHELL: use the $WNHOME env variable as $WNHOME/dict, not
/usr/local.foo/dict)
Hi - for some internal wordnet stuff over here at princeton, I was told to
use perl to do something. I needed a nice way to extract key/gloss pairs
from the data files, and I didn't feel like writing a parser in a language
I am new to, so I looked up your perl library on the related projects
page. So I downloaded it and did the perl Makefile.pl, make, and on make
test it couldn't open the data files because of what I mentioned at the
top.
- John Asmuth
(shameless plug)
PS - for a more up-to-date and generally froodier Python API, check out
PyWN at sourceforge.net/projects/pywn. There is also a link on the related
projects page.
Hi,
Yahoo kills groups that are inactive for 120 days straight. This message
will keep us going for another four months.
Btw, what do y'all think of the perl module? How does it compare to the
C code that Princeton puts out? Is it worth having the two separate
modules Query & QueryData?
Jason
ua960534@... said:
> I've got the above error message while making the Makefile. Anybody
> knows how to deal with this? Any other way to run WN without going
> through the Makefile. Please help
You can simply move the perl module (QueryData.pm) to a directory where
you store perl modules (e.g. ~/perl) and include that directory whenever
you run perl (e.g. perl -I~/perl or put #!/usr/bin/perl -I~/perl at the
top of your perl scripts).
I might have to get rid of the Makefile.PL installation proceedure. Some
things are too complicated for their worth...
Jason
[Sun 29] 12:03am mlx>perl Makefile.PL
Have /usr/local/lib/perl5/5.6.0/Config.pm expected
/usr/local/lib/perl5/5.6.0/su
n4-solaris/Config.pm
Your perl and your Config.pm seem to have different ideas about the
architecture
they are running on.
Perl thinks: [5.6.0]
Config says: [sun4-solaris]
This may or may not cause problems. Please check your installation of
perl if yo
u
have problems building this extension.
Writing Makefile for WordNet::QueryData
I've got the above error message while making the Makefile. Anybody
knows how to deal with this? Any other way to run WN without going
through the Makefile. Please help
mohfy001@... said:
> Can somebody help me with this error message? Since no changes can be
> made to the Makefile.
I use 5.003. I don't know much about perl 5.6. I can say that the
Makefile doesn't do a whole lot and that you could get by just by putting
QueryData.pm into /foo/WordNet and then running perl with the option -I/foo.
Jason Rennie www.ai.mit.edu/~jrennie/
MIT: (617) 253-5339 jrennie@...
Can somebody help me with this error message? Since no changes can be made to
the Makefile.
[Fri 27] 10:29pm mlx>perl Makefile.PL
Have /usr/local/lib/perl5/5.6.0/Config.pm expected
/usr/local/lib/perl5/5.6.0/sun4solaris/Config.pm
Your perl and your Config.pm seem to have different ideas about the
architecture
they are running on.
Perl thinks: [5.6.0]
Config says: [sun4-solaris]
This may or may not cause problems. Please check your installation of perl if
you
have problems building this extension.
Writing Makefile for WordNet::QueryData
ssarnobat@... said:
> ONE OBSERVATION IS THAT SOMEHOW WN DOESNT LIKE A GROUP OF WORDS FED
> TO IT. SOMETIMES IT BARFS. I DID MANAGE TO WORK AROUND THE PROBLEM
> THOUGH BY LIMITING IT TO WORDS ONLY. THAT MIGHT BE THE CAUSE FOR THE
> LEAKS.
Do you have specific examples of words/strings that cause it to break?
Jason Rennie www.ai.mit.edu/~jrennie/
MIT: (617) 253-5339 jrennie@...
--- In wn-perl@egroups.com, "Roger Whipp" <supernova@s...> wrote:
>
> What platform on you running on?
LINUX
> Are you running apache?
NOPES
> Are you using perl_mod?
NOPES...
>
ONE OBSERVATION IS THAT SOMEHOW WN DOESNT LIKE A GROUP OF WORDS FED
TO IT. SOMETIMES IT BARFS. I DID MANAGE TO WORK AROUND THE PROBLEM
THOUGH BY LIMITING IT TO WORDS ONLY. THAT MIGHT BE THE CAUSE FOR THE
LEAKS. COMMENTS??
THANKS FOR YOUR HELP
Sachin
>
> roger
ssarnobat@... said:
> Thank you for your quick reply... I have about 30,000,000 words and
> initially though QueryData just zips through the words, after it is
> about half way done, it just stalls. for each word in the data, I'm
> calling valid_forms to see if the word exists.
>Hmm... can you track memory usage with top or some other similar tool?
>Are you fairly sure that it is a memory problem?
I didn't see your origanal message where you probably gave all the info
on your system and configuration. It would be helpful to know things like
the following.
What platform on you running on?
Are you running apache?
Are you using perl_mod?
roger
Hello again,
One thing you might try that could possibly fix things is "undef"ing the
values that are returned from the valid_forms and query functions. I'm
pretty sure that these are freed automatically, but depending on the way
you are doing things, it's possible that they aren't being freed.
I'm currently running a large query run, essentially running the same 20
queries over and over again. I'm up to 600,000 queries with no noticable
difference in memory usage. When the database is loaded, the memory
usage is 16480K. It hasn't changed from that one bit.
I don't have 30 million words to toss at QueryData.pm, so I can't mimic
your conditions. Would you be willing to send me the script that you're
using to run the queries? You might also consider reading over the
sections of "Programming Perl" that talk about memory usage.
Hopefully we'll be able to fix this thing...
Jason Rennie www.ai.mit.edu/~jrennie/
MIT: (617) 253-5339 jrennie@...
[I'm CCing this to the mailing list in case anyone there might be able to
help]
ssarnobat@... said:
> Thank you for your quick reply... I have about 30,000,000 words and
> initially though QueryData just zips through the words, after it is
> about half way done, it just stalls. for each word in the data, I'm
> calling valid_forms to see if the word exists.
Hmm... can you track memory usage with top or some other similar tool?
Are you fairly sure that it is a memory problem?
ssarnobat@... said:
> Does this happen because some of the words have spaces in them?
The perl module should be able to deal with spaces in words just fine. I
was careful when writing the code to take care of that case. Some of the
testing that I've done has been able to deal with spaces in words w/o
problem. Btw, just to check, did you run the test.pl script? I assume
such simple tests work if you can make it through 15M words :)
I'll take a look at the code this weekend and get back to you. Too busy
ATM.
Jason Rennie www.ai.mit.edu/~jrennie/
MIT: (617) 253-5339 jrennie@...
Hi Joseph,
I added such a function to QueryData.pm. You'll find it in version 1.10
(just released a few minutes ago :). You'll be able to get a list of all
nouns in WordNet with a script like the following:
use WordNet::QueryData;
my $wn = WordNet::QueryData->new ("/usr/local/dict", 0);
my @words = $wn->list_all_words("noun");
print join ("\n", @words), "\n";
The 'list_all_words' function takes as a parameter a part-of-speech.
Jason D Rennie www.ai.mit.edu/~jrennie/
MIT: (617) 253-5339 jrennie@...
Hi Vladimir,
I downloaded the Windows/PC WordNet database package and ftp'd it to my
linux machine (binary transfer method so as to not change the files at
all). I did a diff on a few of the database files and found no
differences. I then ran the short script that you sent me and didn't
have any problems. The following script:
#!/usr/bin/perl
use WordNet::QueryData;
# Load index, mophological exclusion files (time-consuming process)
my $wn = WordNet::QueryData->new ("/home/ai/jrennie/wn16-win",1);
print "fine#2-> ",
join (", ", $wn->query ("fine#a#2", "syns")), "\n";
generates the following output:
[jrennie@tiikeri QueryData]$ ./test2.pl
Dir = /home/ai/jrennie/wn16-win
Verbose = 1
Loading WordNet data, please wait...
Morphological Exceptions...
Index...
Data Files...
Done.
query: WORD=fine POS=a SENSE=2 RELATION=syns
fine#2-> fine#a#2
Since they're exactly the same, you might try using the unix database
package just to see if you see any different behavior...
Jason Rennie
(617) 253-5339
jrennie@...http://www.ai.mit.edu/~jrennie/
russog@... said:
> Yes, I have version 1.09, and I still get the out of memory message.
Oh. Now I know. You undefine $/ QueryData relies on $/ having its
default value order to work properly. This program works just fine:
#!/usr/local/bin/perl -w
use strict;
use WordNet::QueryData;
my $wn = WordNet::QueryData->new ("/usr/local.foo/dict", 1);
my $foo = $/;
undef $/;
open (NUOVO, "Result.txt")||die "Can't open it\n";
my $line = <NUOVO>;
close NUOVO;
$/ = $foo;
my @senses = split(/\n/,$line);
my $thing;
foreach $thing (@senses)
{
print "$thing->", join(" ", $wn->query ("$thing", "syns")), "\n";
}
Jason
russog@... said:
> could you please try this short code for me ? Yes, I have version
> 1.09, and I still get the out of memory message.
> Here is th code , I am going to send you the data in Result.txt in the
> next e-mail
Hmm... something is definitely wrong. The test program that you sent me
uses up hundreds of megs of memory and runs through the queries
incredibly slowly. I'll let you know when I figure out what is going
wrong.
Jason
Jason,
could you please try this short code for me ?
Yes, I have version 1.09, and I still get the out of memory message.
Here is th code , I am going to send you the data in Result.txt in the
next e-mail
#!/usr/local/bin/perl -w
require "/home/russog/WN_QD/QueryData.pm";
my $wn = WordNet::QueryData->new ("/home/usr/local/wordnet1.6/dict");
undef $/;
open (NUOVO, "Result.txt")||die "Can't open it\n";
$line = <NUOVO>;
@senses = split(/\n/,$line);
foreach $thing(@senses){
print "$thing->",join(" ",$wn->query("$thing","syns")),"\n";
}
close NUOVO;
___________________________________
Grazia Russo-Lassner
Computational Linguistics M.S.
Georgetown University
http://epsilon3.georgetown.edu/~russog
livshits@... said:
> I am trying to use Wordnet on an NT machine and running into the
> following problem on a simple file:
I've never tried to use my code on an NT machine, nor have I used the
Windows version of the database, but I'll try to tell you as much as I can
about the error message so that you'll have a better chance of figuring
out where the problem is.
So, this error comes up when WordNet::QueryData gets confused in the
parsing of the WordNet data file. When a new QueryData instance is
created (via the 'new' funciton), the entire set of index.* files are
read in and stored in memory. These index files contain fseek pointers
into the data.* files. Each index.* file line reads something like:
abrasion n 3 2 @ ~ 3 0 10258359 09691437 07800793
Where the three numbers at the end of the are the pointers into the
data.* files. The numbers indicate exact fseek values into the data.*
files. So, when you do a query, QueryData grabs the appropriate fseek
value out of memory, fseeks to that place in the data.* file and reads a
line at that place. The first piece of information in that line is its
fseek value. The "Offsets differ" error message is printed out if the
value I used for fseeking and the number at the beginning of the line do
not match up. Here's the corresponding data.noun entry for the third
sense of abrasion used as a noun:
07800793 19 n 04 grinding 0 abrasion 0 attrition 0 detrition 0 001 @ 07800619
n 0000 | the wearing down of rock particles by friction due to water or wind or
ice
See how the "07800793" matches up? That's what I check for. The error
message that you sent me:
Offsets differ INDEX=2122255 DATA=r
indicates that QueryData read the line beginning at position 2122255 but
found "r" to be the string at the beginning of that line. When I do a
search for "2122255" the unix data.adj file, I find the following line:
02122255 00 s 01 fine 0 001 & 02120292 a 0000 | superior in skill or ability
or accomplishment; "a fine violinist"; "a fine athlete"; "a fine mind"; "the
scupture showed the fine hand of a master"; "a fine performance"
So, it sounds like the index.* files are being read in properly (since it
knows that 02122255 is the location of the second sense of fine), but
something is going wrong with the data.adj fseek. In version 1.09 of
WordNet::QueryData, the fseek (seek) happens at line 474. QueryData calls
seek $fh, $index_offset, 0;
$index_offset is 2122255 in your case. The third argument of '0' tells
it to make the offset relative to the beginning of the file. $fh should
be a pointer to the data.adj file.
A useful thing to do would be to make sure that the offset numbers in the
data.* files match up to real fseek positions. The PC version of the
WordNet database is locked up in an executable so I can't easily open it
up on my linux box.
Another good thing to try would be to add a line to the get_pointers
funciton within QueryData.pm that prints $line, which would be the line
that WordNet found at fseek position 2122255.
Btw, is the problem specific to this word/relation, or do you find it to
be a general problem under NT?
Jason Rennie
(617) 253-5339
jrennie@...http://www.ai.mit.edu/~jrennie/
Hi Grazia,
russog@... said:
> a code as simple as the one below will result in the following error
> message:
Are you using the latest version of WordNet::QueryData? The current
version is 1.09. You should see the following line near the top of
QueryData.pm if you are using the latest version:
# $Id: QueryData.pm,v 1.9 2000/03/31 13:06:53 jrennie Exp $
The following script works fine for me:
#!/usr/bin/perl
use WordNet::QueryData;
# Load index, mophological exclusion files (time-consuming process)
my $wn = WordNet::QueryData->new ("/usr/local.foo/dict");
my @words = ("cat", "dog", "hat", "apple");
my $word;
for $word (@words)
{
print "$word->", join (" ", $wn->query ("$word#n#1", "mero")), "\n";
}
It gives the following output:
[jrennie@tiikeri QueryData]$ ./test2.pl
cat->
dog->flag#n#7
hat->brim#n#2 crown#n#5 hatband#n#1
apple->
This matches up perfectly with the information that I get from the
on-line version of WordNet 1.6
(http://www.cogsci.princeton.edu/cgi-bin/webwn)
Does the above script give you any problems? (you'll need to change
"/usr/local.foo/dict" to the appropriate directory)
Jason Rennie
(617) 253-5339
jrennie@...http://www.ai.mit.edu/~jrennie/
I am trying to use Wordnet on an NT machine and running into the
following problem on a simple file:
use WordNet::QueryData;
my $wn = WordNet::QueryData->new ("d:\\wordnet-1.6\\dict", 1);
print "fine#2-> ",
join (", ", $wn->query ("fine#a#2", "syns")), "\n";
The error message is
...
query: WORD=fine POS=a SENSE=2 RELATION=syns
Offsets differ INDEX=2122255 DATA=r
Offsets differ INDEX=2122255 DATA=r
The data I am using is the unix data files available from Princeton,
they also have a Windows version that's using a different format for
its data as far as I can tell. Not sure if line breaks or something
similar could be causing this.
Could you suggest how I should go about trying to figure out what's
going on here?
Thanks,
--Vladimir
P.S.: Please cc to livshits@....
Hi Jason,
a code as simple as the one below
^^^^^^^^^^^^^^^^^^^^
use....
my $wn .....
for$i(0..$#Data){
for $j(0..$#{$Data[$i]}){
$word = $Data[$i][$j];
print"$word->", join(" ",$wn->query("$word#n#1","mero")),"\n";
}
}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
will result in the following error message:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use of uninitialized value at
/usr/local/lib/perl5/site_perl/WordNet/QueryData.p
m line 466.
Use of uninitialized value at
/usr/local/lib/perl5/site_perl/WordNet/QueryData.p
m line 468.
Out of memory!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Instead, this one to retreive just senses of words, works perfectly.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
for$i(0..$#Data){
for $j(0..$#{$Data[$i]}){
$word = $Data[$i][$j];
print"$word->", join(" ",$wn->query("$word#n")),"\n";
}
}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Do you have any suggestions ?
Thanks
Grazia
___________________________________
Grazia Russo-Lassner
Computational Linguistics M.S.
Georgetown University
http://epsilon3.georgetown.edu/~russog
Hi Grazia,
In the future, I would appreciate it if you were to send such requests to
the mailing list (wn-perl@egroups.com) rather than mailing everyone
personally: 1) this keeps a record of WordNet discussions for future
reference and 2) it aids e-mail filtering agents by identifying the mail
as pertaining to WordNet (both through the e-mail address and by adding
[wn-perl] to the subject line).
russog@... said:
> Has anyone of you already had the same warnings that I get between
> "Index..." and "Data Files..." on "Incorrect part-of-speech ..." ?
I haven't experienced such problems. This error might occur if the
WordNet module does not find the WordNet database in the expected place.
Do the files index.* exist in /home/usr/local/wordnet1.6/dict?
Jason Rennie
(617) 253-5339
jrennie@...http://www.ai.mit.edu/~jrennie/
Hello, everyone.
I am joining the discussion group on Jason's WordNet module, because I am
going to use it for a project in a Text Summarization course.
Talk to you soon
Grazia
___________________________________
Grazia Russo-Lassner
Computational Linguistics M.S.
Georgetown University
http://epsilon3.georgetown.edu/~russog
rogerw@... said:
> I am testing the perl QueryData perl module on the web from a linux
> system running on an apache server.
If all you want is to be able to access WordNet from the web, you can
just point your browser to:
http://www.cogsci.princeton.edu/cgi-bin/webwn
which is the Princeton WordNet group's on-line interface to WordNet. If
your desire is to make a local WordNet Web search interface, I suggest
that you either 1) use the C code that comes with the WordNet database or
2) use the WordNet::Query perl package (which simply acts as a wrapper
around the WordNet C code). WordNet::QueryData sacrifices initialization
efficiency in order to yield efficient individual queries. However, you
won't notice the difference in query speed if you're dealing with any sort
of interactive system (such as a Web interface).
If you really want to make your queries efficient, you could use a perl
module called mod_perl, which allows you to separate initialization
from steps necessary to respond to a Web query.
Hope this helps,
Jason Rennie
(617) 253-5339
jrennie@...http://www.ai.mit.edu/~jrennie/
Can anyone help? I am testing the perl QueryData perl module on the web from a linux system running on an apache server. Is the initialisation step called every time a separate call is made to perl and subsequently to the database files. If so is there anyway around this as it makes the process painfully slow. Really I'm only interested in using the wordnet as an online english - english dictionary for our students so I don't need to do complicated lexigraphical searches. Any help or advice would be much appreciated
Hi Eric,
joanis@... said:
> I just noticed what I think is a bug with the meronym and holonym
> queries. In the WordNet browser, a meronym query on "clay" returns
> "brick", "tile", "pottery", whereas the QueryData mero query returns
> the holonym "silicon", with the holo query returning the meronyms of
> "clay". For all other queries, the response from QueryData answers
> the question "What are the <rel> of <word>?". In the meronym and
> holonym cases, however, the response answers the question "What words
> is <word> a mero/holonym of?".
Wow. Thanks so much for noticing. I took the symbols directly from
"Five Papers on WordNet" and never really thought to check to make sure
they were all correct. I think I'll send George Miller a note so that
the Princeton WordNet group can fix the mix-up in the paper.
I'll have a new version out shortly.
Thanks again,
Jason