lexidma — archive

IDs

From: Michal Mechura <[email protected]>
To: [email protected]
Date: Fri, 08 Sep 2023 06:32:00 -0000

I have just reviewed MiloÅ's changes and I agree with them (with a few details which we will probably iron out by midday today). The idea behind these changes is that, at the model level, we do not prescribe that any objects must have explicit IDs. Instead we describe how the identity of an object can, in the context of its parent, be computed from its properties. That's what we say at the model level. In the serializations, implementers are free to introduce things like ID attributes on XML elements or ID columns in database tables if they want to, and they can decide whether the values of these should be arbitrary or computed dynamically. I think this is a clever generalization which accommodates a wide variety of approaches and "ideologies" implementers might have for handling IDs, and if we're voting, I'm voting in favour :-) M. pÃ 8. 9. 2023 v 4:07 odesÃlatel MiloÅ JakubÃÄek < [email protected] > napsal: I had a long(ish) discussion around this with Michal today (erm, yesterday) and we agreed for a slightly different approach where instead of IDs we actually qualify the uniqueness of the relevant properties, leaving it largely up to the serializations how to handle that. This -- as well as relevant descriptions for optional roots and fragment identification are now merged, as well as the UML diagram and plenty of small fixes (logos, build, typos, ...). Hopefully the discussion tomorrow is not going to be very long ;-) Best Milos Milos Jakubicek CEO, Lexical Computing Brno, CZ Brighton, UK http://www.lexicalcomputing.com http://www.sketchengine.eu On Mon, 4 Sept 2023 at 15:39, Michal MÄchura < [email protected] > wrote: These object types have IDs already (at the model level): entry sense collocateMarker The IDs are always optional. Their purpose is relation membership : to make it possible for objects of these types to be involved in relations. Now that we have decided that we want other object types to have IDs too (for addressing if not for relation membership ) I propose to add optional IDs to the following object types: inflectedForm definition pronunciation transcription example headwordTranslation headwordExplanation exampleTranslation relation etymology etymon etymonUnit M.