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 queried for use 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/.

Comments on this document are encouraged and may be sent to
public-swbp-wg@w3.org;
please include the text "comment" in the
subject line. All messages received at this address are viewable
in a public archive.

At the time of publication the charter of the Semantic Web Best
Practices and Deployment Working Group is expiring and no chartered
group has been proposed to continue further work on this document.
The Working Group does recognize that feedback on this document
may lead to suggestions for further work. The current Working
Group is not placing this work on the
W3C Recommendation Track.

The URIs specified in this document for WordNet terms are served by
W3C in accordance with its resource persistence
policy. Refer
to Appendix I Open Issues for expectations regarding Princeton URIs
for these resources.

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.

Acknowledgements

The following people have reviewed this document
and provided valuable advice:
Jeremy Carroll,
Brian McBride,
John McClure,
Benjamin Nguyen and
Jacco van Ossenbruggen.
The following people have provided valuable advice through
the best practices mailing list and personal correspondence
with the editors:
David Booth,
Dan Connolly
Jeremy Carroll
Kjetil Kjernsmo,
Michel Klein,
Peter Mika,
Alistair Miles,
Steve Pepper,
Jacco van Ossenbruggen and
Ralph Swick.
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.
Special thanks to Ralph Swick for help in
generating CBDs and setting up this conversion in W3C
webspace.
We also thank the MultimediaN e-Culture team,
in particular Jan Wielemaker, for important usage comments.

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.
The W3C hosts the conversion of version 2.0
of Princeton WordNet at the following URI:

Guide to the reader

This document is composed of three parts. The first part (Section two)
has three subsections.
The first subsection 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. The second subsection provides an
Introduction to the WordNet RDF/OWL schema.
Those who are not familiar with WordNet should read the third subsection:
Introduction to the WordNet datamodel,
before reading the Primer.
The second part of this document consists of Sections three and four 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, versioning strategy and
open issues.

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:

rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns

rdfs: http://www.w3.org/2000/01/rdf-schema

owl: http://www.w3.org/2002/07/owl

xsd: http://www.w3.org/2001/XMLSchema

wn20instances: http://www.w3.org/2006/03/wn/wn20/instances/

wn20schema: http://www.w3.org/2006/03/wn/wn20/schema/

2. Introduction to WordNet in RDF/OWL

Primer to using RDF/OWL WordNet

WordNet can either be downloaded and queried from any triple store the user
wishes to use, or it can be queried online.
All files of version 2.0 can be downloaded as one archive file from the
following location: http://www.w3.org/2006/03/wn/wn20/download/.
For
information on advanced possibilities (e.g. for reducing the size of WordNet)
see WordNet Basic and WordNet Full and
Advanced options. WordNet can also be queried online
by performing HTTP GETs on the URIs described below.

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

http://www.w3.org/2006/03/wn/wn20/instances/synset-bank-noun-2

is a NounSynset. This NounSynset contains a WordSense which
is the first sense of the word "bank".
The pattern for instances of Synset is: wn20instances: + synset- + %lexform%- + %type%- + %sensenr%.
The %lexform% is the lexical form of the first WordSense of the Synset (the first
WordSense in the Princeton source as signified by its "wordnumber",
see Overview of the WordNet Prolog distribution).
The %type% is one of noun, verb, adjective, adjective satellite and adverb.
The %sensenr% is the number of the WordSense that is contained in the synset.
This pattern produces a unique URI because the WordSense uniquely identifies
the synset (a WordSense belongs to exactly one Synset).
The pattern for
URIs of WordSenses is the same, except that "synset" is replaced for
"wordsense". Example:

http://www.w3.org/2006/03/wn/wn20/instances/wordsense-bank-noun-1

The pattern for Words is: wn20instances: + word- + %lexform%. The %lexform%
is the actual lexical form of the Word.
For example:

http://www.w3.org/2006/03/wn/wn20/instances/word-bank

Lastly, the classes and properties of the schema also have a pattern,
namely wn20schema: + %ID%, where the %ID% is the name
of the property or class. For example, the URI for the participleOf property is:

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.

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 SWI Prolog's
Semantic Web library [SWI Prolog, 2006]
or Sesame [Broekstra et al., 2002].
The examples are given in SPARQL query
language [SPARQL, 2005]. Which query
language is available to a user depends on the chosen triple store.

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

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.

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 containsWordSense,
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:

