Talk:Q21503250

Reference

See Help:Property constraints portal for more information. Multichill (talk) 16:30, 24 December 2017 (UTC)

Bug report in description?

Lucas Werkmeister (WMDE)
Jarekt - mostly interested in properties related to Commons
MisterSynergy
John Samuel
Sannita
Yair rand
Jon Harald Søby
Pasleim
Jura
PKM
ChristianKl
Sjoerddebruin
Fralambert
Manu1400
Was a bee
Malore
Ivanhercaz
Peter F. Patel-Schneider
Pizza1016
Ogoorcs
ZI Jony
Eihel
cdo256
Epìdosis
Dhx1
99of9
Mathieu Kappler
Lectrician1
SM5POR
Infrastruktur

Notified participants of WikiProject property constraints

@Jura1: I just noticed that you added the following note to the English description of this item last year:

Note: currently works fully only on reports, not with the gadget on items.

Can you explain what you mean(t) by that, and whether it still applies? If there are any bugs in the live constraint checks (no longer a gadget, by the way), we should fix them. --Lucas Werkmeister (WMDE) (talk) 10:37, 28 November 2018 (UTC)

• It was accurate when written. --- Jura 10:53, 28 November 2018 (UTC)
• @Lucas Werkmeister (WMDE): Type constraints seem to be working correctly when editing via the user interface - I tripped over several of them just yesterday. - PKM (talk) 00:31, 29 November 2018 (UTC)

Alright, thanks – since the sentence in question has now been removed from the description, I guess this no longer applies and we’re  Done. --Lucas Werkmeister (WMDE) (talk) 12:42, 30 November 2018 (UTC)

Name

Tracked in Phabricator
Task T244051

Would you agree to change the name of this constraint type to "class" or "subject class"? --abián 17:18, 4 February 2020 (UTC)

• No. --- Jura 17:26, 4 February 2020 (UTC)
  • @Jura1: Do you think the current one is better? Why? --abián 18:03, 4 February 2020 (UTC)

 Done for now in English and Spanish, in line with the value-type constraint (Q21510865) type; arguments have been provided for but not against the change. --abián 18:00, 17 February 2020 (UTC)

• "subject" is ill understood and the current label is understood by most users. Note: I have no opinion on the Spanish label. --- Jura 18:08, 17 February 2020 (UTC)

  Would you find "class constraint" more understandable, without the "subject"? --abián 18:23, 17 February 2020 (UTC)

  • Not sure. "class" is also used in the label of the one of the qualifiers that goes with the constraint. --- Jura 19:44, 3 March 2020 (UTC)

• I prefer “subject class constraint”. Or possibly “subject type constraint”. - 2600:1700:BEB1:3198:283E:C3:1DF2:5AC8 01:42, 28 September 2020 (UTC)
• @Jura1: On Spanish, it has a very confusing name ("restricción de tipo de propiedades de Wikidata", "Wikidata properties type constraint"). The label "subject class constraint" seems better for me, at least in Spanish. --Tinker Bell ★ ♥ 05:31, 16 October 2020 (UTC)
  • @Tinker Bell: I think you can improve the label in Spanish without changing the one in English. Makes one wonder if the report was about the English or the Spanish label. --- Jura 05:37, 16 October 2020 (UTC)
• I  Support renaming it into "subject class constraint" and "value constraint" to "object class constraint". The more we refer to statements as being made up of subject-predicate-object as laid out in the glossar the easier it is for users to understand it. Using inconsistent naming where the same thing in Wikidata is named differently in Wikidata in different contexts makes it harder for users to know what they are dealing with. subject has role (P2868)/object has role (P3831) already use subject has role (P2868)/object has role (P3831) and I think subject/object are mostly in property descriptions when a general term is needed.

The fact that the property creation process ask for the same thing under the name "domain"/"allowed value" doesn't help either.

As far as using the word type I think it should only apply to instance of (P31) relations and not to subclass of (P279). Given that subject type constraint (Q21503250) mixes both we should say class in this context

I doubt that the average user of Wikidata knows by heart what a "type constraint" compared to a "value constraint" happens to be.

Lucas Werkmeister (WMDE)
Jarekt - mostly interested in properties related to Commons
MisterSynergy
John Samuel
Sannita
Yair rand
Jon Harald Søby
Pasleim
Jura
PKM
ChristianKl
Sjoerddebruin
Fralambert
Manu1400
Was a bee
Malore
Ivanhercaz
Peter F. Patel-Schneider
Pizza1016
Ogoorcs
ZI Jony
Eihel
cdo256
Epìdosis
Dhx1
99of9
Mathieu Kappler
Lectrician1
SM5POR
Infrastruktur

