Re: lexicalization count

Dear Philipp,

I attached to this email an initial OWL model representing the LIME
metadata vocabulary.

Let me summarize the model.

The central entity is now the lime:Lexicalization which:

   - provides lexicalizations for an RDF datasets (i.e., a collection of
   linguistic attachments);
   - in one natural language;
   - using one ore more linguistic models (as long as they are used to
   express the SAME information, up to the expressive power of each model);
   - possibly referencing a given OntoLex Lexicon.

In the proposed model, the properties from a lexicalization to the target
dataset and the lexicon are functional.

Since in some usage scenarios we start with an ontology and we want to
discover lexicalizations for it, we also provide a property that connects
any void:Dataset to known lexicalizations.

Each lexicalization refers to various ResourceCoverage(s), which provide
statistics for different types of resources found in the target dataset.

Currently, we have not committed to a specific set of statistics, therefore
I just introduced the ones already mentioned by Philipp. With respect to
his proposal, I slightly changed the domain of some of the properties. For
instance, I do not believe that references (the count of distinct
references) should be applicable to a Lexicon.
As already said by Armando, we have a distinct class (lime:LexicalLinkset)
for expressing the association between a dataset and a conceptualized
linguistic resource (e.g., WordNet). In fact, this association is close to
a mapping relation, thus we decided to introduce a distinct class
LexicalLinkset that extends the standard class void:Dataset. However, we do
believe that preserving the distinction may be useful.

Despite we have removed the our categorization of linguistic resources, I
reintroduced the class ConceputualizedLinguisticResource, which should be
used in conjunction with LexicalLinkset.

In the proposed model, I recreated some classes, such as Lexicon, that
already exists in the core OntoLex model. We should decide, whether they
are the same class or not.

Another interesting point of discussion is our choice of providing two
properties:

   - lang, which indicates the natural language a given lexicalication
   refers to
   - language, which is a shortcut to allow a dataset saying: I know there
   is a lexicalization for me in this natural language.

We should discuss whether these two properties are required, and in case
which of them unify with ontolex:language.


2014-06-04 19:37 GMT+02:00 Armando Stellato <stellato@info.uniroma2.it>:

> Dear Philipp,
>
>
>
> sorry for not catching up earlier with this email. Just came back from
> LREC and departed immediately for another conf in Taiwan which I’m still
> attending. Writing “nightwise”…
>
>
>
> Ok, so, as a first thing, I had a long call with Manuel just now. He will
> send in the next days something that you can publish on GIT. Obviously,
> everthing under discussion, but it is just a starting point to have it open
> and accessible on GIT.
>
>
>
> I anticipate here some replies to your email:
>
>
>
> // counting properties (datatype properties, with domain (ontolex:Lexicon
> OR ontolex:Lexicalization OR void:Dataset OR lime:LanguageCoverage)
>
> lime:numberOfLexicalEntries
> lime:numberOfSenses
> lime:numberOfLexicalizations (denote-tirples)
> lime:numberOfReferences -> the number of distinct references used
>
> We then need to discuss whether we should also include ratios etc.
>
>
>
> As said before, we would prefer to use simple names (in the spirit of
> analoguous properties on void), such as lexicalEntris, senses,
> lexicalizations, references. Small note: not so sure if to keep the
> ambiguity “Lexicalization” (as a dataset of lexicalizations) and
> “lexicalization” as an attachment. It creates then ambiguitirs like the
> property “lexicalizations” (as number of attachments) and “lexicalization”
> as pointer to a Lexicalization.
>
> But, for the moment, let’s stick with them.
>
>
>
>
>
> Then:
>
> lime:language (unified with ontolex:language, extended here to domain
> lime:LanguageCoverage
>
>
>
> Not sure I got it exactly the above. Btw, we will present two different
> props, and then check what can be unified.
>
>
>
> lime:linguisticModel: describing by which model/vocabulary information
> about lexicalization is attached; the domain is void:Dataset and the range
> is the URI of the vocabulary; lime:linguisticModel is thus a subproperty of
> void:vocabulary
>
>
>
> Fine. One note here: we saw now that in the PDF about LIME we sent before,
> there is one thing that we resolved in one chapter, and left obsolete in
> one other.
>
> Wrt our LIME paper, there is no more languageCoverage (and thus, even no
> need of changing it to lexicalCoverage as we wrojngly left said at the end
> of page 2 ) as it has been replaced by Lexicalization. Inside a
> Lexicalization, we may specify different ResourceCoverage, that is, various
> “cuts” of coverage for different ontology types (e.g. the coverage for
> classes, or for properties, or for skos:Concepts ).
>
> This also simplifies the terminology (though, as said before,
> Lexicalization clashes with the name of its own contained attachments).
>
>
>
> One more point: we left open the problem of addressing links to
> LexicalConcepts of conceptualized lexical resources (e.g. wordnet).
>
> We just resolved it in a decently elegant way. A lexicalization only deals
> with attachments between OWL/SKOS dataset/vocabulary (the “onto” part) and
> senses or lexical entris of a lexicon.
>
> Attachments to lexicalconcepts (the ones we called lexicalResourceCoverage
> in our paper) will be dealt in a different way (as it is only implicitly a
> lexicalization), though reusing existing stuff from void.
>
> We would coin the class: LexicalLinkSet as a subclass of void:LinkSet, and
> it would be used to express the links above.
>
>
>
> Note that several linguisticModels can co-exist in principle in a
> dataset...
>
>
>
> Sure. More precisely, an “onto” Dataset may specify more (known)
> Lexicalizations . each lexicalizations refers to only one language. One
> (onto) dataset may have more than one lexicalization per language
> (obviously); this maybe due to different models being available, or simply
> to different lexicons being available and linked to the same (onto) dataset.
>
> We were thinking (for more compactness) to allow for the specification of
> more linguisticmodels for the same lexicalization, whenever *exactly* the
> same lexical content is available (in the same lexicalization). For
> instance, if SKOSXL and materialized SKOS labels and RDFS labels are
> available inside the same physical dataset representing a lexicalization,
> then it is possible to specify them as alternative models inside the same
> Lexicalization instance.
>
>
>
>
> lime:type: providing a type for the resource in question, e.g. bilingual
> lexicon, lexicon, ..., domain is void:Dataset and range is not specified
>
>
>
> eheh, ok, you know our point of view, so better we leave you and John
> discussing on what is intopic or offtopic inside OntoLex, then only in the
> first case, we can give our contribution ;)
>
>
>
> lime:languageCoverage with domain void:Datase and range
> lime:LanguageCoverage.
>
>
>
> ime:LanguageCoverage has a language, a linguistic Model and all the
> counting properties above are defined for it.
>
>
>
> ok, replaced by Lexicalization, see above (and also all pages of PDF,
> except page 2).
>
>
>
> Think that’s all. Manuel will follow with a specification via email, so
> that you can put it on GIT.
>
>
>
> Sorry, I will be unable to participate on (still in conference).
>
>
>
> Cheers,
>
>
>
> Armando (and Manuel from call ;) )
>
>


-- 
Manuel Fiorelli