Wikidata talk:WikiProject property constraints/Archive 2

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Redundancies in (value) type constraint definitions

SELECT DISTINCT ?property ?propertyLabel ?constrLabel ?class1Label ?class2Label {
  VALUES ?constr { wd:Q21503250 wd:Q21510865 } .
  ?property p:P2302 [ ps:P2302 ?constr; pq:P2308 ?class1, ?class2 ] .
  FILTER( ?class1 != ?class2 ) .
  ?class1 wdt:P279+ ?class2 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" } .
} ORDER BY ?propertyLabel ?constrLabel

Try it!

One class is subclass of another. What can we do about these? Matěj Suchánek (talk) 06:45, 21 June 2018 (UTC)

Not sure if something needs to be done. Hierarchies change and type constraint checks only check a limited number of levels.
--- Jura 07:04, 21 June 2018 (UTC)
Thanks for this query. I was not aware that there are so many redundant constraints. In some cases it might be okay, e.g. group of humans (Q16334295) will probably not forever be a subclass of organization (Q43229). But in other cases I have the feeling the constraints were only added to get the type statistics on the database report, c.f. National Library of Spain ID (P950) --Pasleim (talk) 09:31, 21 June 2018 (UTC)

Multiple value type constraint relations?

At this time we have as possible relations for value type constraints in a property only "instance of", "subclass of" and "instance of or subclass of", so we always have only one "value type constraint" statement in the property. What does happen if we add another relation, and thus another "value type constraint" statement? In the case this could prove useful, the item has to satisfy BOTH constraints or AT LEAST one of the two? --Ogoorcs (talk) 12:13, 21 July 2018 (UTC)

@Ogoorcs: If multiple constraints are defined, they are always checked independently of each other, so if you add multiple value type constraints, violations for either or both of them will be reported independently (there will be constraint violations if at least one of them is not satisfied). There are already a few properties with multiple value type constraints, e. g. office held by head of state (P1906) (query). --Lucas Werkmeister (WMDE) (talk) 11:58, 23 July 2018 (UTC)

I guess that this AND default is the reason we have only three type of constraint: one for P31, one for P279 and one that check for the presence of at least one of the two, so an OR. Are there any plans to add OR constraints for properties different from P31 and P279? There are items that need them in order to correct "potential errors" about their properties, like Tomb of the Diver (Q464384), which needs collection (P195). --Ogoorcs (talk) 22:47, 24 July 2018 (UTC)

Constraint errors

There is a constraint error at Property talk:P3896 for Commons link constraint (Q21510852). Is there a different constraint which is applicable to geoshape (P3896)? Jc86035 (talk) 15:55, 1 August 2018 (UTC)

format constraint (Q21502404). Matěj Suchánek (talk) 07:02, 2 August 2018 (UTC)

@Matěj Suchánek: That also results in an error. Jc86035 (talk) 20:10, 2 August 2018 (UTC)

It shouldn't anymore. Matěj Suchánek (talk) 07:05, 3 August 2018 (UTC)

Should cCommonsLinkapplicable also contain geo-shape and tabular-data? I think it'd be appropriate since they both generate Commons links. Jc86035 (talk) 09:24, 3 August 2018 (UTC)

This constraint is used on properties like Commons category (P373), Commons Creator page (P1472) etc. which don't include the namespace prefix in the value. But geoshape (P3896), weather history (P4150) etc. do include it. So if this isn't problem, the suggested change can be applied. Matěj Suchánek (talk) 09:29, 3 August 2018 (UTC)

Unrelated, but presently it appears that citation-needed constraint (Q54554025) and one-of qualifier value property constraint (Q52712340) are not being accepted as valid constraints for some reason (an error is showing on Property talk:P5523). Jc86035 (talk) 16:12, 1 August 2018 (UTC)

Module:Constraints needs to be updated. Matěj Suchánek (talk) 19:57, 1 August 2018 (UTC)

Added citation-needed constraint (Q54554025). The other one is not sufficiently documented. Matěj Suchánek (talk) 07:02, 2 August 2018 (UTC)

You can now query the constraint violations with the Query Service

Hello all,

We started integrating the constraint violations into the Query Service. That means you can build queries using the constraint violations, with the predicate wikibase:hasViolationForConstraint. This will hopefully help you to watch better the quality of Wikidata content.

Please note that this is a first step. Not all constraint violations are exposed yet, only the ones that can be checked fast enough. We're working on having more available in WDQS.

You can base your queries on these few examples:

#10 statements with constraint violations that are currently included
SELECT * WHERE {
?x wikibase:hasViolationForConstraint ?y.
} LIMIT 10

Try it!

