Property talk:P1889

From Wikidata
Jump to navigation Jump to search


different from
item that is different from another item, with which it is often confused
DescriptionThis item is different from that one, and they are often confused. In contrast to said to be the same as (P460) that expresses uncertainty "... the statement is disputed", different from expresses a strong negation. This property is used by some Wikidata tools to prevent an eventual merge of items involved.
Representsdifference (Q10862449)
Data typeItem
Corresponding templateTemplate:Distinguish (Q6458914)
Domainany item (note: this should be moved to the property statements)
Allowed valuesany item (note: this should be moved to the property statements)
ExampleKowalski (Q3199417)Kowalski (Q17128875)
Charles Pratt (Q3373540)Charles Pratt (Q42156264)
Robot and gadget jobs
  • Check that the two items do not have the same authority identifier (AAT, TGN, ULAN, VIAF, GND, etc). The "Unique value constraint" on these identifiers already checks this (eg see P245 (ULAN) Unique value), but together with an explicit claim "different from", we can split that section into "Delete authority identifier from one of the items" vs "Merge the two items".
  • Check that the two items are not subject of the same statement: if Q1 different from Q2, there should be no statements Q3 P1 Q1 and Q3 P1 Q2. Of course, that's a warning not a certain mistake.
Tracking: usageCategory:Pages using Wikidata property P1889 (Q62391044)
See alsoopposite of (P461), family name identical to this given name (P1533), said to be the same as (P460)
  • <items with the most statements of this property>
  • Count of items by number of statements (chart)
  • Count of items by number of sitelinks (chart)
  • Items with the most identifier properties
  • Items with no other statements
  • <most recently created items>
  • Items with novalue claims
  • Items with unknown value claims
  • Usage history
  • Chart by item creation date
  • Database reports/Constraint violations/P1889
  • <random list>
  • Proposal discussionProposal discussion
    Current uses375,414
    Search for values
    [create Create a translatable help page (preferably in English) for this property to be included here]
    Symmetric property: if [item A] has this property linked to [item B], then [item B] should also have this property linked to [item A]. (Help)
    Exceptions are possible as rare values may exist.
    List of this constraint violations: Database reports/Constraint violations/P1889#Symmetric, SPARQL, SPARQL (new)
    Qualifiers “criterion used (P1013), object has role (P3831), valid in place (P3005), statement disputed by (P1310), from narrative universe (P1080), located in the administrative territorial entity (P131): this property should be used only with the listed qualifiers. (Help)
    Exceptions are possible as rare values may exist.
    List of this constraint violations: Database reports/Constraint violations/P1889#Allowed qualifiers, SPARQL, SPARQL (new)

    Distinguishing related items[edit]

    I have two questions about using or not using this property for items which are related anyhow, for example by being in the same subclass hierarchy.

    • The table above advises to "check that the two items are not subject of the same statement: if Q1 different from Q2, there should be no statements Q3 P1 Q1 and Q3 P1 Q2." This could indicate that Q1 and Q2 are the same after all, but it does not need to be so, for example when Q3 is a subclass or instance of two different, but intertwined concepts. Classification of human knowledge is not always that exact.
      Does the advice also apply when those statements are the other way around, Q3 being on the right side of the statements instead of the left side, like Q1 and Q2 being both different instances or subclasses of the same concept? For example, brass band (Q3244156) and fanfare orchestra (Q11264216) could be confused because bands with only brass instruments (no saxophons) are also called fanfara in some languages.
    • The advice says nothing about a direct relation between the two items (Q1 P1 Q2). Normally, such a relation would describe the difference between the two concepts, so there is no reason for this property. But what if the relation is only mentioned on one of the two items? When Q1 is a subclass or instance of Q2, this is usually not mentioned on the Q2 item page, so there is still room for confusion. The reason I bring this up is this edit by Infovarius, see also User talk:Infovarius#Wind orchestras.

    Best regards, Bever (talk) 03:07, 16 March 2017 (UTC)

      • The advice about Q3 is strange indeed. Such items of course can be different instances of subclasses. About reverse relation, I'd say that if there's some P1 between Q1 and Q2 hence P1889 is not needed in Q1, but can be needed in Q2. --Infovarius (talk) 11:58, 22 March 2017 (UTC)

    opposite of (P461) vs. inverse property (P1696)[edit]

    See the equivalent section on ; exact same problem here.

    I acted and removed the two incorrect claims, as I said on the other page I would have loved to correct it instead (and use opposite of (P461)) but the entity search engine while in edit mode won't let me.

    For the meantime, we're better off without a false claim.

    Eledeuh (talk) 03:03, 14 May 2017 (UTC)

    What is "inverse of"? Wikidata property example for properties (P2271), for example, said: part of (P361) inverse property (P1696) has part (P527). But part of (P361)=superset (Q15882515), has part (P527)=subset (Q177646). superset (Q15882515) opposite of (P461) subset (Q177646). Thus, we have example of opposite of (P461). --Fractaler (talk) 11:37, 17 May 2017 (UTC)
    Here I'm mostly interested in properties, as opposed to entities. As I said, this section is a mirror of another here:
    Basically, opposite of (P461) is typically used for ontologically opposed concepts (A & !A for instance). To stay on topic, "said to be the same" is about a non-strict equality relationship between two concepts while "different from" is about the non-equality of two concepts, we can say that "said to be the same" is the opposite of "different from" (theoretically there should be a "said to be different from" I guess).
    inverse property (P1696) however is used as a reciprocality marker, as you noted "has part" vs. "part of", they both represent the exact same relationship, just from a different referential. If we were to be practical, the "opposite of" types of properties cannot be reduced, they have different meanings ; the "inverse of" types of properties can be reduced, they have the exact same meaning, and I suppose their existence is more of a design compromise in the property tree for navigational purposes than anything else.
    Eledeuh (talk) 05:23, 18 May 2017 (UTC)

    Why is this section on the talk page of different from (P1889) ?
    --- Jura 05:37, 18 May 2017 (UTC)

    Because there used to be a claim such that different from (P1889) -> inverse property (P1696) -> said to be the same as (P460), I removed it since, as I stated at the beginning of this very section. --- Eledeuh (talk) 11:48, 18 May 2017 (UTC)
    Ok. Good idea to remove it. You can't use opposite of (P461) as its value needs to be a Q, not a P.
    --- Jura 17:57, 18 May 2017 (UTC)
    Huh, good to know. Thanks for the info! --- Eledeuh (talk)

    Suppress constraint on symmetry[edit]

    I suggest that we get rid of the symmetry constraint - having one item stating that it differs from the other is sufficient, IMHO. The violation report lists about 3000 violations. -- LaddΩ chat ;) 19:50, 29 July 2017 (UTC)

    BUT if we are placing this for users to visibly see then having it on one side alone is not sufficient. Then which way would you prefer that it is done. I will note that the use for authority controls is also important as I have seen numbers of application of these duplicated for the wrong person, and it helps explain your action without saying something on a talk page.  — billinghurst sDrewth 03:52, 1 January 2018 (UTC)
    Perhaps, identical human names indeed warrant reciprocity, but there are other cases where it's unnecessary. Say, a smaller, less known entity is confused with a larger, and better known one. It only works one way. The Steno-Cassette was and is called 'micro cassette' but is different from the far better known Microcassette (that's how I ended up here, after sorting the micro-mess at Commons). In this case, one-way P1889 would be appropriate. Retired electrician (talk) 00:50, 6 September 2019 (UTC)
    Should be always symmetrical. So that merge are impossible and people knowing why. For instance Paris, Texas and Paris, France (we in France have hardly heard about Paris, Texas...)Bouzinac (talk) 09:55, 6 September 2019 (UTC)
    I'm incomplete agreement with Retired electrician, the symmetry constraint is entirely too rigid for a property that treats on relationships between entities where there is no implicit scope on what those entities could be. The example they offered is quite illustrative but I'll offer one myself as well: I placed the property on CMake with a value of GNU Make. The significance (for those without software development experience) is that GNU Make is a much older program, in fact the archetype for source code compilers. CMake is a much newer invention that simplifies and automates the use of GNU Make, often obviating the need to interact with it at all, which easily gives the impression that CMake could represent an organic stage of Make's natural evolution as a tool; in fact there is no common lineage between them and the assumption would almost certainly never occur to those whose initial knowledge was with Make, owing to the fact that the older tool necessitates a more granular understanding of the processes at work.
    The flaw with imposing this restraint is that it assumes a symmetry that is in truth not often seen in nature. Especially when it comes to matters of disambiguation, quite often the potential misunderstanding is borne largely by those more closely associated with the more widespread knowledge set. To use it as a safeguard against errant merges strikes me as somewhat specious, as is should be quite simple to configure the backend to intervene if either entity has the other as a value for this property just as easily as for the condition that they both have each other as the value. 🐈⚞ogueScholar⚟🗨₨UserTalk 19:51, 10 October 2019 (UTC)

    "different to" or "different from"[edit]

    Jc86035 (talkcontribslogs) changed the label from "different from" to "different to". Jc86035 also improved the description, but used the "different to" wording. I have never heard "different to". The American Heritage Dictionary 3rd ed. (1992), in a usage note following the entry for "different" states

    Different from and different than are both common in American and British English. Critics since the 18th century have singled out different than as incorrect, thoug it is well attested in the work of reputable writers....

    Since the longstanding version has been "different from", and this is supported by a quality dictionary, it should not be disturbed. If Jc86035 wants to cite sources to change the en-gb label to "different to", have at it. Jc3s5h (talk) 16:45, 20 December 2018 (UTC)

    @Jc3s5h: Oxford Dictionary of English (built-in, macOS; and online) says "[...] Different to is common in Britain, but is disliked by traditionalists. The argument against it is based on the relation of different to differ, which is used with from; but this is a flawed argument which is contradicted by other pairs of words such as accord (with) and according (to)." It also says "In practice, different from is both the most common structure, both in British and US English, and the most accepted.", so I'll leave the labels as they currently are. Jc86035 (talk) 17:42, 20 December 2018 (UTC)

    Allowed values[edit]

    Being able to set an item as different from (the same Q number it itself is) would seem to negate any statement being made and is semantically useless, it would seem to me. Arlo Barnes (talk) 04:24, 23 January 2019 (UTC)

    I agree. Jc3s5h (talk) 13:01, 23 January 2019 (UTC)