Property talk:P10726

Documentation

• Start a query
• Current uses
• Statistics by class
• List of values
• List of qualifiers
• Count

class of non-item property value
class of the value of a property whose value datatype is not Item. The class should only include acceptable values for the property

Data type	Item
Usage notes	Use on properties that only accept values with a non-item datatype, to specify the class that those values should belong to. The class should only include acceptable values for the property; if no item exists for that class, either create one or set the value type of this property to "unknown value".
Example	ISNI (P213) → International Standard Name Identifier (Q423048) YouTube video ID (P1651) → YouTube video ID (Q110851517) mass (P2067) → mass (Q11423) Australian Business Number (P3548) Australian Charities and Not‑for‑profits Register Charity ID (P10081)
See also	type of unit for this property (P2876)
Lists	Items with the most statements of this property Count of items by number of statements (chart) Items with the most statements Items with the fewest statements Count of items by number of sitelinks (chart) Items with the most sitelinks Items with the most sitelinks, but no link to one Wikipedia (sample: Welsh Wikipedia, cywiki) Items with the fewest sitelinks Most linked wikis Items with the most identifier properties By value of property Most statements Fewest statements Most sitelinks Most linked wikis Total of sitelinks on items Most identifiers Fewest identifiers Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Chart by item creation date Database reports/Constraint violations/P10726 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 857 Main statement 854 99.6% of uses Qualifier 3 0.4% of uses
Search for values

[create Create a translatable help page (preferably in English) for this property to be included here]