#Map/timeline/image grid of items that have a statement with a constraint violation
#defaultView:Map
SELECT DISTINCT ?item ?itemLabel ?image ?coordinate_location ?point_in_time ?date_of_birth WHERE {
  ?s wikibase:hasViolationForConstraint ?y.
  ?item ?z1 ?s.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  OPTIONAL { ?item wdt:P18 ?image. }
  OPTIONAL { ?item wdt:P625 ?coordinate_location. }
  OPTIONAL { ?item wdt:P585 ?point_in_time. }
  OPTIONAL { ?item wdt:P569 ?date_of_birth. }
}

Try it!

#Bar chart of statements that have a constraint violation, grouped by instance of the regarding item:
#defaultView:BarChart
#TEMPLATE={ "template": { "en": "Bar chart of statements that have a constraint violation grouped by ?property the regarding item" }, "variables": { "?property": { "query":"SELECT ?id  WHERE { VALUES ?id {  wd:P31 wd:P17 wd:P571 wd:P361 wd:P19 } }" } } }
SELECT ?instance_ofLabel (COUNT(?instance_ofLabel) AS ?count) WHERE {
  ?s wikibase:hasViolationForConstraint ?y.
  ?item ?z1 ?s.
  BIND(wdt:P31 AS ?property)
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  OPTIONAL { ?item ?property ?instance_of. }
}
GROUP BY ?instance_ofLabel
ORDER BY DESC(?count)
LIMIT 30

Try it!

The modules included on the property talk pages, Module:Constraints, Module:Constraints/SPARQL etc. has been updated with a new query link (thanks Matěj!)

Distinct best value constraint?

@Lucas Werkmeister (WMDE), Ivan A. Krestinin:

As some identifiers get re-assigned, should we create a constraint for this? Within values with best rank, each value should be unique. Items that no longer have a value (old value has an end date), would get "no value" with preferred rank.

It can be compared with Help:Property constraints portal/Single best value created recently.
--- Jura 15:21, 11 August 2018 (UTC)

Single value constraint

Spotify track ID (P2207) currently has single-value constraint (Q19474404). Is it possible to require a part of (P361) qualifier if there is more than one value? Jc86035 (talk) 09:13, 13 August 2018 (UTC)

@Jc86035: would adding part of (P361) as a separator (P4155) achieve what you want? See Help:Property constraints portal/Single value for details. --Lucas Werkmeister (WMDE) (talk) 10:52, 13 August 2018 (UTC)

@Lucas Werkmeister (WMDE): I think so, thanks. Jc86035 (talk) 10:54, 13 August 2018 (UTC)

as main value (Q54828448) and category contains (P4224) or is a list of (P360)

@Lucas Werkmeister (WMDE), Ivan A. Krestinin, Matěj Suchánek:

A problem with "as main value (Q54828448)" is that most properties could be used as qualifiers for category contains (P4224) or is a list of (P360).

These properties are not necessarily useful as qualifiers elsewhere.

Maybe these could be whitelisted as the use with Wikidata property example (P1855).
--- Jura 22:18, 20 August 2018 (UTC)

@Jura1: the whitelist you mention means that we don’t check any constraints on qualifiers of Wikidata property example (P1855) and related properties, because the “Wikidata property example” properties all twist the data model around in a way where qualifiers don’t really mean what they usually mean… technically, it wouldn’t be a problem to add more properties to that list (Matěj Suchánek just added the two new example properties for senses and forms in gerrit:449017), but I’m not convinced that’s necessary. Is it really true that almost any property can be used as qualifiers for those two properties? Can you perhaps show a few examples? Because I don’t yet see how that would make sense. --Lucas Werkmeister (WMDE) (talk) 12:24, 21 August 2018 (UTC)

I don't think all other checks should be de-activated as well. Samples: Q9695035, Q23044622. It does concern mainly item-datatype properties, but not exclusively.
--- Jura 12:35, 21 August 2018 (UTC)

Better suggestions for constraint values on properties

Hello all,

Currently, when adding a new value in the constraints section of a property, there is no suggestion to fill the value or the qualifier. We’ve been improving this by a few changes that are going to be deployed this week.

When adding a new value in the property constraint statement, a list of suggestions will be displayed and, all the relevant constraint items will be showed first. They will be selected among the list of qualifiers present in the statement “property constraint -> one of constraint” of property constraint (P2302).
Of course, you can still type anything you want in the field to find a value. The full text search has been improved (when typing “none constr” you will also see “none of constraint” in the suggester)

In a very near future, we will also make the following happen:

Same behavior for qualifiers inside the constraint statements. The suggester will pick up the values from “allowed qualifiers constraint”
When clicking on “add value” in the property constraint statement, a suggester menu will directly appear (without having to click on the value field)

The first two changes will appear on wikidata.org on August 30th, the following ones in the next weeks. Feel free to make some tests, and let us know if you find a bug or something that doesn’t behave as expected.

Related tickets: phab:T199672, phab:T201288.

