lexidma — archive

Relational remodeling: the diagram

From: John McCrae <[email protected]>
To: [email protected]
Date: Mon, 15 Feb 2021 13:19:00 -0000

Hi Milos, On 15/02/2021 13:01, MiloÅ JakubÃÄek wrote: Hi John, On Wed, 10 Feb 2021 at 14:06, John McCrae < [email protected] > 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</ Definition Translation> </Definition> <Example> bar < Example Translation>bar in German</ Example Translation> </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