Re: Finalizing the LIME module

Hi,

Thanks for your reply

On Mon, Nov 24, 2014 at 7:49 PM, Armando Stellato <stellato@info.uniroma2.it
> wrote:

> Dear John, Philipp,
>
>
>
> thanks for the resume John!
>
>
>
> One thing before we commit any change: we have until now sent always
> updates (later, together with examples) on a turtle version of the file,
> which is rather more readable than RDF/XML. In any case, any format is fine
> for us, but since we have both already in place, this is the right time to
> choose which format to adopt and trash the other one. Just let us know if
> TURTLE is ok or if you prefer to keep the RDF/XML one, and we will send
> updates on the format of your choice.
>
> Apart from further changes, we see in any case the lime.owl you attached
> you sent is still different from the resume of your email (e.g. there is
> stil lLexicalization instead of LexicalizationSet), but we can apply these
> changes asap on the file of the format we agree.
>
>
>
> Now, going to your email:
>
>
>
> LexicalLinkset: Not in proposal... I remain unconvinced that this is
> really useful but it does not seem completely useless, let's keep it.
>
>
>
> We had this left appended for discussion in the next OntoLex meeting.
> Shall we meet this Friday?
>
Yes we will have a call this friday

>
>
> Lexicon: Merge with Ontolex module
>
>
>
> This has been discussed extensively: in last call I (Armando) said we
> (both Manuel and me) would still prefer them to be separate (and, in case
> of data and medata convering on the same object, have it being an instance
> of both classes), though have no strong opposition in merging, providing we
> are at least sure there are no counterexamples.
> I think we found one counterexample: LIME may provide statistical info
> even about other kind of lexicalizations (and thus of Lexicons as well). In
> this case, a separate file containing SKOSXL Labels, to the purpose of our
> statistics, would be a lime:Lexicon as well, though cannot for sure be
> considered an ontolex:Lexicon. So, if we hold that true, at most
> ontolex:Lexicon could be a rdfs:subClassOf lime:Lexicon.
> Regarding the “look back at the past”: I said in the last call that we
> have no big example from the past: in void there is the notion of
> void:Dataset, simply because there is no equivalent at the data level. In
> VOAF, its authors were not owners of the OWL Vocabulary, so had to defined
> a separate class. But one thing I forgot to mention is that they could
> state the following axiom: voaf:Vocabulary rdfs:subclass owl:Ontology,
> which they did not.
>
> Again, I would not like to make it a “defense at all costs” :-) just
> trying to consider all implications…
>
I would not see that need for the LIME module defined in OntoLex to cover
SKOS-XL labels and calling a set of SKOS-XL labels a lexicon is quite
questionable. I think it would be better for users of the model not to have
two objects with the same name that are also conceptually very similar, so
either we merge the two Lexicon classes or one of them (by which I mean the
LIME one ;)) would get a new name such as LexiconStatistics or
LexiconDataset.

>
>
> class: As proposal
>
>
>
>                 ermm…really sorry, don’t recall this: I remember Philipp
> suggested this to be “resourceType”. Did we revert back in the last call
> for any reason? I think I preferred lime:class but didn’t recall to have
> tried to revert to the original name
>
'Resource Type' is probably better... I could update the wiki and OWL files

>
>
> lexicalizedReferences: Not in proposal but useful
>
> references: Not in proposal but OK
>
>
>
> we just noticed now that the “lexicalizedReferences” proposed by Philipp
> was already available in the ResourceCoverage, with the already existing
> name “references”, and was in fact being used only in the ResourceCoverage
> (see examples). In the wiki it is being reported with domain:
> Lexicalization or ResourceCoverage, but that was not our in our proposal
> (see Lime.ttl and our examples). If we had to choose, we would keep
> “references”, as, in the context of a ResourceCoverage, its meaning is
> pretty clear.
>
As I understood it, these are two separate values: the total number of
references and the total number of references referred to by at least one
lexical entry. See also below

>
>
> lexicalizedDataset: 'referenceDataset' in proposal (I prefer that name)
>
>                 however, the label in lime.owl is still “lexicalized
> Dataset”, was that by purpose?
>
Fixed