Thanks, Lea Lacroix (WMDE) (talk) 13:03, 28 August 2018 (UTC)

Q25796498 Contemporary constraint

Hey all, we need to write something about the recently activated contemporary constraint (Q25796498) at Help:Property constraints portal/Contemporary. I still don’t fully understand how this works, so can someone please start? phab:T141859 might be interesting. (@Abián: FYI since we discussed about this constraint on your talk page recently.) —MisterSynergy (talk) 14:29, 25 September 2018 (UTC)

It seems to work. Good addition. I added a few tests in the sandbox:

Thanks for this. --- Jura 15:26, 25 September 2018 (UTC)

Citation needed constraint

Is it possible in some way to exclude P143-(pseudo)sourced statements? This constraint is a one step forward, but there is a little difference between unsourced statement and P143-pseudosourced statement, and a huge difference between these two and a properly sourced statement. Wostr (talk) 01:24, 4 November 2018 (UTC)

Request for comment

At Wikidata:Requests for comment/Inverse constraint on cause-and-effect properties. Thanks, Swpb (talk) 14:11, 5 February 2019 (UTC)

[Breaking change] "wbcheckconstraints" API new result status

Hello all,

This is an announcement for a breaking change to the output format of the WikibaseQualityConstraints constraint checking API, to go live on 6 May 2019 (most likely around noon UTC). It affects all clients that use the wbcheckconstraints API action.

We are adding a new status for constraints, in addition to regular constraints and mandatory constraints: suggestion constraints indicate possible improvements to a statement, but are not inherently problematic like other constraint violations. This implies a new status for constraint results as well: in addition to 'violation' for violations of mandatory constraints and 'warning' for violations of regular constraints, as well as several statuses that are not violations, there is now 'suggestion' for violations of suggestion constraints. The default value of the status API parameter is changed to include this status as well (from violation|warning|bad-parameters to violation|warning|suggestion|bad-parameters), and it can appear as the "status" of a result in the response.

API consumers that are not interested in suggestion constraints can specify a non-default value for the status API parameter, e. g. the old default violation|warning|bad-parameters, to avoid getting responses including this status. Others should decide how to handle it, and update their code accordingly if necessary.

According to our stable interface policy, the change will be enabled 4 weeks after this announcement, on May 6th, and a test system will be set up latest on April 17th on test.wikidata.org.

If you have any question or issue, let us know in the related ticket. Cheers, Lea Lacroix (WMDE) (talk) 12:24, 8 April 2019 (UTC)

New status of constraint: "suggestion"

Hello all,

As you may know, we currently have two levels of property constraints: mandatory constraints and "normal" (non-mandatory) ones. In order to allow more flexibility and subtlety in constraints definition, we are going to introduce a new constraint level, suggestion. This way, editors can distinguish the really crucial constraint violations from the ones that only suggest additional edits that would be nice to make.

When setting up a constraint rule, you could define it as a suggestion by adding a qualifier to the constraint definition statement with the property constraint status (P2316) and the value suggestion constraint (Q62026391).

The suggestion constraint would get a specific icon to make it clearly different from the mandatory and non-mandatory constraints. The current icons look like this:

The feature will be enabled on May 6th. Starting from this date, you will be able to define constraints as suggestions and they will be displayed as such for all logged-in users.

Please note that this is the first roll-out of the feature, some issues may appear. You are also very welcome to give feedback, if some things are not working as you wish they would, we can still fix them. In that case, feel free to ping me or write a comment in the related ticket.

Thanks to the people who made this request, this feature was suggested during one of the “pink pony session” at Wikimania and we hope that you will enjoy it!

Cheers, Lea Lacroix (WMDE) (talk) 12:17, 8 April 2019 (UTC)

Perhaps "violation" isn't the best term for constraint "hits" any more? --Marsupium (talk) 20:37, 8 April 2019 (UTC)

Update: the change is now deployed! You can now add suggestion constraint (Q62026391) as constraint status (P2316) on constraint statements. The notification icon will be an flag, unless a mandatory or ordinary constraint is already listed, in that case its icon will appear.

If you have any question or issue, feel free to ping me or raise it in the ticket. Thanks, Lea Lacroix (WMDE) (talk) 12:10, 6 May 2019 (UTC)

Distinct case-insensitive values

Some of our identifier properties are case-insensitive: this is for instance the case for DOI (P356), Twitter (X) username (P2002), Facebook username (P2013), Instagram username (P2003) and probably quite a few others.

We could enforce that their values are stored in lower or upper case and rely on distinct-values constraint (Q21502410), but this might not be desired as these values often have a preferred casing.

Are there established processes in the curation of these properties to deal with this issue? − Pintoch (talk) 09:56, 22 May 2019 (UTC)

