[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: LEXIDMA comments
Hi all,
Some more comments:
I have also created a converter in Rust for DMLEX that supports XML, JSON and RDF. You can try it here
https://jmccrae.github.io/dmlex-converter/
Source code is at
https://github.com/jmccrae/dmlex-converter
Regards,
John
Hi all,
Here are some further comments (based on working with the standard more closely)
- It is not explicitly stated which elements are expected/able to have an `id` property
- The `member` tag uses `memberID` for the `id` rather than `id`. This means it could have both a `memberID` and an `id`, right?
- `obverseListingOrder` is mandatory on `member`. I don't think we want this and in fact all examples omit this.
- `role` is mandatory on `memberType` but not on `member`. The comment suggests that this can be empty, but why not omit it entirely for relations without roles?
- `collocateMarker` can have `label`s. I think this is quite tricky to parse in the XML as there is a mix of string content and technical content, can we not make it an attribute in the XML?
- Whitespace rules in the XML are not clearly defined. For example consider this
- ÂÂÂÂÂÂÂÂÂÂÂ <exampleTranslation>
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ <text>
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ Koroner <collocateMarker lemma="provÃst">provedl</collocateMarker>
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ <headwordMarker>pitvu</headwordMarker>.
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ </text>
ÂÂÂÂÂÂÂÂÂÂÂ </exampleTranslation>- How do we know that the whitespace is a single character between 'provedl' and 'pitvu', while the whitespace before 'Koronoer' and after '.' is not part of the translation?
Regards,
John
On 02/11/2023 14:01, John McCrae wrote:
Hi all,
Some comments on things I noticed going through the spec
- I don't have an email address listed as an editor
- Do we really want to allow lexicographic resources with zero entries? Similarly, entries with zero senses?
- Many JSON examples are missing (Ex 10, 26)
- The property soundFile is allowed to be a filename. How do ensure portability in this case? Shouldn't we restrict to to URIs?
- The tags have multiple "for" properties, e.g., forHeadwords. Do we have restrictions on how these may be combined, e.g., can a inflectedFormTag apply to headwords or translations or languages. Would it not make sense to combine this into a single property with values, e.g., instead of forHeadwords=true have for="">
- I don't understand the uniqueness constraint in 4.3.2. Can this be made clearer?
- In 4.4.8 the list of properties in the text and the JSON seem to be contradictory
- 4.5.2. Can we add a restriction of at least one description or etymon
- The definition of InflectedFormTag (and several others) seems to list different properties in the serializations
- Examples should also be presented in RDF. Perhaps we can make a quick converter to validate and generate examples in multiple serializations.
Regards,
John-- John P. McCrae (he/him; #startsWithAName John (rhymes with "gone") McCrae (rhymes with "hay") /dÊÉn mÃkÉeÉ/) Assistant Professor - SFI Insight Centre for Data Analytics, Data Science Institute & Computer Science, University of Galway-- John P. McCrae (he/him; #startsWithAName John (rhymes with "gone") McCrae (rhymes with "hay") /dÊÉn mÃkÉeÉ/) Assistant Professor - SFI Insight Centre for Data Analytics, Data Science Institute & Computer Science, University of Galway
-- John P. McCrae (he/him; #startsWithAName John (rhymes with "gone") McCrae (rhymes with "hay") /dÊÉn mÃkÉeÉ/) Assistant Professor - SFI Insight Centre for Data Analytics, Data Science Institute & Computer Science, University of Galway
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]