RDF/OWL Representation of WordNet

NOTE: this document is NOT a W3C draft, it is intended for discussion only.

Editor's Draft 2 February 2006

This version:
$Id: wn-conversion-20060202.html,v 1.3 2006/04/12 14:01:28 swick Exp $
Latest version:
Previous version:
Mark van Assem, Vrije Universiteit Amsterdam
Aldo Gangemi, ISTC-CNR, Rome
Guus Schreiber, Vrije Universiteit Amsterdam


This document presents a standard conversion of Princeton WordNet to RDF/OWL. It describes how it was converted and gives examples of how it may be used in Semantic Web applications.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a editor's draft, considered for publication as First Public Working Draft by the Semantic Web Best Practices and Deployment Working Group, part of the W3C Semantic Web Activity.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.


Dan Brickley and Brian McBride have contributed to the WordNet conversion described in this note through their work in the WordNet Task Force and additional comments and suggestions. @@TODO more ACKs


1. Introduction and guide to the reader

WordNet [Fellbaum, 1998] is a heavily-used lexical resource in natural-language processing and information retrieval. More recently, it has also been adopted in Semantic Web research community for use in annotation, reasoning, and as background knowledge in ontology mapping tools [@@REFS]. Currently there exist several conversions of WordNet to RDF(S) or OWL.

The WordNet Task Force of the SWBPD WG aims at providing a standard conversion of WordNet for direct use by Semantic Web application developers. Some of the earlier conversions are incomplete and are incompatible with each other, for example because they provide different URIs for the same entity in the original source. By providing a standard conversion that is as complete as possible the TF aims to improve interoperability of SW applications that use WordNet and simplify the choice between the existing RDF/OWL versions. We have based this conversion on examining the commonalities of previous conversions, extending them where necessary and making choices to suit different needs of application developers. This conversion may be used directly in Semantic Web applications, or as a source for modified WordNet versions (e.g. turning WordNet into an ontology). We have focused on staying as close to the original source as possible, i.e. reflect the original data model without interpretation. For example, whether or not (parts of) WordNet actually constitute a proper subclass hierarchy is outside the scope. Princeton hosts the conversion of the most recent version of WordNet RDF/OWL at the following URI:


Note that this URI points at the newest version, see WordNet versions for more information. WordNet RDF/OWL is maintained by... [@@TODO ... statement of permanence and updates of this version. The TF should look for an organization that is willing to make a commitment for maintaining WordNet for a longer period of time, say one or two years. This commitment entails making available a version of WordNet RDF/OWL for each new Princeton WordNet version and providing a suitable server to host WordNet RDF/OWL and processing functionality to return CBDs in response to HTTP GETs on WordNet URIs.]

Guide to the reader

This document is composed of three parts. The first part (Section one) provides a primer to the usage of the WordNet RDF/OWL representation and is intended as a convenient starting point for users and developers that have already worked with Princeton WordNet and have basic knowledge of RDF(S) and OWL, or those who have already worked with another RDF/OWL representation of WordNet. Those who are not familiar with WordNet should read Introduction to the WordNet datamodel and possibly Introduction to the WordNet RDF/OWL schema before reading the Primer. The second part consists of Sections three through eight which give more background information for those who are not familiar with WordNet and describe advanced options. It also provides more background to the decisions taken during conversion. The third part (the Appendices) contains detailed information on the RDF/OWL representation and versioning strategy.

This document is intended to reflect the consensus of the community using WordNet on the Semantic Web and the opinion of the TF on how best to represent the Princeton WordNet datamodel in RDF/OWL.

This document uses the following namespace abbreviations in URIs:

2. Primer to using RDF/OWL WordNet

Downloading WordNet

The first step in using this conversion is selecting the appropriate version to download. For each version of Princeton WordNet since version 2.0 there is a counterpart available in RDF/OWL. The whole of WordNet is split up into several files: two for the Synsets, WordSenses and Words, and one file per relationship in Princeton WordNet (e.g. all hyponyms are in one file). All files of version 2.0 can be downloaded as one archive file from the following location: [@@URL]. For downloads of newer versions and information on advanced possibilities (e.g. for reducing the size of WordNet) see [@@URL], and Wordnet versions and Advanced options, respectively. The base URI of the RDF/OWL of version 2.0 is

Overview of classes, properties and URIs

The WordNet schema has three main classes: Synset, WordSense and Word. The first two classes have subclasses for the lexical groups present in WordNet, e.g. NounSynset and VerbWordSense (see Figure one). Each instance of Synset, WordSense and Word has its own URI. There is a pattern for the URIs so that (a) it is easy to determine from the URI the class to which the instance belongs; and (b) the URI provides some information on the meaning of the entity it represents. For example, the following URI

is a NounSynset with the synsetId "107909067" and the first noun in the synset has the lexical form "bank". The pattern for instances of Synset is synsetId + lexical form of the first WordSense + lexical group symbol (n=noun, v=verb,a=adjective, s=adjective satellite and r=adverb). The first WordSense in the synset has the lexical form "bank". The pattern for URIs of WordSenses is the lexical form of its Word + the WordSense's lexical group + the sense number. Example:


For the URIs for Words we use the lexical form + the prefix "word-". For example:



Figure 1. The class hierarchy of the WordNet schema

PropertyDomainRange Prolog clause

synsetContainsWordSense Synset WordSense s
word WordSense Word s

lexicalForm Word xsd:string s
synsetId Synset xsd:string s
tagCount Synset xsd:integer s

gloss Synset xsd:string g
hyponymOf Synset Synset hyp
entails Synset Synset ent
similarTo Synset Synset sim
memberMeronymOf Synset Synset mm
substanceMeronymOf Synset Synset ms
partMeronymOf Synset Synset mp
classifiedByTopic Synset Synset cls
classifiedByUsage Synset Synset cls
classifiedByRegion Synset Synset cls
causes Synset Synset cs
sameVerbGroupAs Synset Synset vgp
attribute Synset Synset at
adjectivePertainsTo Synset Synset per
adverbPertainsTo Synset Synset per