Related bot request, to normalize the case of Twitter ids: Wikidata:Requests_for_permissions/Bot/PintochBot_5. − Pintoch (talk) 11:04, 24 May 2019 (UTC)

Complex constraint exception needed

The value-requires-statement constraint (Q21510864) on instance of (P31) should not apply when the value is an instance of (P31) taxon (Q16521), since this is inherently a subclass. E.g. Livingston (Q50421806)instance of (P31)Pterois volitans (Q824672). I don't know how to make such a constraint, or if there is a more appropriate way to express such a fact without creating a violation. Thanks! Swpb (talk) 18:57, 19 July 2019 (UTC)

Study on property constraints

Notified participants of WikiProject property constraints I'm proposing for a Rapid grant a study on property constraints that would analyze Wikidata data and would conduct surveys on the use and understanding of constraints. If you have any questions about the proposal, please feel free to ask me, and if you would like to participate in the survey, please let me know! Thanks in advance. :-) --abi án 11:53, 24 September 2019 (UTC)

Sounds very interesting. I'm interested in participating in the study. Peter F. Patel-Schneider (talk) 16:09, 24 September 2019 (UTC)

"different from property"

Certain properties should not duplicate other properties (e.g. it is inappropriate when described at URL (P973) is present for it to have the same URL as official website (P856), same for subclass and instance). Is there a constraint that can do that? Circeus (talk) 14:07, 22 May 2019 (UTC)

I thought described at URL (P973) was specifically designed for direct links to official documents, documentation or simple text. official website (P856) links do domains instead. Can you provide a superposition example? Ogoorcs (talk) 12:53, 3 November 2019 (UTC)

External identifiers

Hi All,

I wrote a proposal about expanding the statements regarding external identifiers, please have a look and add your opinions: https://www.wikidata.org/wiki/Wikidata:Project_chat#External_Identifiers_-_expanding_statements,_best_practice --Adam Harangozó (talk) 15:30, 1 November 2019 (UTC)

uuid constraint

Notified participants of WikiProject property constraints

At Wikidata:Database_reports/uuid, I made a report checking for the uniqueness of Universally Unique Identifier (Q195284).

For now, there are only conflicts within the same property. --- Jura 12:27, 4 November 2019 (UTC)

While the format suggested they are UUIDs strictly speaking they may not be.

Most properties use the same format (lowercase, separated in groups by "-") a few use slightly different ones (no "-", uppercase, uppercase/lowercase). Ideally they would be normalized before comparison. Already using Lcase leads to time-out.

Should these be normalized?

Should we have a separate datatype that stores them in 128bit form? --- Jura 07:11, 5 November 2019 (UTC)

Lcase() works now. --- Jura 09:18, 5 November 2019 (UTC)

See also: Wikidata:Project_chat#UUID_search --- Jura 13:38, 3 February 2020 (UTC)

Wikidata:2020 report on Property constraints

I have already published the 2020 report on Property constraints. Although the scope of the report is limited, you are welcome to leave any comments about Wikidata Property constraints on the talk page.

Thanks! --abi án 19:20, 30 January 2020 (UTC)

Can we better document separator (P4155) and group by (P2304) for property constraints

When trying to understand our current system it's not clear to me what separator (P4155) and group by (P2304) mean exactly. Does separator (P4155) also work for distinct-values constraint (Q21502410). When I first read group by (P2304) I thought it intended to do the function of separator (P4155). Given that's not the case, what is it for? Maybe we can add Wikidata usage instructions (P2559) to the items?

Notified participants of WikiProject property constraints ChristianKl ❪✉❫ 10:53, 22 June 2020 (UTC)

group by (P2304) is just for the layout of the constraint reports. --- Jura 10:55, 22 June 2020 (UTC)

Specifically, for the layout of the bot-generated reports – WikibaseQualityConstraints doesn’t use it. --Lucas Werkmeister (WMDE) (talk) 11:49, 22 June 2020 (UTC)

WikibaseQualityConstraints supports separator (P4155) for single-value constraint (Q19474404), single-best-value constraint (Q52060874) and multi-value constraint (Q21510857). --Lucas Werkmeister (WMDE) (talk) 11:49, 22 June 2020 (UTC)

Proposing new constraint: contemporary with given item

Right now we have contemporary constraint (Q25796498), which allows us to say that an item must have existed at the same time as an item it is linked to through a property. This is great; however, it can only be used with properties which have a data type of Item. There are some other properties, especially External identifier properties, which should only be used on items which are contemporary with some set item. For example, any item which has a USL Championship player ID (P4019) property set should be contemporary with USL Championship (Q1362411). Any person who died before the league was established in 2010 could not have played in the league, and therefore should not have a player ID. Another example is Twitter (X) username (P2002), which should only be applied to items who existed at the same time as Twitter (Q918). There are many other external IDs which link to a source that has a limited time range, and therefore could benefit from a "contemporary with given item" constraint. There are also likely a few properties other than external IDs which could benefit from this (e.g. items with email address (P968) should be contemporary with email (Q9158)).

