Re: [lexidma] Relational remodeling: the diagram

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

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.
• I am using some more general classes ('entry relation', 'sense relation', 'form', 'morphosyntactic property') that can be subtyped into more specific types ('Headword', 'SubentryOfEntryRelation')
• 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')

Regards,

John

On 08/02/2021 17:31, Michal MÄchura wrote:

Hi all,

Here (see attachment) is an entity-relationship diagram which combines the two reports Iâve done on relational remodelling. A couple of notes to guide you through it:

• The main data types are entries and senses. Iâm sure every IT person will be happy to see that the list of senses inside an entry is always a flat list (there is no hierarchical embedding), that there are no such things as subsenses and subentries (at least not formally, as separate data types) and that every sense inside each entry is guaranteed to be about the entryâs headword and not about something else. On the other hand, lexicographers should be happy to see that phenomena such as subsensing and subentries can still be captured here, just not as embedding hierarchies but as relations.

• An entry can contain data like headword and POS (top left), and a sense can contain data like definitions, translations and examples (top right). We will have to flesh out what those are, but this shouldnât be difficult. A lot of good thinking on this has been done in Elexis already.

• In the bottom half of the diagram you see three data types for the three relations which allow us to record the fact that, going from right to left (1) a sense is to be shown to the end-user as a subsense of another sense, (2) an entry is to be shown to the end-user as a subentry inside a sense of another entry, and (3) an entry is to be shown to the end-user as a subentry of another entry.

• Depending on the formalist you choose for your implementation or serialization (relational database, RDF, XML, JSONâ), the three relations can be implemented as three tables in a relational database (like in this diagram) or as something else. I have drawn the diagram as if I was planning an implementation in a relational database. I donât know how to draw it more abstractly than this. (Incidentally, the fact that foreign keys â attributes like ChildSenseID etc. â are explicitly mentioned in the diagram means that strictly speaking it isnât an ER diagram. But I thought it was useful to have them there anyway, to make it obvious from their names who the child is and who the parent is.)

• Senses and relations have a ListingOrder (= a sort key) which determines their order when presented to the end-user. This means that (1) inside an entry, its senses and subentries can be shown in a given order and (2) inside a sense, its subsenses and subentries can be show in a given order.

To summarize, this diagram expresses what I was arguing for in my last two reports. The idea is that we remodel some embedding phenomena as relations, and by doing that, we create an IT-friendly data model, with flat lists, with fewer data types and with relations between them.

M.

â

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php