Re: Finalizing the LIME module

Dear all,

  I can not have a telco this Friday, but please go ahead without me. I 
guess John can lead the telco. From my side the agenda is:

1) LIME: see points below of Armando
2) Translation of labels: issues and questions
3) Provenance of translations: the proposal of John is to include a 
property in LexInfo called "lexinfo:confidence" with range (for 
instance) vartrans:TranslationActivity subclassOf provo:Activity. We 
would like to avoid having to import the provo ontology in vartrans, 
therefore the proposal is to outsource this property to lexinfo.

I will send out access details, but as already mentioned I can not attend.

Philipp.

Am 24.11.14 19:49, schrieb Armando Stellato:
>
> 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?
>
> 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…
>
> 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
>
> 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.
>
> lexicalizedDataset: 'referenceDataset' in proposal (I prefer that name)
>
>                 however, the label in lime.owl is still “lexicalized 
> Dataset”, was that by purpose?
>
> 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…)
>
> 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
>
> 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.
>
> 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
>

-- 
--
Prof. Dr. Philipp Cimiano
AG Semantic Computing
Exzellenzcluster für Cognitive Interaction Technology (CITEC)
Universität Bielefeld

Tel: +49 521 106 12249
Fax: +49 521 106 6560
Mail: cimiano@cit-ec.uni-bielefeld.de

Office CITEC-2.307
Universitätsstr. 21-25
33615 Bielefeld, NRW
Germany