I don't know what the process is for implementing a new constraint, but what do others think of this proposal? –IagoQnsi (talk) 02:09, 29 July 2020 (UTC)

Distinct best value constraint

The idea is that a given value (e.g. "AI") should be present just once within "best value". "AI" was reassigned.

I added that as complex constraint at Property_talk:P297.

Not sure whethern another similar property constraint would be the best solution here. I tend to like a separator (P4155)-like approach more, similarly as we use it for "single value constraint" and "single best value constraint". In other words: have some qualifier which needs to have distinct values when the identifier (or property in general) cannot have distinct values for whatever reason. This would also require changes to be made to the "distinct values constraint". —MisterSynergy (talk) 12:45, 23 September 2020 (UTC)

The statements at Q1450765#P297 and Q25228#P297 have an end or start date-qualifier. I don't think a query with best rank should show both items.
The nice thing with that identifier is that the dates are known. That might not be the case for air transport related codes that get re-assigned. --- Jura 12:58, 23 September 2020 (UTC)
- "start date" and "end date" are not necessarily the only possible separators here. One needs to find a solution which fits the situation regarding the problematic property.
  In general, we meanwhile know that a strict single value constraint is too restrictive for most (identifier) properties, thus the "single best value constraint" makes sense—although we unfortunately do not use it very much. The situation with "distinct values" is quite different in my opinion, as I expect only very few properties to potentially use a "distinct best value constraint". —MisterSynergy (talk) 16:59, 23 September 2020 (UTC)
  - I think it's better to rely on ranks than some separator qualifier. Already in the AI sample above, a start and an end date qualifier would have to be compared somehow.
    The question is somewhat different from the "single value constraint".
    To see how many more there are, I created a P31 value: Wikidata property for an identifier value that can be re-assigned (Q99543626). --- Jura 17:47, 23 September 2020 (UTC)

Proposal: none-of value-type constraint

Description: a constraint that bans values of a certain type

Use: Many of the none-of constraints on instance of ban items of the same class. Because there is no constraint to ban items by class, items are individually added and significantly inflate the number of property constraint (P2302)s. Using a "none-of value-type constraint" could simplify banning qualitys - items that are supposed to be used on other describing properties and not instance of.

Example use:

occupations are not supposed to be in instance of, so instance of should have this constraint.

property constraint

none-of value-type constraint

edit

0 references

add reference

add value

Lectrician1 (talk) 19:55, 10 October 2021 (UTC)

Notified participants of WikiProject property constraints Lectrician1 (talk) 09:56, 12 October 2021 (UTC)

Proposal: move all identifier properties from "single value constraint" to "single best value constraint"

Currently most of our identifier properties use the single-value constraint (Q19474404) (4721 identifiers), and only very few the single-best-value constraint (Q52060874) (37 identifiers); see also this query. This is probably the outcome of two factors:

routine; "single value" is older and much better known by editors than "single best value"
software support; particularly the KrBot covi reports did not support "single best value" for quite some time and it broke the entire report (meanwhile solved)

However, given our current knowledge about identifiers, external databases, duplicated entries and redirecting identifiers in them, I think that single-best-value constraint (Q52060874) should be the standard constraint for all identifier properties and single-value constraint (Q19474404) should only be used if there is a specific reason (and consensus) to do so. I thus think of ways to seek community consensus for a systematic change, probably through an RfC. Before I draft something, I would like to hear opinions on this matter from this smaller, more expert group of editors. Thanks for any input in advance! —MisterSynergy (talk) 17:29, 23 September 2020 (UTC)

Maybe we could remove all that have exceptions?
VIAF has a single value constraint, but now that users try to solve them bottom up it's not entirely clear if it helps them. Certainly, I don't think one should try to determine a "best" value. --- Jura 17:35, 23 September 2020 (UTC)
- We cannot make all situations immediately solvable just by selecting one of these constraints, particularly if there are more than one profiles in the external database. However, "single best value" gives a better hint how to properly solve multiple value situations using ranks in many scenarios so that we end up with actual duplicated profiles as constraint violations, but no more redirects and so on that we currently often see as violations.
  Some current "single value constraints" definitely need a closer evaluation before they could potentially be upgraded. Defined exceptions are generally not a good idea due to poor scaling (and in my opinion just technical debt from the early times of the constraint violations system). —MisterSynergy (talk) 18:13, 23 September 2020 (UTC)
  - I think the main advantage of the single value constraint is that it prevents bots from adding additional statements without especially overriding them. I don't think this requires defining exceptions for cases where multiple values are present. Frequently there are two valid values and both should be kept. Setting one to preferred eliminates the other from checks and this may not be desirable. It's clear that this can be something new to learn for those tempted to solve "all" constraint violations. --- Jura 18:20, 23 September 2020 (UTC)
    - After some thinking I am convinced that bots are no factor here. The predominant bot framework pywikibot does not have any constraints support included anyways, so it is completely up to the bot operators to handle all of this properly. Tool-wise, we have particularly QuickStatements (which simply does not add an existing value a second time regardless or ranks, but otherwise does not care about the constraint), HarvestTemplates (not sure exactly who it behaves), and OpenRefine (which claims to support both constraints). —MisterSynergy (talk) 20:43, 23 September 2020 (UTC)
      - What other indicator should operators use to check if one or several values are expected?
        Anyways, I don't see how defaulting to "best rank" would solve the problem with cases where once in a while more than one contemporary identifier is possible (this type). --- Jura 09:06, 24 September 2020 (UTC)
