Wikidata:Property proposal/is exception to constraint

is exception to constraint edit

Originally proposed at Wikidata:Property proposal/Generic

Not done

Description	(used as qualifier) there are valid reasons why this statement shouldn't be subject to the constraint
Data type	Item
Allowed values	property constraint (Q21502402)
Example 1	Saint Petersburg (Q656) category for people born here (P1464) Kategorie:Births in Petrograd (Q18665174) → single-value constraint (Q19474404)
Example 2	Saint Petersburg (Q656) category for people born here (P1464) Category:Births in Saint Petersburg (Q13392612) → single-value constraint (Q19474404)
Example 3	MISSING

Motivation edit

At the moment we have plenty of constraints with a lot of violations. A good portion of those constraint violations are justified. For many properties the amount of valid constraint violations is too large to list them all on the property in the constraint section. If we would have a way to tag the valid constraint violations it will be easier to spot the constraint violations that we care about and based on which we should take actions to rectify them.

Notified participants of WikiProject property constraints ChristianKl ❪✉❫ 13:37, 18 June 2020 (UTC)[reply]

Discussion edit

I don't think this is the right solution, as a property may have multiple constraints of the same type and currently it is not possible to refer to a specific statement. See phab:T236295 as a proposal to extand Wikibase data model.--GZWDer (talk) 13:46, 18 June 2020 (UTC)[reply]

@GZWDer: Can you give examples where a property has multiple constraints of the same type and it would be a problem to mark it as an exception of one of the constraints and not the other? ChristianKl ❪✉❫ 14:24, 18 June 2020 (UTC)[reply]

@ChristianKl: See Property:P18.--GZWDer (talk) 15:19, 18 June 2020 (UTC)[reply]

@GZWDer: image (P18) indeed has multiple instances of the formatter constraint. I however don't see any cases where it's desireable to declare an expection to one of them and not the others. ChristianKl ❪✉❫ 15:23, 18 June 2020 (UTC)[reply]

Weak oppose; it seems that we should rather improve the constraint definition itself, e.g. by using a single-best-value constraint (Q52060874) instead of single-value constraint (Q19474404). Managing this *in items* does not seem to be a good idea to me. ---MisterSynergy (talk) 12:28, 19 June 2020 (UTC)[reply]

@MisterSynergy: Using single-best-value constraint (Q52060874) more widely does help with some problems, but there's currently no equivalent for distinct-values constraint (Q21502410). ChristianKl ❪✉❫ 22:51, 19 June 2020 (UTC)[reply]

A separator (P4155) could help to solve such situations much better than just an exception marker. —MisterSynergy (talk) 22:56, 19 June 2020 (UTC)[reply]

The description of separator (P4155) suggests that it's only for single value constraints. Does it work for more then just that constraint? If so, it would likely be good to update the property description. ChristianKl ❪✉❫ 12:00, 20 June 2020 (UTC)[reply]

Well yes, it does not seem to work for distinct value constraints. We do have a couple of such definitions, which made me think that it does work. Needs to be cleaned up, I guess.
Yet, there can (and should) be other means to solve these cases. Simply stating that this claim "is exception to (some) constraint" is not very meaningful. For distinct value constraints, one could perhaps better simply use identifier shared with (P4070) as a generic qualifier that suppresses constraint violations. ---MisterSynergy (talk) 08:08, 22 June 2020 (UTC)[reply]

Not, all constraints are mandatory. If you for example take the format constraint (Q21502404) on image (P18) there are plenty of exceptions that are fine. It seems noting those on the represented items is cleaner then noting them in the property.

Not all distinct value are identifiers and identifier shared with (P4070) doesn't even indicate that the value is a valid exception. ChristianKl ❪✉❫ 11:10, 22 June 2020 (UTC)[reply]

@Lucas Werkmeister (WMDE): What do you think about making separator (P4155) also work for distinct values? ChristianKl ❪✉❫ 11:10, 22 June 2020 (UTC)[reply]

If it does not work at the moment, I am not sure whether we should make it work. There is definitely need to handle "unfixable" constraint violations better, but please let's not do it with a unsemantic one like you propose here. ---MisterSynergy (talk) 11:34, 22 June 2020 (UTC)[reply]

@ChristianKl, MisterSynergy: It would probably be possible to support separator (P4155) for distinct-values constraint (Q21502410), though it may make the underlying SPARQL query less efficient. I haven’t yet made up my mind whether I like the suggestion or not. --Lucas Werkmeister (WMDE) (talk) 13:05, 23 June 2020 (UTC)[reply]

I think that could be useful for some constraints/combinations, e.g. distinct-values constraint (Q21502410) on taxon name (P225). I wouldn't apply in general, especially not to the sample currently given in the proposal (category for people born here (P1464) → single value constraint (Q19474404)). --- Jura 08:23, 27 June 2020 (UTC)[reply]
@ChristianKl, GZWDer, MisterSynergy, Lucas Werkmeister (WMDE), Jura1: Not done Stale and unsupported. Please reference this discussion if there's a new proposal for this. ArthurPSmith (talk) 16:54, 14 January 2021 (UTC)[reply]