The work done at the University of Chile
which also resulted in a conversion 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:

does not model the hyponym hierarchy as a subclass hierarchy;

it represents words and word senses as separate entities with
their own URI which makes it possible to refer to them directly;

contains all relations that are in Princeton WordNet;

provides OWL semantics in the form of inverse properties, definition
of property characteristics (e.g. Symmetry) and
property restrictions on classes.

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 adjective 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.

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://www.w3.org/2006/03/wn/wn20/instances/wordsense-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://www.w3.org/2006/03/wn/wn20/instances/wordsense-bank-noun-1
returns the following triples (the Concise Bound Description):

Because this WordNet version does not have blank nodes and reified triples,
the Consice Bounded Description of a the URI
http://www.w3.org/2006/03/wn/wn20/instances/wordsense-bank-noun-1
is the same as the result of the following SPARQL query:

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
(cf. [Ide and Véronis, 1998]).
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.

Downloadable files

Below the files to download are listed for version 2.0 of WordNet RDF/OWL.
Alternatively, an archive file for both Full and Basic versions are available
from the following location:
http://www.w3.org/2006/03/wn/wn20/download/.

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

4. 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:

owl:allValuesFrom restrictions (e.g. to define that AdjectiveSynsets only containWordSenses from the class AdjectiveWordSense)

owl:someValuesFrom restrictions (e.g. to define that each Word has at least one value for the property sense from the class WordSense);

owl:TransitiveProperty statements (e.g. to define that entails is a transitive relation;

owl:inverseOf statements (e.g. to define that hypernymOf is an inverse of hyponymOf.

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.
The last two statements can be ignored by RDFS users
while keeping the following in mind:

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;

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:

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 [Wielemaker et al., 2003]
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:

it should be a full conversion (i.e. be as complete as
possible);

it should be convenient to work with;

it should provide OWL semantics while still being
intepretable by pure RDFS tools (i.e. OWL semantics are
provided but can be ignored).

URIs for all entities (in particular WordSenses and Words)
so that they are directly accessible;

human-readable URIs;

a Basic and Full version;

separate files so only the necessary data for the application
at hand needs be loaded;

an on-line service that returns the Concise Bounded Description
of any WordNet URI.

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

provided the appropriate owl:disjointFrom statements;

provided relevant OWL restrictions for each class;

defined each class as being both of rdf:typeowl:Class
as well as rdfs:Class;

defined each property as an rdf:Property as well as
either owl:DatatypeProperty or owl:ObjectProperty;

defined an owl:inverse for each property;

defined the relevant property characteristics
(e.g. owl:TransitiveProperty) for each property.

Appendix B: Versioning and redirection strategy

The material for this Appendix should address how new versions should be treated,
how they can be accessed and what their relationship towards other versions i.
How this can be done is still under discussion. See Issues,
whereto the material that was present here in the previous version of this document
has been moved.
@@TODO

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:

Sense type: value is one of the set {n, v, a, s, r} which stands for
noun, verb, adjective, adjective satellite and
adverb, respectively;

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;

Tag count: frequency of this word sense measured against a text corpus.

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
are 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.

s(Synset_ID,W_num,Word,Ss_type,Sense_number,Tag_count).

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.

Word number: provides a number for the word sense within the synset
(not ordered)

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;

Sense type: value is one of the set {n, v, a, s, r} which stands for
noun, verb, adjective, adjective satellite and
adverb, respectively;

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;

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.

g(Synset_ID,Gloss).

The g operator specifies the gloss for a synset.

Gloss is a string.

Maps to: wn:gloss(Synset_ID, Gloss)

hyp(Synset_ID_A,Synset_ID_B).

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.

sim(Synset_ID_A,Synset_ID_B).

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.

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.

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:

if synset A is a noun (so B is adjective):
wn:attribute(Synset_ID_A,Synset_ID_B)

if synset A is adjective: wn:attribute(Synset_ID_B,Synset_ID_A)

Inverse property: wn:attributeOf

ant(Synset_ID_A,W_num_1,Synset_ID_B,W_num_2).

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)

Property characteristics: Symmetric

sa(Synset_ID,W_num,Synset_ID,W_num).

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)

ppl(Synset_ID,W_num,Synset_ID,W_num).

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