I Support the proposal. I'm not aware of any cases where "single value" constraint would be better and it should likely be removed when we switch over the existing to "single best value". ChristianKl ❪✉❫ 00:37, 15 December 2020 (UTC)
Support per Christian. --99of9 (talk) 06:37, 28 December 2021 (UTC)
Comment What about a single item in Wikidata that has two or more external identifiers duplicated in an external source? Which duplicate is the better external identifier to rank as preferred? --Dhx1 (talk) 12:53, 28 December 2021 (UTC)
Oppose, just delete wrong values and redirects. No need to collect garbage. We have no enough amount of resources to keep actual values in good state. Just take a look to constraint violations page of any popular property. Suggestion to collect and maintain garbage is counterproductive. Overcomplicated data scheme increases amount of errors and error types. It requires much more efforts for data maintenance (errors fix, validation, duplicates detection, merging and etc.) I already stopped several property maintenance tasks because new scheme with keeping garbage requires too complex algorithms. — Ivan A. Krestinin (talk) 21:15, 28 December 2021 (UTC)

Need input: deprecated rank and type/value type constraint checks

Triggered by phab:T277524 we noticed again an issue with the interaction of the type and value type constraint and deprecated statements. Currently the type and value type constraints treat a deprecated statement like any other statement. They are not ignored. I believe they should be for the constraint check to actually be valid. I'd like to pick up phab:T170401 so that any deprecated statement is basically ignored for the purpose of type and value type constraint checks. Before making that change I wanted to check if there are unintended side-effects I'm missing or other reasons why we shouldn't do this. --Lydia Pintscher (WMDE) (talk) 10:07, 16 March 2021 (UTC)

Maybe I'm missing something, but don't all other constraints ignore deprecated statements? Or maybe, that's just KrBot. --- Jura 10:11, 16 March 2021 (UTC)
I can only think of the recurrent misuse of the deprecated rank, sometimes used to mark historical facts or statements of terminated entities. But the fact that misuse can have visible consequences on Wikidata sounds good to me, isn't that what constraints are for? 😃 When I implemented the contemporary constraint type I included the condition to always ignore data with this rank, but I think it would be better to implement and test this condition in one place for all constraint types, this could simplify things. --abi án 08:50, 27 April 2021 (UTC)
Support I don't know of a reason why you shouldn't do that. --99of9 (talk) 06:39, 28 December 2021 (UTC)
Somebody added Albert Einstein (Q937) instance of (P31) donkey (Q3537778) with deprecated rank. Should constraint violations system ignore this violation? Deprecated values should not violate format constraint (Q21502404), subject type constraint (Q21503250), value-type constraint (Q21510865) and other constraints. "Deprecated" is not equal to "any garbage". Its should be controlled and maintained same as other values. — Ivan A. Krestinin (talk) 21:41, 28 December 2021 (UTC)

Add constraint violation based on rank?

I'd like to have a constraint violation when reason for preferred rank (P7452) is used with a statement that isn't actually ranked as preferred. Is that possible? {{u|Sdkb}} ^talk 05:57, 28 December 2021 (UTC)

Notified participants of WikiProject property constraints. {{u|Sdkb}} ^talk 05:58, 28 December 2021 (UTC)

I don't think this is a use case for constraints. You would have to add this constraint to every property.

This query finds such cases within a few seconds. One could easily transfer such a result periodically to an onwiki report page if useful. —MisterSynergy (talk) 09:17, 28 December 2021 (UTC)

Summary about exceptions to current "distinct value"/"unique value" constraint

Please see Help:Property_constraints_portal/Unique_value#Exceptions and help complete/expand.

Notified participants of WikiProject property constraints @Ivan_A._Krestinin: --- Jura 09:27, 14 February 2022 (UTC)

No "mundane" subclasses of Wikimedia internal items