Notified participants of WikiProject property constraints WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. ChristianKl ❪✉❫ 17:09, 11 December 2020 (UTC)

• I prefer that the constraint can be generalized to an arbitrary property path. cf. phab:T176768, phab:T173593, phab:T173596.--GZWDer (talk) 17:50, 11 December 2020 (UTC)
• I  Support the change suggested by ChristianKl. Relabeling subject type constraint (Q21503250) as "subject class constraint" and value-type constraint (Q21510865) "object class constraint" would make the meaning of the constraints more clear and easier to find. The change would require that Wikidata editors understand the technical defnitions of "object" and "subject," but that is a reasonable expectation. As it stands now, the meaning of subject type constraint (Q21503250) is not intuitive and thus makes it harder for new editors to understand. — The Erinaceous One 🦔 09:54, 14 December 2020 (UTC)

• As much as I am aware, the usual terminology is "domain" for what we call "type constraint", and "range" for what we call "value type constraint". I would be fine with "domain" and "range", but it is not helpful to replace the established names with something else that is also not a standard in any way. —MisterSynergy (talk) 18:08, 11 December 2020 (UTC)
  • You're right that the names you mention are also valid and understood, but we already have the range constraint (Q21510860) for numerical values. See also https://www.w3.org/TR/rdf11-primer/#section-triple and en:Semantic triple#Subject,_predicate_and_object. --abián 19:14, 11 December 2020 (UTC)
    • @Lucas Werkmeister (WMDE): Maybe range constraint (Q21510860) should be for numerical values as well as items/properties/lexemes? This would make it for a user easier because the amount of constraints he has to learn is one less. Are there technical reasons for why those two constraints should be separate items? ChristianKl ❪✉❫ 21:14, 11 December 2020 (UTC)

Well, they’re completely different constraint types, in meaning as well as in implementation, in my opinion. If you use the same name for both, you may have reduced the amount of constraint names a user has to learn, but not, I think, the real number of constraint types a user would have to understand. --Lucas Werkmeister (WMDE) (talk) 08:47, 14 December 2020 (UTC)

• • According to the RDF that's linked our subject type constraint (Q21503250) is a constraint that constrains the domain of the subject while the value constraint is a constraint that constrains the range of the object.

I don't think calling the constraint that constrains what the subject can be after the subject would be using the words against the standard.

In any case our current way where a type constraint is both about the type and about subClassOf is using the terms against the standard. I would be more happy with "domain constraint" then with type constraint. ChristianKl ❪✉❫ 21:17, 11 December 2020 (UTC)

• Not sure if "object class constraint" is really helpful. "object" is sometimes understood as referring to the object of the main statement, whereas what we currently call "value type" constraint is about the "value" of a property, even when it's used as qualifier or in references. --- Jura 08:10, 12 December 2020 (UTC)
• We do use "domain" in property proposals, but doesn't it also describe which entities we use the property on? --- Jura 08:10, 12 December 2020 (UTC)
  • @Jura1: Currently, we use "type constraint" to describe which entities we use the property on. If someone uses the property outside of those entities they get a constraint warning.

We don't have a "domain" property, so when a new property is created usually the information from the domain field gets translated into type constraint. ChristianKl ❪✉❫ 12:40, 14 December 2020 (UTC)

Well, there a few other factors: type constraints don't work for qualifiers. The domain is also translated with property scope constraint (Q53869507) and allowed-entity-types constraint (Q52004125). --- Jura 15:43, 14 December 2020 (UTC)

Before we had property scope constraint (Q53869507) and allowed-entity-types constraint (Q52004125) it was just type constraint and now it's still mostly and sometimes people might store that data in it. Generally, I think it would be better if that would get it's own row. ChristianKl ❪✉❫ 16:31, 14 December 2020 (UTC)

free software

Please, look at this page the following warning: "Entities using the Guix Variable Name property should be instances or subclasses of free software or free and open-source software (or of a subclass of them), but GNU Binutils currently isn't." IMHO, setting an instance of something to preferred rank is relevant, that does not mean that setting an instance of another thing to normal rank is like deprecated. Genium. 08:02, Jul 28, 2021 (UTC+02:00)

Is there an inverse of this constraint?

As in, the domain should not be of a certain type? I know you can use conflicts-with constraint (Q21502838) with property (P2306)instance of (P31), but that only covers things that are directly instances of the class, not of subclasses. ―Jochem van Hees (talk) 22:31, 22 December 2021 (UTC)