RE: Finalizing the LIME module

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

Received on Monday, 24 November 2014 18:50:06 UTC