A little over a week ago I created Wikidata constraint status (Q116690561), and also made mandatory constraint (Q21502408) and suggestion constraint (Q62026391) (the items used to define the constraint status (P2316) qualifier on property constraints) instances of it, similar to how Wikidata constraint scope (Q54718960) serves as the class for the three items constraint checked on qualifiers (Q46466783), constraint checked on main value (Q46466787) and constraint checked on references (Q46466805).

This is because I plan to remove all three remaining subclasses of Wikibase reason for deprecated rank (Q27949697), one of them being suggestion constraint (Q62026391) (I have investigated why, and it was apparently a mistake), since they may interfere with the definition of what constitutes a valid reason for deprecation.

Normally, each recognized reason is defined as an instance of said item, but the statement implementing this constraint also allows instances of any (arbitrarily distant) subclass of Wikibase reason for deprecated rank (Q27949697), and as items have mistakenly been made part of this subclass chain, the number of items technically complying with this constraint is currently over 9,000, many of which (such as a whole range of topics within medicine) make no sense as "reasons" to deprecate anything.

In addition, there have been other issues with real-world items in effect becoming subclasses of Wikimedia internal item (Q17442446), suggesting that it may not be enough to merely narrow down this constrant on reason for deprecated rank (P2241), but that we should completely break the subclass chain below of Wikibase reason for deprecated rank (Q27949697) (as it's a "highly exposed" internal item), and therefore I'd later like to include it in a none-of constraint on subclass of (P279).

But in preparation for this, mandatory constraint (Q21502408) and suggestion constraint (Q62026391) need somewhere to go, and as they have no reason to be classes themselves (their labels make them easily confused with property constraint (Q21502402), but they are mere status indicators associated with property constraints), I found that making them instances of another Wikimedia internal item would do the trick while keeping them as leaves in the tree.

Does anyone see any problem with this plan, such as current constraint checks or similar depending on the two status indicators having certain properties? SM5POR (talk) 11:37, 14 February 2023 (UTC)

Notified participants of WikiProject property constraints SM5POR (talk) 11:38, 14 February 2023 (UTC)

@SM5POR I don't see any problem with that, but I would wait on other, more skilled users to have their say. As for me, thank you very much for taking care of this issue! Sannita - not just another it.wiki sysop 14:09, 14 February 2023 (UTC)

Proposed plan seems to me more complicated and non-understandable than having mandatory constraint (Q21502408) and suggestion constraint (Q62026391) simply subclasses of Wikibase reason for deprecated rank (Q27949697). And I don't understand what's the problem not having subclasses of it. --Infovarius (talk) 19:45, 25 February 2023 (UTC)

@Infovarius: Sorry for my late response; I implemented the plan (except for the proposed constraint) shortly before your comment, and then had a family issue to attend to.

What may seem complicated and non-understandable is probably my description of the plan, not the underlying plan itself; I'm aware of my tendency to write lengthy explanations of even the simplest of things, since I worry about not making myself understood. Please accept my apology for this verbosity.

Of the two constraint status label items mentioned, only suggestion constraint (Q62026391) had a subclass of (P279) Wikibase reason for deprecated rank (Q27949697) claim, which had been added by mistake. Thus there was no reason to retain it.

Both items were however subclasses of property constraint (Q21502402), which may seem natural since their labels also end with the word "constraint", but these two are used in a way entirely different from how those actual constraints are used (as values of the constraint status (P2316) qualifier vs the main property constraint (P2302) property).

Simply removing all subclass of (P279) claims from the two items would have had the effect of detaching them altogether from the main Wikidata class tree. To avoid that, I needed to make them instance of (P31) some item, and that's the one I created.

Finally, the reason not to allow any subclass of (P279) Wikibase reason for deprecated rank (Q27949697) was brought up in Talk:Q27949697#This item is a scourge almost a year ago, as that class is a Wikimedia internal item (Q17442446), which yields various undesirable properties to its subclasses, such as virtually turning everything from ancient Egyptian magic to the Covid-19 pandemic into web pages, data carriers and intellectual works. I haven't found out how often this has happened, but as some users find it annoying enough to wish this class gone, I considered it worth the effort to try to reduce the annoyance. --SM5POR (talk) 15:53, 18 March 2023 (UTC)

subject type constraint tripping up on the wrong items

Bennebroek (Q817840): village and former municipality in North Holland, the Netherlands currently trips up subject type constraint (Q21503250) for CBS municipality code (P382). Looking at the sparql query, it only uses the current statements:

SELECT ?item ?itemLabel ?instance ?instanceLabel
WHERE
{
	{
		SELECT DISTINCT ?item ?instance {
			?item wdt:P382 [] .
			MINUS {
				VALUES ?classes { wd:Q2039348 wd:Q3648563 } .
				?item wdt:P31/wdt:P279* ?classes .
			} .
			OPTIONAL {
				?item wdt:P31 ?instance .
			} .
		} LIMIT 100
	} .
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } .
}

