Re: SKOS compatibility

Dear all,

I agree with what John says regarding the mapping bewteen SKOS and the 
OntoLex model, and this is what I was trying to say in the last telco.

In fact, the lemon model allowed to represent most of the information 
expressed in SKOS (unless we had decided to remove some of the 
representational possibilities in the OntoLex model). Let's see if I got 
this correctly:

 1. I would say that the link should be to Lexical Entries, and we could
    automatically generate the information about LexicalForm and also
    writtenRepresentation (string and language). (See example 5 in lemon
    cookbook about "animal" and "creature")
 2. Usually a label in SKOS represents the lemma, so this would be what
    we call in lemon "cannonical Form", and any morphosyntactic variants
    would be additional Lexical Froms (other Forms) associated to the
    same LexicalEntry.
 3. Each LexicalEntry would be related to a different LexicalSense. At
    the LexicalSense level we  could state that there is a relation of
    "terminological variants" between or among them (see the
    classification we proposed in
    http://www.w3.org/community/ontolex/wiki/Specification_of_Requirements/Properties-and-Relations-of-Entries).
    What we could probably not state is which this terminological
    variant relation is (are we talking about diachronic variants
    (tuberculosis and phthisis)? I am not sure we could infer this
    automatically... maybe yes?? But the thing is that we could
    represent this in the Ontolex model).
 4. Additionally, in lemon (see Example 9 in the lemon cookbook), we
    could state that one was the preferred reference, versus alternative
    and hidden references, although here the semantics were not 100%
    equivalent to SKOS, but still we could say that the "preferred
    label" corresponds to the "preferred reference", and the rest are
    alternative References??
 5. The only problem is that sometimes what we consider morphosyntactic
    varianst (acronyms vs. full forms) are also different labels in SKOS
    (so, consequently Lexical Entries in lemon), and according to our
    OntoLex model, they should be Lexical Forms associate to the same
    Lexical Entries. Maybe this could also be inferred automatically??

In any case, and taking into account that SKOS normally represents 
terminological resources, I would say that mostly the correspondence 
would be to Lexical Entries.

My two cents!
Elena.



El 22/07/2013 12:06, John McCrae escribió:
> Hi Armando,
>
>
>
>
> On Fri, Jul 19, 2013 at 7:22 PM, Armando Stellato 
> <stellato@info.uniroma2.it <mailto:stellato@info.uniroma2.it>> wrote:
>
>     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?
>
> The issue is one of orthographic representations, that is spelling 
> variants between languages (e.g., theatre and theater) but more 
> particularly also the issue of pronunciation guides such as /ˈθiːətə(ɹ)/.
>
> More particularly the mapping should be to lexical entries, I believe, 
> because they represent the core element of the OntoLex model, so it 
> seems natural to link there. This means of course that the properties 
> I propose do not give a one-to-one correspondence between SKOS and 
> OntoLex but instead that they give a good guideline for how people can 
> fix up their SKOS(-XL) model to be linguistically sound
>
> Regards,
> John
>
>     Cheers,
>
>     Armando
>
>     *From:*johnmccrae@gmail.com <mailto:johnmccrae@gmail.com>
>     [mailto: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).
>
>


-- 
Elena Montiel-Ponsoda
Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
Facultad de Informática
Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, España
www.oeg-upm.net
Tel. (+34) 91 336 36 70
Fax  (+34) 91 352 48 19