different from item that is different from another item, with which it may be confused
Description
This 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.
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.
Latest comment: 7 years ago2 comments2 people in discussion
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.
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)Reply
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.
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.
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. — billinghurstsDrewth03:52, 1 January 2018 (UTC)Reply
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)Reply
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)Reply
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⚟🗨₨UserTalk19:51, 10 October 2019 (UTC)Reply
There are many usecases when we should show that some class A is not its subclass B, but obviously B:P1889=A is redundant (as we have P279 already). The same for some other properties. --Infovarius (talk) 11:41, 13 April 2020 (UTC)Reply
Since the last comment here, over 100,000 new constraint violations have been created and they account for 10% of all the uses of this property. Looking at pairs of items, 3/4 have statements in both directions, 1/4 only have a statement in one direction. It seems that in practice, people don't think this property has to be symmetric. - Nikki (talk) 06:00, 16 May 2024 (UTC)Reply
Sounds like people are lazy and don't worry too much about warnings (certainly there are plenty of nagging warnings I disagree with and ignore). On balance I think its useful as a warning, but should not be an error. I'd hope a person could glance at a Label/Description pair list and fix most of them. 100000 violations in 5 years is manageable. Vicarage (talk) 08:27, 16 May 2024 (UTC)Reply
Latest comment: 6 years ago2 comments2 people in discussion
Jc86035 (talk • contribs • logs) 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)Reply
@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)Reply
Latest comment: 3 years ago3 comments3 people in discussion
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)Reply
Agreed as well. This should produce some error when someone tries to say an entity is different from itself. Can someone who knows how implement this? {{u|Sdkb}}talk07:04, 4 July 2021 (UTC)Reply
Latest comment: 4 years ago17 comments2 people in discussion
Hello, I tried to harvest templates to populate different from (P1889) with the 'Distinguish' Template from enwiki. It is however impossible to make changes since there is a symmetric violation constraint. So it is impossible to industrialize and populate P1889 (at least with harvest templates). Bouzinac (talk) 20:52, 8 April 2020 (UTC)Reply
Salut Jura1, even with symmetric constraint removed, the harvest won't function 145th Street station (IRT Lenox Avenue Line) → Q2015285 → Constraint violation: symmetric violation Bouzinac (talk) 09:06, 12 April 2020 (UTC)Reply
Tjs le même blocage de symmetric violation... (existe t il un paramétrage genre "ne s'applique que si on a tenté de rentrer l'info à la main" ) ?Bouzinac (talk) 09:21, 12 April 2020 (UTC)Reply
A mon avis, cette contrainte ne sert pas trop .. J'ai essayé avec [1] et reçois le même résult .. Peut-être il faut attendre à ce que la mise à jour se propage .. --- Jura09:34, 12 April 2020 (UTC)Reply
Si, cette contrainte de symmétrie sert, car in fine, si A est différent de B, B doit être renseignée en différent de A (mais pas pile poil au moment du renseignement :) ) Bouzinac (talk) 09:40, 12 April 2020 (UTC)Reply
A la limite, oui. Autre source d'étonnement : quickstatements permet l'enregistrement de P1889 sans être bloqué par la symmetric constraint. Mais Harvest template, lui "respecte" cette contrainte....? Bouzinac (talk) 11:10, 12 April 2020 (UTC)Reply
function checkConstraints(pageid, qid, value, ii) {
Dans le javascript du projet harvesttemplate, on a ce code là , y a peut être moyen de glisser une exception P1889 ? j'ai déposé un msg sur le github du projet [2] :
var claim = createClaim(value);
$.getJSON('https://tools.wmflabs.org/plnode/cc',{
entity: qid,
claim: claim,
constraints: 'all'
}).done(function(data) {
if (data.violations == 0){
addValue(pageid, qid, value);
} else {
report(pageid, 'error', 'Constraint violation: ' + data.problems[0]['text'], qid);
}
}).fail(function(err) { //likely because of WQS query limit
report(pageid, 'error', 'failure while checking constraints', qid);
console.log(err.responseJSON.error);
delay = 5000;
});}
– The preceding unsigned comment was added by [[User:|?]] ([[User talk:|talk]] • contribs).
Latest comment: 3 years ago1 comment1 person in discussion
I'd like to suggest adding a type constraint that prevents something from being both instance of (P31) (synonym "is") and this property (synonym "is not"). After all, X is Y and X is not Y cannot be simultaneously true. -Thunderforge (talk) 19:10, 1 November 2021 (UTC)Reply
Create a conflicts-with property constraint amongst P460 and P1889?
My question is, when an item currently has both properties, which property should be used (depending on whatever criteria you have in mind)? --- Jura16:59, 3 March 2022 (UTC)Reply
There can be multiple situations when a conflicting property constraint would occur:
I think said to be the same as (P460) already implies that it's doubtful ("some reference considers them to be the same" or "we aren't sure that they are the same, but it's likely").
sort -t, -k 2 query1.csv | sed -Ee 's`http://www.wikidata.org/entity/``;s`,`\t`' | uniq -D -f1 | \
sed -Ee 's`(.*)\t(.*)`\2,\1`' | awk -F , '{ d[$1] = d[$1] == "" ? $2 : d[$1] ":" $2 } END { for (k in d) { split(d[k],a, \
":"); for (i in a) for (j in a) if (i != j) printf "%s|P1889|%s\n", a[i], a[j] } }'
Latest comment: 1 year ago7 comments6 people in discussion
Hi! Inspired by yesterday presentation of @Mahir256: at WikidataCon 2023 about how to reduce Wikidata's size without loosing content (video), I was wondering about some maybe-not-so-useful statements of different from (P1889), specifically:
My question is: do we need them all, only a part of them, or we can delete them all (also through constraints)? Opinions are welcome. --Epìdosis10:29, 30 October 2023 (UTC) P.S.Reply
I've always felt that WD's combination of label+description needs less disambiguation than wikipedias that only have labels, and we are better having targeted disambiguations. So while Warwick Castle might need enwiki disambiguation for its use as castle, locomotive, ship or painting in a wikipedia, we only need to distinguish between ships of the same name, and separately paintings, with tailored use of this property. I've never felt comfortable with saying X can be confused with an X disambiguation page, so would be happy if they all went. A bot could assess whether any class pairs were close enough to record here. PS, where in the 8 hour recording is the relevant talk? Vicarage (talk) 15:13, 30 October 2023 (UTC)Reply
@Epìdosis, Vicarage: My view is that if 1000 different from (P1889) statements help to prevent even a single bad merge, then they have more than earned their keep.
A couple of interesting queries, worth running if you believe in en:Chesterton's fence, are to look at what reasons are given as qualifiers on different from (P1889) statements pointing to items for dab pages ( https://w.wiki/7x$t ); and at which classes items with such statements most commonly belong to ( https://w.wiki/7x$x ).
As for the rest, there's nothing that is worth the time spent doing it, and even taken all together they're just a drop in the bucket compared to wikidata's total number of statement. The time and energy would be far better spent on continuing to build the project -- it's not as if we are short of either material to add or material to fix, a far more valuable use for our work. Jheald (talk) 18:46, 30 October 2023 (UTC)Reply
Seconded! The "different from" statements will at least slow down some bad merges (though I have seen editors remove the "different from" statements and then merge anyway). - PKM (talk) 01:31, 31 October 2023 (UTC)Reply
The same story for categories and templates. Those (not very numerous!) "different from" statements have goal to emphasize the difference between very confusing pairs and to prevent bad merges and bad sitelink moves. --Infovarius (talk) 20:02, 31 October 2023 (UTC)Reply
, different from (P1889) 
Notified participants of WikiProject Disambiguation pages 
Notified participants of WikiProject Data Quality (and may we need a WikiProject dedicated to data redundancy?) --Epìdosis 10:30, 30 October 2023 (UTC)