per(Synset_ID_A,W_num,Synset_ID_B,W_num).

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.

Documentation seems to be wrong here. The relation
holds between wordsenses, not words. We also split the
relation into two properties, as the documentation already
indicates.

Maps to:

A is adjective(satellite), B is noun or
adjective(satellite): wn:adjectivePertainsTo(Synset_ID_A,Synset_ID_B)

A is adverb, B is adjective(satellite):
wn:adverbPertainsTo(Synset_ID_A,Synset_ID_B)

Inverse property: @@TODO

fr(Synset_ID,F_num,W_num).

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

Example:
fr(200610468,8,1).

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

The Synset_ID and W_num together identify a
VerbWordSense that is associated with a particular sentence in
which the verb can be filled in. If the W_num is zero, the sentence
applies to all senses in the Synset. In that case we generate a
wn:frame for each sense in the Synset.

A problem in conversion of this Prolog file is
that the actual sentences are only identified by a number (F_num), and
not present in the actual source. The actual sentences and their number
(F_num) are present in the Unix version of Princeton WordNet, in
a file called frames.vrb. Two example lines (there are 35 lines)
from that file: "26 Somebody ----s that CLAUSE",
"27 Somebody ----s to somebody". We have converted these lines into
a Prolog clause sen(F_Num, String) and stored them in a
file sen.pl, to be able to do the conversion.

Additional properties

The following additional superproperties have been added to the schema
for querying convenience:

meronymOf

Subproperties: partMeronymOf, memberMeronymOf, substanceMeronymOf

Inverse: wn:holonymOf

classifiedBy

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:lexicalForm rdfs:subpropertyOf rdfs:label.
For WordSense the contents for the rdfs:label is chosen by
copying the contents of the wn:lexicalForm 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 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.

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, rdfs:subPropertyOf,
owl:equivalentClass and owl:equivalentProperty.
This is only possible without loss of information if the WordNet schema is equal
to or 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 property/class equalities and strict specialization).

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

[@@TODO. See Appendix "Issues"]

Appendix F: Relation to previous versions

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

A fourth conversion by University of Chile was done
in parallel with the activities of this TF.

In this document we have not tried to come up with a
completely new conversion. Rather, we have studied these
existing conversions, filled in some gaps and made a few different
decisions. Below we discuss the differences per conversion.

The conversion by Brickley is a partial conversion, as
only the noun-part of WordNet is converted. Of the relations only
the hypernym relation is converted.
Brickley converts the noun hierarchy into rdfs:Classes and
the hyponym relationship into
rdfs:subClassOf. This is an attractive
interpretation, but we argue that not all hyponyms can be
interpreted in that way. For example,
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. An attempt to provide a consistent
semantic translation of hyponymy has been done [Gangemi, 2003], but in this work we
explicitly avoid semantic translation of the intended meaning
of WordNet relations.

The conversion by Decker & Melnik is also a partial one. It does
convert all synset types, but only three of the WordNet relations. Another
difference is that it attaches word forms as labels to the Synset instances.
Hence WordSenses and Words do not have a URI.

The two previous conversions are based on an older version of Princeton
WordNet and are not updated as far as the TF can tell. Both provide RDFS semantics,
but not OWL semantics.

The conversion of Neuchatel is close to the one in this
document. It has roughly the same class hierarchy, with two
exceptions. Firstly, it contains a class to represent word senses,
but does not have a separate class for words. Secondly,
it defines classes like "Nouns_and_Adjectives" (with subclasses Noun
and Adjective). The "Nouns_and_Adjectives" classes are used
in restriction definitions, where we have chosen to use owl:unionOf,
because it better reflects the actual semantics.
Aonther difference with this conversion is that Neuchatel is in
pure OWL (e.g. all properties are either owl:ObjectProperty or
owl:DatatypeProperty), while the conversion of the TF is
both in RDFS and OWL (e.g. each OWL property is also defined
to be an rdfs:Property).
The conversion by the TF splits some relations into sub-relations,
because their semantics warranted such a separation. 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 Neuchatel conversion does not
provide sub-relations, and omits relations "derivation" and "classification".
and also does not provide inverses for all relationships. The conversion uses
hash URIs, while the TF's uses slash URIs
(the benefits of the slash approach are described in Hash versus
slash URIs).
The main advantages of the conversion by the TF in comparison to the Neuchatel
conversion is that it is more complete,
uses slash URIs, is interpretable by both RDFS and OWL infrastructure,
and represents Words as first-class citizens.

