Help talk:Property constraints portal/Unique value
Relation to single value edit
@Ivan A. Krestinin: I’m not sure about the relationship between this constraint type and “single value”.
- Does this constraint imply a “single value” constraint?
- If an item has the same value for a “unique value” property twice, is that a violation of this constraint, or only a violation of the “single value” constraint?
--Lucas Werkmeister (WMDE) (talk) 13:08, 30 May 2017 (UTC)
- All constraints are independent. "Single value" checks number of values of the property in every item. Any item with values count >= 2 violates this constraint. Item with duplicated value violates both "single value" and "unique value". "Type" constraint checks instance of (P31). Item can have multiple instance of (P31) values. Results of subclass check are aggregated using OR operation. — Ivan A. Krestinin (talk) 15:59, 30 May 2017 (UTC)
Unique value per namespace edit
I am not sure if that would be a new constraint or a parameter within this one, but occasionally we have properties which should be unique but are being added to both article and category items for the same concept, for example Commons category (P373). In such a case it might be easier to find issues if we allow one copy per namespace. --Jarekt (talk) 19:38, 28 June 2017 (UTC)
- I think I see the problem you mean, but I’m not sure I understand the solution you propose. How do we know that it’s okay for Douglas Adams (Q42) and Category:Douglas Adams (Q8935487) to have the same Commons category (P373)? Wikidata items don’t have different namespaces as far as I’m aware, both of these are just regular items. --Lucas Werkmeister (WMDE) (talk) 12:02, 29 June 2017 (UTC)
Default scope edit
Notified participants of WikiProject property constraints
@Jura1, Pintoch, ChristianKl, Hsarrazin, Salgo60, PKM: With the deployment, the default constraint scope (P4680) of this constraint type was changed from “everywhere” to only constraint checked on main value (Q46466787). --Lucas Werkmeister (WMDE) (talk) 13:48, 15 February 2018 (UTC)
A 'separator' qualifier would be useful edit
@Ivan A. Krestinin, Lucas Werkmeister (WMDE): Per User:Jarekt above, a 'separator' qualifier on this property would be useful, to allow different items to have the same value if they are noted as being items with different roles.
For example, after discussions with subject-experts today, it was recommended that property OpenDomesday settlement ID (P3118) should both both to a {{|Q486972}} that matches the target, and to the {{Q|2116450)} which encompassed that settlement. Either could be argued to be the 'actual' primary entity that Domesday describes.
Similarly, as Jarekt noted above, standard procedure for Commons category (P373) would be for it to be on both Douglas Adams (Q42) and Category:Douglas Adams (Q8935487) -- that presence on both was the very purpose for which the property was invented, to compensate for only one being able to have the sitelink. So it should be possible to organise that that should not be marked a violation; whereas additional use on any other item connected with Adams should be.
The 'separator' mechanism (eg 'separator' = subject has role (P2868)), which works so well on the 'single value constraint', would seem a good way to achieve this. Jheald (talk) 21:43, 11 June 2022 (UTC)
- @Jheald: As far as I’m aware, this should be supported, see T277855. I guess we forgot to update this documentation page at the time; can you try out if it works? Lucas Werkmeister (WMDE) (talk) 09:13, 13 June 2022 (UTC)
- @Lucas Werkmeister (WMDE): Thanks, yes, that worked. Jheald (talk) 05:44, 15 June 2022 (UTC)
- Alright, I’ve added it to the documentation. Thanks for checking! Lucas Werkmeister (WMDE) (talk) 10:34, 15 June 2022 (UTC)
- @Lucas Werkmeister (WMDE): Thanks, yes, that worked. Jheald (talk) 05:44, 15 June 2022 (UTC)