Adding pronunciation to examples.

[fcbond]

Currently Pronunciation is only defined for
lemmas. However, it would be worthwhile to add
it to Example, for the following reasons (summarized from Bond, 2025).

Some wordnets are being developed with language teaching (TUFS) or maintenance (Abui, Cantonese) in mind. All of these have recorded data for example sentences.

• Having pronunciation, especially audio, helps language learners. By
  hearing how words sound in full sentences, learners can better understand how they flow together
  and how stress and rhythm work in natural speech, improving their fluency and pronunciation (Lew,
  2011, pp255–266).
• For language documentation, where the orthography may not be fully standardized, having audio
  recordings of example sentences preserves the authentic pronunciation and prosody of the language, especially in
  cases where writing systems might not fully capture the phonetic details or where different writing systems coexist.

Francis Bond. 2025. Adding Audio to Wordnets. Proceedings of the 13th International Global Wordnet Conference (GWC2025). (Note: non-final version)

[goodmami]

Thanks for this context. I thought your proposal was hypothetical and didn't realize you have a paper about it and data available. My argument in #86 (comment) was that we shouldn't add a feature if we don't have an immediate need for it.

I'm still somewhat hesitant because I'm concerned about feature creep in the format, especially because I'm the only regular maintainer of Wn (which is essentially a hobby).

That said, if we're considering places where we might want to include audio, it would be the linguistic content (word forms, examples, definitions, but not relations, tags, counts, etc.). Given that, I think your proposal covers it except for ILIDefinition, but due to it being an "interlingual" definition (albeit invariably in English for practical reasons), I'd argue that we should not provide a pronunciation there.

[jmccrae]

I think this would be essentially little more than extending the places where the existing <Pronunciation> element can appear. Currently, it can only appear for <Lemma> and <Form> but @fcbond would like to allow this to appear for <Definition> and <Example> elements too.

I would say that this should not be too much of a technical change and not that hard to implement.

I would also share some of @goodmami's concern that this is not intended to be a format that is universal for all wordnets, but an interoperable core to support resources like CILI. We want to avoid too much feature creep if we can.

[goodmami]

I would say that this should not be too much of a technical change and not that hard to implement.

Yes, the change to the format is mostly* straightforward. I'm more concerned with the work involved with Wn: adding 3 new tables to the schema, adding new SQL query functions, adding methods to the Python API, updating the LMF reader and exporter, adding documentation and tests, and maybe exposing endpoints in the web API. A few lines changed in the DTD could mean days of work for me.</complaint>

* The <Definition> and <Example> elements have #PCDATA as their child element, so if we add additional XML elements it would become mixed content:

- <!ELEMENT Definition (#PCDATA)>
+ <!ELEMENT Definition (#PCDATA | Pronunciation)*>

The | and * are mandatory here, and it means you can have any number and any order of PCDATA sequences and <Pronunciation> child elements under <Definition>.

[goodmami]

@jmccrae and @fcbond, any thoughts on how to deal with the mixed content? e.g.,

  <Definition>
    without musical accompaniment
    <Pronunciation variety="GB">...</Pronunciation>
    <Pronunciation variety="US">...</Pronunciation>
  </Definition>

Results in these elements:

• text: \n without musical accompaniment\n
• Pronunciation element (GB)
• text: \n
• Pronunciation element (US)
• text: \n

Or the equally-as-valid:

  <Definition>
    <Pronunciation variety="GB">...</Pronunciation>
    without
    <Pronunciation variety="US">...</Pronunciation>
    musical accompaniment
  </Definition>

• text: \n
• Pronunciation element (GB)
• text: \n without\n
• Pronunciation element (US)
• text: \n musical accompaniment\n

For the interpretation of these in an application, I would suggest we do whitespace normalization similar to HTML such that we end up with a single text node without musical accompaniment, and all <Pronunciation> elements pertain to the entire definition and not for particular substrings. At least, when xml:space="default".

When xml:space="preserve", however, I'm not really sure what to do about intervening elements. Maybe pretend they aren't there but preserve the whitespace around them? In this case, the text for these two examples would be:

• \n without musical accompaniment\n \n \n
• \n \n without\n \n musical accompaniment\n

[jmccrae]

@fcbond, @goodmami Do we want to implement this for the 1.4 release? Otherwise I can accept the current PRs and make the release without this.

[goodmami]

@jmccrae @fcbond did you have any thoughts about the consequences of making the elements mixed-content or my proposal for dealing with it?

Otherwise, if the data that requires this change will not be released imminently, such as with OMW 2.0, then I'm happy to defer it to the next schema version so we can proceed with the OMW 2.0 and Wn 1.0 releases.