Help talk:Property constraints portal
 | This talk page is used to discuss the content of the help page. If you want to discuss about the constraints, how they are defined or applied, please go to Wikidata talk:WikiProject property constraints. |
 Archives | |||
|---|---|---|---|
| |||
add no-instances-of constraint
editCurrently instance of (P31) has a lot of none-of constraint (Q52558054) constraints that list instances of a class and replace the instance of (P31) link with a special link. For example various instances of studio album (Q208569) cause a replacement with the property form of creative work (P7937). This causes the constraints to be large and require updating whenever a new instance of the class is created. It seems to me that these constraints should instead use a constraint that uses the class directly, instead of its instances. This would be easier to create, easier to understand, and easier to update.
https://www.wikidata.org/wiki/Wikidata:WikiProject_Ships is set in a way where it would be useful to have this new kind of constraint. There are thousands of instances of ship class (Q559026) like Olympic-class ocean liner (Q767166) that are not supposed to be used as values for instance of (P31) instead using vessel class (P289) but adding them all as a replacing none-of constraint would be very difficult, and new ship classes are created frequently. So a no-instances-of constraint would be very useful for ships.
Is this the correct place to argue for the creation of a new constraint type, or is there some better place? Peter F. Patel-Schneider (talk) 21:04, 19 August 2023 (UTC)
Expanded constraint types (follow up to Peter's thread above)
editI've created a wish on the Community Wishlist that would allow none-of constraints (as well as item-requires-statement and conflicts-with constraints) to use the "class" and "relation" parameters the way subject-type and value-type constraints do currently. I don't know how much endorsements matter in the new Wishlist process (thanks Peter for yours!), but if anyone else feels like doing so, it might help get the request into the lap of a developer. Swpb (talk) 17:52, 16 July 2024 (UTC)
Should 'Label in Language' property constraint include `mul`
editAs `mul` is being released on Wikidata phab:T330281, we need to look into how this will affect Property Constraints.
One that could be affected is 'Label in Language'. In this case, we must decide on whether we `mul` labels meet the requirement for the property constraint.
An example of a property that has the constraint Bibliothèque nationale de France ID, and the current violations of the property constraint
Please tell us your thoughts on whether `mul` labels meet the requirements for the 'Label in Language' constraint here phab:T370293.
And let us know if there are any other constraints that you think that could be affected with the implementation of `mul` for the default values of labels and aliases.
Arian Bozorg (WMDE) (talk) 14:52, 17 July 2024 (UTC)
Notified participants of WikiProject property constraints just in case anyone’s not watching this page ^^ Lucas Werkmeister (WMDE) (talk) 15:49, 17 July 2024 (UTC)- Yes, mul labels definitely do meet the requirements on any Label in Language constraint, I consider it a bug in the property constraint it is not currently accepted (and I’m not the only one). There are even bots removing labels in languages identical to the mul label (while that might be debatable in specific cases, they have a point, and we can expect this to be done even more often in the future). We have a combination of “items using the property should have a label in language xy” + “this item has this exact label in all languages”, and this is completely fine. mul labels are not (should not be) the kind of fallback we see in e.g. an en→de fallback chain; it’s not an “emergency fallback” to show something when we just have no better option. It’s a completely valid label in all languages.
- (The only slightly problematic thing in this is the problem of script: The mul label should be the “native” name of the item, i.e. in its “native” script; e.g. for people, the mul label might be “Karel Čapek”, “محمد بن موسى خوارزمی”, “Володимир Олександрович Зеленський”, etc. And label in a different script might be considered less usable even though it is “not language-specific”, “valid for all languages”. So I guess we might want to have a property constraint saying “all items using this property should have a language in Latin script”. But… that is a different constraint! And this is a problem which is (AFAIK) not solved on Wikidata currently at all. See e.g. values of native label (P1705) on given name (Q202444) items, or generally any other usages of the mul language in monolingual text values: on the one hand, we want to have native label (P1705) annotated with a language so that we can e.g. choose the proper text direction and font, on the other hand, we don’t want to list all languages for which it is valid, because really, we want to say something like “mul-Latn” (or maybe we want to have a “mono-script string” datatype, ahem). But as I said, this is an existing and more complicated problem, I wouldn’t expect the implementation of a single property constraint to solve it.) Mormegil (talk) 10:15, 7 December 2024 (UTC)
