W3C home > Mailing lists > Public > public-ontolex@w3.org > July 2013

RE: SKOS compatibility

From: Armando Stellato <stellato@info.uniroma2.it>
Date: Fri, 19 Jul 2013 19:22:33 +0200
To: "'John McCrae'" <jmccrae@cit-ec.uni-bielefeld.de>, "'public-ontolex'" <public-ontolex@w3.org>
Message-ID: <03ad01ce84a4$8ed99450$ac8cbcf0$@info.uniroma2.it>
Dear John,

 

thanks for the proposal. I’ll go directly to the second point:

 

so, I proposed this too in my reply to Philipp, and following what has been discussed:

 

1)      We cannot directly have skosxl:[pref|alt|hidden]Label be subproperty of denotes^-1, because while we would probably like to see them pointing to LexicalEntries…

2)      …the class-correspondence should be: LexicalForm subclassOf skosxl:Label

 

Would you then consider having something like:

 

SubObjectPropertyOf( 

   ObjectPropertyChain( ontolex:preferredEntry ontolex:canonicalForm ) 

   skosxl:prefLabel 

 )

 

?

 

Now, one question: if I remember correctly, it has been mentioned that one problem in having ontolex:LexicalForm subclassOf skosxl:Label is that skosxl:literalForm is functional while ontolex:writtenRep is not. But it’s not clear to me (probably due to lack of examples or simply less discussion on the LexicalEntry/LexicalForm roles) while writtenRep should not be functional as well. I’ve got that the multitude of entries describing a ontology entity can be reached through different LexicalEntries (clear for everybody I think), and the multitude of tenses/morphologies etc.. can be obtained by different LexicalForms attached to a LexicalEntry. So far, so good (if I’m not missing anything), but then I suppose the LexicalForm should have really one and only one lexical representation too (thus functional too). Could you, in negative case, post me one example?

 

Cheers,

 

Armando

 

From: johnmccrae@gmail.com [mailto:johnmccrae@gmail.com] On Behalf Of John McCrae
Sent: Friday, July 19, 2013 5:26 PM
To: public-ontolex
Subject: SKOS compatibility

 

Hi all,

 

A couple of points I wanted to propose to enable the model to have a clearer compatibility with SKOS and SKOS-XL.

 

Firstly, the use of rdfs:label on LexicalEntrys, is a technique that we have used previously so that we do not need to create a form node for each entry. E.g.,

 

:Shisa a ontolex:LexicalEntry ;

  rdfs:label "shisa"@eng .

 

Would be considered equivalent to

 

:Shisa a ontolex:LexicalEntry ;

  ontolex:lexicalForm [

    ontolex:writtenRep "shisa"@eng 

  ] .

 

There are two other alternatives here, either we do not have any such properties (specifying a form is then mandatory) or we introduce a new property in the OntoLex namespace that has the role. Note, one of the key issues here is that with OWL we cannot specify the equivalence between this property and the lexicalForm o writtenRep chain, so I would prefer to re-use rdfs:label, which has the correct semantics anyway

 

Secondly, we should be able to indicate which entries are the preferred, alternative and deprecated lexicalizations of a given concept. For example, we could look into introducing a property which starts in the ontology and points to a lexical entry, e.g., something like this

 

:Scope a ontolex:LexicalEntry ;

  ontolex:sense [ ontolex:reference dbpedia:Scope_(Charity) ] .

:Spastics_society a ontolex:LexicalEntry ;

  ontolex:sense [ ontolex:reference dbpedia:Scope_(Charity) ] .

 

dbpedia:Scope_(Charity) ontolex:preferredEntry :Scope ;

  ontolex:hiddenEntry :Spastics_society .

 

As such, these properties would each be sub-properties of the inverse of 'denotes'.

 

Do these two proposals seem reasonable?

 

Regards,

John

 

PS SKOS recommend using hiddenLabel for spelling mistakes. I don't think we should support this in the meaning of hiddenEntry instead with the idea being that hidden terms are simply outdated (deprecatedEntry may be a better name for the property if we do not wish to follow SKOS).
Received on Friday, 19 July 2013 17:23:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 10:57:30 UTC