derivationallyRelated WordSense WordSense der
antonymOf WordSense WordSense ant
seeAlso WordSense WordSense sa
participleOf WordSense WordSense ppl
frame VerbWordSense xsd:stringfr

classifiedBy Synset Synset cls
meronymOf Synset Synset mm,ms,mp

Figure 2. Overview of properties in the WordNet schema. The "Prolog clause" column indicates the Prolog clause(s) used to generate instances of the properties.

See Figure two for an overview of the properties. The figure is divided into four categories: properties that connect the main classes, properties that provide data in the form of XML Schema Datatypes, properties that represent WordNet relations between synsets, properties that represent relations between word senses, and finally two superproperties that were introduced for relationship properties. See Appendix D for a list of all relations. The URIs of the classes and properties in the schema have the pattern: base URI + property/class name. For example, the participleOf property has the URI:

Example queries

Here follow some typical queries that can be posed on the WordNet RDF/OWL once it is loaded into a triple store such as Sesame or SWI Prolog's Semantic Web library [@@REFS] [SWI Prolog, 2006]. The examples are given in SPARQL query language [SPARQL, 2005]. Which query language is available to a user depends on the chosen triple store.

When users download WordNet, they download a specific version of WordNet in RDF/OWL that has a version number that corresponds to the Princeton WordNet version on which it is based. To distinguish the different available versions, each version has a version-specific base URI, such as:

After downloading and loading WordNet in RDF/OWL into a triple store this version-specific base URI should be used when querying. The query examples below use version 2.0 as an example. See WordNet versions for more information.

The following queries for all Synsets that contain a Word with the lexical form "bank":

	PREFIX  wn: <http://wordnet.princeton.edu/wn20/>
	SELECT  ?aSynset
	WHERE   { ?aSynset wn:containsWordSense ?aWordSense .
		  ?aWordSense wn:word ?aWord .
		  ?aWordSense wn:lexicalForm  "bank"@en }	
Notice the addition of the language tag using "@en". This is necessary in all queries for strings. Queries without the correct language tag do not return results.

The following queries for all antonyms of a specific WordSense ("bank"):

	PREFIX  wn: <http://wordnet.princeton.edu/wn20/>
	SELECT  ?aWordSense
	WHERE   { wn:bank-noun-1 wn:antonymOf ?aWordSense }	

The following queries for all Synsets that have a hypernym that is similar to some other Synset:

	PREFIX  wn: <http://wordnet.princeton.edu/wn20/>
	SELECT  ?aSynset
	WHERE   { ?aSynset wn:hyponymOf ?bSynset .
	          ?bSynset wn:similarTo ?cSynset}	

Advanced features

Although WordNet is not a strict class hierarchy, it is possible to interpret it as such for certain types of applications. This is also possible with this version, see Advanced options.

The above section describes the Full version of RDF/OWL WordNet. There is also a Basic version for users who only require the Synsets for their application and wish to reduce the size of their triple store. See WordNet Basic and WordNet Full for more information.

3. Introduction to the WordNet datamodel

The core concept in WordNet is the synset. A synset groups words with a synonymous meaning, such as {car, auto, automobile, machine, motorcar}. Another sense of the word "car" is recorded in the synset {car, railcar, railway car, railroad car}. Although both synsets contain the word "car", they are different entities in WordNet because they have a different meaning. More precisely: a synset contains one or more word senses and each word sense belongs to exactly one synset. In turn, each word sense has exactly one word that represents it lexically, and one word can be related to one or more word senses.

There are four disjoint kinds of synset, containing either nouns, verbs, adjectives or adverbs. There is one more specific kind of adverb called an adjective satellite. Furthermore, WordNet defines seventeen relations, of which ten between synsets (hyponymy, entailment, similarity, member meronymy, substance meronymy, part meronymy, classification, cause, verb grouping, attribute) and five between word senses (derivational relatedness, antonymy, see also, participle, pertains to). The remaining relations are "gloss" (between a synset and a sentence), and "frame" (between a synset and a verb construction pattern). There is also a more specific kind of word. Collocations are indicated by hyphens or underscores (an underscore stands for a space character), e.g. mix-up and eye_contact.

4. Introduction to the WordNet RDF/OWL schema

The schema of the conversion has three main classes: Synset, Word and WordSense. Synset and WordSense have subclasses based on the distinction of lexical groups. For Synset this means subclasses NounSynset, VerbSynset, AdjectiveSynset (in turn subclass AdjectiveSatelliteSynset) and AdverbSynset. For WordSense this means subclasses NounWordSense, VerbWordSense, etcetera. Word has a subclass Collocation used to represent words that have hyphens or underscores in them. Word does not have subclasses such as VerbWord, because a word like "bank" is separate from its function as e.g. a verb or a noun. There is no representation for "all noun word senses with the lexical form 'bank'" and "all verb word senses with the lexical form 'bank'" in the original source, so there is no such class in the class hierarchy.

There are three kinds of properties in the schema. A first set of properties connects instances of the main classes together. The class Synset is linked to its WordSenses with the property synsetContainsWordSense, and WordSense to its Word with the property word. A second set of properties represents the WordNet relations such as hyponymy and meronymy. There are three kinds of relations: those that relate two Synsets to each other (e.g. hyponymOf), those that relate two WordSenses to each other (e.g. antonymOf) and a miscellaneous set (gloss and frame). See Conversion details for an overview of all relations. A third set of properties gives information on entities (they have XML Schema datatypes as their range such as xsd:string). Examples are synsetId that records the original ID given in Princeton WordNet to a synset, and the tagCount of a wordsense. The actual lexical form of a Word is recorded with the property lexicalForm. Each synset has an rdfs:label that is filled with the lexical form of the first word sense in the synset.

Major differences with previous versions

