Open main menu

Property talk:P5972


word in another language that corresponds exactly to this meaning of the lexeme
Representstranslation (Q7553)
Data typeSense
DomainSense (note: this should be moved to the property statements)
According to this template:
  • dog (en) → chien (fr)
  • chien (fr) → dog (en)
According to statements in the property:
no label (L3302-S1)no label (L189-S1)
When possible, data should only be stored as statements
See alsoitem for this sense (P5137)
Proposal discussionOriginally created without a formal discussion
Current uses881
Search for values
  Allowed entity types are sense (Q54285715): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P5972#allowed entity types, SPARQL (new)
  Scope is as main value (Q54828448): the property must be used by specified way only (Help)
List of this constraint violations: Database reports/Constraint violations/P5972#scope, hourly updated report, SPARQL, SPARQL (new)
  Conflicts with “subclass of (P279): this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P5972#Conflicts with P279, search, SPARQL, SPARQL (new)

constraint “symmetric constraint (Q21510862)” declaration error: “the constraint is not applicable to datatype “Sense””.

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Translation as property and queryEdit


Do we really a property for translation? More exactly what is the difference between :

  • LXXX P5972 LYYY


  • LXXX P5137 QZZZ
  • LYYY P5137 QZZZ

Point-blank I don't see a difference, this seems exactly equivalent to me and the second method seems better to me (as we need to store item for this sense (P5137) anyway). At the very least, maybe we can add some constraints based on this equivalence.

@Tubezlob, Mfilot, Infovarius, KaMan, Jura1:

Cheers, VIGNERON (talk) 07:53, 8 November 2018 (UTC)

@VIGNERON: That's true as long as we agree to create items for all parts of speech. There seems similar discussion at Wikidata_talk:Lexicographical_data/Archive/2018/11#Translations. KaMan (talk) 08:05, 8 November 2018 (UTC)
I think it all depends on how one uses it. For experiments, it can be good to list all translations for "January", but overall 3 variants between the same language pair could be more interested. Personally, I rather see a statement than a translation in the "gloss" field.
Furthermore P5137 statements make it hard to view the other lexeme. Obviously, the GUI on all these could use some more development. --- Jura 08:15, 8 November 2018 (UTC)

The assumption is that translations are not necessarily transitive, and that they don't always form a mutually translatable perfect group of Lexemes (in which case the star-based method off P5317 would be better). I do agree that using P5972 when we already have P5317 is problematic and leads to all the problems that interwiki maintenance had previously - I would preferably say to use P5972 only if P5317 is problematic. (Just as we can still can have explicit interwiki links in the Wikipedias). Does this make sense? --Denny (talk) 15:28, 8 November 2018 (UTC)


This property was nominated for deletion and kept. Multichill (talk) 20:32, 27 May 2019 (UTC)

Return to "P5972" page.