Property talk:P2668

Type “Wikidata property (Q18616576)”: item must contain property “instance of (P31)” with classes “Wikidata property (Q18616576)” or their subclasses (defined using subclass of (P279)). (Help)

List of violations of this constraint: Database reports/Constraint violations/P2668#Type Q18616576, hourly updated report, SPARQL

Value type “Wikidata property change frequency (Q23611439)”: This property should use items as value that contain property “instance of (P31)”. On these, the value for instance of (P31) should be an item that uses subclass of (P279) with value Wikidata property change frequency (Q23611439) (or a subclass thereof). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2668#Value type Q23611439, SPARQL

Allowed entity types are Wikibase property (Q29934218): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2668#Entity types

Scope is as main value (Q54828448): the property must be used by specified way only (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2668#Scope, SPARQL

Item “property constraint (P2302)”: Items with this property should also have “property constraint (P2302)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2668#Item P2302, search, SPARQL

One of never changes (Q23611288), sometimes changes (Q24025284), values can be added (Q23611840), continuously changes / unstable identifier (Q23611587), somevalue: value must be one of the specified items. Please expand list if needed. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P2668#One of, values statistics, search, SPARQL

I restored the label to the one from the proposal. I don't recall the new label being mentioned there and it doesn't seem to have lead to any actual use.
--- Jura 03:19, 31 March 2016 (UTC)[reply]

Since when did this become mandatory on properties? And why? I do not understand how one is supposed to know the correct value to use for it. I have used "unknown value" for this, but that gets a constraint violation. UWashPrincipalCataloger (talk) 01:09, 28 August 2022 (UTC)[reply]

@Dhx1 was the one who added; hopefully they can explain further. JesseW (talk) 04:26, 28 August 2022 (UTC)[reply]

@UWashPrincipalCataloger @JesseW The constraint is just a suggestion constraint (Q62026391) and is not mandatory. I think the definition of stability of property value (P2668) is currently poor for the reasons stated below, but think ultimately the intent of the property would be very useful in modelling how and the frequency for which property values change. This is useful for tools such as anti-vandalism tools to further predict the likelihood of a change being made maliciously.

Problems I see with the current definition of this property:

• Conflation in how a value would change (e.g. addition to a list with no removals permitted) with how frequently a value would change.
• Terms such as "sometimes" and "constantly" are ambiguous and mean different things to different people. I suggest event interval (P2257) (or other/new property) could perhaps be used as a qualifier instead?
• In the example of positions held by a person, these positions could change approximately once every 5 years during the lifespan of the person, but then never change after the person has died. For such complex relationships, perhaps a myriad of more specific values such as "changes periodically during lifespan of subject" with event interval (P2257) being used as a qualifier and for more complex modelling, valid in period (P1264) and valid in place (P3005) (and other qualifiers) could state the rate of change has not been constant in history or geography.
• For physical quantities such as area (P2046), the rate of change of an area of a glacier is completely different to the area of a sports pitch as defined by an international standard. Perhaps the stability of a property value should instead be modelled on types of items in the Q namepsace, rather than modelled in the P namespace. A glacier has an "area" property that is defined to change constantly in the real world, but is only expected to be resampled annually as part of a government program to perform annual glacier measurements? A sports pitch as defined by an international standard would then never be expected to change in area, as a new sports pitch item would be created instead for the newly defined sports pitch of different dimensions.

Thoughts on what to do with this property? Dhx1 (talk) 06:15, 29 August 2022 (UTC)[reply]

I think at the least the option to say stability is unknown should be provided. I hate creating a new property and seeing the constraint violation on it because of this suggestion constraint. Nearly every property now shows this violation. UWashPrincipalCataloger (talk) 10:00, 29 August 2022 (UTC)[reply]

It's easy to add unknown value as a possibility (and I've done so). As for whether this should be a suggestion constraint... I'm neutral, leaning slightly towards no. It seems vaguely useful (although I don't disagree with Dhx1's comments about ways that might make it better), but we already have two required statements, and I'm not sure it's worth enough to make it a third (especially without any tools using it yet). JesseW (talk) 18:06, 29 August 2022 (UTC)[reply]

I don't think this constraint is useful at this time. I went ahead and "moved it" to Wikidata property for an identifier (Q19847637), where (on identifiers) it seems a little better defined; see the items of Wikidata property change frequency (Q23611439) containing references to identifiers. Azertus (talk) 12:44, 8 September 2023 (UTC)[reply]

For what I know, values can be added (Q23611840) indicates that new statements for a given property can be added in the same item. For example, if someone may start a new job, then a new value for occupation (P106) is added in the item, even if another one was already specified.

Anyway, I noticed that stability of property value (P2668)values can be added (Q23611840) is also stated for identifiers, which lends itself to three possible interpretations:

1. Sometimes a new value for the identifier is added in the same item. This doesn't make much sense (by definition of identifier), except for really specific cases.
2. Sometimes the value for the identifier may change (i.e., it is incorrectly used in place of sometimes changes (Q24025284)). Also in this case, I can't explain why such statement is used in 450 identifiers. Do we really have so many identifiers that may change over time?
3. Sometimes the source dataset provides new identifiers. I guess this is what the property creators^[1] meant by using values can be added (Q23611840) for identifiers, but I don't think this complies the intended semantics for this property. One should instead use expected completeness (P2429) for this purpose.

Given this, I think that most of the times the correct statement for identifiers is stability of property value (P2668)never changes (Q23611288). Am I wrong?

1. ↑ I ping some recent property creators for a confirmation @Trade, Infrastruktur, Kirilloparma, Jonathan Groß:)

Horcrux (talk) 17:31, 10 October 2023 (UTC)[reply]

I think it would be useful to have a list with the largest percentage of withdrawn identifier value along with their stability of property value (P2668) so we can see how it's being used Trade (talk) 21:51, 14 October 2023 (UTC)[reply]

@Trade: I've put some (hoping useful) data here. --Horcrux (talk) 09:33, 18 October 2023 (UTC)[reply]

Maybe the query would run better if identifiers without any withdrawn entries were ignored? Trade (talk) 11:53, 18 October 2023 (UTC)[reply]

@Trade: I'm afraid I'm not understanding. Are you suggesting to filter out results with 0% percentage of withdrawn IDs? Why? And how would the query "run better"? --Horcrux (talk) 11:59, 18 October 2023 (UTC)[reply]

Yes Trade (talk) 12:04, 18 October 2023 (UTC)[reply]

@Trade: The table is sortable, you can sort its values with respect to the last column in descending order. --Horcrux (talk) 12:35, 18 October 2023 (UTC)[reply]