Single value: this property generally contains a single value. (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/P10726#Single value, 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/P10726#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/P10726#Scope, SPARQL

Value type “string (Q184754), quantity (Q309314), point in time (Q186408), coordinate (Q3250736), image (Q478798), video (Q98069877), audio recording (Q3302947), table (Q496946), value (Q2912517), text (Q234460), cartographic work (Q25106976), linguistic form (Q115786086)”: This property should use items as value that contain property “instance of (P31), subclass of (P279)”. On these, the value for instance of (P31), subclass of (P279) should be an item that uses subclass of (P279) with value string (Q184754), quantity (Q309314), point in time (Q186408), coordinate (Q3250736), image (Q478798), video (Q98069877), audio recording (Q3302947), table (Q496946), value (Q2912517), text (Q234460), cartographic work (Q25106976), linguistic form (Q115786086) (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/P10726#Value type Q184754, Q309314, Q186408, Q3250736, Q478798, Q98069877, Q3302947, Q496946, Q2912517, Q234460, Q25106976, Q115786086, SPARQL

Relabeling the property to "values are instances of" and broadening the scope to Wikibase items

I think "values are instances of" would be clearer than "class of property value" and this would also allow the property to be used to link instances of Wikibase datatype (Q19798645) to their supported values, e.g:

• Wikibase item datatype (Q115470359)values are instances ofWikibase item identifier (Q111513391)
• Wikibase property datatype (Q115468759)values are instances ofWikibase property identifier (Q111513349)
• Wikibase lexeme datatype (Q115470231)values are instances ofWikibase lexeme identifier (Q111513387)
• Wikibase string datatype (Q29934246)values are instances ofUnicode string (Q115684457)does not have part (P3113)horizontal tab character (Q26772372)does not have part (P3113)vertical space character as per PCRE (Q115583846)
• Wikibase URL datatype (Q29934281)values are instances ofURL (Q42253)
• Wikibase Math datatype (Q42742777)values are instances ofTeX expression (Q115642178)
• Wikibase Musical Notation datatype (Q62080777)values are instances ofLilyPond expression (Q115642263)

What do you think of this idea?

@Lectrician1:, @AntisocialRyan:, @Nepalicoi:

--Push-f (talk) 09:03, 13 December 2022 (UTC)

Sorry nevermind, that doesn't work because the property is a subproperty of Wikidata item of this property (P1629) ... so I guess I have to keep arguing for my proposal values are instances of . --Push-f (talk) 09:06, 13 December 2022 (UTC)

@Push-f I don’t understand why that does not work but I neiter understand why it’s a subproperty of Wikidata item of this property (P1629) .

@Lectrician1: it seems to me that "associated element" property is supposed to usually have a single value, proposing a subproperty of it implies that the value of the subproperty is also a value for the main one so it seems it kind of defeat the purpose. Is there a reason ? author  TomT0m / talk page 11:23, 13 December 2022 (UTC)

If you are asking about the reason why class of non-item property value (P10726) was created that is explained in its property proposal. Wikidata item of this property (P1629) does not have clear semantics ... it's basically just "related item", whereas class of non-item property value (P10726) has clear semantics. --Push-f (talk) 11:29, 13 December 2022 (UTC)

@Push-f I understood the semantics, I read the property proposal.

I asked why the fact that it is a subproperty implied that that does not work. author  TomT0m / talk page 12:02, 13 December 2022 (UTC)

Oh because I was suggesting the property to be used for data items e.g. Avalues are instances ofB ... however obviously AWikidata item of this propertyB doesn't make sense if A is a data item (because Wikidata item of this property (P1629) which is implied via subproperty of (P1647) is only defined for the data item scope). --Push-f (talk) 12:05, 13 December 2022 (UTC)

@Push-f I don’t get your problem. You mean if « A » is an item ? But it’s not the case, for neither properties. author  TomT0m / talk page 12:09, 13 December 2022 (UTC)

Yes I was initially suggesting the scope of class of non-item property value (P10726) to be broadened to Wikibase items so that the property can also be used for the 7 examples I listed above. --Push-f (talk) 12:11, 13 December 2022 (UTC)

(bottomline, either the lack of semantics of Wikidata item of this property (P1629) implies no constraint of its subproperty, either it is something clearer such as « the item associated to the relation, like « married with » => « item about the marriage relationship » and we should better create this property. The lack of semantics has its merits, it has the defaults of its qualities) author  TomT0m / talk page 12:07, 13 December 2022 (UTC)

@TomT0m The reason I made it a subproprerty is to indicate to people that this should replace Wikidata item of this property (P1629). The goal of this property is to replace Wikidata item of this property (P1629) which is currently conflated. You can remove it if you think it causes confusion. Lectrician1 (talk) 16:33, 13 December 2022 (UTC)

I don't think it should be removed ... the subproperty statement makes sense ... even if it prevents the subject scope from being broadened to items. --Push-f (talk) 17:05, 13 December 2022 (UTC)

@Push-f what you're describing is a completely different relationship. So yes, keep your other proposal. Lectrician1 (talk) 16:31, 13 December 2022 (UTC)

How is it completely different? Other than the scope of the subject? --Push-f (talk) 17:03, 13 December 2022 (UTC)

This property is to say a wikidata property's value represents this class. The property you're proposing is saying the property of the subject has stored values in their wikibase that are this class. Lectrician1 (talk) 16:48, 14 December 2022 (UTC)

Nooo, I don' t understand...

@User:Lectrician1, you added URL match pattern (P8966)property constraint (P2302)item-requires-statement constraint (Q21503247)property (P2306)class of non-item property value (P10726), which requires adding "class of property value" at least to 5000 properties.

@User:MasterRus21thCentury, you added class of non-item property value (P10726)property constraint (P2302)distinct-values constraint (Q21502410).

1. What is the purpose? It literally requires now creating a copy of properties in main namespace. I could imagine, that it is useful for things like 63 statements of has characteristic (P1552)MediaWiki page title (Q83336425) statements, because has characteristic (P1552) is too generic. But with current constraints it is not possible.
2. Why we need to link to "mass"? It is already possible to go from measurement property to measure item with mass (P2067)type of unit for this property (P2876)unit of mass (Q3647172) + unit of mass (Q3647172)measured physical quantity (P111)mass (Q11423) (query).

--Lockal (talk) 08:52, 12 January 2023 (UTC)

@Lockal

1. The purpose is to replace Wikidata item of this property (P1629). See https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2022/12#Creation_of_items_for_all_external_identifier_identifers
2. I mean, you don't have to link to mass, but the relationship is possible so it's used as an example.

Lectrician1 (talk) 14:12, 12 January 2023 (UTC)

Constraints against P1629

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 Yesterday @Dhx1: added a few constraints to Wikidata item of this property (P1629), applicable 'stated in' value (P9073) and to URL match pattern (P8966), mobile formatter URL (P7250), third-party formatter URL (P3303), formatter URL (P1630), in order to require the use of this property with the formatter URLs etc. Whilst I agree that, after the creation of this property, we should arrive to a point in which P1629 gets deleted because all its uses will be absorbed by the couple P9073/P10726, since we are still very far from this result, I think the addition of such constraints is premature and has a few pros alongside with many cons (e.g. making the number of constraint violations enormous and unmanageable). As of now this property is still used in a few items because its creation is recent and a lot of items representing the IDs are missing; when we will manage to solve this problem, I will obviously support the reinsertion of these constraints, but I would it in the present situation; thus I have undone them and I have opened this discussion. Comments are welcome. --Epìdosis 14:07, 18 March 2023 (UTC)

If I look at the examples of Wikidata item of this property (P1629) the first one is father (P22) Wikidata item of this property (P1629) father (Q7565). father (P22) class of non-item property value (P10726) human (Q5) and organism (Q7239) would make sense but not father (Q7565). To me that does't look like this usage of Wikidata item of this property (P1629) is covered by either applicable 'stated in' value (P9073) or class of non-item property value (P10726). ChristianKl ❪✉❫ 15:06, 18 March 2023 (UTC)

We could add suggestion constraint status to make the constraint exceptions appear less urgent. But the constraints do some important work in informing everyone of the intended future state. Otherwise everyone will just keep using Wikidata item of this property (P1629) without being any wiser. Dhx1 (talk) 02:56, 19 March 2023 (UTC)

Revision by عُثمان

@User:عُثمان Revision

Why doesn't this always apply? Lectrician1 (talk) 23:56, 9 January 2024 (UTC)

@Lectrician1 I don't remember. I should have made a note of it. عُثمان (talk) 23:59, 9 January 2024 (UTC)

Use with class-of-Items values is wrong

@Lectrician1: Using values whose classes are made up of Wikidata items is 1) an unapproved scope expansion of this property, and 2) redundant in purpose to value-type constraint (Q21510865), which you said yourself in the property proposal. That hasn't changed. If the value of place of marriage (P2842) can include any instance of marriage location (Q124222019) (a class I see you created yesterday for this purpose), then marriage location (Q124222019) should be a value of class (P2308) in the value-type constraint (Q21510865) on place of marriage (P2842). That said, the constraint already pretty well captures the classes that marriage locations could belong to; I can't think of an appropriate value that doesn't belong to one or more of the already specified classes. So I've yet to see an example where using class of non-item property value (P10726) with an item-containing class accomplishes something that value-type constraint (Q21510865) doesn't.