Representing words as first-class citizens
allows fine-grained mappings to WordNets in other languages.
Future integration of WordNet with WordNets in other
languages can be done on three levels: relating Synsets,
relating WordSenses and relating Words from the different WordNets
to each other. However, as the other
conversions do not provide URIs for words, these only allow integration
on the first two levels.
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.

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.
It does not have the superproperties for WN relations that we have
introduced, and it uses hash URIs.
The main technical advantages of the version by this TF is
that it includes OWL semantics and that it uses slash URIs.

The previously mentioned conversions do not convert the frame sentences,
while the TF's conversion and the conversion of University of Chile include them.

A practical advantage of the TF's conversion over the other conversion is
the availability of a Basic and Full version and separate files for the WN
relations.

In summary, the advantages of the TF's conversion over other versions are that
it is complete, uses slash URIs, provides OWL semantics while still being
interpretable by RDFS infrastructure, provides a Basic and Full version,
and provides URIs for words.

Appendix G: Introducing 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 in Primer to using RDF/OWL WordNet.

We use two different namespaces: one for the schema and one for the instances.
This makes it possible to manage the schema separately from the instances.

Some words contain characters that are not allowed in NCNames. In order to
generate a correct URI we changed the following characters into underscores:
'/', '\','(', ')' and ' ' (space).
For example, the URI for the word "read/write_memory" becomes:

http://www.w3.org/2006/03/wn/wn20/instances/word-read_write_memory

The motivation for representing words as instances
of a class with their own URIs instead of as labels or blank nodes
is discussed in Relation to previous versions.

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 type for the noun-synset "bank":

The disadvantage of hash URIs is that when a HTTP GET is done (e.g. for
the second 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://www.w3.org/2006/03/wn/wn20/instances/synset-bank-noun-2.
[@@REFS for def of hash/slash URIs and the frag id problem]
Possible choices are:

a graph that contains a pre-defined set of properties if the resource
has values for them (e.g. rdf:type, rdfs:subClassOf);

all statements connected to the resource with some offset, e.g. everything
connected in at most two steps;

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].

Note that a variant of Recipe 5 in [Recipes, 2006] may be used to implement
the HTTP GET on these WN URIs.

Appendix H: Internationalization

This section contains two language related topics. First of all, Princeton
WordNet is
a source that documents American English. To reflect this in the conversion, all
RDF documents of this conversion are declared to be written in
American English by adding the
xml:lang='en-US' to the RDF tag of all WordNet files.

Secondly, it is desirable to be able to integrate other existing WordNets
in other languages in the future
(for a list of available WordNets see http://www.globalwordnet.org/gwa/wordnet_table.htm).
Although this
TF does not have the goal of performing such integration, it has the intention
of making such integration possible with this RDF/OWL version of Princeton WordNet.
Integration of WordNets implies creating mappings between entities in the WordNets
to indicate lexico-semantic relationships between them, e.g. a property that
signifies that the
meanings of two Synsets overlap. The entities that represent language concepts
that should be able to map are instances of the classes: Synset, WordSense and Word.
To this end this conversion supplies URIs for instances of all three classes.
We have not given the URIs in this conversion a part that encodes the language,
such as http://www.w3.org/2006/03/wn/wn20/en/synset-bank-noun-2.
The reason is that two WordNets in different
languages require different base URIs. This alone guarantees uniqueness of e.g. the
Word "chat" in an English WordNet and the word "chat" (cat) in a French WordNet.
Identification of the language a particular word belongs to can also be done by using
the xml:lang tag.

Appendix I: Open Issues

Princeton based URIs

The TF is in contact with Princeton. Princeton is willing to provide a namespace
for RDF/OWL WordNet. At the present moment we do not use Princeton based URIs
but will do so in the future when (a) we have consensus within our community
that this is an appropriate representation of WordNet (b) we have checked with
Princeton the remaining modeling issues and check if we have made modeling
decisions (c) there is consensus on how to serve WordNet online (see issues
stated elsewhere).

This document was originally written as if there will be an RDF/OWL version of
each Princeton WordNet edition. Is this feasible? There should be an
institute who takes responsibility for not only creating new versions but also
making them available for online use. Concerning creating new versions:
when new versions by Princeton
only differ from previous in its content, then this is just a matter
of running the Prolog conversion program and putting the new version
online. This document describes the convertion of Princeton version 2.0.
In version 2.1 there is at least one structural difference, namely the
introduction of a "instanceOf" relationship.

Maintanance / publishing newer versions

This version is based on the Princeton WordNet 2.0. Is it feasible and desirable
to find an institute willing to commit to maintaining WordNet for a longer
period, say two years? This also entails bringing out a new RDF/OWL version
for each new Princeton version. Without such a commitment the RDF/OWL version
presented in this document will be outdated within one or two years because of
updates to the original source.

Serving old and new versions

An idea suggested in an earlier version of this Draft was to introduce a new
base URI for each new version, and to use redirection from a stable URI which
redirects to the newest available version of RDF/OWL WordNet. For example,
the URI

http://wordnet.princeton.edu/wn/

can redirect to the latest version, e.g. 2.0 as in

http://wordnet.princeton.edu/wn20/

Some text suggested in an earlier version of this draft follows below:

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:

http://wordnet.princeton.edu/wn20/

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.

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).

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

