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.
â
|