I also don't understand the relevance of your link to the proposal discussion for number of participants (P1132); what does that have to do with the value-type constraint (Q21510865) here? Respectfully, Swpb (talk) 17:12, 10 January 2024 (UTC)

@Swpb

1. Okay i guess I'll try to "approve" it then

2. It's not redundant. mother (P25) is an example property where the value-type constraint (Q21510865) should be human (Q5) and not mother (Q7560). We don't allow humans to be things other than human (Q5). That's why we can't make the value of value-type constraint (Q21510865) mother (Q7560).
Therefore, class of non-item property value (P10726) could be used to show that the value of mother (P25) is a mother (Q7560). Lectrician1 (talk) 18:58, 10 January 2024 (UTC)

Also, the reason I want to expand the scope is because it

1. Makes logical sense

2. I want to phase out Wikidata item for this property and this acts as a replacement. Lectrician1 (talk) 19:02, 10 January 2024 (UTC)

1. You can't approve anything by yourself, I assume you mean get it approved by a consensus. Your proposal for deprecating Wikidata item of this property (P1629) isn't going great, so I don't think you're going to get it there.

2. "Redundant" may not be the best word, more like "pointless". Yes, the value-type constraint on mother (P25) should and does limit its values to human (Q5), so there's no point in adding mother (Q7560) to that constraint. The property for linking mother (P25) to mother (Q7560) is Wikidata item of this property (P1629), your proposed deprecation notwithstanding. Swpb (talk) 19:30, 10 January 2024 (UTC)

@Swpb Soooooo would you be okay if we expanded the scope of this property to items so that we can deprecate Wikidata item of this property (P1629) or do you want a "class of property value for items" property proposed? Lectrician1 (talk) 20:30, 10 January 2024 (UTC)

Neither: I don't want to see the scope of this property expanded, for the reason I gave above, and at this point I don't see the need for a need for a new property, or for the deprecation of Wikidata item of this property (P1629). I'm not sure why it's a problem that Wikidata item of this property (P1629) sometimes has multiple values, if those values are correct. In your given example of YouTube video ID (P1651), the values YouTube (Q866) and YouTube video (Q63412991) are just wrong: the only correct Wikidata item of this property (P1629) (or more specifically, class of non-item property value (P10726), since ID values are strings) for YouTube video ID (P1651) is YouTube video ID (Q110851517). The inclusion of incorrect values is not a problem with the scope of Wikidata item of this property (P1629). I've put a single-value suggestion constraint on Wikidata item of this property (P1629) so editors will think a bit more about what value(s) are correct. Swpb (talk) 20:55, 10 January 2024 (UTC)

I'm not sure why it's a problem that Wikidata item of this property (P1629) sometimes has multiple values, if those values are correct.

Because people decide to use Wikidata item of this property (P1629) instead of more-specific properties, which decreases machine-readability and thus the quality of Wikidata. If we removed Wikidata item of this property (P1629), people would be forced to use the more-specific properties and overall data quality would thus improve.

