Wikidata:Property proposal/reverse lemma

From Wikidata
Jump to navigation Jump to search

reverse lemma[edit]

Originally proposed at Wikidata:Property proposal/Lexemes

   Not done
Descriptionlabel of lemma written backwards
Representsreverse dictionary (Q1304223)
Data typeString
Domainlexemes, at least in scripts where it can be useful.
Example 1windsurf (L4) → "frusdniw"
Example 2octogone (L800) → "enogotco"
Example 3data (L2013) → "atad"
Example 4test (L397) → "tset"
Robot and gadget jobscan be bot maintained

Motivation

Make it easy to search lexemes by their endings. Even tough this is computable, I don't think it would work efficiently for retrieving.
--- Jura 11:31, 29 June 2018 (UTC)[reply]

Discussion

  •  Comment What would be the purpose of this exactly? How would you use it? We don't even have SPARQL for Lexemes yet; this seems like something you could do when we have SPARQL but maybe not? Also, if really needed, shouldn't we have it on each form, not just on the lemma? ArthurPSmith (talk) 16:39, 29 June 2018 (UTC)[reply]
    • @ArthurPSmith: Nouns which decline a certain way and verbs that conjugate a certain way are easier to pick out when you can specify the last characters of their lemmas. Mahir256 (talk) 16:58, 29 June 2018 (UTC)[reply]
      • @Mahir256: I thought handling conjugations and declensions was the purpose of conjugation class (P5186)? Is there some expectation that you could search based on some kind of reverse auto-completion? But that would require dev support. I'd like to see a concrete example of how anybody would make use of this property. Particularly if it won't be available for forms but only the main lemma, as Jura has requested here. ArthurPSmith (talk) 17:47, 29 June 2018 (UTC)[reply]
    • I hesitated about Forms. If the need arises, maybe we could do that, but I'd limit this to lexemes/lemmata. We could obviously wait till all features are available before we start using Lexemes, but this isn't really the chosen approach.
      --- Jura 17:03, 29 June 2018 (UTC)[reply]
  •  Oppose I think these are better stored internally (as a read-only RDF triplet for SPARQL purposes, only recomputed whenever someone changes a lexeme/form, maybe?), rather than as explicit properties of the lexemes/forms. Mahir256 (talk) 16:58, 29 June 2018 (UTC)[reply]
    • I don't think there is such a function and we have similar properties for soundex and the like. If it would ever be available, we could remove this.
      --- Jura 17:03, 29 June 2018 (UTC)[reply]
  •  Oppose as entirely computable. @Jura1: Do you remember Wikidata month number? It only ever saw very limited use and its purpose was eventually deprecated by unrelated backend optimisations in SPARQL. I would wait till SPARQL for Lexemes become live to decide whether live searching for the endings of Lexemes would be a problem. Deryck Chan (talk) 10:33, 2 July 2018 (UTC)[reply]
    • For this to work, some tools to query Lexemes obviously need to work. This can be SPARQL, but it might eventually work with standard search. BTW, did you try to find items with an English label ending with "yck"? Is there just one or is it just that this can't be done in SPARQL?
      --- Jura 04:41, 8 July 2018 (UTC)[reply]
  •  Oppose If there is sufficient interest in suffix-search, this can be implemented in Cirrus search and/or the RFC export for WDQS. If there is no sufficient interest to support this, it's unlikely that that this property would see sufficient usage to make this useful. -- Duesentrieb (talk)
  •  Oppose I see no need for storing explicitly such an easily and trivialy computable data. And even if we would need it, it should be on form level, not on lexeme level. Cdlt, VIGNERON (talk) 14:39, 19 July 2018 (UTC)[reply]
  •  Not done, no support − Pintoch (talk) 09:30, 7 September 2018 (UTC)[reply]