Shortcuts: WD:PP/GEN, WD:PP/Generic

# Wikidata:Property proposal/Generic

Jump to navigation Jump to search

## See also

This page is for the proposal of new properties.

 Before proposing a property Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties. Check if the property was previously proposed or is on the pending list. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically. Select the right datatype for the property. Start writing the documentation based on the preload form below and add it in the appropriate section. Creating the property Once consensus is reached, change status=ready on the template, to attract the attention of a property creator. Creation can be done 1 week after the proposal, by a property creator or an administrator. See steps when creating properties.
 On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2018/07.

## Generic properties

### SNOMED CT identifier

Under discussion

#### Motivation

I think this property is an useful data, different from official website (P856), for example: Gtkmm (Q284796) has official website (P856) value: https://www.gtkmm.org/, and we could have a GNOME Wiki Id property, with a possible value: https://wiki.gnome.org/Projects/gtkmm -- diskutujo 22:56, 1 May 2018 (UTC)

#### Discussion

• @Liuxinyu970226: I didn't know I can do that, but reading the page, I'm not sure if is a good idea create a proposal, because I'm not sure about the license of the contents, and I think that 300 items are insufficient for a new interwiki prefix.

Not done--Micru (talk) 17:00, 17 July 2018 (UTC)

### visible by means of