This conversion builds on three previous WordNet conversions, namely by:

  1. Dan Brickley
  2. Stefan Decker & Sergey Melnik
  3. University of Neuchatel
  4. University of Chile
To be more precise, the work done at University of Chile was done in parallel to the work of this TF. The major differences between this version and the ones listed above are that this version:
  1. does not model the hyponym hierarchy as a subclass hierarchy;
  2. it represents words and word senses as separate entities with their own URI which makes it possible to refer to them directly;
  3. contains all relations that are in Princeton WordNet;
  4. uses OWL to define inverse properties and to express restrictions on properties which may be used to check the correctness of the WordNet data.
More details can be found in Relation to previous versions. See Advanced options for a solution to use this version's hyponym hierarchy as a subclass hierarchy and WordNet Basic and WordNet Full for a short discussion on Point two.

5. Querying WordNet: offline and online

There are two ways to query RDF/OWL WordNet. The first option is to download the appropriate WordNet version (see WordNet Basic and WordNet Full and Choosing the appropriate WordNet version) and load it into local processing software such as Sesame [@@REF] or SWI-Prolog's Semantic Web library [SWI Prolog, 2006]. Query languages such as SPARQL [SPARQL, 2005] and Prolog programs may then be written to query the data.

Example SPARQL query on version 2.0 of RDF/OWL WordNet for all WordSenses which have a Word with the lexical form "bank":

	PREFIX    wn: <http://wordnet.princeton.edu/wn20/>
	SELECT  theWordSense
	WHERE   { theWordSense wn:word theWord .
		  theWordSense wn:lexicalForm  "bank"@en }	

The second option is to query the on-line version of WordNet by doing an HTTP GET on an already known WordNet URI such as http://wordnet.princeton.edu/wn/wn/bank-noun-1/. This HTTP GET request returns the Concise Bounded Description of the requested URI, which is an RDF graph that includes all statements in the whole WordNet RDF/OWL which have that URI as its subject (see [CBD, 2004] for details). This is a far less flexible approach because it is not possible to pose queries (e.g. a query for all synsets which contain the word "bank"). However, it does give a sensible set of triples to answer the question "tell me about this resource" if the user has no prior knowledge of this resource.

In version 2.0 of WordNet RDF/OWL, the HTTP GET on http://wordnet.princeton.edu/wn/wn/bank-noun-1/ returns the following triples (the Concise Bound Description):

	wn20:bank-noun-1	rdf:type			http://www.w3.org/2000/01/rdf-schema#Resource
	wn20:bank-noun-1	rdf:type			wn20:NounWordSense
	wn20:bank-noun-1	wn20:inSynset			wn20:107909067-depository_financial_institution-n
	wn20:bank-noun-1	wn20:word			wn20:bank
	wn20:bank-noun-1	wn20:derivationallyRelated	wn20:bank-v-3
	wn20:bank-noun-1	wn20:derivationallyRelated	wn20:bank-v-5
	wn20:bank-noun-1	wn20:derivationallyRelated	wn20:bank-v-6
	wn20:bank-noun-1	rdfs:label			"bank"@en
	wn20:bank-noun-1	wn20:tagCount			"883"@en	