>
>
> linguisticModel: Called 'lexicalModel' in proposal (I prefer linguistic).
> Note this should be an annotation property.
>
>                 about the name: both of us not really sure, so we leave it
> to you (btw, in lime.ttl and examples is linguisticModel). Just our two
> cents: we are referring always to purely lexical models (rdfs, skos,
> skosxl, ontolex), but as we say…we leave to you the final word.
>
>                 about the type: we disagree with annotation property:
> besides what can be (currently) inferred by a reasoner, there are concrete
> relationships between the values of this property and conditions to be met
> by agents using them. Also, we have some axioms in mind (to be discussed in
> another topic…)
>
This should be an annotation property because otherwise we would make any
URI targeted by this property into an individual, of course this also makes
it difficult to state cardinality restrictions... perhaps it is not
necessary although I wonder who decided to make it a annotation property in
lime.owl.

>
>
> senses: Not in proposal but OK
>
> lexicalEntries: OK
>
>
>
> agreed last time, though…we are rather reluctant on putting
> ResourceCoverage also in the domain for them. Also, they are not useful for
> computing (given the absolute values) the statistics we produce. In fact,
> given the two formulas below, the “lexicalizations for elements of type T”
> are provided by the “lime:lexicalizations” property, but still the
> “elements of type T” is missing
>
I think that all these statistic properties should apply to both the full
lexicalization and resource coverage.  For example, it is quite possible to
give the number of lexical entries which lexicalize classes in the
reference ontology and this number is not the same as the number of
lexicalizations (lexical senses) between the lexicon and the classes of the
reference ontology.

>
>
>
>
>
>
> 1)      *avgNumberOfLexicalizations:* defined as
>
>
> 2)      *percentage*: reported (in percentage) as:
>
>
>
>
> though…maybe here we are missing something?
>
>
>
>
>
> Everything else’s fine, just let us know whether to update the ttl or the
> owl.
>
I don't know where the Turtle file is... please stick to GitHub
<https://github.com/cimiano/ontolex> and the Wiki
<https://www.w3.org/community/ontolex/wiki/Final_Model_Specification>

Regards,
John

>
>
> Cheers,
>
>
>
> Manuel and Armando
>
>
>
>
>
>
>
> *From:* johnmccrae@gmail.com [mailto:johnmccrae@gmail.com] *On Behalf Of *John
> P. McCrae
> *Sent:* Friday, November 21, 2014 2:23 PM
> *To:* public-ontolex
> *Subject:* Finalizing the LIME module
>
>
>
> Hi Armando, Manuel, all,
>
> I was attempting to figure out the differences between the proposal you
> guys sent for LIME and the version on the wiki. As I see it the following
> alignment is what we roughly agree on:
>
> ConceptualizedLinguisticResource: Remove this class.
> LexicalLinkset: Not in proposal... I remain unconvinced that this is
> really useful but it does not seem completely useless, let's keep it.
> LexicalizationSet: OK
> Lexicon: Merge with Ontolex module
> ResourceCoverage: Not in proposal, but OK.
> avgNumOfLexicalizations: 'avgNumOfEntries' in proposal, I think
> lexicalizations is a clearer name
> class: As proposal
> language: Merge with Ontolex module
> lexicalEntries: OK
> lexicalLinkset: see above
> lexicalization: OK
> lexicalizations: Not in proposal but useful
> lexicalizedDataset: 'referenceDataset' in proposal (I prefer that name)
> lexicalizedReferences: Not in proposal but useful
> lexicon: OK (but we should consider a clearer name, e.g., lexiconDataset)
> linguisticModel: Called 'lexicalModel' in proposal (I prefer linguistic).
> Note this should be an annotation property.
> percentage: OK
> references: Not in proposal but OK
> resourceCoverage: Called 'coverage' in proposal, we should keep this as it
> is shorter and more distinct
> senses: Not in proposal but OK
>
> As such I attach what I would propose as a finalized version of Lime,
> assuming you agree with what I stated above.
>
> Regards,
> John
>