Re: [lexidma] Relational remodeling: the diagram

[John McCrae <john.mccrae@insight-centre.org>]

Hi all,

I have an editable link to my version of the diagram here:

https://drive.google.com/file/d/1B0xD77HjZFlHVTQlCNw2fLs7OOvV5P0U/view?usp=sharing

I have updated it with the vocabulary shared by Carole.

Regards,

John

On 15/02/2021 13:19, John McCrae wrote:

Hi Milos,

On 15/02/2021 13:01, MiloÅ JakubÃÄek wrote:

Hi John,

On Wed, 10 Feb 2021 at 14:06, John McCrae <john.mccrae@insight-centre.org> wrote:

Hi Michael,

I was working on my own diagram that I put here:

I think we are on a similar path, although there are some difference in modelling

• I am kind of assuming that every element can have an ID and some way of making child elements.

Yes but not a obligatory ID. May I recall that best IDs are natural IDs and we should not enforce artificialÂIDs where they are not necessary.

Sure, I think we agree here.

• I allow elements to appear in many places, e.g., examples can be of entries, senses, collocation, so I use structure over specific classes ('CollocationExampleTranslation')

That's an absolutely unwanted feature from the processing point of view. One of the reasons to make the model is to avoid things like this, especially as they are not necessary to convey the associated information.Â

E.g. a translation can be of many things of course -- but it is different type of translation and it should be exactly specified like that.

Actually, I am not sure which view you are supporting here.

The difference is between (in XML notation) reusing 'Translation' e.g.,

<Definition> foo <Translation>foo in German</Translation> </Definition>

<Example> bar <Translation>bar in German</Translation> </Example>

versus introducing specific types:

<Definition> foo <DefinitionTranslation>foo in German</DefinitionTranslation> </Definition>

<Example> bar <ExampleTranslation>bar in German</ExampleTranslation> </Example>

Both are fine and have different advantages/disadvantages. The former leading to a smaller and hence easier-to-implement model, the latter allows more specification, should we need to have a different set of properties of a translation in different contexts. I lean towards the former, but we should evaluate what makes the most sense in terms of requirements and applications of the model.

Regards,

John

Best

Milos