Because this WordNet version does not have blank nodes and reified triples, the Consice Bounded Description of a the URI http://wordnet.princeton.edu/wn/bank-noun-1/ is the same as the result to following SPARQL query:
	SELECT http://wordnet.princeton.edu/wn20/bank-noun-1 ?p ?x
	WHERE {<http://wordnet.princeton.edu/wn20/bank-noun-1> ?p ?x}
Notice that if the base URI http://wordnet.princeton.edu/wn/ is used for the HTTP GET, then the base URI of the returned triples is different. This is because the request is forwarded by Princeton to the base URI of the newest WordNet version (see WordNet versions).

Different URIs for Synsets, WordSenses, Words

We have chosen to introduce identifiers for the instances of classes Synset, WordSense and Word. We use the base uri + a locally unique ID. Three kinds of entities need a URI: instances of the classes Synset, WordSense and Word. Instead of generating any unique ID we have tried to use IDs derived from information in the source and also tried to make them human-readable. Because the IDs have distinct syntactic patterns, it is easy to identify the type of the resource (Synset, WordSense or Word) by examining the URI. The patterns are described below.

Local IDs of Synset instances are composed of the synset ID, the lexical form of the first word sense in the synset and the lexical group symbol. Thus human readers know the lexical group of the word senses in the synset and has an idea about the kinds of words in the synset. Example:


For WordSenses the word + its lexical group + the sense number is used. Example:


For the URI for Words we use the lexical form, which is unique within English, plus the prefix "word-". For example:


The prefix is required to prevent clashes between the property and class names of the schema and the words. For example, the URIs for the class "Word" and the property "antonym" would be the same as the URIs for the words "Word" and "antonym". Another option would be to put the schema in a different namespace than the data, but that results in additional management for users and the maintainers of the WordNet RDF/OWL version. The prefix approach avoids this drawback.

Some words contain slashes which have been converted into underscores when generating URIs. This is done to prevent the slashes to be interpreted as the character used to separate hierarchical components in URIs [IETF, 2005]. For example, the URI for the word "read/write_memory" becomes:


This conversion uses "slash URIs" instead of "hash URIs". See Introducing URIs for Synsets, WordSenses, Words for more information.

6. WordNet Basic and WordNet Full

The complete WordNet in RDF/OWL version described here consists of different files and is over 150 MB uncompressed RDF/XML in size. The required memory footprint when loading all files into software such as SWI-Prolog's Semantic Web library may be double that amount (figures vary for different software). To mitigate memory shortage problems and/or improve query response times we have made a separate file for each WordNet relation. The required footprint can be dimished by loading only those files/relations that are required by the application at hand.

WordNet is often used for a task known as sense disambiguation: the annotation of lexical forms in texts with a synset's ID (or, on the Semantic Web, its URI) to record the meaning of the lexical form [@@REFS]. The disambiguation process consists of selecting the appropriate synset. In the sense disambiguation task (and others in which only the Synsets are of interest) the WordSenses and Words add memory footprint which may not be used. To keep the footprint small for such applications we provide a WordNet Basic version. This version consists of the synset file of the WordNet Full, an additional data file and a separate schema file. This last file contains one additional property called senseLabel (domain Synset and range xsd:string). It also omits classes and properties that are not used in the Basic version (e.g. WordSense and containsWordSense). The data file contains instances of the new property for each Synset in the synset file. The property value is filled with the lexical forms that are attached to Words in the Full version. When selecting candidate Synsets for a lexical form in a text one queries for senseLabels matching the lexical forms.

Like for WordNet Full, the Basic users can also limit the relations to those that are required for their task, with the caveat that the following relations are defined between WordSenses and are therefore useless to Basic users: derivational relatedness, antonymy, see also, participle, pertains to.

Each version has a separate RDF/OWL schema file. Although the same schema could be used for both versions because the Basic schema is a subset of the Full schema (apart from the additional property senseLabel), it may be confusing to have classes in the Basic schema which do not have instances. For clarity two separate schema files were made.

See also WordNet versions for a list of downloadable files.

7. WordNet versions

There are two choices concerning versioning which any new user of RDF/OWL WordNet has to make. First of all, one has to choose whether to use the Basic or Full version. Secondly, there are different versions published of Princeton WordNet and converted into RDF/OWL (version 2.0, version 2.1 etcetera). It should be prevented that an "old" and a "new" synset are collapsed into one synset by an RDF triple store because they have the same URI when using two versions in one store (e.g. because of legacy data mixed with data indexed with the newest WordNet version). If this does happen, the properties of the old and new synset are mixed, which is not appropriate (it becomes impossible to distinguish which property/value pair belongs to which version of the synset) To prevent this, each conversion published by the TF has a separate namespace. (Currently only version 2.0 is converted into RDF/OWL, but there will be more conversions available in the future.) A service at Princeton automatically redirects from the namespace

to the namespace of the newest version, e.g.
This allows users to keep working with the WordNet version for which they programmed their software (e.g. http://wordnet.princeton.edu/wn20/) regardless of changes in new versions. Therefore we recommend that programmers base their code on the version-specific base URI instead of the general namespace that redirects to the newest version-specific base URI.

When two different versions are to be used in concord, it may be necessary to establish a mapping between the synset for "financial institution" in the older and newer version. This can be a complex task because although the synset itself and its word senses may remain the same, the surrounding synsets may have changed, making it difficult to decide whether the two synsets are "the same" or not. Providing such mappings between synsets in different versions is out of the scope of this TF. It may also be unappropriate to provide such mappings because what constitutes a "correct" mapping may differ between applications.

See also Versioning and redirection strategy for more information on the redirection strategy.

Downloadable files

Below the files to download are listed for version 2.0 of WordNet RDF/OWL. Files for other versions can be found at @@URL. The files below use the version-specific base URI http://wordnet.princeton.edu/wn20/

WordNet 2.0 Full consists of the following three files plus any of the files that contain relations that are listed below.


WordNet 2.0 Basic consists of the following three files plus any of the files that contain relations except those that contain relations between WordSenses


Files that contain relations between Synsets: hyponymy, entailment, similarity, member meronymy, substance meronymy, part meronymy, classification, cause, verb grouping, attribute


Files that contain relations between WordSenses: derivational relatedness, antonymy, see also, participle, pertains to


Files that contain other relations: gloss and frame


8. Advanced options

OWL features

The basic modeling of this WordNet version has been done in RDFS (classes, subclassing and property definitions). Additional statements have been added to the schema using OWL [OWL Overview, 2004] to provide more semantics to OWL users. The OWL primitives that have been used are: The first three constructs enable e.g. checking correctness of the data (which is not necessary for users and these statements are ignored by software that does not support OWL DL reasoning [@@REF], which includes Jena, Sesame and SWI-Prolog's SW library [@@REFS]). The last two statements can be ignored by RDFS users while keeping the following in mind:
  1. for transitive properties RDFS users have to construct the transitive closure of the graph themselves or write software that deals with transitivity while querying the data;
  2. the WordNet data does not explicitly contain the inverse of e.g. hyponymOf. The inverse statement is only implied with the OWL statement hyponymOf owl:inverseOf hypernymOf. In other words, querying the hypernymOf relation will return no results when using software that is not OWL-aware. Therefore, RDFS users should not use the inverse properties because they do not yield query results. Because querying for X hypernymOf Y is just a syntactic variant of querying for Y hyponymOf X RDFS users do not have less information than OWL users. See Conversion details for a list of the inverse properties.

Using WordNet as a class hierarchy

For some purposes it may be useful to treat WordNet as a class hierarchy, where each (Noun)Synset is an rdfs:Class and the hyponym relationship is interpreted as the rdfs:subClassOf relationship. Do note that this is not a correct interpretation, e.g. the synset denoting the city "Paris" is a hyponym of the synset denoting "capital", but "Paris" should be an instance of "capital" instead of a subclass. Therefore this interpretation was not added in this version. Users that wish to interpret WordNet as a class hierarchy may add the following triples to their local triple store:

	<rdf:Description rdf:about="&wn;Synset">
		<rdfs:subClassOf rdf:resource="&rdfs;Class" />

	<rdf:Description rdf:about="&wn;hyponymOf">
		<rdfs:subPropertyOf rdf:resource="&rdfs;subClassOf" />

The first statement makes each instance of Synset an instance of class (effectively, they are both an instance and a class), while the second makes the hyponym property a subproperty of the subclass relationship. This approach has been successfully used in [@@REF MIA tool?] for creating a subclass hierarchy so that it can be displayed in standard subclass browsing software.

Appendix A: Requirements

Requirements that were observed while designing the RDF/OWL conversion are:

  1. it should be a full conversion (i.e. be as complete as possible);
  2. it should be convenient to work with;
  3. it should provide OWL semantics while still being intepretable by pure RDFS tools (i.e. OWL semantics are provided but can be ignored).

The requirement of completeness has been fullfilled by carefully analyzing the conceptual model of WordNet as well as its data. Existing versions and their documentation were used to compare with our analyses. Some results of the analyses are documented here in Introduction to the WordNet datamodel, Relation to previous versions and Conversion details.

To satisfy the requirement of convenience we have provided:

To satisfy the requirement of providing OWL semantics while still being interpretable by pure RDFS tools we have:

Appendix B: Versioning and redirection strategy

As already described in @@TODO each WordNet conversion published by the TF has a separate base URI to prevent version clashes. An HTTP GET request for URIs with the following base URI are redirected to the URI of the newest version:
For example, requesting
is redirected with a 303 response code to e.g.
At this point the request should return a graph that is deemed an appropriate response to this request, for which we have chosen the Concise Bounded Description. A straightforward way to implement the response is to have a server-side script that collects all the relevant statements from the WordNet RDF/OWL source files. To relieve Princeton of implementing the server-side scripting Princeton responds to the HTTP GET on
with another 303 redirect to the following URI which is maintained by @@INSTITUTE:
... @@TODO insert base URI of INSTITUTE... /wn20/bank-noun-1/ 
There the server-side scripting is performed and the resulting RDF graph returned to the original requesting server.

Appendix C: Overview of the WordNet Prolog distribution

The Prolog distribution consists of eighteen files: one file that represents synsets and then one for each of the seventeen relationships. The file with synsets contains Prolog facts such as:


Each fact denotes exactly one word sense. The word senses with the same synset ID together form a synset. The two facts above together form the synset with the ID 100003009. The arguments of the clause are the following:

  1. Synset ID: unique number for a synset. If ID starts with 1: synset contains only nouns 2: verbs 3: adjectives 4: adverbs
  2. Word number: provides a number for the word sense within the synset (not ordered)
  3. Lexical form: a string, possibly containing a hyphen (connecting collocated words), an underscore (stands for a space between two collocated words), and escape sequences to encode diacritics;
  4. Sense type: value is one of the set {n, v, a, s, r} which stands for noun, verb, adjective, adjective satellite and adverb, respectively;
  5. Sense number: gives a number to the sense in which the lexical form is used that is unique for the sense type (e.g. there are ten different nouns with the lexical form "bank" numbered 1 to 10; there are eight different verbs with the lexical form "bank" numbered 1 to 8;
  6. Tag count: frequency of this word sense measured against a text corpus.

Relations are identified by lists of facts like the following:


The first identifies a hyponymy relation between two synsets, the second part meronymy between synsets, the third antonymy between two word senses (second and fourth argument are word numbers). The documentation defines characteristics for each relationship, such as (anti-)symmetry, inverseness and value restrictions on the lexical groups (e.g. nouns, verbs) that may appear in relations. Most of these informally stated requirements can be formalized in OWL and are present in the conversion.

Investigation of the source files and documentation revealed several conflicts between source and documentation. For example, the order of synset arguments of the member meronym relation seems to be different than the documentation asserts. For each conflict we have proposed a solution. Details of the conversion can be found in Conversion details.

Appendix D: Conversion details

The following lists the definition of each Prolog clause as stated in the Prolog distribution's documentation, followed by notes on the meaning of the clause, an example, the mapping to RDF/OWL, OWL characteristics defined for the property, its inverse property and possible conflicts between documentation and source files.

The quotes from the Prolog documentation of Princeton WordNet contain Prolog variables written in lower-case (should start with upper-case letter) and sometimes two variables in one clause that aare spelled exactly the same (should have different spelling because two different variables are intended). This has been corrected in the quotes shown below from that documentation for improved clarity.


A s operator is present for every word sense in WordNet. In wn_s.pl, W_num specifies the word number for word in the synset.

The arguments of the clause are the following:

  1. Synset ID: unique number for a synset. If ID starts with 1: synset contains only nouns 2: verbs 3: adjectives 4: adverbs
  2. Word number: provides a number for the word sense within the synset (not ordered)
  3. Lexical form: a string, possibly containing a hyphen (connecting collocated words), an underscore (stands for a space between two collocated words), and escape sequences to encode diacritics;
  4. Sense type: value is one of the set {n, v, a, s, r} which stands for noun, verb, adjective, adjective satellite and adverb, respectively;
  5. Sense number: gives a number to the sense in which the lexical form is used that is unique for the sense type (e.g. there are ten different nouns with the lexical form "bank" numbered 1 to 10; there are eight different verbs with the lexical form "bank" numbered 1 to 8;
  6. Tag count: frequency of this word sense measured against a text corpus.

Each s(...) represents one word sense. All s(...) with the same ID together form the whole synset.

Maps to:


The g operator specifies the gloss for a synset.

Gloss is a string.

Maps to: wn:gloss(Synset_ID, Gloss)


The hyp operator specifies that the second synset is a hypernym of the first synset. This relation holds for nouns and verbs. The reflexive operator, hyponym, implies that the first synset is a hyponym of the second synset.

Example: hyp(100003226,100003009). [organism, living_thing]. With "reflexive" inverseness is meant.

Maps to: wn:hyponymOf(Synset_ID_A, Synset_ID_B)

Property characteristics: Transitive

Inverse property: wn:hypernymOf

Superproperty: rdfs:comment


The ent operator specifies that the second synset is an entailment of first synset. This relation only holds for verbs.

Example: ent(200001740,200004923) [breathe, inhale], ent(200004701,200004127) [sneeze, exhale]

Maps to: wn:entails(Synset_ID_A, Synset_ID_B)

Property characteristics: Transitive

Inverse property: wn:entailedBy


The sim operator specifies that the second synset is similar in meaning to the first synset. This means that the second synset is a satellite the first synset, which is the cluster head. This relation only holds for adjective synsets contained in adjective clusters.

Maps to: wn:similarTo(Synset_ID_A, Synset_ID_B)

mm(Synset_ID_A, Synset_ID_B).

The mm operator specifies that the second synset is a member meronym of the first synset. This relation only holds for nouns. The reflexive operator, member holonym, can be implied.

Example: mm(100006026,107463651). [Person, People]. With "reflexive" inverseness is meant.

Documentation seems to be wrong here. Arguments are the other way around in Prolog source.

Maps to: wn:memberMeronymOf(Synset_ID_A, Synset_ID_B)

Inverse property: wn:memberHolonymOf

Superproperty: wn:meronymOf

ms(Synset_ID_A, Synset_ID_B).

The ms operator specifies that the second synset is a substance meronym of the first synset. This relation only holds for nouns. The reflexive operator, substance holonym, can be implied.

Documentation seems to be wrong here. Arguments are the other way around in Prolog source.

Example: ms(102073849,107118730). [oxtail, oxtail soup]. With "reflexive" inverseness is meant.

Maps to: wn:substanceMeronymOf(Synset_ID_A, Synset_ID_B)

Inverse property: wn:substanceHolonymOf

Superproperty: wn:meronymOf

mp(Synset_ID_A, Synset_ID_B).

The mp operator specifies that the second synset is a part meronym of the first synset. This relation only holds for nouns. The reflexive operator, part holonym, can be implied.

Documentation seems to be wrong here. Arguments are the other way around in Prolog source.

Example: mp(100004824,100003226). [cell, organism]

Maps to: wn:partMeronymOf(Synset_ID_A, Synset_ID_B)

Inverse property: wn:partHolonymOf

Superproperty: wn:meronymOf

der(Synset_ID_A, Synset_ID_B).

The der operator specifies that there exists a reflexive lexical morphosemantic relation between the first and second synset terms representing derivational morphology.

Documentation seems to be wrong here. The pattern is der(Synset_ID_A,Nr1,Synset_ID_B,Nr2). It seems that the numbers refer to WordSenses within the synsets. "Reflexive" probably means symmetric. Not sure if there are "doubles" in the prolog source like for other predicates (can be excluded when creating triples, but it produces the same triple so does not matter - one could argue whether to create the triple or not when its symmetric counterpart is missing in the source).

Example: der(100002645,3,201420446,4). [unit, unify]

Maps to: wn:derivationallyRelated(WordSense_ID_A, WordSense_ID_B)

Property characteristics: Symmetric

cls(Synset_ID_A, Synset_ID_B,Class_type).

The cls operator specifies that the first synset has been classified as a member of the class represented by the second synset.

Class_type: t:topical, u:usage, r:regional

Example: cls(100004824,105681603,t). [cell, biology]

Maps to:

Inverse property: @@TODO

Superproperty: classifiedBy

cs(Synset_ID_A, Synset_ID_B).

The cs operator specifies that the second synset is a cause of the first synset. This relation only holds for verbs.

cs(200018968,200014429). [cause_to_sleep, sleep/catch_some_Z's]
cs(200020073,200019883). [keep_up, sit_up/stay_up]
cs(200020689,200014429). [anaestesize/put_to_sleep/... , slumber/sleep/catch_some_Z's]

Documentation seems to be wrong here. Arguments are the other way around in Prolog source (e.g. anaethesize causes to sleep).

Maps to: wn:causes(A,B)

Inverse property: wn:causedBy

vgp(Synset_ID_A, Synset_ID_B).

The vgp operator specifies verb synsets that are similar in meaning and should be grouped together when displayed in response to a grouped synset search.

Documentation is unclear. The actual format in the file is vgp(sidA, W_num1, sidB, W_num2). But in wn_vgp.pl the W_num's are always '0'. This seems to mean that the relation holds for all the words in the synset, i.e. the relation holds between synsets.

It seems that the file contains all the symmetric definitions, i.e. vgp(A,0,B,0) means that the file also contains vgp(B,0,A,0). One of the two can be ignored. No problem if the conversion code does not do this, because the asserted double triple is exactly the same. See comment under "der".

Maps to: wn:sameVerbGroupAs(A,B)

Property characteristics: Symmetric

at(Synset_ID_A, Synset_ID_B).

The at operator defines the attribute relation between noun and adjective synset pairs in which the adjective is a value of the noun. For each pair, both relations are listed (ie. each synset_id is both a source and target).

Example: at(101028287,300455926). [mercantilism, commercial]

The inverse version is also listed, so both at(A,B) and at(B,A) are in the source file.

Maps to:

Inverse property: wn:attributeOf


The ant operator specifies antonymous words. This is a lexical relation that holds for all syntactic categories. For each antonymous pair, both relations are listed (ie. each Synset_ID,W_num pair is both a source and target word.)

The synset_id + W_num identifies a word sense.

Maps to: wn:antonymOf(WordSense1, WordSense2)

@@TODO: this seems symmetric relation, but inverse is specified in the schema


The sa operator specifies that additional information about the first word can be obtained by seeing the second word. This operator is only defined for verbs and adjectives. There is no reflexive relation (ie. it cannot be inferred that the additional information about the second word can be obtained from the first word).

The synset_id + W_num identifies a word sense. The statement "no reflexive relation" probably means that the relation is not symmetrical.

Maps to: wn:seeAlso(WordSense1, WordSense2)

@@TODO: is this a subproperty of rdfs:seeAlso?


The ppl operator specifies that the adjective first word is a participle of the verb second word.

The Synset_ID + W_num identifies a word sense.

Maps to: wn:participleOf(WordSense1, WordSense2)

Inverse property: wn:participle


The per operator specifies two different relations based on the parts of speech involved. If the first word is in an adjective synset, that word pertains to either the noun or adjective second word. If the first word is in an adverb synset, that word is derived from the adjective second word.

Maps to:

Inverse property: @@TODO


The fr operator specifies a generic sentence frame for one or all words in a synset. The operator is defined only for verbs.

Maps to: wn:frame(VerbWordSense, xsd:string)

Language tag

It is good practice to use the xml:lang attribute to specify the language in which literals are written. Currently all the RDF files are given a language tag on the document level (in RDF tag) for this purpose.

Use of rdfs:label

It is good practice to give labels to instances, in this case of Word, WordSense and Synset. For Word this is solved by adding wn:lexicalLabel rdfs:subpropertyOf rdfs:label. For WordSense the contents for the rdfs:label is chosen by copying the contents of the wn:lexicalLabel of the Word. For Synset the first word (according to W_num) is chosen as the label. As there is no preferred status of one WordSense within a Synset (the W_num does not seem to have a specific meaning) this is an arbitrary choice.

Conversion program

The conversion file can be found at: http://www.cs.vu.nl/~mark/wn/convertwn.pl. The source code contains instructions for use.

The conversion program makes use of the open-source SWI-Prolog programming language and its Semantic Web library.

The program can be used for conversion of new Princeton WordNet versions to RDF/OWL as long as the format and semantics of the Prolog source files are not changed.

Caveat: the Prolog source does not contain the Frame definitions. [@@TODO explanation on how to convert Frames part]

Appendix E: Possible mappings to SKOS

"SKOS Core provides a model for expressing the basic structure and content of concept schemes such as thesauri, classification schemes, subject heading lists, taxonomies, 'folksonomies', other types of controlled vocabulary, and also concept schemes embedded in glossaries and terminologies." [SKOS Core Guide, 2005]. Because WordNet may be considered a complex kind of thesaurus, it is natural to try to represent it using SKOS. This version has not concentrated on such a representation, but we list some options for a future version in the SKOS schema.

The central class of SKOS is skos:Concept. Its instances are connected using the skos:broader/skos:narrower properties. To each concept one can attach exactly one skos:prefLabel and zero or more skos:altLabels.

The term "mapping" can have two meanings in this context. In the first meaning, the schema of WordNet (i.e. its classes and properties) is mapped to the SKOS classes and properties using rdfs:subClassOf and rdfs:subPropertyOf. This is only possible if WordNet is a strict specialization of SKOS. In the second meaning, a set of rules is specified that converts WordNet into instances of the SKOS schema. This is a more flexible approach and allows for more complex mappings (mappings other than strict specialization).

A first choice concerns what WordNet class(es) to map to skos:Concept.

@@TODO. Should all WN classes be regarded as skos:COncepts? Granularity difference. Also difficult choice regarding what to map to skos:prefLabel/skos:altLabel. WordSenses have equal status in WN, no one preferred over the other. If you choose not to make all classes of WN subclass of skos:Concept then you lose information. So seems not possible to define WN as strict specialization of SKOS.

Appendix F: Relation to previous versions

This conversion builds on three previous WordNet conversions, namely by:

  1. Dan Brickley;
  2. Stefan Decker & Sergey Melnik;
  3. University of Neuchatel;
  4. University of Chile.

In this document we have not tried to come up with a completely new conversion. Rather, we have studied these existing conversions and filled in some of the gaps. Here are some of the typical differences w.r.t the existing conversions:

  1. Brickley represents the hyponym relationship as a rdfs:subClassOf. This is an attractive interpretation, but we argue that not all hyponyms can be interpreted in that way. An attempt to provide a consistent semantic translation of hyponymy has been done [Gangemi, 2003], but in this work we do not attempt a semantic translation of the intended meaning of WordNet relations, while we aim at a logically valid translation of the WordNet data model into RDF/OWL.
  2. We represent Words and WordSenses URIs. The conversion by the University of Neuchatel represents Words as URIs, but not word senses.
  3. We have split some relations into sub-relations. For example, the Prolog relationship per denotes (a) a relation between an adjective and a noun or adjective or (b) a relation between an adverb and an adjective. We convert per into adjectivePertainsTo and adverbPertainsTo.

The conversion of Neuchatel is close to the one in this document. The Neuchatel conversion omits relations "derivation" and "classification". It does not provide sub-relations and inverses for all relationships. Both conversions differ from the other two in that they provide OWL extensions in which property characteristics such as symmetry, inverseness and value restrictions are defined.

The motivation for representing Words separately is that words are language-specific. The word "chat" in english has a different meaning than the same lexical form in French. The French word does have a lexico-semantic similarity to the English word "cat". For future integration of WordNet with other multilingual resources it is essential that one can refer to two different words with the same lexical form, or two words with a different lexical form but similar meanings. Future integration of WordNet with e.g. WordNets in other languages is possible because each Word has its own URI in the WordNet namespace. The WordNet word "cat" can be linked to the French word "chat" contained in a French WordNet by linking the URIs from the separate namespaces to each other in an appropriate manner, e.g. with a property that represents a lexico-semantic relationship between words.

The conversion by University of Chile was made in parallel to the efforts of this TF (see e.g. this mail on the public-swbp-wg@w3c.org mail archive). It has almost the same class hierarchy as this conversion; only the class Collocation is not present. The schema is modelled in RDFS, so it does not define restrictions, disjointness axioms, property characteristics and inverse properties.

Appendix G: Introducing URIs for Synsets, WordSenses, Words

Besides introducing WordSenses and Words as separate entities, we also introduce URIs for them (i.e. they are not labels or blank nodes). First we discuss the motivation for representing them as instances of a class with URIs instead of as labels or blank nodes. Then we discuss how the URIs for instances of WordSense, Word and Synset are generated during conversion.

In some previous conversions WordSenses or Words did not have a URI. A possible motivation for this choice is that the source does not provide unique identifiers for them and tasks such as sense disambiguition does not require them. Not having URIs for WordSenses makes it impossible to refer to WordSenses directly and to use them e.g. for annotation. We have chosen to introduce WordSenses as separate entities with URIs to enable such applications. A similar argument holds for Words: not having URIs for them makes it impossible to refer to them directly. Having URIs also makes it possible to integrate Princeton WordNet in RDF/OWL with other WordNets in RDF/OWL. For example, it enables stating relationships between e.g. the WordNet Word "chat" and "chat" in a French WordNet. Although integration is not part of the activities of this TF, it does aim to make it possible in the future. Therefore Words are given their own URI.

Three kinds of class instances need a URI: instances of the classes Synset, WordSense and Word. Instead of generating any unique ID we have tried to use IDs derived from IDs in the source and also tried to make them human-readable.

For the local ID of Synsets we have chosen the synset identifier provided in the source. For human readability we add two redundant elements: the word of the first WordSense in the synset and the lexical group symbol. Example:


Note that because the synset ID is now incorporated in the Synset URI, an application can only retrieve the ID by parsing the URI. To circumvent this awkward parsing, we introduce a property wn:synsetId for Synset to store the ID in.

There are two straightforward options for the local ID that make a WordSense unique within WordNet. Firstly, the combination of synset ID + sense number. Secondly, the first word in the synset + lexical group + sense number. We chose the second option as it is more readable. Example:


For the URIs for Words we use the lexical form + the prefix "word-". For example:


The prefix is necessary to prevent URI clashes with entities in the schema (e.g. the URI for property "antonym" or the class "Word" would clash with those for the lexical forms). Another solution would be to place the schema in a separate namespace, but it may become unclear which schema namespace belongs to which data namespace. Having one namespace per WordNet RDF/OWL version does not have this drawback.

Disallowed characters in URIs and diacritics

@@TODO after producing new Prolog conversion program ... replace slashes in words with underscore ... handle diacritics

Hash versus slash URIs

There are two options in formatting the relationship between the namespace and the local part, usually termed "hash" URIs and "slash" URIs after the symbol used to connect the two parts. The following gives an example of each for the noun-synset "bank":
The disadvantage of hash URIs is that when a HTTP GET is done (e.g. for the first example above) the browser will return the whole document located at http://wordnet.princeton.edu/wn. The reason for this is that servers do not receive the fragment identifier. Because WordNet is very large this is not a desirable option. (There is a work-around defined in [URI QA, 2004] that utilizes a special HTTP message header, but this would require a commitment from both client and server to use this special format.) The alternative is to use slash URIs. This choice implies that a decision needs to be made on which statements the server should return when an HTTP GET is done for resources with a URI such as http://wordnet.princeton.edu/wn/107909067-bank-n/. [@@REFS for def of hash/slash URIs and the frag id problem] Possible choices are: The difference between the two last ones is that the Symmetric CBD not only includes statements for which the URI is the subject, but also those for which the URI is the object. We have chosen for the CBD of the URI because it "constitutes a reasonable default response to the request 'tell me about this resource'" [CBD, 2005].

Appendix H: Open Issues

Questions regarding class hierarchy

W_num and sense_number

Each WordSense in a Synset has a "W_num" (starting from 1). It seems that this is not essential ordering information (i.e. only used to distinguish between word senses in the prolog source), so it has not been included in the conversion. Similar point for the sense_number in the prolog source.

Have to check with Princeton if indeed this information is not vital and also check with user community if they are not using these numbers.

Generating instances of symmetric properties

The Prolog source sometimes contains symmetrical pairs, e.g. the source file for antonyms should contain ant(A,B) but also ant(B,A) according to the documentation. However, the conversion program finds clauses where this is not the case. Currently the program does NOT add an antonym in the RDF for such cases.

Need to check with Princeton if these are either omissions or errors.


A natural extension of this work would be to integrate the OWL model with LMF (Lexical Markup Framework) under development by the ISO TC37/SC4/WG4.

Appendix I: Change Log since 17 October

Appendix J: References

[Brickley, 1999] D. Brickley. Message to RDF Interest Group: "WordNet in RDF/XML: 50,000+ RDF class vocabulary". http://lists.w3.org/Archives/Public/www-rdf-interest/1999Dec/0002.html See also http://xmlns.com/2001/08/wordnet/.

[CBD, 2005] CBD - Concise Bounded Description W3C Member Submission 3 June 2005; http://www.w3.org/Submission/2005/SUBM-CBD-20050603/

[Decker & Melnik] S. Decker and S. Melnik. WordNet RDF representation. http://www.semanticweb.org/library/

[Fellbaum, 1998] C. Fellbaum. WordNet: An Electronic Lexical Database. MIT Press, 1998.

[Gangemi, 2003] A. Gangemi, N. Guarino, C. Masolo, and A. Oltramari. Sweetening WORDNET with DOLCE. AI Magazine, 24(3):13-24, 2003.

[Graves, 2005] Alvaro Graves http://www.dcc.uchile.cl/~agraves/wordnet/

[OWL Overview, 2004] Deborah L. McGuinness, Frank van Harmelen (eds.). OWL Web Ontology Language Overview, W3C Recommendation 10 February 2004; http://www.w3.org/TR/owl-features/

[SKOS Core Guide, 2005] Alistair Miles and Dan Brickley (eds). SKOS Core Guide, W3C Working Draft 2 November 2005; http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102

[SPARQL, 2005] SPARQL Query Language for RDF W3C Working Draft 23 November 2005; http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/

[SWI Prolog, 2006] http://www.swi-prolog.org/

[University of Neuchatel] WordNet OWL Ontology; http://taurus.unine.ch/GroupHome/knowler/wordnet.html

[URI QA, 2004] The URI Query Agent Model - A Semantic Web Enabler; http://sw.nokia.com/uriqa/URIQA.html

[IETF, 2005] The Internet Engineering Task Force. Uniform Resource Identifier (URI): Generic Syntax http://www.ietf.org/rfc/rfc3986.txt

$Revision: 1.3 $ of $Date: 2006/04/12 14:01:28 $