Make Synset.ili an optional string; add wn.ili module

[goodmami]

Is your feature request related to a problem? Please describe.

The Synset.ili attribute returns an ILI object. Before, this caused problems when trying to use it directly in a call, like wn.synsets(ili=ss.ili). Recent versions allow this to work as well, but it might still be good to simplify things.

Describe the solution you'd like

Instead of returning an ILI object, Synset.ili would just return a string or None. In order to get ILI status, definitions, or metadata (which is really metadata of the ILI definition), we could have an wn.ili module with relevant methods. I suspect that people rarely get these kinds of data, so it's probably fine to tuck it in a module.

Additional context

This would be a breaking change, so best to only do it once for the v1.0 release.

[goodmami]

@fcbond do you know if anyone is inspecting the ILI objects from Synset.ili?

[goodmami]

If we're breaking things, then I might take this opportunity to change it so the ILI metadata becomes the metadata of the definition, as it is in WN-LMF. That means we'd need an ILIDefinition class to contain it.

[fcbond]

Hi, as far as I know, only I am inspecting ILI objects, so changing the interface a little would be fine. Should we also think about allowing other identifiers (like wikidata)? I don't have a concrete proposal, just musing I'm afraid.

…

On Tue, 14 Oct 2025 at 04:30, Michael Wayne Goodman < ***@***.***> wrote: *goodmami* left a comment (goodmami/wn#282) <#282 (comment)> If we're breaking things, then I might take this opportunity to change it so the ILI metadata becomes the metadata of the definition, as it is in WN-LMF. That means we'd need an ILIDefinition class to contain it. — Reply to this email directly, view it on GitHub <#282 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIPZRUYFTT5COTVIA6EX4T3XRN4RAVCNFSM6AAAAACJC6NOAGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJZHA4DANJYG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Francis Bond <https://fcbond.github.io/>

[goodmami]

@fcbond thanks for the feedback!

Should we also think about allowing other identifiers (like wikidata)?

We talked about alternative (i.e., non-CILI) ILI identifiers, like for Wikidata or Geonames, in globalwordnet/english-wordnet#1126. While I initially proposed using them with the ili attribute (e.g., <Synset ... ili="Q123"...>), I think you were right in suggesting this wouldn't be tenable, such as for words with both an identifier in CILI and in Wikidata/Geonames. To handle these, we could propose a schema change in https://github.com/globalwordnet/schemas/ for WN-LMF 1.5 or later. I'm not sure if we should make a new attribute for each identifier scheme:

  <!-- Prague -->
  <Synset id="oewn-08775759-n" ili="i82908" geo="3067696" wikidata="Q1085" ...>

... or find some other way to annotate them.

Or maybe we shouldn't be annotating them in the Wordnets at all? I notice that Wikidata has links to CILI as well as Geonames (and many others), so we probably shouldn't be duplicating that work.

[fcbond]

I think the use case I imagine is, we want to make a wordnet of place names, so we can treat them in the same we we do open class words, e.g. to do do consistent WSD. Then if we do this for multiple languages, we need something to say that this synset in Language A is the same as that in language B. For normal words, we can use ILI, but then for the names we need an interlingual identifier, and the obvious choice would be to use wikidata (or geonames).