Closed michmech closed 5 months ago
Suggestion: Explain in the text why we prohibit subentrying by recursion and why we prefer to model subentries through relations. Explain that the relations can be used to trigger software into rendering the entries and subentries as a hierachy for the human editors.
I thought about it a little more and I now think that there is no need for us to explain in the text why we prohibit subentrying by recursion and why we prefer to model subentries through relations. That sort o argumentation belongs in a different type of document, not in the spec itself. The spec should say how the data model is organized, not argue why it is organized that way.
As for explaining that relations can be used to trigger software into rendering the entries and subentries as a hierarchy for humans, we already do that, in effect: some of the examples (in appendix A.1) come with a suggested rendering for human users.
No further action is required, in my opinion. I suggest to close this issue.
(Submitted by Bob Boelhouwer)
A distinctive feature of DMLex is that all entries are at the same level. There are no subentries. The main argument for this is that it is computational more efficient. But, I’m not sure of for modern computational equipment this is a significant advantage. An argument for using embedding structures is that editors working on compiling a dictionary would prefer to have an overview of all the submeanings and collocations that can make up an entry. Moreover, they will have a better indication of how what the entry will look like when presented to the public.