Re: [WNET] RDF/OWL versions of WN

Hi Alistair,

> What property should be used to give the lexical value of a Word?  (I can't find one, am I missing something?)

Woops, it was in my first version but somehow left out in [3]. Added 
wn:lexicalForm to [3].

> The reason I'm asking is: I'm drafting something on extending SKOS Core, and would like to describe how the wordnet model could be mapped to SKOS Core using some rules (see [7]). This would give an example of the more general case where a model with multiple layers of lexical representation can be mapped to SKOS Core's simple concepts->labels model.  Something like e.g.

Interesting idea, I am currently thinking about how to solve the same 
issue for MeSH. The discussion on the SKOS mailing list about MeSH 
qualifiers solves that part of MeSH, but not the 
Descriptor>Concept>Term structure.

> The interesting thing about wordnet is I thing it could have two alternative mappings to SKOS Core, resulting in concept schemes at different levels of granularity.  Because for example, you could also define the mapping as:

If I understand correctly, your point is: (1) is Synset a skos:Concept 
with different labels or (2) is  WordSense a skos:Concept with a label?

Does the following example correctly summarize what you are planning 
to do in the second situation:

- synset S-Z contains WordSenses WS-A and WS-B
- synset S-Z has hypernym S-Q
- WS-A is linked to the Word with wn:lexicalForm "Car"
- WS-B is linked to the Word with wn:lexicalForm "Automobile"

... converted to ...

- WS-A a skos:Concept with skos:prefLabel "Car"
- WS-B a skos:Concept with skos:prefLabel "Automobile"
- WS-A skos:broader ... [all the wordsenses converted to skos:Concepts 
contained in S-Q]
- WS-B skos:broader ... [idem]

(note I think in this approach you should use prefLabel instead of 
altLabel - there simply is no other label)

If this is correct, then in the second approach you lose the 
information that "Car" and "Automobile" are synonyms. You do have that 
info in the first approach.

> What do you think of this? I think it's worth writing up, if only to provoke discussion.

Rules for converting sources to SKOS you mean? Very useful, but an 
advanced topic, not something for the Guide I guess? THis could be 
part of a separate "SKOS conversion" note we talked about a few months 
ago on the SKOS list.

> A related comment on ...

<snip classes>

> I was going to ask the same thing: what's the point of these classes? Wouldn't it be more practical to assert the logical dependence of these two structures using rules, allowing one to be inferred from the other?

I'm guessing that they are the definition part of two complete classes 
that by mistake didn't get a name (i.e. the <owl:Class rdf:ID="..."> 
is missing). They weren't there in Aldo's first version [1], but are 
in his second [2].

Cheers,
Mark.


> Cheers,
> 
> Al.
> 
> [7] http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/drafts/appextensions.html?rev=1.7
> 
> 
>>-----Original Message-----
>>From: public-swbp-wg-request@w3.org
>>[mailto:public-swbp-wg-request@w3.org]On Behalf Of Mark van Assem
>>Sent: 20 September 2005 14:20
>>To: public-swbp-wg@w3.org
>>Cc: McBride, Brian; Aldo Gangemi
>>Subject: [WNET] RDF/OWL versions of WN
>>
>>
>>
>>
>>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
>>
>>
> 
> 

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        mark@cs.vu.nl - http://www.cs.vu.nl/~mark

Received on Thursday, 6 October 2005 13:35:17 UTC