Wikidata:Property proposal/values are instances of

values are instances of edit

Originally proposed at Wikidata:Property proposal/Computing

Withdrawn

Description	to be used on data types to denote which values they support
Data type	Item
Domain	items that are instances of data type (Q190087)
Example 1	Wikibase item datatype (Q115470359)values are instances ofWikibase item identifier (Q111513391)
Example 2	Wikibase property datatype (Q115468759)values are instances ofWikibase property identifier (Q111513349)
Example 3	Wikibase lexeme datatype (Q115470231)values are instances ofWikibase lexeme identifier (Q111513387)
Example 4	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)
Example 5	Wikibase URL datatype (Q29934281)values are instances ofURL (Q42253)
Example 6	Wikibase Math datatype (Q42742777)values are instances ofTeX expression (Q115642178)
Example 7	Wikibase Musical Notation datatype (Q62080777)values are instances ofLilyPond expression (Q115642263)
Planned use	I plan to add such statements for every instance of Wikibase datatype (Q19798645).
See also	class of non-item property value (P10726)

Motivation edit

I think we really need a property to link instances of data type (Q190087) to the values variables/properties of that data type may assume.

While we could model this in reverse with manifestation of (P1557) this would be a very awkward way of modelling this because e.g. not every URL is a manifestation of the Wikibase URL datatype, so it would have to be qualified with nature of statement (P5102)sometimes (Q110143752), which would just make the whole statement quite useless).

Suggested English aliases:

has value
allows value
supports value
is a set of values

--Push-f (talk) 07:23, 9 December 2022 (UTC)[reply]

Discussion edit

Support So this is like "allowed values" of props? If so, I support but I think it should be called "allowed values" --Vladimir Alexiev (talk) 16:36, 12 December 2022 (UTC)[reply]
- Yes it is similar to value-type constraint (Q21510865). I agree that "has value" wasn't the best label and have relabeled the proposed property to "values are instances of", which I think is the more clear :) --Push-f (talk) 04:37, 13 December 2022 (UTC)[reply]
  I'm concerned that doesn't make much of a difference; besides being grammatically inconsistent with most other property labels (we simply write P412 as "voice type", not "voice is instance of") it exposes the expression "instance of" in a way that will hardly make it easier for novice editors to pick the right property (when they enter "instance" in the form field they should get instance of (P31) as their primary suggestion, not this one).
  
  This will be a pretty uncommon property anyway, so I recommend a long and explicit label such as "subject value type" (meaning "the subject of this statement has a value that is an instance of"). This is also meant to differentiate it from other kinds of "value" properties such as numeric value (P1181), face value (P3934), applicable 'stated in' value (P9073), estimated value (P8340), stability of property value (P2668), maximum value (P2312), reference value (P5446), dummy value (P5692), or minimum value (P2313).
  
  Could there be confusion with item inherits statement from (P5852)? That is hopefully less of a problem.
  
  See also class of non-item property value (P10726) (related property), maybe even category for value same as Wikidata (P3734), category for value different from Wikidata (P3709), and use with property value (P8395) (not sure whether and how they relate).
  
  I think the rule to avoid plural forms in item labels applies equally well here. "Musical Notation values are instances of Lilypond expression" means exactly the same thing as "Musical Notation value is an instance of Lilypond expression", if you were to use "instance" anyway.
  
  Besides, I'm doubtful as to the usefulness of this property, but I will defer that argument for others to make; I focus on the choice of label, should it be created anyway. --SM5POR (talk) 06:23, 13 December 2022 (UTC)[reply]
Oppose There should not be separate items for the datatypes; these items do not meet the notability criteria and should be deleted. For example, Wikidata property (Q18616576) and Wikibase property (Q29934218) have existed for years, but recently items were created for Wikibase property identifier (Q111513349) and Wikibase property datatype (Q115468759) as well. What purpose does it serve to have separate items for these? Other than among themselves they are not linked from any other item, so they do not meet the notability criteria. –LiberatorG (talk) 06:04, 13 December 2022 (UTC)[reply]
The data types are clearly notable because they meet WD:N#2: they are a clearly identifiable conceptual entities and they are described by two serious and publicly available sources (mw:Wikibase/DataModel as well as http://wikiba.se/ontology). Because the data types are notable the identifiers for the entity types are also notable because of structural need (WD:N#3) as demonstrated in examples 1-3 of this proposal.

--Push-f (talk) 09:58, 13 December 2022 (UTC)[reply]
Examples 1-3 merely indicate the syntax of statements involving the entity types. Proposing a syntax for the statements doesn't demonstrate a structural need for said statements; it's like saying you have a structural need for "+" in order to be able to express "A+B". The actual question is: Why do you need to make those statements (not "A+B", but those involving the entity types)? Can you give a practical example of application rather than mere expressions?

However, that issue depends on the data type items you created being notable in the first place. I'm afraid I'm not familiar with the situations where they are used nor what makes them "clearly identifiable conceptual entities", but I will have to leave that question to @LiberatorG who made me realize those items didn't exist before you created them. Without examples of practical use, citing formal requirements in the notability guidelines carry very little weight, like pulling a virtual house of cards out of thin air. --SM5POR (talk) 12:05, 13 December 2022 (UTC)[reply]
The data items for the data types in examples 4-7 have all been created back in 2017/2019 by Jura1. And yes I created the items for the other 3 data types because they were previously conflated (subclass of (P279)Wikibase entity (Q111513007) does not belong on the same item as instance of (P31)Wikibase datatype (Q19798645) because these are two separate entities with different exact match (P2888) values). --Push-f (talk) 13:44, 13 December 2022 (UTC)[reply]

Primary sources do not establish notability; otherwise an item could be created for every menu item in a software application, because it's own documentation documents it. To be clear I do think that the concepts of a Wikibase item, Wikibase property, etc. are notable, but don't see how the datatype as a distinct concept from a Wikibase item or Wikibase property is notable. In rare cases a datatype could be notable, just as we have an item for Albert Einstein's brain (Q2464312) because it was detached, studied, and written about independent of Albert Einstein (Q937), but that doesn't mean that there should be separate items for other people's brains that are known only for their function within the person, or items for Einstein's other internal organs. Similarly I don't see an issue with a single item for a Wikibase string that is a subclass of Unicode string (Q115684457) or string (Q184754); this does not require any new items or properties. –LiberatorG (talk) 18:09, 13 December 2022 (UTC)[reply]
I realize that you are probably right about primary sources not establishing notability ... WD:N however does not explicitly state that ... it just says "serious and publicly available references" ... it doesn't restrict who may have published that reference. But what you're saying makes sense.

In that case I'd justify the existence of Wikibase item datatype (Q115470359), Wikibase property datatype (Q115468759) and Wikibase lexeme datatype (Q115470231) with the Wikidata:Use common sense policy.

We have over 100 million data items that all use these data types ... so it is very much only common sense to describe these data types in the Wikidata database itself. --Push-f (talk) 09:02, 14 December 2022 (UTC)[reply]
Withdrawn I didn't consider modelling this via subclass of (P279) ... that does actually make sense since an instance of e.g. Wikibase string datatype (Q29934246) is also an instance of a Unicode string (Q115684457). --Push-f (talk) 08:57, 14 December 2022 (UTC)[reply]