http://wordnet.princeton.edu/wn/

to the namespace of the newest version, e.g.

http://wordnet.princeton.edu/wn20/

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.

URIs as primitive queries

URIs can be used as a means of primitive queries.
The following URI in WordNet refers to the first NounWordSense of the word "bank",
which is an RDF node in WN:

http://www.w3.org/2006/03/wn/wn20/instances/wordsense-bank-noun-1.

The current proposal is to return the CBD [CBD, 2005] of the requested RDF node.
Many agents would probably like somewhat bigger chunks of data at once, e.g.
all WordSenses of "bank". This could be done by returning the set of
WordSenses with the Word "bank" on HTTP GETs on e.g. the URI:

http://www.w3.org/2006/03/wn/wn20/instances/wordsenseset-bank.

A full SPARQL service for WN can also address this need, but this is a nice
alternative that does not require all agents to understand SPARQL. Another
reason is that running a SPARQL service requires more resources from the
hosting institute.
However, this second (type of) URI does not refer to any RDF node or RDF arc.
Is this use of URIs "accepted practice" (or could become
such a thing) or "should be avoided at all costs" because the approach mixes
the naming of nodes with naming sets of nodes?
See also http://lists.w3.org/Archives/Public/public-swbp-wg/2006Mar/0076.html.
If it is a good idea, how should the URIs be constructed?

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.

Frames

There seems to be additional semantics in the frame sentences, and
hence could be alternative ways to convert the sentences. For example,
the structure of the sentences seems to fall into two parts, plus
an optional part. For example, the frame sentence
"Somebody ----s that CLAUSE" has a prefix, a postfix and a lexical
category. These could be extracted and added as properties to an instance
of a class Frame. It should be checked with users if this information
is useful and with Princeton about the meaning of the lexical categories.

Other

Should wn:seeAlso be a subproperty of rdfs:seeAlso? If so, other properties
could also be appropriate subproperties of rdfs:seeAlso, as the semantics of
the triple S rdfs:seeAlso O is "... that the resource O may provide additional information about S."
[RDF Primer, 2004]

We assume wn:sameVerbGroupAs is between synsets, but
have to check with Princeton if it should be between
WordSenses.

A strategy is required (test set?)
to check whether the conversion program's output is correct.

Should this document contain information on the relation to SKOS? There
are problems in seeing WN as a strict specialization of SKOS:
Should all WN classes be regarded as subclasses of skos:Concepts or should only
Synsets or WordSenses be regarded as skos:Concepts?
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 it
seems impossible to define WN as strict specialization of SKOS. The remaining
solution is a rule-based mapping. But again the decision remains what is an
appropriate mapping of the main classes to skos:Concept. It seems a choice between
Synsets and WordSenses is necessary. In the former case, it seems logical to
map the hyponym relation to skos:broader. It the latter case, a possibility
is to put the WordSenses in a skos:Collection and hierarchically relate these
collections based on the hyponymy relation. However, this would result

Document now contains a set of downloadable files for version WordNet RDF/OWL
version 2.0. Should this be moved to a separate WN download document?

This version is not OWL DL, because rdfs:label is used on instances.
Should the description of the benefits of the OWL definitions in the schema
be changed?