Talk:Q21502410

Question

If there are two claims that have the same subject - property - object but have different qualifiers, would these violate the unique values constraint? For example,

• statement 1: Q356062 (ADPC protein)-- P680 (molecular function) -- Q14762611 (microtubule binding) with qualifier P459 (determination method) to Q23174122 IDA (inferred from direct assay).
• statement 2: Q356062 (ADPC protein)-- P680 (molecular function) -- Q14762611 (microtubule binding) with qualifier P459 (determination method) to Q23190881 IEA (inferred from electronic annotation).

--I9606 (talk) 18:55, 24 September 2016 (UTC)

@I9606:. I think the constraint reports skip them or Ivan A. Krestinin can set them to skip them. BTW, it might better to ask him this on his talk page.
--- Jura 10:17, 3 October 2016 (UTC)

See Help:Property constraints portal for more information. Multichill (talk) 16:30, 24 December 2017 (UTC)

Identifier shared with

I've just discovered the existence of identifier shared with (P4070). I know it is possible to qualify single-value constraint (Q19474404) with separator (P4155)identifier shared with (P4070) in order to report that, if an item has two different identifiers, one without identifier shared with (P4070) and one without identifier shared with (P4070) (or, otherwise, one with a value of identifier shared with (P4070) and one with a different value of identifier shared with (P4070)), it is not an error. My question is: is there a way to report that, if two different items have the same identifier with qualifier identifier shared with (P4070) pointing to each other, it is not an error? This would solve constraint violations such as Q6832525#P2694. Thank you all! --Epìdosis 10:40, 20 January 2020 (UTC)

Unicity by date (or some other criteria)

There are numerous example where the unicity of the property value is true only at each instant (date and time) Unicity violations are reported when several distinct items share the same value, but one of the items was replaced by another one, while keeping most of its properties, inclusing those that should be distinct.

This constraint should then check if there are "start date" and/or "end date" qualifiers for the property (the alternative being that the distinct items have "replaced by"/"replaces" properties and "dissolution date"/"foundation date", provided that the dates do not overlap, which happens sometimes when an entity is progressively transfered to another one with a transition period between the foundation of a new entity and the dissolution of the former one with the transfer fully completed to the newer one).

Notably this is needded for various classes of "unique identifiers".

Is there a way to

• allow the addition of "start date" and "end date" qualifiers, to resolve distinctness violations by date, or
• allow the addition of one or more "criter used" qualifiers (with the items using the distinct property value having distinct sets of values for these "criter used" qualifiers)?

I think it's much preferable prefer using explicit date (or other criteria) to the previous proposal using "shared by" (with no criteria at all, so with no clear indication on how choose which item to use for a given property value supposed to be distinctive, when in fact they are distinct only in some scope of use: at a specific date, or for a specific function, or region of application, or branch of activity, or in some classification).

Many "distinct" items are considered distinct only for one authority that created that distinctive value, considering it as a single item. But in reality, science and knowledge evolves and classifications too with more precision added: what was a single item (with a distinctive value like an identifier) becomes a class of items, or several competing classes of items (in different classifications for other domains).

---

In fact Wikidata makes too much effort trying to distinguish "instances and classes" and should consider everything is a class ("instances" of a class are just "subclasses" of a class: they can be reinstanciated, by considering these classes are not "final"). This complicates everything in Wikidata, with lot of duplicated entries. We should not have both "nature of element/instance of" and "subclass of", we just need "subclass of" for everything. Distinction between instances of a class would just turn into distinction between subclasses of the same class. And whever we can specifiy an item B as a property value of any other item A, should not depend on the fact that B is an instance of T or a subclass of T, but only on how T is defined, as a class (whever T has some required property defined or not defined, with a specific value that can be used as a criteria).

In wikidata, NO class should be "final", every class could be derived (rather than instanciated). The result would be much more coinsistant and much easier to maintain for evolutions. This is the safest approach used for data modeling in Javascript, Lua... and not the old broken approach used by C/C++/Java and by Wikidata (based on ease of implementation for compilation of programs, a complete non-sense for Wikidata for human knowledge). We don't need "instances" at all in Wikidata (it's highly preferable to mark classes as "final" when we know that items have for now no derivatives, but this is always temporary to the extent of current knowledge or the limiting scope of a field of study).

Thanks. Verdy p (talk) 14:25, 14 April 2020 (UTC)

refers to different subject

if a statement is deprecated with reason refers to different subject (Q28091153), it should no longer be flagged as a duplicated identifier.

deprecating a value instead of deleting it is a common strategy to make sure the incorrect value isn't added again, and removing the flag once this is done would encourage this behavior. Binarycat32 (talk) 19:20, 18 January 2024 (UTC)