Under discussion
Description items of interest can be visible through other items (e.g. webcams) Item type of linked items: Q template a water well such as Mosaikbrunnen (Q27229889) might be live-visible on a web cam such as NZZ WebCam (Q53678107) after the WVZ data set import (https://www.wikidata.org/wiki/Q53629101), we want to mark the fountains that are visible live on the webcams of the city offers view on (P3173), webcam page URL (P4238)

#### Motivation

When people want to see an item of interest real time through the internet, this gives them a hint how to do so. Another application may be tourist binoculars available in many city- or mountain-viewpoints.  – The preceding unsigned comment was added by Ralfhauser (talk • contribs) at 03:19, May 18, 2018‎ (UTC).

"offers view on" (P3173) appears to be the reciprocal approach.

Probably, there is yet another property needed "in focus of URL" because the webcam URL is only likely to give access to the webcam, but some webcams hopefully allow to specifiy by means of an url also what (i.e. which direction, focus, zoom) they should point

#### Discussion

•  Support This is a great example of documenting unusual physical relationships thanks to Wikidata. Matthew (talk) 08:22, 18 May 2018 (UTC)
•  Comment you could do it like this without the need of a new property--Pasleim (talk) 16:28, 18 May 2018 (UTC)
• See webcam page URL (P4238). Thierry Caro (talk) 17:37, 18 May 2018 (UTC)
•  Oppose per @Pasleim:'s suggestion that doesn't require the creation of a new property. Dhx1 (talk) 13:49, 6 June 2018 (UTC)

### production website

Under discussion
Description An official page of a television series hosted by the network or production company. URL "production website" in en:template:infobox television property My Mister (Q43111245) → http://www.chorokbaem.com/main/ko/sub04_02_31.html?xid=4&subxid=2 official website (P856)

#### Motivation

Production website is used in the English infobox. It would be nice to be able to link it to other languages Wikipedia pages just like official website (P856). CherryPie94 (talk) 12:27, 18 May 2018 (UTC)

#### Discussion

Do you have an example where it would be different from official website (P856)? Perhaps just a qualifier on official website (P856) would take care of this? ArthurPSmith (talk) 17:34, 18 May 2018 (UTC)
If we are to link it to Wikipedia infobox it would not work. Currently, the official website is migrated from Wikidata to Englis Wikipedia, but since there is no property for the production website, that can't be done. https://en.wikipedia.org/wiki/My_Mister#External_links This TV series has 1 official link, and 2 links to the production company pages about the TV series. CherryPie94 (talk) 10:42, 20 May 2018 (UTC)
Support Ok, I was mainly just looking for the property template to be filled out, I added your example. ArthurPSmith (talk) 15:01, 21 May 2018 (UTC)
Oppose the proposal lack more examples, domain, infobox parameter, cardinality (can it have multiple values?) etc. URL (P2699) with a qualifier could be used, couldn't it? -- JakobVoss (talk) 06:22, 16 June 2018 (UTC)

### Political coalition

Under discussion
Description agreement for cooperation between different political parties politician (Q82955) Item Dilma Rousseff (Q40722) → position held (P39) → President of goku (Q5176750) → Political coalition = For Brazil to keep on changing (Q5466690) parliamentary group (P4100)

#### Motivation

I'm involved in a project of strutured narrative about brazilian elections that I think it will be useful to improve elections items at Wikidata. The database of the official electoral institutions can provide a lot of information. Scrap and bring this data is part of the plan. A political coalition is an agreement for cooperation between different political parties. In a parlamentary item, besides party, it would be great to have the coalition that politician was involved while the electoral process. Ederporto (talk) 01:19, 20 May 2018 (UTC)

#### Discussion

•  Comment position held (P39) statement tend to be overloaded with qualifiers. Maybe an item for each coalition government works better.
--- Jura 17:57, 20 May 2018 (UTC)
@Jura1: Can you be more clear? I didn't get it. Thanks, Ederporto (talk) 23:01, 20 May 2018 (UTC)
•  Support David (talk) 12:45, 26 May 2018 (UTC)
•  Weak oppose. I'm not sure this is the best way to model this. I think we need to look at a broader set of political coalitions and how they work across countries, and figure out a setup that works as widely as possible. --Yair rand (talk) 19:43, 27 June 2018 (UTC)
•  Support -- diskutujo 18:28, 30 June 2018 (UTC)
•  Support. In the Brazilian case, this refers to electoral coalitions, an object of our electoral system. I understand this applies elsewhere. Joalpe (talk) 01:27, 8 July 2018 (UTC)

### sense for this name

Not done
Description sense of a lexeme corresponding to name Sense (not available yet) Warsaw (Q270) native label (P1705) "Warszawa" → Warszawa/capital of Poland

#### Motivation

Not sure how to do this. (Add your motivation for this property here.)
--- Jura 15:22, 13 May 2018 (UTC)

#### Discussion

It sounds like you are trying to create an inverse of item for this sense (P5137) (which you created though we can't use it yet)? Or is this somehow different (can you clarify)? In any case, I think the inverse direction (which P5137 may already cover) is the better one here, otherwise you'll have one statement per language on each place item. ArthurPSmith (talk) 14:48, 14 May 2018 (UTC)
• I'm trying to figure out how to solve last year's usecase. I'm not sure if P5137 would be sufficient. Maybe we could try an equivalent of statement is subject of (P805). This could be used as a qualifier for a statement such as 'native label = "Warszawa" '.
--- Jura 15:12, 14 May 2018 (UTC)
• I updated this accordingly.
--- Jura 12:22, 15 May 2018 (UTC)

If I understand correctly, this is intended to connect a Statement on an Item to a Lexeme using a qualifier. The use case makes sense to me, but if I understand the structure of this page correctly, this request is misplaced: this section appears to be for Properties to be used on Senses. The proposed Property refers to a Sense, but would be used as a Qualifier on a Statement (supposedly on Items), on on Senses. So the request should probably be at Wikidata:Property_proposal/Generic. -- Duesentrieb (talk) 11:24, 24 May 2018 (UTC)

Not done --Micru (talk) 17:00, 17 July 2018 (UTC)

### number of rocket stages

Not done
Description number of stages for a rocket rocket stage (Q4809) Quantity rocket (Q41291) positive integers Sputnik (Q1393751) -> 2

#### Discussion

Ideally this would have a less unwieldy name like "number of stages", although I'm afraid people would then start adding it to stuff like 2018 Tour de France (Q28859163).--Reosarevok (talk) 19:34, 9 June 2018 (UTC)
Oppose has parts of the class (P2670) with an item like "rocket stage of Sputnik" and quantity (P1114) would be a better way to specify this relationship. The proposed property is too specific. ChristianKl❫ 14:05, 14 June 2018 (UTC)

Not done --Micru (talk) 16:58, 17 July 2018 (UTC)

### reference has role

Ready Create
Description role, or specific nature, of the given reference reference (Q121769) Item references limited list of allowed values AS PART OF REFERENCE → first description (of a taxon) (Q1361864) convert existing uses of P31 as a reference to use the new property

#### Motivation

We currently have about 50,000 cases where instance of (P31) is used as a property in a reference, rather than as a main statement. See queries: tinyurl.com/y78odkdu (counts of values), tinyurl.com/y8owabzc (examples). The use on e.g. Q101538#P225 is typical.

In my opinion, use of P31 in this way is ugly and confusing -- IMO it would be better if P31 was only used for its main purpose, as a direct statement on an item giving its nature.

Use of P31-on-references is similar to the way P31 once used also to be used as a qualifier. But those uses have now everywhere been removed and replaced with subject has role (P2868) and object has role (P3831).

P31-on-references is currently doing some important work. In particular, the #1 value of P31-on-references, first description (of a taxon) (Q1361864), to be able to indicate that the reference in question contained the first description and definition of a taxon is extremely valuable and important to be able to highlight for taxonomic references.

To me it therefore makes sense to propose a new drop-in replacement "reference has role" for P31-on-references, as a specific property to take over this function, which is different from the normal use of P31; and which would allow a constraint to limit acceptable values to an agreed controlled vocabulary. -- Jheald (talk) 14:30, 10 June 2018 (UTC)

#### Discussion

Notified participants of WikiProject Taxonomy -- Jheald (talk) 14:56, 10 June 2018 (UTC)

•  Support. Appears to me, a relatively inexperienced Wikidata-er, to fill a niche role. If/when created, could instance of (P31) be software-restricted from being placed in references, to avoid confusion & accidental placement? —Tom.Reding (talk) 15:24, 10 June 2018 (UTC)
The software wouldn't completely prevent it, but it would register a constraint violation, and place a warning error sign next to it. Jheald (talk) 19:52, 10 June 2018 (UTC)
Comment - This is not an isolated proposal: publication in which this scientific name was established also deals with this issue, but proposes to move this to a statement. Since there are so many cases for this, and likely to become more, a separate property (making this a statement) seems well justified. The qualifier "first description (of a taxon) (Q1361864)," looks quite awkward to me (also wrong: it is the establishing of a name that matters here, not the description): if there are three references listed, will the software that reads in data be able to determine what reference this qualifier belongs to? A separate property would make this unnecessary. - Brya (talk) 17:12, 10 June 2018 (UTC)
@Brya: I don't see the two proposals as necessarily in conflict. Firstly, there are other reasons why one might want to annotate a reference: establishing a taxon is only one example. Secondly, even if there was a separate statement for when the scientific statement was established, one might still want to note of a reference that it was the originating paper, or the statement that redefined the taxon, or some other notable thing about the paper. But it would be a good thing to get rid of the current P31s.
As to your technical question, the annotation becomes part of the reference (as the present uses of P31 do). It is therefore uniquely associated with a single reference, just as much as the properties "stated in" or "volume" or "page" would be. There is no danger of crosstalk with any other reference. Jheald (talk) 19:52, 10 June 2018 (UTC)
Yes, on this last point, I had realized that the danger of software reading it out wrong was quite limited. It will still be confusing to the reader. - Brya (talk) 16:41, 11 June 2018 (UTC)
Hi Brya, I think this proposal makes queries like that a little bit more understandable. I'm not really happy with the creation of publication in which this taxon name was established (P5326). --Succu (talk) 19:10, 25 June 2018 (UTC)
Hi Succu, I understand that switching to publication in which this taxon name was established (P5326) would involve a lot of edits (some fifty thousand items being involved). But there is an even larger number of items involved which don't yet have an original publication attached (much, much larger), so it is worth taking time to reconsider before taking on that larger number. Having a property like P5326 is much more user-friendly. - Brya (talk) 05:31, 26 June 2018 (UTC)
This add (made by Jheald) would be a perfect usage of type of reference (P3865). For my concerns please see below (type <> role). --Succu (talk) 21:45, 4 July 2018 (UTC)

### mathematical concept defining formula

Not done
Description mathematical formula representing the definition of a mathematical concept Mathematical expression instances and subclasses of mathematical concept (Q24034552) absolute value (Q120812) → ${\displaystyle \left\{{\begin{array}{rl}x,&{\text{if }}x\geq 0\\-x,&{\text{if }}x<0.\end{array}}\right.}$ absolute value (Q120812) → ${\displaystyle x\mathop {sgn} (x)}$ defining formula (P2534)

#### Motivation

defining formula (P2534) allows to add the formula that defines a mathematical statement, but currently there isn't a property to add the formula that defines a mathematical concept. Malore (talk) 18:00, 10 June 2018 (UTC)

#### Discussion

•  Support David (talk) 16:21, 14 June 2018 (UTC)
•  Oppose per Arthur, just use defining formula (P2534) - feel free to broaden its description and usage instructions to reflect that. − Pintoch (talk) 13:50, 15 June 2018 (UTC)

Not done --Micru (talk) 16:57, 17 July 2018 (UTC)

### mathematical concept definition

Not done
Description definition of a mathematical concept in natural language Multilingual text (not available yet) instance or subclass of mathematical concept (Q24034552) absolute value (Q120812) → "unsigned" portion of a number absolute value (Q120812) → distance of a number from zero

#### Motivation

It's the same of "mathematical concept defining formula" but expressed in natural language instead of mathematical expression.

It differs from the item description because the latter should be a short sentence used only to identify the item. Another difference is that a mathematical concept can have multiple definitions.

It should contain as few symbols as possible to be comprehensible by everyone. Malore (talk) 18:27, 10 June 2018 (UTC)

#### Discussion

Oppose Sorry, but for me is exactly the same as the description. The Wikipedia article fills the function of disambiguate the possible interpretations or definitions of a formula. The item exists to show the metadata about the formula, not its interpretation, if someone is curious about the possible meanings of it, they should go to the Wikipedia article. Good contributions, Ederporto (talk) 23:48, 10 June 2018 (UTC)

Also, this is so subjective. The quantity of symbols does not ensures the unserstanding, the choice of words is more dangerous than the use of symbols. Ederporto (talk) 23:53, 10 June 2018 (UTC)

Oppose this is what the description field is for. Also multilingual text (data type) does not exist. ArthurPSmith (talk) 18:35, 11 June 2018 (UTC)

@ArthurPSmith: They have differentt goals. The goal of the description field is to distinguish the item from similar ones, while the goal of this property is to give all the definitions of the concept. It is the same of "mathematical concept defining formula" (the other property I proposed) but in natural language instead of symbols. --Malore (talk) 21:41, 11 June 2018 (UTC)

Oppose Wikidata is designed to store structured information, definitions of concepts in natural language are not structured. Descriptions can be used for that. − Pintoch (talk) 13:52, 15 June 2018 (UTC)

@Pintoch: I agree with you that Wikidata should store structured content, and maybe this property is not appropriate, but I think it would serve a different function than descriptions. In my opinion, descriptions (like aliases) are for identify items, not for define them, because otherwise they would need to be sourced.--Malore (talk) 02:19, 3 July 2018 (UTC)

Oppose -- JakobVoss (talk) 06:13, 16 June 2018 (UTC)

Not done --Micru (talk) 16:56, 17 July 2018 (UTC)

### API endpoint

Under discussion
Description base URL of a web service URL data set (Q1172284), web service (Q193424) Wikidata (Q2013) → https://www.wikidata.org/w/api.php (no standard protocol) Library of Congress (Q131454) → "unknown"qualifier described at URL (P973) https://libraryofcongress.github.io/data-exploration/ Library of Congress (Q131454) → http://lx2.loc.gov:210/LCDBqualifier protocol (P2700) Search/Retrieve via URL (Q337367) GitHub (Q364) → https://api.github.com/graphqlqualifier protocol (P2700)qualifier described at URL (P973) https://developer.github.com/v4/ GitHub (Q364) API → https://api.github.com (no standard protocol)qualifier file format (P2701) JavaScript Object Notation (Q2063) websites of each item and third-party directories such as https://www.programmableweb.com/apis/directory SPARQL endpoint (P5305), feed URL (P1019), URL (P2699)

#### Motivation

Specify API endpoints to access databases via web services. Standard protocols can be added with qualifier protocol (P2700) and link to API documentation with qualifier described at URL (P973). This property was also discussed as part of Wikidata:Property proposal/SPARQL endpoint. API endpoints can already be specified with URL (P2699) and qualifier protocol (P2700) but many endpoints don't follow a standard protocol and it's more convenient to query endpoints without qualifier. -- JakobVoss (talk) 06:58, 16 June 2018 (UTC)

#### Discussion

Support (but please don't support your own proposal - it makes it clearer to assess at a glance if there is consensus) − Pintoch (talk) 08:23, 18 June 2018 (UTC)
Support ArthurPSmith (talk) 14:44, 18 June 2018 (UTC)
Oppose duplicates the existing property proposed at Wikidata:Property proposal/Archive/48#P2699. I don't think it can work work as intended by the proposer ("it's more convenient to query endpoints without qualifier."). Maybe it's just that the use case isn't specified.
--- Jura 06:15, 19 June 2018 (UTC)
This makes no sense to me: you just argued the opposite at Wikidata:Property proposal/SPARQL endpoint -- JakobVoss (talk) 21:07, 20 June 2018 (UTC)
• I don't think I did, but it's possible that I just don't understand your usecase. As you haven't given it, that seems normal. So what do you want to do with this property that you can't do with the one proposed for the same at Wikidata:Property proposal/Archive/48#P2699. Please include a sample query and application.
--- Jura 04:05, 21 June 2018 (UTC)
Support - Bit sad that we already have SPARQL endpoint (P5305), because this seems to be much more versatile. Husky (talk) 19:20, 19 June 2018 (UTC)
Support - I actually like that we have SPARQL endpoint (P5305) as well, because I think that a SPARQL endpoint has particularly strong relevance for people working with Wikidata. But I do think this property is a useful distinction over generic URL (P2699) -- an API for data extraction is a very specific sort of URL, that it is useful to separate from other sorts of URLs the site may offer; and the API URL statements are already going to be quite complicated, with quite a lot of potential qualifiers flying around. It's a lot cleaner to be able to consider them separately, without them being muddled together with all sorts of other URLs, with all sorts of other role-specific qualifiers. Jheald (talk) 21:05, 19 June 2018 (UTC)

#### Motivation

To have a better organization of the filters and to stop using {{Property documentation}} parameters. 11:12, 30 June 2018 (UTC)

#### Discussion

•  Oppose I think it would be better to model this by creating an item for each filter, and using properties to describe its scope and purpose. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:38, 2 July 2018 (UTC)
• I like your idea too. :-) -- 13:08, 2 July 2018 (UTC)
•  Comment I think the goal (and my wish) is to turn off abuse filters specific to certain properties as soon as contraints are well integrated with recent changes and input interface. Then, we won't need them anymore. Matěj Suchánek (talk) 08:50, 3 July 2018 (UTC)
• Sadly, I'm not sure the development team wants the quality extensions to prevent edits or to show warnings as abuse filters do (and, as far as I know, there are no signs to believe they're going to implement these possibilities in the near future), but that's my wish as well. Nonetheless, I also admit that the community isn't managing constraints well: endless lists of exceptions, unjustified constraints to simply generate reports (instead of using the Query Service or Listeria with that purpose), additions and removals of constraints by editors who individually consider the current number of violations too high or too low, etc. -- 09:59, 3 July 2018 (UTC)
•  Comment There don't seem to be plenty of these. Most aren't specific to properties and some not even viewable by people like me (e.g. Special:AbuseFilter/5).
--- Jura 11:43, 9 July 2018 (UTC)

### perfume note

Under discussion
Description the note of a perfume no label (Q55315285) Item "notes" in en:Template:Infobox Fragrance, "notes" in fr:Modèle:Infobox Parfum perfumes Habanita (Q3125263) → vanilla (Q13241) no label (Q3393810) → Coriandreae (Q15513308) Femme (Q3068231) → Coriandreae (Q15513308) Harvesting from fragrance infoboxes eventually complete (Q21873974)

#### Motivation

Improving perfume support. Next step is top_note, heart_note and base_note, stored in the en infobox. Teolemon (talk) 15:24, 1 July 2018 (UTC)

#### Discussion

•  Support. Perhaps the value items should be "instances of note"? Also potentially useful for beers/wines etc. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:56, 2 July 2018 (UTC)
• Yes, good idea :-) Teolemon (talk) 21:10, 6 July 2018 (UTC)

### CJKV variant character

Description Equivalent forms of Han characters used in different regions Z-variant (Q8062847) Item CJKV character instance of CJK character (Q53764732) 挙 (Q54879263)("挙") → 擧 ("擧") (writing system (Q8192): Kyūjitai (Q1147857)) 挙 (Q54879263)("挙") → 举 ("举") (writing system (Q8192): simplified Chinese characters (Q185614)) 挙 (Q54879263)("挙") → 舉 ("舉") (writing system (Q8192): traditional Chinese characters (Q178528)) 温 (Q54872784)("温") → 溫 ("溫") (writing system (Q8192): traditional Chinese characters (Q178528), Kyūjitai (Q1147857)) 漢 (Q54872914)("漢") → 汉 ("汉") (writing system (Q8192): simplified Chinese characters (Q185614)) 殺 (Q54879672)("殺") → 杀 ("杀") (writing system (Q8192): simplified Chinese characters (Q185614)) 巣 (Q54881859)("巣") → 巢 ("巢") (writing system (Q8192): Kyūjitai (Q1147857)) Wikipedia:Z-Variant; Unicode (kZVariant): https://www.unicode.org/reports/tr38/index.html#kZVariant Linking corresponding shinjitai/kyūjitai/traditional Chinese/simplified Chinese/Variant Chinese characters with one another. eventually complete (Q21873974) traditional Chinese characters (Q178528),simplified Chinese characters (Q185614),Kyūjitai (Q1147857),Shinjitai (Q1055887),Extended shinjitai (Q5421905),Hanja (Q485619),Chu Nom (Q875344),Xin Zixing (Q8044489),Variant Chinese character (Q837611),Sawndip (Q923677)

#### Abstract

The proposed property is designed to link equivalent Han characters used in different regions that are encoded under different codepoints in Unicode. It is inspired by the kZVariant property present in the Unihan database but attempts to improve on it by describing how the characters are related to one another.

#### Motivation

As of July 2018, up to 1016 items with the description "CJK (hanzi/kanji/hanja) character" have been created. Upon closer inspection, most of these characters belong to the set of Kyōiku kanji and are unique. However, two Han characters which are semantically related, (Q54552723)("") and (Q3594925)("") have been created with no indication of their relationship with one another. The former is a Japanese shinjitai while the latter is a simplified Chinese character, both of which are related by their kyūjitai/traditional form "". A property is needed to indicate this relationship. KevinUp (talk) 01:02, 3 July 2018 (UTC)

#### Discussion

•  Support Variant Han characters should be linked to each other. Okkn (talk) 18:16, 3 July 2018 (UTC)
• @Was a bee, Deryck Chan, NMaia, VIGNERON, Stevenliuyi: Any thoughts? --Okkn (talk) 18:29, 3 July 2018 (UTC)
•  Support BTW, I noticed that the kyūjitai/traditional Chinese character “樂” (U+6A02) has the same form as hanja U+F914, U+F95C and U+F9BF. The three hanja characters are actually one character with different pronunciations (heteronym (Q875690)). Should we create one item or four different items in this case? If we create separate items, should we also use this property to link them? --Stevenliuyi (talk) 22:06, 3 July 2018 (UTC)
• If separated four items were created for 樂, they can be linked using this property. However, at this time, I think we don't have to separate them. --Okkn (talk) 05:40, 4 July 2018 (UTC)
• Hi. "" is a rare exception of a single character being split into four codepoints due to different pronunciations. The codepoints U+F914, U+F95C and U+F9BF belong to CJK Compatibility Ideographs (Q2493848). Unfortunately, it is not possible to create new items for them because the compatibility forms will convert back to its main ideograph after being created. An example of how compatibility forms are dealt with can be seen here: (Q54879672) and (Q54872914). KevinUp (talk) 11:58, 4 July 2018 (UTC)
• Tentative  Support, and I think the qualifier should be writing system (P282)? Deryck Chan (talk) 22:58, 3 July 2018 (UTC)
•  Support Support this. By the way, all Han characters have counterpart in different languages? Although I don't know well about diversity of Han characters, if there are characters which exist only in certain language, how about using, for example, "no equivalent" to show such fact. --Was a bee (talk) 22:07, 4 July 2018 (UTC)
•  Support Jc86035 (talk) 11:42, 6 July 2018 (UTC)

@KevinUp, Stevenliuyi, Deryck Chan, Was a bee, Jc86035:  Done: CJKV variant character (P5475) --Okkn (talk) 17:47, 18 July 2018 (UTC)

### GlyphWiki ID

Done. GlyphWiki ID (P5467) (Talk and documentation)

#### Motivation

This new Wikidata property for Wikidata property for authority control for people (Q19595382) would allow a better coverage of the arts (Q2018526).
Identifying artists, curators and exhibition places ('location') through exhibition records has the quality of a reliable authority control.
As exhibitions are fundamental to the discourse in Modern and Contemporary Art, making them searchable with artist-info.com enables new possibilities for research and analytics.
It is different to authority control for people based on auction, library, dictionary (e.g. ThiemeBecker, Bénézit, Oxford) or artwork collection records (museums).
We are documenting with artist-info.com solo- and group-exhibitions at exhibition venues (galleries, museums, non-profit) with all participating artists and if possible with the curator from 1880 up to the present, worldwide.
Our sources are exhibition catalogs, archives, and ephemera. The interactive exhibition histories of artist-info show the relational structure and profiles of artists, curators and exhibition venues alike.
We include links to Wikipedia pages of artists, curators and locations on the related artist-info pages (10.431 as of July 8, 2018) for more biographical information as well as an authority control link to VIAF (includes Wikidata) and WorldCat (VIAF or LCCN based) for library holding information (14.108 as of July 8, 2018).
We publish our groundbreaking research based on exhibition records on www.artist-info.com/blog/
The database was started 1993 and first published on the Internet in November 1996. You find as of July 8, 2018: 182.800 artists, 7.504 curators, 12.285 venues in 1.500 cities in 163 countries, 212.501 exhibitions (680.844 edges).
Access to all artist-info.com artist, curator and exhbition venue pages is free (no registration, no charges).
THHAP (talk) 10:07, 8 July 2018 (UTC)

#### Discussion

• @Pintoch: Thank you for your advice. Example 1, 2, 3 is corrected. THHAP (talk) 12:12, 18 July 2018 (UTC)

@ديفيد عادل وهبة خليل 2, THHAP, Pintoch:  Done: artist-info artist ID (P5489). − Pintoch (talk) 09:01, 19 July 2018 (UTC)

### artist-info curator ID

#### Motivation

NATO Stock Numbers (NSNs) are used by NATO member country armed forces for identifying materiel (equipment, spare parts, components, etc) which can be ordered through military supply chains. With an NSN, public databases can be searched to retrieve manufacturer details, pricing, information on hazardous substances, some technical specification details and numerous other details. Dhx1 (talk) 13:09, 10 July 2018 (UTC)

### description of glyph

Under discussion
Description description of a specific glyph. Multilingual text (not available yet) item if individual characters are represented by items 🔗 (Q55522849) → two or three interlocked chain links (English) MISSING MISSING No

#### Motivation

This provides a visual description of a specific symbol. GZWDer (talk) 12:29, 14 July 2018 (UTC)

#### Discussion

•  Comment multilingual text does not exist as a datatype. Why wouldn't you just put this into the description of the item? ArthurPSmith (talk) 13:59, 16 July 2018 (UTC)
• For example the character "⌛" can be described as "an hourglass", but it is clearly not suitable for description as it is confusing. See wikt:Wiktionary:Votes/2016-08/Description.--GZWDer (talk) 17:10, 16 July 2018 (UTC)
• I don't see that that discussion supports your claim that it is "clearly not suitable for description". The discussion seemed to be on the issue of senses, not of describing the glyph, and of course it was in Wiktionary, not Wikidata so the meaning of "description" is not clearly identical. In Wikidata we have now 🍑 (Q55424107) which is described as "peach emoji" in English. "hourglass emoji" or "glyph in the form of an hourglass" seems fine as descriptions to me. That's what the description field is for, and we shouldn't be adding new properties that serve essentially the same purpose. ArthurPSmith (talk) 17:59, 17 July 2018 (UTC)
•  Oppose. A natural-language text description is not structured data. --Yair rand (talk) 18:20, 16 July 2018 (UTC)
•  Oppose per Yair. Mahir256 (talk) 20:36, 17 July 2018 (UTC)

### Unicode block

Under discussion
Description Unicode block that a character is in Unicode block (Q3512806) Item item for Unicode characters 🔗 (Q55522849) → Miscellaneous Symbols and Pictographs (Q2494135) 気 (Q3594993) → CJK Unified Ideographs (Q994386) MISSING eventually complete (Q21873974) Yes

#### Motivation

This information is important for individual Unicode characters.GZWDer (talk) 12:37, 14 July 2018 (UTC)

#### Discussion

Support Mahir256 (talk) 23:00, 14 July 2018 (UTC)

### artist-info exhibition ID

Under discussion
Description Identifier in the artist-info database for exhibition records External identifier Wikidata property for authority control for people (Q19595382), Wikidata property related to art (Q27918607) [a-zA-Z0-9-]+-Id[0-9]\d+ no units Armory Show (Q688909) → 69th-Regiment-Armory-Id363342 Live in your Head: When Attitudes Become Form (Q21661998) → Kunsthalle-Bern-Id317396 This Is Tomorrow (Q3018307) → Whitechapel-Art-Gallery-Id327043 https://www.artist-info.com, artist-info (Q55344434) Adding artist-info location Id to artist-info (Q55344434) Statements.For 79 of 528 exhibitions, which are related to art-exhibition (Q667276), artist-info knows all participating artists, which the wikidata entry doesn't.As Identifier property on a Wikidata art-exhibition pageExample: Adding artist-info exhbition ID as Identifier to Armory Show (Q688909), to find all artists of this seminal exhibition and the many hundred other exhibitions 1880 – today of these artists. artist-info.com exhibition database knows 212.560 (54.395 group-exhibitions, 158.165 solo-exhibitions) always with the complete list of participating artists, from 1880 up to the present, in 12.292 venues, in 1.500 cities in 163 countries. always incomplete https://www.artist-info.com/users/exhibition/$1-$2 No bots or gadgets artist-info.com is the only database which provides the key information 'all artists/exhibition' for art exhibitions. Examples for artists are

#### Motivation

See as well artist-info artist ID, artist-info curator ID, artist-info location ID proposal motivation.
As artist-info.com is the only database which 'all artists/exhibition' for art exhibitions I would like to add this property proposal in addition to artist-info artistID, curator ID, and location ID, too.
Not only that this informatin is missing in artist CVs, gallery, museum, or non-profit exhibition histories, the unique artist-info.com advantage is our artist-database, identifying artists always with her/his ID regardless which exhibition.
Access to all artist-info.com artist, curator and exhbition venue pages is free (no registration, no charges). THHAP (talk) 15:34, 14 July 2018 (UTC)

#### Discussion

•  Support David (talk) 11:13, 16 July 2018 (UTC)

### date of release

Under discussion
Description the date that something became available to a wider audience in some way publication (Q732577), sort of Point in time artificial entity (Q16686448)? Portal 2 (Q279446) → 19 April 2011 MISSING MISSING I'm not doing this for myself; that's not how it's supposed to work publication date (P577)

#### Motivation

Yes, I know, publication date (P577) already exists.

publication date (P577) is currently used for both real dates (when the secondary sources say a film was released) and made-up dates (the date on the cover of the magazine, which is actually incorrect because half the articles were published on their website the month before). This property would be for the real dates. This would be useful for data analysis, information published in magazines and journals (see my comments at Wikidata:Project chat#Modelling a publication schedule), and biological classification (see EncycloPetey's comments at Wikidata:Project chat#publication date vs inception (in general)). In short, having the actual date information was disseminated instead of a made-up date is useful sometimes because one of them is factual, and occasionally some other information (like the naming of a species) depends on the small difference between those dates.

This would replace or duplicate publication date (P577) where it is verified with secondary sources that the date is real, and would be added alongside publication date (P577) where it is verified that the stated date is not real. Jc86035 (talk) 17:28, 16 July 2018 (UTC)

#### Discussion

I question what is meant by "real" dates here. publication date (P577) is necessary for the stated date of publication of a work even if the stated date is not the actual date. While issues of priority in biological classification rely upon the actual releases date, bibliographical needs require the stated date of publication printed on the materials. We can't says that one property supplants the other. --EncycloPetey (talk) 17:41, 16 July 2018 (UTC)

@EncycloPetey: For brevity and at the risk of making the proposal seem a bit incoherent, a "real" date for the purposes of those two paragraphs is one which is set in reality – the "actual" release date. I misused "supplant"; I meant "supplement". Jc86035 (talk) 17:45, 16 July 2018 (UTC)

### Ideographic description sequences

Under discussion
Description a way to describe Han characters String "ids" in wikt:template:Han char CJK characters Sequence of Han characters and ⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 雪 (Q3595029) -> ⿱⻗彐 帝 (Q3594965) -> ⿱⿳亠丷冖巾 海 (Q3594998) -> ⿰氵每 (China, Hong Kong, Taiwan, South Korea, Vietnam); ⿰氵毎 (Japan) http://www.babelstone.co.uk/CJK/IDS.TXT 87887 as of Unicode 11, minus indecomposible characters eventually complete (Q21873974) for encoded characters Yes

#### Motivation

This is a way to represent characters, especially unencoded characters like taito (Q7676480). Note we need a qualifier for example 3. GZWDer (talk) 17:48, 16 July 2018 (UTC)

#### Discussion

•  Comment @GZWDer: Ideographic description sequences is useful to describe the glyphs of Han characters. However, I think, in Wikidata, we should store this kind of data as items (with a qualifier series ordinal (P1545)), rather than strings. By doing so, we can easily generate the composition trees of Han characters. What do you think? --Okkn (talk) 18:06, 16 July 2018 (UTC)
• @Okkn: Note the representation is an ordered tree, not a sequence. for example ⿱⿳亠丷冖巾 means ⿱(⿳亠丷冖)巾.--GZWDer (talk) 18:09, 16 July 2018 (UTC)
• @GZWDer: I know that. But the sequence for the "箱", for example, is "⿱⺮相", not "⿱⺮(⿰木目)", right? Or both two sequences should be stored in this property?--Okkn (talk) 18:17, 16 July 2018 (UTC)
• A character may have more than one ideographic description sequences, but the shortest possible Ideographic Description Sequence is preferred. Note Unicode Standard does not define equivalence for two Ideographic Description Sequences that are not identical. See page 424 of [2].--GZWDer (talk) 18:23, 16 July 2018 (UTC)
• Note ideographic description sequences are Prefix notation (Q214510) and brackets never appear in sequences.--GZWDer (talk) 18:25, 16 July 2018 (UTC)
• I know IDSes. Ok, I also think we should only store the shortest one. In that case, shouldn't we link from "箱" to "相" or from "相" to "木"? I want to draw a tree like Figure 1 on the page 131 of [3]. --Okkn (talk) 18:33, 16 July 2018 (UTC)
• Examples of representing IDSes as structured data are shown below. This property can be a subproperty of part of (P361). --Okkn (talk) 20:10, 16 July 2018 (UTC)

For "箱":

IDSes
edit
▼ 0 reference
 + add reference
⺮ (item not yet created) edit
▼ 0 reference
 + add reference
edit
▼ 0 reference
 + add reference
+ add value

For "相":

IDSes
edit
▼ 0 reference
 + add reference
edit
▼ 0 reference
 + add reference
edit
▼ 0 reference
 + add reference
+ add value
Then we will create a lot of items about Han character components. (Yes, [4] includes unencoded components.) How to deal with things like ⿰氵每 (China, Hong Kong, Taiwan, South Korea, Vietnam); ⿰氵毎 (Japan)?--GZWDer (talk) 21:57, 16 July 2018 (UTC)
If we import all Han characters encoded in Unicode 11, the number of components is much lower than that. I think that it's not particularly a problem. Also, in some environment, even the encoded components can't be displayed correctly. So using items brings considerable benefits to everyone.
Variations can be represented as follow:
IDSes
edit
▼ 0 reference
 + add reference
edit
▼ 0 reference
 + add reference
edit
▼ 0 reference
 + add reference
edit
▼ 0 reference
 + add reference
+ add value
I'm not sure whether the common parts ( and 氵) should be duplicated or not. --Okkn (talk) 05:55, 17 July 2018 (UTC)

### Cangjie input

Under discussion
Description The cangjie input code for the character Cangjie input method (Q1033196) String "canj" in wikt:template:Han char Han characters [A-Y]{1,5} 雪 (Q3595029) -> MBSM 帝 (Q3594965) -> YBLB 海 (Q3594998) -> EOWY Unihan database Yes

#### Motivation

This is an common input method of Chinese characters. GZWDer (talk) 18:06, 16 July 2018 (UTC)

#### Discussion

•  Support --Okkn (talk) 19:04, 16 July 2018 (UTC)
•  Support NMaia (talk) 17:57, 17 July 2018 (UTC)
•  Support Mahir256 (talk) 20:36, 17 July 2018 (UTC)

### four-corner method

Under discussion
Description The four-corner code(s) for the character. Four-Corner Method (Q2303847) String "four" in wikt:template:Han char Han characters \d{5} 雪 (Q3595029) -> 10177/10174 帝 (Q3594965) -> 00227 海 (Q3594998) -> 38157 Unihan database Yes

#### Motivation

Note the four-corner method includes the fifth number which is optional in searching. Unihan database represent it as XXXX.X. I don't know whether the dot is needed.GZWDer (talk) 18:16, 16 July 2018 (UTC)

#### Discussion

•  Support --Okkn (talk) 19:04, 16 July 2018 (UTC)
•  Support NMaia (talk) 17:56, 17 July 2018 (UTC)

### Hangul of a Chinese character

Under discussion
Description The modern Korean pronunciation(s) for this character in Hangul Hangul (Q8222) Item Han characters 雪 (Q3595029) -> 帝 (Q3594965) -> 海 (Q3594998) -> 樂 -> 1. 악; 2. 락 (North Korea), 낙 (South Korea); 3. 요 Unihan database Yes

#### Motivation

This is another important information of Han character.GZWDer (talk) 19:29, 16 July 2018 (UTC)

#### Discussion

•  Support The solusion using items seems good to me. --Okkn (talk) 06:17, 17 July 2018 (UTC)
•  Support NMaia (talk) 17:55, 17 July 2018 (UTC)

### Eumhun

Under discussion
Description an (often native Korean) word indicating a Han character's meaning. Only used as a qualifier of Hangul property (see above). eumhun (Q20851511) MISSING Han characters 雪 (Q3595029) -> 눈 帝 (Q3594965) -> 임금 海 (Q3594998) -> 바다 樂 -> 1. 노래 (for 악); 2. 즐길 (for 락 and 낙); 3. 좋아할 (for 요) Note: 즐길 is an inflected form of 즐기다 涴 -> 물 굽이쳐 흐를

#### Motivation

Note I don't know what's the correct datatype - the eumhun may consist more than one word.--GZWDer (talk) 19:47, 16 July 2018 (UTC)

#### Discussion

•  Comment I'm not familiar with Hangul, but this kind of data should be represented as the datatype of Lexeme, or its Sense, right? --Okkn (talk) 06:24, 17 July 2018 (UTC)

### Extra granulated item

Under discussion
Description Extra granulated item Wikimedia page outside the main knowledge tree (Q17379835) Item Abbotsbury (Q306685) → Abbotsbury (Q24665923) Melle (Q20177) → Melle (Q30027441) UFO (Q225344) → Ufo (Q12340062) mainly for Ljsbot articles that make an unusual distinction Bots can start by changing from duplicate or said to be the same. said to be the same as (P460)

#### Motivation

So that over granular item aren't marked as Wikimedia duplicated page (Q17362920) or said to be the same as (P460), see User talk:Jheald#Lsjbot and Wikimedia duplicated page and search the project chant for cebwiki. This avoids cluttering them up with the "complete" duplicates. While it is clear in this example one if for the settlement and one for the unit, most other projects just have 1 article. Lucywood (talk) 20:25, 16 July 2018 (UTC)

#### Discussion

•  Comment I think I understand the intent here, but I'm not sure how this really improves the situation - is the idea to have some mechanism for distinguishing items we might want to keep from duplicate items that are basically irrelevant that we should try to remove (by merging on cebwiki for instance)? We do have things like facet of (P1269) or part of (P361) if one is somehow contained in the other. ArthurPSmith (talk) 17:53, 17 July 2018 (UTC)

### lexeme of property constraint

Under discussion
Description qualifier to define a property constraint in combination with P2302 Lexeme similar to P2305 item of property constraint (P2305): qualifier to define a property constraint in combination with P2302

### exception to constraint (lexeme)

Under discussion
Description lexeme that is an exception to the constraint, qualifier to define a property constraint in combination with P2302 Lexeme similar to P2303 exception to constraint (P2303): item that is an exception to the constraint, qualifier to define a property constraint in combination with P2302

#### Motivation

Supposedly we would need to adapt to the new namespace. Forms might need the same. Feel free to add above.
--- Jura 09:13, 27 April 2018 (UTC)

#### Discussion

Comment a lexeme version of exception to constraint (P2303) could make sense, but do you have any uses in mind for “lexeme of property constraint”? Lexemes as constraint parameters? --Lucas Werkmeister (WMDE) (talk) 13:26, 27 April 2018 (UTC)

### relative date

Under discussion
Description signed time difference between two entities, the other entity being the one indicated by the [ID OF THE OTHER PROPERTY] statement with the same rank and qualifiers (negative value indicates the other entity occurs later) Number (not available yet) any time units Easter − 47 days (Q14914941) → −47 days MISSING MISSING addition to the Easter ±n days items point in time (P585), [ID OF THE OTHER PROPERTY]

#### Motivation

See the section below; this property does not make any sense without the other. Jc86035 (talk) 08:36, 19 July 2018 (UTC)

### relative dates are relative to

Under discussion
Description the entity with which [ID OF THE OTHER PROPERTY], with the same rank and qualifiers, indicates a time difference Item item that has a point in time, or item with a Wikidata property (P1687) statement (in reference to the statement(s) for that property) Easter − 47 days (Q14914941) → date of Easter (Q51224536) MISSING MISSING addition to the Easter ±n days items point in time (P585), [ID OF THE OTHER PROPERTY]

#### Motivation

Currently the items listed at Help:Easter related dates are not actually formally linked. This and future subproperties could be useful for other recurring things like record charts, but I didn't want to propose lots of relative equivalents to existing date properties without any consensus that there should be relative date properties. The reasons two properties are needed are because two different value datatypes are needed (the time and the other item), and to ensure that relationships can also be stated with both properties as qualifiers. Jc86035 (talk) 08:36, 19 July 2018 (UTC)