- From: Mark van Assem <mark@cs.vu.nl>
- Date: Tue, 20 Sep 2005 15:20:20 +0200
- To: public-swbp-wg@w3.org
- CC: "McBride, Brian" <brian.mcbride@hp.com>, Aldo Gangemi <aldo.gangemi@istc.cnr.it>
Hi,
In light of comments of Brian and Guus I had another look at how to
reconcile RDF and OWL for WordNet.
I worked out a solution in which there is one RDF data file and one
RDF/OWL schema which is understandable for both RDFS and OWL tools as
much as possible. I created a new schema in [3], didn't create the RDF
data itself, but will do so if this solution receives positive feedback.
Another solution is to have two separate versions:
- RDF data + RDF Schema
- RDF data + OWL schema
I myself am leaning towards the opinion that it's better to have two
seperate versions, because things get a bit messy, please comment if
you think otherwise or agree.
An orhogonal issue is that I think a few of the classes in Aldo's
current proposal [2] do not really belong to the core WN datamodel.
Therefore, I moved them to a separate "extensions" file [4] and not to
[3].
Cheers,
Mark.
--------------------------------------------------------------------------------
There are three problems in the context of WN's OWL model:
1) RDFS tools don't understand owl:Class, owl:ObjectProperty and
owl:DatatypeProperty (these are crucial, other statements e.g.
owl:disjointWith and owl:TransitiveProperty can be ignored
without missing something that the tools can understand);
Problem 1 can be solved by these additions to Aldo's schema (older
version in
[1], newer version in [2]):
- each class gets an rdf:type link not only to owl:Class but also to
rdfs:Class
- each property gets an rdf:type link not only to either
owl:DatatypeProperty or owl:ObjectProperty but also to rdf:Property.
I added to [2] these statements resulting in the file [3].
--------------------------------------------------------------------------------
2) RDFS requires explicit rdf:type links for all instances of a class
and explicit rdfs:subClassOf links between subclasses.
OWL can use completely defined classes (owl:EquivalentClass) to
implicitly define rdf:type links (instance classification). Some
logical superclasses of a complete class can be inferred also
(rdfs:subClassOf links).
Partially defined OWL classes with restrictions can also be
automatically classified below logical superclasses
(rdfs:subClassOf links). Instance classification however does not
occur.
Problem 2 can be solved by having two separate versions:
- RDF1 + RDF Schema
- RDF2 + OWL Schema
In the RDF(S) version, all links that are inferred in the OWL version
are added explicitly. I.e. the data in file RDF1 contains the explicit
links while the file RDF2 does not.
A second solution is to combine the two schemas in such a way that
RDFS tools can understand them as much as possible, and have an RDF
file that has all the links explicitly. For my attempt at such a
combined schema, see [3]. Fortunately, Aldo already added explicit
subclass links, so that's not a problem.
--------------------------------------------------------------------------------
3) RDFS tools miss out on domain and range info that is specified in
local OWL class restrictions. The same for inverse properties. They
also cannot handle domain/range defs with owl:unionOf.
A third problem is domain and range info that is defined in local
restrictions. This is not available to RDFS tools. However, Aldo
provided global domains and ranges for all props, so RDFS tools are
not clueless, i.e. get the info that they are able to understand.
Then there still is a small set of WN properties that creates problems
with domains/ranges, namely:
- props that are owl:inverseOf another prop
- wn:attributeOf (none defined)
- wn:seeAlso (unions in dom/range)
- wn:adjectivePertainsTo (union in range)
Because RDFS tools do not understand owl:inverseOf, they will lack the
right domain/range defs for inverse properties because they are
generally not stated in an OWL file but inferred. In general this can
be solved by explicitly adding the domains and ranges for inverse
props. Aldo already did so for WN's inverse properties
(but forgot for attributeOf, so I added that), so the inverse props
are taken care of.
Unions in domains/ranges is more tricky. A partial solution would be
to add triples like these (example range def for "propX"):
- AorB rdf:type rdfs:Class
- propX rdfs:range AorB
- AorB owl:unionOf (A, B)
- A rdfs:subClassOf AorB
- B rdfs:subClassOf AorB
An RDFS tool thus can use AorB for inferring the type of an instance
in the range of propX and can also use AorB for querying.
I did not implement the solution I state above in [3], I would like
some feedback on this first.
An alternative would be to just leave it like it is, i.e. not having
dom/ranges available for these inverse props in RDFS tools. What
important use cases like in [6] exist that require the domains/ranges
of these props?
A remaining problem is that instances of inverse properties are not in
the RDF data, i.e. there is nothing to access by RDFS tools.
As they cannot be queried anyway (well, queries just don't deliver
results), we could also opt to make the inverse properties "invisible"
to RDFS tools by NOT adding rdf:type rdf:Property as for other
properties in the solution to problem 1.
--------------------------------------------------------------------------------
I also moved some of the classes to a separate "extensions" file with
a separate namespace, because I think one can argue that they are not
part of the original WN conceptual model:
SynsetUsedAsClassifier
MonosemousWord
PolysemousWord
UniqueBeginner
Incidentally, these classes are all "complete" classes, so this rids
some of the complexity for RDFS tools. Also, if an RDFS tool requires
the set of instances denoted by these classes, it will not
be very difficult to write a query to select them:
I implemented the "basic model" in [3] and "extensions" in [4].
Advantage of this solution: one basic RDF data and one basic RDF/OWL
schema which everyone can use, extensions still accessible for those
who want them.
--------------------------------------------------------------------------------
Small adittions/error corrections:
errors: wn:antonymOf is not inverse of itself, same for
wn:sameVerbGroupAs. Range of wn:adjectivePertainsTo is owl:unionOf
wn:NounWordSense and wn:AdjectiveWordSense (instead of two separate
range defs for each class), same for wn:seeAlso's domain and range.
UniqueBeginner was not yet defined with a restriction, changed its def
to:
Class(a:UniqueBeginner complete
intersectionOf(unionOf(b:VerbSynset b:NounSynset)
restriction(b:hyponymOf allValuesFrom(owl:Nothing))))
--------------------------------------------------------------------------------
Question:
There are two anonymous classes that are defined complete. What are
they for? They are still in [3], but I guess something has to be done
about them:
EquivalentClasses(intersectionOf(a:Word restriction(a:wordInSynset
someValuesFrom(a:Synset))) intersectionOf(a:Word restriction(a:sense
someValuesFrom(intersectionOf(restriction(a:inSynset
someValuesFrom(a:Synset)) a:WordSense)))))
EquivalentClasses(intersectionOf(restriction(a:synsetContainsWord
someValuesFrom(a:Word)) a:Synset)
intersectionOf(restriction(a:containsWordSense
someValuesFrom(intersectionOf(restriction(a:word
someValuesFrom(a:Word)) a:WordSense))) a:Synset))
--------------------------------------------------------------------------------
[1] http://www.w3.org/2001/sw/BestPractices/WNET/wordnet_datamodel.owl
[2] http://www.loa-cnr.it/www.loa-cnr.it/Files/wordnet_datamodel_v4.owl
[3] http://www.cs.vu.nl/~mark/wn/wordnet_datamodel_v5.owl
[4] http://www.cs.vu.nl/~mark/wn/wordnet_datamodel_v5ext.owl
[5] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Sep/0035.html
[6] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Sep/0033
--
Mark F.J. van Assem - Vrije Universiteit Amsterdam
mark@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Tuesday, 20 September 2005 13:20:57 UTC