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
