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: Recent edits


Hi all,

I'm sending you a preview of the edits I have made to our draft, based in the various bits of feedback I have received. Some of the modules have undergone a major rewrite, so please read this carefully. The major changes are:

- I have cleaned up the names of datatypes and properties mentioned throughout the text, removed inconsistencies, and even changed the names of some of them.

- I have simplified how we handle controlled vocabularies/look-up values in the Core. Instead of having many separate datatypes for the different kinds of controlled vocabularies, we now only have one datatype (called Tag). The fact that some look-up values apply to part-of-speech labels, some apply to inflection labels and so on, is represented in DMLex as business rules which implementors can choose to enforce or not to enforce. I have come to the conclusion, after thinking about it long and hard, that it's better to do it like this because we will end up having a simpler, easier-to-understand, easier to implement object model with fewer types, which is exactly what software developers like to see!

- The Linking Module has also been simplified in a similar fashion. Instead of having many datatypes for many different kinds of relations based on their arity and directionality (SenseSet, SensePair, SenseTuple...) we now only one datatype (called Relation). Constraints on the number and types of the objects that are participating in these relations are expressed in DMLex as business rules which impementors can choose to enforce or not. Again, my motivation for this change is simplicity, where by simplicity I mainly mean having as few datatypes as possible â even i it means that some constraints now have to be represented as business rules instead of being baked right into the datatype system.

- I have become convinced that, in addition to monolingual and bilingual dictionaries, we need to support multilingual ones as well, where there is one source language and multiple target languages. So I have split the Bilingual Module into two, a Bilingual Module and a Multilingual Module. These two modules are mutually exclusive: impementors can implement one or the other but not both.

I hope you will be broadly in agreement with these changes. I apologize to those who are working on serializations: some of these changes may be game changers for you, depending on how far advanced you are.

The files I am sending you are PDFs, generated from Markdown files I am using internally for writing (because writing straight into DocBook is too difficult for me). I am going tol convert it all into DocBook and submit it as a GitHub pull request in time for the next meeting.

M.

Attachment: 04-multilingual.pdf
Description: Adobe PDF document

Attachment: 05-linking.pdf
Description: Adobe PDF document

Attachment: 06-inline-markup.pdf
Description: Adobe PDF document

Attachment: 03-bilingual.pdf
Description: Adobe PDF document

Attachment: 02-core.pdf
Description: Adobe PDF document



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