Re: lexical resources with n-ary translations

Hi Christian,

If the argument is just that the current modelling is more verbose then I
would not be too keen to revise the model here. There will always be use
cases that can be modelled more efficiently with specific constructs, but
on the other hand, a standard model such as OntoLex also has to take into
account users of the model, who wish to have a consistent way to query and
work with the model. Of course, if the community feels that this is
important enough to allow multiple modelling options we can consider this.

Regards,
John

Ar Aoine 26 Meith 2020 ag 13:56, scríobh Christian Chiarcos <
christian.chiarcos@web.de>:

> Hi John,
>
> thanks for the recap.
>
> Am Fr., 26. Juni 2020 um 12:56 Uhr schrieb John P. McCrae <john@mccr.ae>:
>
>> Hi Christian,
>>
>> Much of this was discussed during the development of the vartrans module,
>> but I will try to recap:
>>
>> https://www.w3.org/2016/05/ontolex/#translation
>>
>> The main way to represent translations is by 'shared reference' that is
>> using a single concept for entries in multiple languages.
>>
>
> Yes. The context of discussing translation with multiple targets was for a
> situation where a direction between one source language expression and
> multiple target language expressions (into different target languages) need
> to be recorded. This is not possible with shared reference (because this
> comes without directionality) and I see no way to do that in OntoLex other
> than encoding the relation between each source and target expression pair
> independently. Semantically, this is fine, but it is verbose.
>
> Take the first entry of https://www.springer.com/de/book/9789020116670
> and assume that we wanted to encode that English is the source (first
> entry, defines organization of dictionary) that is translated into four
> languages:
> Abelian group | abelsche Gruppe | groupe abélien | abelse groep | абелева
> группа
>
> criteria:
> number of triples and objects
> +-direction (encodes translation direction)
> +- metadata (allows to provide source metadata)
>
> OntoLex modelling
> Shared reference: 1 ontolex:LexicalConcept, 5 ontolex:evokes properties
> (-direction, +metadata [at concept])
> vartrans:translation (non-reified): 4 vartrans:translation properties
> (+direction, -metadata)
> vartrans:Translation (reified): 4 vartrans:Translation objects, 8
> vartrans:relates (vartrans:source/vartrags:target) properties (+direction,
> +metadata)
>
> alternative modelling
> *vartrans:Translation (n-ary): 1 vartrans:Translation object, 5
> vartrans:relates (1 vartrans:source, 4 vartrags:target) properties
> (+direction, +metadata)
>
> The difference here is reified binary Translations require at least double
> as many triples as reified n-ary Translations and I can see why people
> would like to avoid that. However, this is an issue only if the direction
> of translation needs to be recorded, because in terms of space complexity,
> shared reference is equivalent with n-ary Translation.
>
> If such a use case for multilingual data with one source language and a
> large number of target languages does exists, where direction matters and
> verbosity is an issue, it is probably safest to *not* use the OntoLex
> vocabulary directly, but to create my:NAryTranslation as a subclass of
> ontolex:LexicalConcept with properties my:source and my:target as
> subproperties of ontolex:isEvokedBy and use these instead of the vartrans
> vocabulary.
>
> Cheers,
> Christian
>