Try it!

The query should probably be changed to something like

SELECT ?item ?itemLabel ?instance ?instanceLabel
WHERE
{
	{
		SELECT DISTINCT ?item ?instance {
			?item wdt:P382 [] .
			MINUS {
				VALUES ?classes { wd:Q2039348 wd:Q3648563 } .
				?item p:P31/ps:P31/wdt:P279* ?classes .
			} .
			OPTIONAL {
				?item wdt:P31 ?instance .
			} .
		} LIMIT 100
	} .
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } .
}

Try it!

so that statements of all ranks are included. I didn't do that for the subclass of (P279) part because the temporal part is less of an issue and might give unexpected results. I do wonder how to deal with deprecated statements. Do we need to filter those out or not? @Lucas Werkmeister: any opinion about this? Multichill (talk) 14:12, 6 May 2023 (UTC)

Constraint type to disallow values of a certain type?

I see a lot of use for a constraint type that says "the value of this property may not belong to this type". An inverse of value-type constraint (Q21510865). For example, it could replace a lot of long none-of constraint (Q52558054) on instance of (P31) with simpler and more complete constraints, and see further motivation here. I know it can be done with complex constraints, but those are tedious to implement and don't produce warning icons on violating statements. How do we go about proposing new constraint types? Swpb (talk) 19:54, 28 June 2023 (UTC)

The last one was requested on Phabricator. Infrastruktur (talk) 20:52, 28 June 2023 (UTC)

Thanks, I've created a new request modeled on that one: [1]. Swpb (talk) 15:53, 29 June 2023 (UTC)

Requesting input on community wishlist item

I'm planning to introduce this proposal in the 2024 Community Wishlist Survey, which starts in January. I would greatly appreciate if members of this WikiProject could check it out before then. Thanks! Swpb (talk) 19:25, 17 October 2023 (UTC)

This does not fit into the 2024 Community Wishlist Survey at all in my opinion. Wikidata:Project chat and/or this page would be the correct venue. —MisterSynergy (talk) 19:46, 17 October 2023 (UTC)

@MisterSynergy: It requires software development work, so how is it not appropriate for the CWS? Swpb (talk) 19:05, 1 November 2023 (UTC)

Wikidata talk:WikiProject property constraints/Archive 2

Contents

Redundancies in (value) type constraint definitions

Multiple value type constraint relations?

Constraint errors

You can now query the constraint violations with the Query Service

Distinct best value constraint?

Single value constraint

as main value (Q54828448) and category contains (P4224) or is a list of (P360)

Better suggestions for constraint values on properties

Q25796498 Contemporary constraint

Citation needed constraint

Request for comment

[Breaking change] "wbcheckconstraints" API new result status

New status of constraint: "suggestion"

Distinct case-insensitive values

Complex constraint exception needed

Study on property constraints

"different from property"

External identifiers

uuid constraint

Wikidata:2020 report on Property constraints

Can we better document separator (P4155) and group by (P2304) for property constraints

Proposing new constraint: contemporary with given item

Distinct best value constraint

Proposal: none-of value-type constraint

Proposal: move all identifier properties from "single value constraint" to "single best value constraint"

Need input: deprecated rank and type/value type constraint checks

Add constraint violation based on rank?

Summary about exceptions to current "distinct value"/"unique value" constraint

No "mundane" subclasses of Wikimedia internal items

subject type constraint tripping up on the wrong items

Constraint type to disallow values of a certain type?

Requesting input on community wishlist item

Navigation menu

Wikidata talk:WikiProject property constraints/Archive 2

Redundancies in (value) type constraint definitions

Multiple value type constraint relations?

Constraint errors

You can now query the constraint violations with the Query Service

Distinct best value constraint?

Single value constraint

as main value (Q54828448) and category contains (P4224) or is a list of (P360)

Better suggestions for constraint values on properties

Q25796498 Contemporary constraint

Citation needed constraint

Request for comment

[Breaking change] "wbcheckconstraints" API new result status

New status of constraint: "suggestion"

Distinct case-insensitive values

Complex constraint exception needed

Study on property constraints

"different from property"

External identifiers

uuid constraint

Wikidata:2020 report on Property constraints

Can we better document separator (P4155) and group by (P2304) for property constraints

Proposing new constraint: contemporary with given item

Distinct best value constraint

Proposal: none-of value-type constraint

Proposal: move all identifier properties from "single value constraint" to "single best value constraint"

Need input: deprecated rank and type/value type constraint checks

Add constraint violation based on rank?

Summary about exceptions to current "distinct value"/"unique value" constraint

No "mundane" subclasses of Wikimedia internal items

subject type constraint tripping up on the wrong items

Constraint type to disallow values of a certain type?

Requesting input on community wishlist item

Navigation menu

Search