OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

lexidma message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [lexidma] IDs


Good news: MiloÅ and I have just ironed out some last-minute details about the ID story.

The working draft which is in the repository now (PDF here) is what weâll be voting on in a moment. So, if anyone wants to give it a final skim-through, now's your chance.

M.


pà 8. 9. 2023 vÂ8:31 odesÃlatel Michal MÄchura <462258@mail.muni.cz> napsal:
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 <milos.jakubicek@sketchengine.eu> 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


On Mon, 4 Sept 2023 at 15:39, Michal MÄchura <462258@mail.muni.cz> 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]