In your given example of YouTube video ID (P1651), the values YouTube (Q866) and YouTube video (Q63412991) are just wrong: the only correct Wikidata item of this property (P1629) (or more specifically, class of non-item property value (P10726), since ID values are strings) for YouTube video ID (P1651) is YouTube video ID (Q110851517).

The current property description doesn't indicate that. It just says "item corresponding to the concept represented by the property". It's very ambiguously defined. It's also why this property is problematic: it basically acts as "this property is related in some way to this item".

Also there was an approved proposal that stretched the definition of Wikidata item of this property (P1629) outside of the "class of property value" you explained above to include the database which an ID is part of.

Maybe we should start a discussion on the correct usage of the property on its page? Lectrician1 (talk) 21:12, 10 January 2024 (UTC)

I'm not going to engage in a parallel discussion on whether Wikidata item of this property (P1629) should be deprecated: there's already a discussion taking place on that. I do think statements where the value is a type of external identifier should be moved to its sub-property class of non-item property value (P10726), but that doesn't make them wrong, just not as specific as possible. I think before you propose an item-datatype equivalent of class of non-item property value (P10726), I'd want to see some better examples where Wikidata item of this property (P1629) has taken on multiple, especially contradictory, meanings. Swpb (talk) 21:35, 10 January 2024 (UTC)

@Swpb

I'd want to see some better examples where Wikidata item of this property (P1629) has taken on multiple, especially contradictory, meanings.

Have you seen this now? Lectrician1 (talk) 18:19, 13 January 2024 (UTC)

Can we get through migrating to existing properties before we talk about proposing new ones? I have too many fronts going as it is. Swpb (talk) 18:41, 13 January 2024 (UTC)

Could you answer the question please? Just asked for clarity 🥺 Lectrician1 (talk) 18:42, 13 January 2024 (UTC)

Sure, I'm just saying I'm a little too overwhelmed answering concerns about my migrations (I'm on mobile on the weekend) to help with a P1629-related property proposal at the moment, not taking a position on whether we will need one. Next week I'll work on some sparql queries to see what we're working with, beyond the ID-valued properties I've been focused on so far. If you feel the need to go forward with a proposal before then, you can, I'm just saying I'd want a better grasp of the use cases first. Swpb (talk) 20:19, 13 January 2024 (UTC)

As an aside, one thing that would help specifically for identifiers is a constraint that currently can't be constructed, but that I'm pushing for. We would like to be able to say that properties that are instances of Wikidata property for an identifier (Q19847637) (e.g. YouTube video ID (P1651)) should not use Wikidata item of this property (P1629), but should instead use its sub-property class of non-item property value (P10726) if the value is an identifier type (e.g. YouTube video ID (Q110851517)), or identifies (P10476) (not a sub-property of Wikidata item of this property (P1629)!) if the value is the type of thing identified (e.g. YouTube video (Q63412991)). This would look like Wikidata item of this property (P1629)property constraint (P2302)conflicts-with constraint (Q21502838)property (P2306)instance of (P31)class (P2308)Wikidata property for an identifier (Q19847637)replacement property (P6824)class of non-item property value (P10726) OR identifies (P10476). But since conflicts-with constraint (Q21502838) doesn't take class (P2308) as a parameter, we can't do this yet. Swpb (talk) 21:37, 10 January 2024 (UTC)

I agree with Swpb. The problem is the value of mother (P25) is a mother (Q7560) uses is a differently than is a is used in other parts in Wikidata. I think that makes Wikidata more confusing to use.

Seperately as a matter of process, when it comes to making proposals to increase the scope of a property you should ping everyone involved in the property discussion behind the property. ChristianKl ❪✉❫ 12:02, 11 January 2024 (UTC)

@ChristianKl

uses is a differently than is a is used in other parts in Wikidata

I know we don't use "mother" in P31 in wikidata and that's why it might seem unconventionaly to declare it as an "is a" relationship. But... if the relationship between the value of mother (P25) and the entity itself is not an "is a" relationship, then what type of relationship is it actually? Lectrician1 (talk) 18:15, 13 January 2024 (UTC)

I don't think that should be the driving consideration, because it doesn't lead to consistent usage of concepts. There are many different notions of is_a being used in different projects and it's valuable to have consistency within a project. ChristianKl ❪✉❫ 12:57, 14 January 2024 (UTC)

I don't understand. What doesn't lead to consistent usage of concepts? Could you elaborate/give example please? Lectrician1 (talk) 14:47, 14 January 2024 (UTC)