Coining a specific vocabulary for synsets in the OntoLex model

Yes I agree that we should introduce a specific name in our model for
Synset.

Firstly, the modelling proposed for WordNet is based on existing modelling
(i.e. lemon (1.0) and SKOS) so hence the usage of skos:Concept

As for  a new class I am not so keen on the name SemanticIndex, I would
assume that the best would simply be to call it Synset, so as to ease
adoption among the wider community. Semantic index I dislike as it is for
associated with Latent Semantic Indexing, and in this sense more of a
signature of a concept than a concept itself.

I don't think we should explicitly say the ontolex:LexicalForm is a
skosxl:Label. In fact, the lexical form represents the orthographic union
of surface forms of words, that is the same form (at least according to the
lemon definition, itself based directly on the LMF definition) can have
multiple strings (e.g., spelling variants, version in other writing
systems, pronunciations, segmentations, etc.) unlike a SKOS-XL label.

Regards,
John

**4)      **IMHO, we should coin a specific vocabulary for each element of
> the lexicon model, and then inherit (where appropriate) from SKOS/SKOSXL,
> to distinguish such elements which belong only to a lexical resource from
> those of any generic KOS. In the wiki, John wonders if what I called
> “SemanticIndex” is not a skos:Concept, and I reply: “yes it is, in fact my
> proposal is that our vocabulary for describing lexical resources can
> inherit from the SKOS/SKOS-XL one”. If you look at the example, even John
> did this, as the LexicalForm is nothing different from a skosxl:Label
> (where lemon:writtenRep could be replaced by skosxl:literalForm) though it
> may be worth creating a dedicated class. I would thus suggest:
> LexicalForm rdfs:subClassOf skosxl:Label
> but to use skosxl:literalForm instead of lemon:writtenRep
>
> maybe, in this specific case, we can even not reinvent a name, and totally
> reuse the skosxl:Label, which after all is not so bad and pretty fitting
> our necessities… (as it is already related to something specifically
> thought for language).
>
> On the contrary, for LLD, I would necessarily restrict the class
> skos:Concept to the class of elements which we expect to host things like
> the WordNet Synset class. You can see my sample extension-point above in
> the wiki (“Examples of Modelling in RDF (Alternative approach)”), though by
> now mean I suggest <SemanticIndex> (that was a placeholder, taken from a
> previous work), but in any case I think “Sense” is not appropriate
> (lemon:sense well evokes the sense relation, while I don’t like to see a
> class of “Senses”, that is, to me being a sense is more a role in a given
> relationship, than a intrinsic property of an object).
>
> ****
>
> **a.       **While I think that a more-specific-than-skos:Concept class
> would be welcome for Lexical Linked Data (such as WordNet), and thus put in
> the middle of the: LexicalEntry --> ??? --> OntologyResource  template, I’m
> not sure that the lemon:sense (first arrow) should be necessarily
> restricted to it. John’s use of skos:Concept in the middle suggested me
> that even a generic well-lexicalized KOS could be used for providing
> LexicalEntries and Senses to enrich an ontology. However, I’m still
> thinking about it…
>
> ****
>
>
>