RE: SKOS compatibility

Hi, John

As for the following suggestion:

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

I think that deprecated would not include spelling mistakes, just that 
the term is outdated, or non-preferred. So if you plan to include 
spelling mistakes, might be better to leave it as it is.

Best

Lupe

El 2013-07-19 19:22, Armando Stellato escribió:
> 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).

-- 
GUADALUPE AGUADO DE CEA
Universidad Politecnica de Madrid

Received on Saturday, 20 July 2013 17:58:24 UTC