How do we want to handle unverifiable information?

[kyrieb-ekat]

@mailynmailyn
For example, a language that doesn't have records or reference in Wikidata, a name which is sourced by word-of-mouth, etc. This is the official thread for discussing possible approaches.

Currently:

• users can only select languages that exist in Wikidata's language list (has a wikidata ID/object)
  • OBJECT?: make a unique language object "other" which prompts them to enter their language name?
    • Do we want to deal with this? Could get unmanageable and political (recognized minority languages)
      -STATEMENT? Make an additional statement (such as the boxes under an item describing them as an Instance of Musical Instrument) which has Property: [Language/Dialect of] [Region/Language/Group] with sublabel [(str)User entered language]?
• Wikidata has to be the ones to add languages
  • Do we allow items to be added to Wikiadata until they exist in Wikidata? For example, retain the unverified language on the UMIL page while we lobby Wikidata for adding this language, if verified, push to Wikidata, if not...?

Additional problem: edits made in a language none of the moderators/editors understand- what if LLMs disagree on translation? What if conflicting results on lookup/other translation services?

In Wikidata we can build out a nuanced statement block, wherein the source can be us UMIL Database and our descriptors will then be linked, and when clicked will go to UMIL for viewing; we can add subfiuelds to it further describing the item ("unverified") etc. However, this will require some deliberate property picking and structuring so the item returns as a language in a sparql query alongside the existing labels; this approach will not have this added new/unverfieid language name show up as an instrument label, rather as an instance of other language "name" (src)UMIL.

This is just a starting point, other points for discussion will be how to handle sources etc.

[dchiller]

I think we should only have languages that are in Wikidata. It would be one thing if we were trying to have our own separate lexicon, but we are trying to improve Wikidata's. If there is a language not on Wikidata that should be, for whatever reason, then that should happen outside of any UMIL-related workflow.

edits made in a language none of the moderators/editors understand- what if LLMs disagree on translation? What if conflicting results on lookup/other translation services?

I'm skeptical that this can be our job. We can make a good-faith effort (use the tools we have available), but we ultimately are focused on facilitating Wikidata editing, which someone could do without this anyway.

[kyrieb-ekat]

Right; re the latter it's ultimately us putting forward our best attempt, but I think implementing a method to flag it as something like "we've confirmed it's nothing crude" to be added under our aegis might be helpful, or with a property-entity statement conveying as much. Alternatively, we just on the UMIL entity page put information about how we try to vet everything, etc etc as a kind of disclaimer to that end, as well as on UMIL itself maybe?

Language problem then might be where, if their language isn't in wikidata, we send them to wikidata first, or give them a "sorry, check back later" message? They do have a process for adding new languages, but I think it's a bit involved.

[dchiller]

a method to flag it as something like "we've confirmed it's nothing crude" to be added under our aegis might be helpful

Agreed. We can be more lenient on things like "here's an alternate name in this language that none of us know and an LLM is unsure about" and more strict on "this isn't spam/inappropriate"