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

# Wikidata:Property proposal/Generic

 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 2019/01.

## Generic properties

### Pakistan Railways station code

Under discussion
Description code to identify a railway station operated by Pakistan Railways External identifier "code" in en:Template:Infobox station railway station (Q55488)'s in Pakistan (Q843) [A-Z]+ Karachi City Station (Q4373381) → KYC Peshawar Cantonment railway station (Q7171369) → PSC Lahore Junction railway station (Q3695748) → LHR Islamabad railway station (Q15228858) → MGLA various Wikipedia articles and references from the Pakistani government as may be found regarding this property add this to items for stations (especially a great deal which only have sitelinks to urwiki) as many as there have been railway stations in Pakistan—around 1200, according to some estimates I found eventually complete (Q21873974) not yet, though this is surely possible Indian Railways station code (P5696), Amtrak station code (P4803), ESR station code (P2815), China railway TMIS station code (P1378)

#### Motivation

The presence of this identifier is motivated by similar identifiers for the United States (Amtrak station code (P4803)), Russia/the USSR (ESR station code (P2815)), China (China railway TMIS station code (P1378)), and most recently India (Indian Railways station code (P5696)). Mahir256 (talk) 01:15, 25 August 2018 (UTC)

#### Discussion

@Thierry Caro, BukhariSaeed, Obaid Raza: who might find this interesting.

Why can't be used station code (P296) with a qualifier? --Sabas88 (talk) 09:43, 27 August 2018 (UTC)

@Sabas88: If you would like to propose the deletion of the other four properties I mentioned (plus more of the sort), you are welcome to do so, but in the meantime having a separate property for this large collection of stations has its benefits, including the ability to easily define formatter URLs for each country on each country's respective property. Mahir256 (talk) 12:46, 27 August 2018 (UTC)
Oppose for now, if there are reasons that how codes in this country are used in URL schemes, I would change to support. --Liuxinyu970226 (talk) 23:58, 1 September 2018 (UTC)
•  Support Nepalicoi (talk) 12:25, 17 September 2018 (UTC)
@Nepalicoi: Supporting just by adding such template is a pain in the ass, that won't help anyone to know how the potential new property will be helpful for us. --Liuxinyu970226 (talk) 12:05, 6 October 2018 (UTC)
@Mahir256: Please can you cite your sentenses such as "various Wikipedia articles and references from the Pakistani government as may be found regarding this property" with proper bibliographical references? Without references, I'm afraid that your sentenses can be mostly empty sentenses. --Liuxinyu970226 (talk) 12:07, 6 October 2018 (UTC)
@Liuxinyu970226: There are items for rail stations in Pakistan, such as Lahore Junction railway station (Q3695748) (hey, you edited that item!) that presently have a station code (P296) (derived from their respective enwiki articles) which could be converted to use this property. One can also derive lists of codes from old versions of the Pakistan Railways site (this does not mean that the codes are unused presently!--see page 6 here of a recent timetable). Mahir256 (talk) 17:04, 6 October 2018 (UTC)
•  Oppose for now, unless there's a use of this in URLs; at the moment, I can't find any uses of these codes in URLs anywhere on the web, not even on https://www.pakrail.gov.pk . As others say above, there is already a generic solution for when a custom formatter is not needed, and the data could be transferred very easily to a new property created for this purpose if this were the case. -- The Anome (talk) 08:38, 10 November 2018 (UTC)
•  Support consistent with others. There is no requirement for external-id properties to have a formatter url. --- Jura 05:00, 12 November 2018 (UTC)
@Jura1: So link to https://127.0.0.1/\$1.php is also good to go for you?! These subproperties without a defined target for them one-per-one are nowadays problem introducer instead of useful, that's why I won't nominate to have a property for Japanese Telegraph code "電報略号", even I know that that serves an item. --Liuxinyu970226 (talk) 15:21, 18 November 2018 (UTC)
I don't understand what make you conclude that. The proposed datatype isn't URL, but identifier as ISO 3166-2 code (P300). It's also unclear what problem that would introduce. LHR needn't be mixed with London Heathrow. --- Jura 17:05, 18 November 2018 (UTC)
•  Support per @Jura1: -- Bodhisattwa (talk) 12:19, 26 December 2018 (UTC)
•  Oppose Per Liuxinyu970226 and The Anome, it's prefer not to introduce any identifiers from a war zone country. --60.26.9.13 02:41, 4 January 2019 (UTC)
Comment - @anonymous user, You are joking, right? -- Bodhisattwa (talk) 04:01, 7 January 2019 (UTC)

### model item for

Under discussion
Description Defines which item is a best practice example of modelling a subject, which is described by the value of this property Item Items which are classes Douglas Adams (Q42) → human (Q5) Nelson Mandela (Q8023) → politician (Q82955) Zootopia (Q15270647) → animated film (Q202866) Mona Lisa (Q12418) -> painting (Q3305213) Record model items for all of the most used classes on Wikidata, then gradually expand over time to include more granular concepts always incomplete (Q21873886) Wikidata :Property proposal/Model item

#### Motivation

Defines which item is a best practice example of modelling a subject, which is described by the value of this property. Providing best practice examples linked from the subject will make it much easier for people to understand how to model types of items, especially new people. The main hope is that this will lead to more consistent modelling of items rather than different editors making up their own structure. It will also allow a central place to decide how to model certain kinds of items.

By modelling this within the structure of Wikidata rather than in Wikiprojects the structure is multilingual. Also looking at where the model item refers to the concept we can run a standard query that will work for most cases to find all the items that the model applies to, this is not limited to ‘instance of’. This could be used to check which items do and do not have high importance statements, e.g authors without a date of birth.

This could later be complemented with another property which defines the schema for a class of item (e.g author or politician)

This property requires that the inverse property Model item also be accepted to be most useful.

Thanks

John Cummings (talk) 20:15, 11 September 2018 (UTC)

#### Discussion

•  Support - NavinoEvans (talk) 21:04, 11 September 2018 (UTC)
•  Support Jane023 (talk) 06:30, 12 September 2018 (UTC)
•  Support David (talk) 08:20, 12 September 2018 (UTC)
•  Support very good idea, but  Comment what is the intended extent? should all classes have a model or just the upper classes? I see animated film (Q202866) in the example but wouldn't film (Q11424) be better? (both way are fine, but too many model would probably end up as confusing as no model at all) Cdlt, VIGNERON (talk) 08:33, 12 September 2018 (UTC)
Thanks very much @VIGNERON:, I don't think these items will define the schema for that class, just act as good practice examples for people to copy. I'm currently working on an idea for schema modelling using a new property. My guess is having model items for more granular items like 'author' or 'animated film' will be helpful and that you'd want for people to be specific, modelling authors from the model item for 'human' would probably mean people miss out a lot of the author specific details. Same for animated film, e.g animators, software used, rendering engine, voice actors (by language version) etc are all specific to animated films (and some specific to computer modelled animated films even). I don't know how granular you would want to go though, do we want a model item for '16th Century Welsh poets'? I think that's a community decision. --John Cummings (talk) 09:34, 12 September 2018 (UTC)
@Jura1:, I suggest that both are needed to help people navigate, they're not exactly inverse properties of each other as a model item could be the model for several subjects e.g Douglas Adams could be the model for 20th Century British authors and 20th Century British Playwrights. Having both will be more valuable than only having one of them. --John Cummings (talk) 12:19, 12 September 2018 (UTC)
I rather debate on the talk page of "20th Century British authors" about the model status of Q42 than the inverse. --- Jura 12:37, 12 September 2018 (UTC)
I think there is some confusion, do you mean you want to have a discussion on the schema for '20th Century British authors' on the item for '20th Century British Authors'? If so then I assume there is some way of setting up a bot that adds a note to the talk page for model items (e.g Douglas Adams) that directs you to the correct location (e.g item for 20th century British authors). I also think this this unlikely to be an issue once we've implemented some way of describing schemas within the items. --John Cummings (talk) 12:51, 12 September 2018 (UTC)
We already have. So even more so. You can always query it. --- Jura 12:57, 12 September 2018 (UTC)
Hi @Pasleim:, when you say enough, for which use cases do you mean? --John Cummings (talk) 22:08, 12 September 2018 (UTC)
It is enough because all the statements can be inferred from Wikidata:Property proposal/Model item. For new users, for whom this property is mainly, it will make most sense to create a list of all model items. To create such a list you only need one of the two properties. If you have both properties you don't gain anything but your maintenance work will be doubled. --Pasleim (talk) 10:08, 17 September 2018 (UTC)
•  Oppose. Better to point in the other direction. --Yair rand (talk) 22:33, 12 September 2018 (UTC)
@Yair rand:, can you explain why only one direction is better? Surely having two directions will help people to find useful items? These properties are not exactly inverse of each other because an item can be a model item for more than one class. --John Cummings (talk) 22:54, 12 September 2018 (UTC)
• This is actually not relevant information about Douglas Adam. --- Jura 08:54, 13 September 2018 (UTC)
• @John Cummings: I don't see how being a model item for more than one class would make it not an exact inverse. If there's a statement going one way, there would be a statement going the other way. (That is, if X is a model item for both Y and Z, this property would point from X to both, and the inverse would point both to X from both Y and Z.) With both directions, we have two versions of the data, which are not automatically in sync. If someone changes one statement but does not change the other statement, one version will be incomplete. Requiring two actions for each change will cause the data to be less reliable. --Yair rand (talk) 19:36, 16 September 2018 (UTC)
@Yair rand:, thanks. I think this is an issue that needs resolving, that inverse properties are very useful for querying and finding items but are problematic for staying in sync, do you know if anyone has proposed a bot or any other solution to keep them in sync? Not having inverse properties feels like throwing the baby out with the bath water... I will do some looking around at possible solutions John Cummings (talk) 09:31, 17 September 2018 (UTC)
@Germartin1:, could you explain why you think we shouldn't have this property? Thanks, --John Cummings (talk) 09:27, 13 September 2018 (UTC)
First of all, it's an inverse of your other proposal, hence redundant according to Wikidata principles. Personally, I don't see how it adds any kind of value to an item. Germartin1 (talk) 09:37, 13 September 2018 (UTC)
@Germartin1: I don't fully understand why this is against Wikidata principles? Is there a guideline or info page you can point? We have around 100 inverse property pairs at the moment. For example, template's main topic (P1423) and topic's main template (P1424) ... or ... is a list of (P360) and has list (P2354). NavinoEvans (talk) 10:43, 13 September 2018 (UTC)
•  Support Useful, particularly with inverse property. See no harm in using both in supporting developing best practice and some kind of consistency. Stinglehammer (talk) 10:31, 13 September 2018 (UTC)
•  Support Yeah, can see this being helpful. Lirazelf (talk) 11:06, 13 September 2018 (UTC)
•  Support Very useful Jason.nlw (talk) 13:21, 13 September 2018 (UTC)
•  Oppose Nepalicoi (talk) 12:21, 17 September 2018 (UTC)
Hi @Nepalicoi:, can you explain why you oppose the proposal? Thanks, --John Cummings (talk) 14:37, 17 September 2018 (UTC)
• Given that Douglas Adams (Q42) and Nelson Mandela (Q8023) are item that's violate our rules, I don't think it does a reasonable job to present them as a model item and pretend they are best practice. If we have model items they shouldn't conform to our policies. The fact that you have a 50% rate of examples that violate our rules which might be a lot higher then the average rate of items that violate our rules, make me question the concept a bit. ChristianKl❫ 17:32, 25 November 2018 (UTC)

### Logically implies (necessary condition)

Under discussion
Description Necessary condition, i.e. logical consequence of a mathematical statement Logical consequence (Q374182), requirement (Q774228) Mathematical expression Maxwell's equations (Q51501) Mathematical theorems (or other mathematical laws e.g. from theoretical physics) Maxwell's equations (Q51501) =>(P?) Coulomb's law (Q83152) https://en.wikipedia.org/wiki/Logical_consequence connect physics theorems / axioms by logical relation to annotate constraints / necessary conditions should be allowed

#### Motivation

My vision is to enable creating a logically structured semantic network of mathematical theorems (starting with theoretical physics). This would allow researchers to quickly grasp the constraints of the formulae (Wikidata items) they are working on, the framework they are working in. A theorem / formula (Wikidata item) is falsified already if one of its necessary conditions turns out to be falsified. Thus it is vital to know them, in order to prevent mathematical researchers from wasting their time working on something that may be invalid.  – The preceding unsigned comment was added by PhilMINT (talk • contribs) at February 19, 2018‎ (UTC).

#### Discussion

•  Support @PhilMINT: This is an interesting proposal - unfortunate that it seems to have gotten lost. I believe the datatype should be item, not "formula" (your example follows that pattern). I don't particularly like the parenthetical label - you can add that as an alias. Perhaps to be clearer the main English label should be "logically implies"? ArthurPSmith (talk) 20:30, 13 September 2018 (UTC)
• Conditional  Support. I agree that the datatype should be item. I think this property could be useful, although I don't know how many interesting theorems imply other interesting theorems outright, rather than imply in the context of plausible background assumptions. The "source" will be different secondary and textbook sources depending on the relation claimed. "Domain" is another field that seems to be filled in incorrectly: the domain of this property should be something like mathematical object (Q246672) or proposition (Q108163): we need a clear decision on what the domain will be. MartinPoulter (talk) 10:10, 19 September 2018 (UTC)
•  Comment(s) I also included this in Wikidata:Property proposal/Natural science in the maths section. Interesting proposal. I’d propose to add qualifiers to add the necessary axiom and logic in which the implication is valid (eg. some implications are true under ZFC but fot in ZF, or true in first order logic but not in a substructural one). But this needs more development : Banach–Tarski paradox (Q737851) is a logical consequence of ZFC, ie. it is a theorem of ZFC. Specifically, commenting your example, if we consider Maxwell equation an axiomatic system, does not this simply state that Coulomb’s law are a theorem of the Maxwell theory in first order logic ? This is what a logician would tell. In that spirit, I’d complete the proposal with the following properties and/or qualifier that might be needed in a context of mathematical logic like the refinement around the different logics and axiom-set. Please feel free to discuss the best models for the different combinations. For example it might be better to create a « theorem of » property with a theory range « Coulomb's law theorem of Maxwell equation (in first order logic) » considering maxwell equation as a logical theory. author talk page 14:40, 3 October 2018 (UTC)
•  Weak oppose - I agree with the comments above that from a logical perspective this is pretty ill defined. It is likely to be misused because of that, I would say. It is not the proposal's fault at all - I just don't think there is a way to represent this sort of knowledge in a natural way in Wikidata's data model. Perhaps this could be narrowed down to a smaller scope which would make it well defined. − Pintoch (talk) 23:02, 13 January 2019 (UTC)

#### logic and axiom system

Under discussion
Description Necessary condition, i.e. logical consequence of a mathematical statement logical system (Q17488292)   -- or specifically the set of rule of inference (Q1068763) (resp. rule of inference (Q1068763) - the set of axiom or logical theory) Item qualifier of « implies » statement (the previous proposal), maybe useful elsewhere logical system (Q17488292)   (resp rule of inference (Q1068763) - the set of axiom or logical theory) theorem of search < ZFC set theory >logic search < Q4055684 > Something with a higher order logic theorem : Courcelle's theorem (Q5178114). What is the best way to model ? Something with a weaker logic : Markov's principle (Q3922074) that is true in a weaker logic than classical logic but is not obvious. What is the best way to model ? This article discusses the different axioms we can choose in an intuitionistic logic : http://math.fau.edu/lubarsky/Separating%20LLPO.pdf should be allowed
##### discussion

These properties or qualifiers are useful to model en:Deductive_system used to derive the theorems, but there may be terminology issues and different way to model this, so this is only a proposition starting point that needs to be discussed and amended. Taking into account the axiom and inference rules leads to the difficulty that complete logical systems includes the two and that items topic often implies the inference rules used. We already have some properties for logic like admissible in search to link inference rules to logic, for example, but it’s not enough obviously) author talk page 14:40, 3 October 2018 (UTC)

@MartinPoulter, ArthurPSmith, PhilMINT: Notified participants of WikiProject Mathematics author talk page 14:44, 3 October 2018 (UTC)

•  Comment I don't have any strong opinion on this. How many different logic/axiom systems are there? And aren't those two different things anyway? Maybe we already have a qualifier that can capture this appropriately? ArthurPSmith (talk) 18:51, 5 October 2018 (UTC)

### restriction of

Under discussion
Description file format A is a restriction of file format B if all instances of A are also instances of B, but instances of B are not necessarily instances of A. Item en:Template:Infobox file format extended from file format (Q235557) file format (Q235557) GeoTIFF (Q1502796) → Tag Image File Format (Q215106) EPUB 3 (Q27196933) → ZIP (Q136218) Portable Document Format/Archive, version 1 Basic (Q26543628) → Portable Document Format, version 1.4 (Q26085326) http://hul.harvard.edu/gdfr/documents/GDFR-Format-Model-and-Relationship-1_0_7.rtf Populate this property with information from the extended_from infobox parameter (after careful examination, because the meaning of this parameter is often misunderstood). based on (P144)

#### Motivation

This proposal is derived from a rejected "extension of" property proposal.

For digital preservation, we need to know when a file of format A is also a valid instance of format B (see http://hul.harvard.edu/gdfr/documents/GDFR-Format-Model-and-Relationship-1_0_7.rtf, section 3.2). The property based on (P144) is related but broader (for example, EPUB 3 (Q27196933) is a restriction of ZIP (Q136218), but it is also based on (P144) Extensible HyperText Markup Language (Q166074) and Cascading Style Sheets (Q46441).  – The preceding unsigned comment was added by Dipsode87 (talk • contribs) at 10:24, September 13, 2018‎ (UTC).

#### Discussion

•  Support. YULdigitalpreservation (talk) 12:56, 13 September 2018 (UTC)
•  Support. Toto256 (talk) 13:02, 13 September 2018 (UTC)
•  Support Nice and clear proposal, thanks. ArthurPSmith (talk) 20:14, 13 September 2018 (UTC)
•  Support John Samuel (talk) 17:18, 14 September 2018 (UTC)
•  Support David (talk) 09:41, 15 September 2018 (UTC)
•  Comment as this seems to be meant for file formats, I added that in the description. --- Jura 10:45, 15 September 2018 (UTC)
• I think it would be helpful if the label was more specific, to avoid misuse. --Yair rand (talk) 19:54, 17 September 2018 (UTC)
•  Support Dhx1 (talk) 23:46, 29 September 2018 (UTC)
Comment_It seems to me that subclass of (P279) can definitely do the trick. If all files within a subformat are also valid superformat files, then if any file which conforms to the format is an instance of it the restricted subformat is definitely a subclass of its parent. This make sense if you consider the definition of the format as a « class expression » that defines the properties shared by its instances. So I’d tend to  Oppose. author talk page 13:26, 3 October 2018 (UTC) Note that the definition is the same than subclass of (P279) and we should not multiply the number of typing properties. author talk page 13:28, 3 October 2018 (UTC)

### parties (public international law subjects who consented to be bound by the treaty)

Under discussion
Description This property is intended to list the parties (countries or international organizations) of the treaty. It should allow adding several values. Item treaty (Q131569) country (Q6256), international organization (Q484652) Vienna Convention on the Law of Treaties (Q239768) → Nigeria (Q1033) Treaty on International Civil Law of 1889 (Q40449446) → Bolivia (Q750) Convention on the Elimination of All Forms of Discrimination against Women (Q277072) → Sweden (Q34) no signatory (P1891) (previous step in the process of adoption of a treaty) depositor (P2058) (after a treaty was ratified by a country, this country sends the instrument to the depositary)

#### Motivación

This property is needed, because currently Wikidata can show which subjects signed a treaty by property signatory (P1891), but there is no corresponding property to know if any of the signatories consented to be bound by the treaty.

The property should work as this:

``` <P> parties/consented to be bound:    <Q> country/int org
<qualifier> mean                              <Q> ratification, acceptance, approval, accession, ...
<qualifier> date approved                     <date> YYYY-MM-DD (date when the country consented to be bound, such as when parliament voted for it)
<qualifier> approved by law* (if aṕpropriate) <Q>/<text> number or name of the law
<qualifier> date deposited                    <date> YYYY-MM-DD (date when instrument was deposited to the depositary)
<references>

<Q> country/int org 2...
<qualifier> mean                              <Q> ratification, acceptance, approval, accession, ...
<qualifier> date approved                     <date> YYYY-MM-DD
<qualifier> approved by law* (if aṕpropriate) <Q>/<text> number or name of the law
<qualifier> date deposited                    <date> YYYY-MM-DD
<references>
* or approved by signature, etc.
```

Should also be taken in account to add end date, when the treaty is not binding to the country anymore due to withdrawal of the treaty. Zerabat (talk) 22:43, 14 September 2018 (UTC)

#### Discussion

•  Support David (talk) 09:42, 15 September 2018 (UTC)
• Is this specifically for international agreements, or could it also be used for, say, agreements between organizations? --Yair rand (talk) 19:55, 17 September 2018 (UTC)
• This could be for agreements between any subject of international law: between states, between states and other interantional law subjets (e.g. international organizations), and between other international law subjects themselves. --Zerabat (talk) 00:02, 21 September 2018 (UTC)
• @Zerabat: any reason this would be restricted to international law ? And not generalized to signed agreements like contracts or anything ? It seem similar to a contract in spirit, it bounds the different signers. author talk page 13:20, 3 October 2018 (UTC)
• Even if signatory (P1891) may be both for private law and international law, I don't think you need to "approve" a contract signed previously between two persons. In that case, the signature means approval or agreement. But in international law usually is commitment first and then obligation. --Zerabat (talk) 13:36, 3 October 2018 (UTC)
• @Zerabat: Just checked fr:Traité_(droit_international_public) and it seem that the adoption procedure and is way more complicated than this : there is steps « negociation first, then adoption, authentication (formal) / signature / ratification (in french or english) / entry into force / and optionally adhesion for countrys that joins afterward (it seems they are then engaged after the signing) ». My first thought is « rename the property « ratified by ».
It seems that in some countries (« dualist » one) there even is an afterward step to include the rules into the common law of the country (by opposition of « monist » one for which the ratification of a treaty makes it automatically included into the rules). I think this property is intended to register the countries in which the treaty has been ratified ?
. We could also think of a property to register the status of the treaty like « adoption status » with possible values « negociation / adoption / ratification … ». Also I think we could create a property specific for signature as it seems to be a different thing, as you say, as a traditional contract signature. author talk page 15:28, 3 October 2018 (UTC)
Comment after a bit more thinking, I’d propose to model with significant event (P793) , to make each step of adoption atomic and move the dates out of the qualifiers.
Your property would nethertheless be useful to list all the country in which the treaty is fully active, with start/stop date and appropriate ranks. This is because I think the Wikidata way is not to « update » a statement about the status of a country but to use rank to make the most recent statuses be used in infoboxes and put an end date and normal rank to statuses that was valid at some date (per Help:Ranking, if the temperature change we don’t update the statement, we create a new one with a different date and change the rank, I think we should do something consistent for evolving statuses). For example we list the bound country after the step of « entry into force », qualified with a begin date, or after the adhesion step for the appropriate country, and we forget the other qualifiers (date approved and date deposited mostly). author talk page 15:50, 3 October 2018 (UTC)
One problem with having the country as a qualifier value is that it means one can't use further qualifiers like identity of object in context (P4626), which can be necessary sometimes. --Yair rand (talk) 02:21, 22 November 2018 (UTC)
@Yair rand: Pardon me but looking at the examples I don’t really understand why we don’t use the value of identity of object in context (P4626) as the main value of the statement ?? author talk page 13:34, 22 November 2018 (UTC)

### this should be fixed / maintenance tag

Under discussion
Description relevant maintenance issue for this entity or statement (create a new item for the issue if an appropriate one does not exist) Item Thriller (Q380825) → [new item for "this item incorrectly conflates a music track and a composition"@en] [some statement] → [new item for "this statement may be factually incorrect"@en; or Template:Dubious (Q5618578)] Love, Simon (Q29169280) → [new item for "this item for a creative work does not have all release/publication dates"@en] I Will Always Love You (Q666856) → [new items for "this item's singles chronology or singles chronologies should be in qualifiers to P179 statements on an item for the single"@en, "this item incorrectly conflates a music track and a composition"@en, "this item incorrectly conflates multiple music tracks (live recordings, remixes and cover versions should have their own items)"@en, "this item combines data for different creative works, which should be separated into distinct items"@en, "this item incorrectly conflates a song/track with its music video"@en, and "this item incorrectly conflates a music track with a single (singles are regarded like albums even if they only have one track)"@en] American Idiot (Q151714) → [new items for "this item has data which applies only to individual versions or editions of this creative work, which should be separated into different items" and "items should exist for this item's versions or editions"@en]

#### Motivation

(Inspired by Geertivp's comment at m:Community Wishlist Survey 2019/Wikidata/Improvements to the reliability of Wikidata.)

It is not possible to manually add maintenance tags like Wikipedia's "citation needed" tags. A standard way to add issues to items and statements (e.g. "this item needs to be updated" or "this statement (date/geocoordinate) could be made more precise" or "this item for a creative work does not have all release/publication dates") would be very helpful. Property constraints cannot substitute for all of those issues.

Currently the only realistic way to get input for some odd issue is to post on the project chat, and if no one replies the issue will be forgotten in the archives; and for some tasks (e.g. example 1) it is currently much, much easier to automatically add a maintenance tag than it is to automatically fix the problem. It may also be difficult for Wikipedia editors to know how to correct information that is transcluded to articles.

This property would be analogous to OpenStreetMap's "fixme" key. I have proposed the "item" datatype rather than the "string" datatype because this way it will be easier to manage and translate issues. Jc86035 (talk) 11:15, 4 November 2018 (UTC)

(If a script or gadget is indeed written for registered Wikipedia editors to add these statements directly from infoboxes, I would favour having the tool post custom/other issues at a centralized page, rather than create a new property with datatype string for issues which aren't in the list of options.) Jc86035 (talk) 16:28, 6 November 2018 (UTC)

#### Discussion

•  Weak support I understand your point, but wouldn't it be better to just fix it or write it in the talk page. Can't queries be used to find out which items lack statements? Germartin1 (talk) 16:44, 4 November 2018 (UTC)
The idea behind the "fix-me button" is that the person that sees the faulty/doubtful entry does not necessarily/easily know the correct value for the Statement without substantial analysis. Just being able to hightlight the potential quality problem can invite other, more capable, users to fix the problem (either edit or delete after analysis of finding additional sources). Also the Reasonator or the Wikipedia infobox filling algorithm could further ignore doubtful information. Geertivp (talk) 17:24, 4 November 2018 (UTC)
•  Strong support Just the other day I was thinking how nice it would be if Wikidata had a "citation needed" mechanism, and was even contemplating a property proposal for that! You could add this as a qualifier to a particular statement to indicate it needed a supporting citation (or some other issue fixed), I assume? The examples you have are for more general issues at the entire entity level where it could be a regular statement. ArthurPSmith (talk) 23:14, 4 November 2018 (UTC)
@ArthurPSmith: Yes; it's just that I haven't noticed any statements recently where this would be appropriate and which I didn't fix. There are probably lots of small islands where the coordinates aren't accurate enough to indicate which island the item is actually about, for instance, but I haven't gone searching for them. Jc86035 (talk) 18:36, 5 November 2018 (UTC)
Citation needed doesn't really need a new property though--we just need to use something like the item for mainspace [citation needed] or make one and to put that in the reference list for a particular claim. So this isn't all that strong a case for a tag like this. --Izno (talk) 15:46, 6 November 2018 (UTC)
@Izno: I don't think it should go in the reference list. If an existing property is used in references, then a bunch of items have to be checked for by the Wikidata-related Lua modules and their statements removed from the reference list, which makes it more difficult to transclude sources and filter unsourced statements. (And if the new property is used in references, then the new property… also has to be checked for by the Lua modules.) Jc86035 (talk) 16:23, 6 November 2018 (UTC)
Yeah that's probably a decent reason not to deal with it in references. Qualifiers? Might be cool for e.g. a Lua module on a wiki to see the Q number that is assigned to citation needed and say "oh, that's a citation needed: I should display my template for citation needed". --Izno (talk) 18:44, 6 November 2018 (UTC)
•  Support Wostr (talk) 23:47, 5 November 2018 (UTC)
• Conflating can be a rough case to deal with since you need to add multiple items possibly (which are the conflating ones?). So maybe that should get its own property "conflates" or similar? --Izno (talk) 01:46, 6 November 2018 (UTC)
@Izno: I'm not sure how useful it would be, other than as a subproperty of this one; and maybe that would overcomplicate the use of this property. Usually (as far as I'm aware) if an item's sitelinks discuss two or more topics (e.g. audio/composition, library/building, taxon/species, word/concept, work/book, locality/district/government, group/people) then either the item should only be about one of those things, or there should be items or lexemes created to represent the individual topics. Jc86035 (talk) 14:27, 6 November 2018 (UTC)
•  Support Jheald (talk) 09:06, 6 November 2018 (UTC)
•  Oppose given the proposed scope: marking items as incomplete just seems nonsense. See notably sample 3= Q29169280 → [new item for "this item for a creative work does not have all release/publication dates"]). --- Jura 18:56, 6 November 2018 (UTC)
• @Jura1: Where was this proposed to be used for "marking items as incomplete"? All wikidata items will always be incomplete, so that really wouldn't be a useful label. This is for specific problems that can be seen but can't be immediately solved. ArthurPSmith (talk) 19:42, 6 November 2018 (UTC)
• Have look at sample 3 and similar items. Then, maybe compare with the number of publications dates found at other sources. The suggested reason applies to most if not all film items. Merely tagging stuff isn't really helpful. --- Jura 19:48, 6 November 2018 (UTC)
• If it's not useful then people won't use it for that, but this doesn't seem like "nonsense" to me - for that example the list of publication dates could be known to be complete or incomplete and it certainly makes sense to have a way to denote that specific fact directly on the item. ArthurPSmith (talk) 19:33, 7 November 2018 (UTC)
• Here you just supported a proposal that does that. Marking items as complete or incomplete is probably something that is needed, but I don't think we should start adding tons of statements marking items or some of their statements as incomplete. This can be done with constraints. --- Jura 08:59, 8 November 2018 (UTC)
•  Comment Secondly, another problem with the above is that it combines questions about the validity of statements with structural issues. We already have ranks (and some properties) that are meant to deal with the first ones and I don't think this should be mixed into this problem as well. --- Jura 08:59, 8 November 2018 (UTC)
•  Comment thirdly, I think part of the above maintenance issues already surface with standard or complex property constraints. The first are being made available on query server. As such, I don't think they should be repeated as statements. I'm curious what the participants of WikiProject Property Constraints think about it. --- Jura 08:59, 8 November 2018 (UTC)
@Jura1: For some of those issues I have actually used property constraints on the related identifiers (e.g. MusicBrainz release group ID (P436)), but it can be ambiguous as to exactly why the constraint is there, and sometimes complex constraints are required (i.e. no one is going to know about the issue because the constraint doesn't show up on the item).
I don't think combining those types of issues into one property would be problematic. Many Wikipedias use one master template or CSS class to make all of their page issue templates, for instance, and Wikidata doesn't need to have a distinction between inline issue templates and page issue templates. Jc86035 (talk) 09:18, 8 November 2018 (UTC)
•  Oppose per Jura1; further thoughts: (1) those claims would be about the item itself, not about the entity described by the item; (2) we don’t keep up with covi list maintenance, and this one would be probably much worse as the targeted fixes are typically much more complex than constraint violations; (3) even fixme items with lengthy descriptive labels are often unsuitable to exactly describe the problem, so users might be confused, rather than motivated to fix something; (4) tagging with templates on item talk pages seems more appropriate. —MisterSynergy (talk) 09:27, 8 November 2018 (UTC)
@MisterSynergy: I think using item talk pages would be a reasonable alternative, but it might not be very useful unless the issues are shown on the item itself with a gadget or script. Jc86035 (talk) 09:33, 8 November 2018 (UTC)
I do not think that random item page visitors would contribute to fix the tagged problems to any measurable extent. Unlike Wikipedias, our data users (readers) do not typically browse items in a browser where they could see the tags. You would have to collect the tags anyway, and list them on a maintenance page akin to Ivan's covi lists. Petscan can perfectly do this with template tags on item talk pages, and this can also be automatically transferred to a suitable wiki page by bot. —MisterSynergy (talk) 09:44, 8 November 2018 (UTC)
@MisterSynergy: Also, the "create a talk page" approach for statements might result in issues that are never marked as resolved even after the statement's correction, and would be much harder to transclude to Wikipedias which might want to know that the data being used is potentially bad.
While random people visiting Wikidata items probably don't contribute measurably, I wonder what would happen if a Wikipedia decided to start automatically displaying "citation needed" tags for all unreferenced statements in Wikidata infoboxes. Presumably the same visibility would also be helpful for specific issues. (I assume that Wikipedias might prefer that situation over having more aesthetically pleasing but citation-less and unverified infobox data?)
(in reply to your point 1) I think it's reasonable to have a meta-property for items, since there are already meta-properties for properties (and permanent duplicated item (P2959) is arguably also a meta-property). Jc86035 (talk) 09:56, 8 November 2018 (UTC)
(1) The problem of forgotten tags exists for a statement-based approach as well. (2) From my experience, mainly at dewiki, Wikipedias tend to avoid using any (potentially) “problematic” statement at all; many even ignore all unreferenced statements; I don’t think we can or should expose such rather complex problems to Wikipedia readers on a large scale. (3) I don’t like most of the other meta statement properties as well; this one seems particularly dangerous. (4, new) We would need to define policies how to deal with controversial tags; at Wikipedias, editors fight a lot about the question whether a particular tag (template) is appropriate in a page or not; I’m glad we don’t have this yet at Wikidata. —MisterSynergy (talk) 17:22, 8 November 2018 (UTC)
@MisterSynergy: Using item talk pages works if the issue is a problem with the item as a whole, but it doesn't help to identify individual statements that might be problematic - unless you can think of a way to do that with a template? I can imagine a template highlighting specific properties that should be checked more carefully, for example. Also I haven't ever run across an item with such a template in Wikidata, are there some existing examples? ArthurPSmith (talk) 15:29, 8 November 2018 (UTC)
As far as I know, we do not have this yet in Wikidata. A statement-based approach might work for items and statements, but not for qualifiers and references, and probably also not well for ranking and snaktype issues. —MisterSynergy (talk) 17:22, 8 November 2018 (UTC)
•  Strong support for the big challenge of Wikidata mapping external concepts. In Sweden I start seeing the problem when external concept should be matched that doesnt have mapping relation type (P4390) SKOS exact match (Q39893449). Then we inside Wikidata needs to define
I feel this is a complex process and we need to have more examples/ discussions internally and als externally to start understand how this need to be done. Marking objects were we see this challenge is an excellent start. We can today see a challenge what we inside WIkidata map as a church and the Swedish National heritage creates 2 objects for a church: One is just the building and the other is a container object for all objects next to the church. I guess in Wikipedia a church is a church but when we tries to match more specialist domains we will see that we maybe doesnt have the same granularity...and I guess WIkidata as a World wide site we will meet a lot of challenges....
I would also like to be able to combine this with a Phabricator ticket number... so issues/discussions can be tracked - Salgo60 (talk) 09:58, 8 November 2018 (UTC)
•  Support We are already tagging some issues like , but it would be better to have designated property for this. --Jarekt (talk) 13:16, 8 November 2018 (UTC)
•  Wait I think the general concept makes sense but we need to have more discussion about the optimal name. I also agree that incompletion shouldn't be ground for adding this tag. ChristianKl❫ 19:13, 8 November 2018 (UTC)
• I think we should define some kind of workflow/tools to be used as this is complex. I created an EPIC T202530 "Feedback processes and tools for data-providers" to gather questions/thoughts like this in e.g. user stories - Salgo60 (talk) 09:44, 9 November 2018 (UTC)
@ChristianKl: Why not? For some items, particularly if there is to be a complex import for a subset of items which can't be defined through a trivial SPARQL query and which are edited frequently, it may be useful to temporarily add a tag to an item, regardless of whether or not the tag indicates incompletion. The name should be agreed upon, although perhaps it would be useful to have that discussion in a more visible place, since there is consensus for the property but the discussion has stalled. Jc86035 (talk) 16:48, 16 November 2018 (UTC)
If you can define such a query you can simply have a page with the list of items that have a particular incompletion. I don't see why such a list isn't doing the job. Anybody who actually looks at the item will be able to see themsevles that it's incomplete.ChristianKl❫ 17:35, 17 November 2018 (UTC)

### exonym

Under discussion
Description name given to an entity in a language that is not the official language of the place or country of this entity (useful if the entity changed its name at some point and using the label could cause an anachronism) exonym (Q81639) monolingual text or lexeme-invalid datatype (not in Module:i18n/datatype) places, organizations Examples can be found for example here : https://en.wikipedia.org/wiki/Geographical_renaming#Exonyms_and_endonyms MISSING MISSING avoid anachronism in infoboxes, per community demands official name (P1448)

#### Motivation

As stated in the description, some entity change their names. We handle this with official name (P1448) in the native language of the entity, but we don’t have an equivalent for names in different countries. author talk page 14:40, 13 November 2018 (UTC)

a discussion in Project chat Wikidata:Project_chat/Archive/2018/11#Questions_about_names_:_«_unofficial_»_names_given_by_foreigners_and_the_future_of_names_in_the_lexeme_era ( pinging participants @Jmabel, AnonMoos: ) author talk page 09:15, 14 November 2018 (UTC)

#### Discussion

•  Comment Would you consider having this as a Lexeme-valued property, rather than monolingual text? ArthurPSmith (talk) 21:21, 13 November 2018 (UTC)
•  Comment I agree it should be lexeme related property. KaMan (talk) 05:11, 14 November 2018 (UTC)
• Answer @KaMan, ArthurPSmith: Actually I would have sweared I had putted « monolingual text or lexeme » as datatype in the proposal but it seems I did not /o\ Done now

(also Notified participants of WikiProject Names author talk page 09:07, 14 November 2018 (UTC)

•  Support OK, support as lexeme-valued property. Even though there are a lot of examples on the link you give, it would be nice to see some examples laid out explicitly the way you would like them done (also maybe one or two not in English). ArthurPSmith (talk) 15:12, 14 November 2018 (UTC)
•  Comment name (P2561) could generally be used. It avoids debating if the name is an exonym or not. --- Jura 12:50, 15 November 2018 (UTC)
@Jura1: I’m unconfortable with this solution in this case, there is at least a need to discriminate between several kind of names and the generic property is not enough. A solution to define an exonym could anyway to create a mandatory qualifier « name given by », after all it’s a ternary relationship as an exonym is associated to an entity that gives the name, always. But it could also fit on the lexeme if we use the lexeme datatype which is the consensus at this point - another difference with this property. author talk page 12:59, 15 November 2018 (UTC)
What about name (P2561) with qualifier issued by (P2378)? --Pasleim (talk) 18:02, 20 November 2018 (UTC)
• @TomT0m: Please put in the examples in the way the property is supposed to be used. That information clarifies the proposed semantics of a proposed property. ChristianKl❫ 23:40, 16 December 2018 (UTC)
•  Oppose Given unclearness of the semantics. ChristianKl❫ 19:26, 17 January 2019 (UTC)

### measured by (KPI),key performance indicator,indicator,KPI

Under discussion
Description Target, is measured by this (key performance) indicator performance indicator (Q860554) Item All KPIS Target 1.1 of the Sustainable Development Goals (Q50254181) is measured by Indicator 1.1.1 of the Sustainable Development Goals (Q57595345) Target 5.4 of the Sustainable Development Goals (Q57590789) is measured by Indicator 5.4.1 of the Sustainable Development Goals (Q57595472) Target 16.b of the Sustainable Development Goals (Q57590935) is measured by Indicator 16.b.1 of the Sustainable Development Goals (Q57595665) 7368361 https://en.wikipedia.org/wiki/Performance_indicator ; https://www.bernardmarr.com/default.asp?contentID=1346 update all sustainable development targets with ~200 indicators, and more to come. ~200 no discovery method (P1046) is only for planets

#### Motivation

I want to compare different indicators measuring the same targets in different countries / companies. Michael Cieslik (talk) 09:18, 28 November 2018 (UTC)

#### Discussion

•  Comment Do you have some examples of how this could be used outside of the Sustainable Development goals? ArthurPSmith (talk) 18:00, 28 November 2018 (UTC)
•  Comment Of course, you can compare the different metrics if best football team, by the Total FIFA World Ranking points on one hand and Total World Cup Points on the other hand. These are two different KPIs. Or compare the "education performance per country" (a good education through indicators, e.g. PISA study Programme for International Student Assessment (Q323481).) Michael Cieslik (talk) 22:42, 29 November 2018 (UTC)
•  Support, though I'm not sure if "KPI" needs to be in the label --- Jura 09:35, 15 December 2018 (UTC)
•  Support what about calling it simply "Key Performance Indicator"? Otherwise it could be misunderstood as a property for physical properties (example: temperature measured by thermometer) --Sabas88 (talk) 21:27, 14 January 2019 (UTC)

Under discussion
Description the item is administrated by the following administrative entity. Item geographical object (Q618123) West Kowloon Station Mainland Port Area (Q48928408) → Shenzhen (Q15174) Tomb of Suleyman Shah (Q7818644) → Turkey (Q43) Canadian National Vimy Memorial (Q2561040) → Canada (Q16)

#### Motivation

Some people misunderstand the definition of located in the administrative territorial entity (P131). The present "protected" version of West Kowloon Station Mainland Port Area (Q48928408) is swearing black is white.

The description of location (P276) stated that: "In case of an administrative entity use P131". It is clear that the Mainland Port Area is an administrative entity, and it is a common knowledge that the Mainland Port Area is located in the Hong Kong SAR.

With reference to previous discussion in project chat, create a new property is the solution. 210.3.92.226 04:55, 30 November 2018 (UTC)

#### Discussion

The High Court of Hong Kong has made a judgement on 13 December 2018. According to paragraph 64 of the Judgement, Judge Anderson Chow said:

It is not in dispute that the Mainland Port Area falls with the territory of Hong Kong under the “Order of the State Council of the People’s Republic of China No 221” dated 1 July 1997, which was promulgated in accordance with the “Decision of the National People’s Congress on the Establishment of the Hong Kong Special Administrative Region” adopted at the Third Session of the Seventh National People’s Congress on 4 April 1990.

223.17.64.233 14:18, 13 December 2018 (UTC)

It still has disputes, at least on the definition of "Hong Kong", afaik at least Swahili language version says that Hong Kong is just only a Peninsula of Zhujiangkou. --125.38.13.94 01:24, 9 January 2019 (UTC)
Oppose Per Liuxinyu970226, better to split Hong Kong (Q8646) as a geographical concept one, and a SAR one, just like that we do have at least two items for Amsterdam, one for the geographical city and another one for the municipality government. --125.36.185.115 03:10, 25 December 2018 (UTC)

### stored as lexeme

Under discussion
Description (qualifier) lexeme version of monolingual text Sense all names stored in Q-items as Monoligual text which represent notable lexemes Bombyx mori (Q134747) taxon common name (P1843) Polish: jedwabnik morwowy → "stored as lexeme" jedwabnik morwowy (L38523-S1) Slovakia (Q214) demonym (P1549) Polish: Słowak applies to part (P518) masculine (Q499327) → "stored as lexeme" Słowak (L38296-S1) English (Q1860) native label (P1705) English: English → "stored as lexeme" English (L35189-S1) Germany (Q183) short name (P1813) French: Allemagne → "stored as lexeme" Allemagne (L22302-S1)

#### Motivation

Now, when we have lexemes in Wikidata, some monolingual texts could be replaced by lexeme datatype. This however is not easy step. This property could simplify in the future transition by providing direct link to lexeme and its sense. KaMan (talk) 11:54, 1 December 2018 (UTC)

#### Discussion

Support Linking to senses would probably be hard to do automatically, I think this is a great idea. ArthurPSmith (talk) 19:21, 3 December 2018 (UTC)
Support Useful linkage, and valuable step for any future transition. Jheald (talk) 17:00, 4 December 2018 (UTC)
•  Oppose proposed label seems inconsistent with others at Wikidata. Usual naming could be "subject of lexeme" --- Jura 06:57, 10 December 2018 (UTC)
@Jura1: Could you please give plenty of examples of these "others at Wikidata"? I don't think there is many from one namespace to another. KaMan (talk) 07:03, 10 December 2018 (UTC)
• Do you have any property label that follows the proposed naming? Any property value is obviously "stored" at Wikidata. Comparing to print dictionaries, one might think it's interesting to repeat, but it's implied once you are at Wikidata. Possibly it's a translation issue from Polish. --- Jura 07:06, 11 December 2018 (UTC)
• @Jura1: "subject of" makes sense when we are referring to a regular property on an item, but this proposal is for a qualifier, so a different context. "subject of lexeme" certainly does not seem right to me to describe a piece of monolingual text that is some value for a statement on an item. "stored as lexeme" makes sense, but there may be a better label. "subject of lexeme" is not better though. ArthurPSmith (talk) 19:06, 10 December 2018 (UTC)
• it's the qualifier value that is the subject of the lexeme. It probably doesn't even need to be limited to use as a qualifier, as some names have items for themselves. --- Jura 07:06, 11 December 2018 (UTC)
• Can you give an example? I don't see how that would work with Wikidata's multilinguality. ArthurPSmith (talk) 17:11, 11 December 2018 (UTC)

### measured by (KPI)

Under discussion
Description Target, is measured by this (key performance) indicator Target 1.1 of the Sustainable Development Goals (Q50254181) is measured by Indicator 1.1.1 of the Sustainable Development Goals (Q57595345) Item All KPIS Target 1.1 of the Sustainable Development Goals (Q50254181) is measured by Indicator 1.1.1 of the Sustainable Development Goals (Q57595345) Target 5.4 of the Sustainable Development Goals (Q57590789) is measured by Indicator 5.4.1 of the Sustainable Development Goals (Q57595472) Target 16.b of the Sustainable Development Goals (Q57590935) is measured by Indicator 16.b.1 of the Sustainable Development Goals (Q57595665) 7368361 https://en.wikipedia.org/wiki/Performance_indicator ; https://www.bernardmarr.com/default.asp?contentID=1346 update all sustainable development targets with ~200 indicators, and more to come. ~200 no discovery method (P1046) is only for planets

#### Motivation

I want to compare different indicators measuring the same targets in different countries / companies. Michael Cieslik (talk) 09:18, 28 November 2018 (UTC)

### minimum wage

Under discussion
Description lowest wage which can be paid legally in a state for working minimum wage (Q186228) Quantity countries or their subdivisions \d+ items with instance of (P31) = currency (Q8142) Ukraine (Q212) → 3723 hryvnia (Q81893) [ valid in period (P1264) = month (Q5151) ] Belarus (Q184) → 330 Belarusian ruble (Q160680) [ valid in period (P1264) = month (Q5151) ] Germany (Q183) → 1498 euro (Q4916) [ valid in period (P1264) = month (Q5151) ] California (Q99) → 11 United States dollar (Q4917) [ valid in period (P1264) = hour (Q25235) ] none putting that property into items about countries and then incorporating them into infoboxes median income (P3529)

#### Motivation

Important economical information that should be in every item about country alongside median income (P3529). --Tohaomg (talk) 00:53, 12 December 2018 (UTC)

#### Discussion

• valid in period (P1264) as a qualifier would mean something very different than the examples use it to mean. I recommend either using a different unit ("dollars per hour" and such, perhaps), or using a different qualifier. --Yair rand (talk) 02:23, 12 December 2018 (UTC)
•  Support David (talk) 07:43, 12 December 2018 (UTC)
•  Comment As it’s likely we already have items for these, for example SMIC (Q751095)   I’d say it’s probably a good idea to use an item datatype and to use a more generic property for the numerical value of it. It would avoid to bloat the item of the country as there may be many different values over time.

Proposition:

• < France > minimum wage search < Q751095 >
• amount search < 1 498,47 €/month >
start time (P580) < 1 Janvier 2018 >
/
amount search < 9,88 € / hour >
start time (P580) < 1 Janvier 2018 >
. It could also be two properties for the hourly and the monthly value to make stuff clearer, this represents different realities. There is also subteleties with the net and gross salaries … I think all this needs a little thought actually author talk page 20:02, 18 December 2018 (UTC)
•  Support most countries have hourly or monthly minimum wages, however in Germany there is no monthly minimum wage but an hourly (please change it). Possibly use two properties as proposed by TomT0m Germartin1 (talk) 01:12, 21 December 2018 (UTC)
•  Support However, I think using TomT0m proposition is a good idea. -- diskutujo 01:50, 1 January 2019 (UTC)

### Parliament of South Africa ID

Under discussion
Description Identifier of a person on the Parliament of South Africa website Parliament of South Africa (Q2185780) External identifier human (Q5) [1-9][0-9]* Beverley Abrahams (Q47529725) → 1226 Beauty Dambuza (Q16744388) → 4343 Evelyn Wilson (Q47529709) → 1686 Patrick Maloyi (Q16744503) → 4303 https://www.parliament.gov.za/group-details/0 2063 Reference members of the South African National Assembly to their corresponding official page 443+ eventually complete (Q21873974) https://www.parliament.gov.za/person-details/\$1

#### Motivation

At the moment, members of the National Assembly of South Africa are not linked to their corresponding pages on the Parliament's official website except by the use of described at URL (P973) statements. These could be replaced by a more structured property. jacksonj04 (talk) 12:20, 13 December 2018 (UTC)

#### Discussion

•  Support --Gerwoman (talk) 19:20, 13 December 2018 (UTC)
•  Support: analogical property was approved - Wikidata:Property proposal/Verkhovna Rada MP id --Tohaomg (talk) 20:11, 13 December 2018 (UTC)
•  Support David (talk) 07:41, 14 December 2018 (UTC)
•  Question Are these IDs persistent once the person leaves office? To take one example, the described at URL (P973) to the official website provided on Vuyokazi Ketabahle (Q47529718) no longer seems to be valid. The current preference is to only create new properties for parliament websites if the ID continues to be useful after leaving office — i.e there is at least one valid formatter URL (P1630) even for ex-members. --Oravrattas (talk) 10:44, 14 December 2018 (UTC)
• I haven't found an example of an identifier being reused, but the page disappearing is definitely an issue to take into consideration. --jacksonj04 (talk) 10:50, 14 December 2018 (UTC)

* Neutral until the pages aren't perennial. Nomen ad hoc (talk) 08:09, 15 December 2018 (UTC).  Oppose per Oravrattas. Nomen ad hoc (talk) 14:07, 1 January 2019 (UTC).

### co-director

Under discussion
Description co-director(s) of film co-director (Q24387718) Item instances of human (Q5) Finding Nemo (Q132863) → Lee Unkrich (Q380920) (IMDb) Inside Out (Q6144664) → Ronnie del Carmen (Q7366035) (IMDb) Slumdog Millionaire (Q125076) → Loveleen Tandan (Q3837845) (IMDb)

#### Motivation

Different from director because co-director usually didn't eligible for film awards. Usually used by Pixar films (see en:List of Pixar films). Hddty. (talk) 07:46, 17 December 2018 (UTC)

### maintenance operation

Under discussion
Description operation that maintains, cleans up or repairs this item and lenghtens its lifespan maintenance, repair and overhaul (Q1043452) Item activity (Q1914636) car (Q1420) → auto maintenance (Q3055308) footwear (Q161928) → Repair of footwear and leather goods (Q29586102) tooth (Q553) → tooth brushing (Q93935) fabrication method (P2079), test method (P4988)

#### Motivation

It would be nice if we could have this. Thierry Caro (talk) 05:00, 19 December 2018 (UTC)

#### Discussion

•  Support David (talk) 07:49, 19 December 2018 (UTC)
•  Comment good idea. For wikidata, that would be Thierry Caro editing? ;) BTW, maybe better samples could be found instead of #1 and #2 (currently Example 1 car (Q1420) → auto maintenance (Q3055308), footwear (Q161928) → Repair of footwear and leather goods (Q29586102)). Supposedly these are "maintenance operations" (as mentioned in description), but not necessarily "maintenance methods" (proposed label). --- Jura 06:14, 22 December 2018 (UTC)
• Somehow I think the actual methods would be more interesting. Obviously the item link as value could have more detailed statements, but if we just can up with a plenty of items that simply have "maintenance" appended to the subject label, this wouldn't add much value. --- Jura 14:07, 22 December 2018 (UTC)
• If there is just an item describing all methods, we could use the custom "somevalue" and the qualifier statement is subject of (P805) to link the item (e.g. "auto maintenance"). --- Jura 14:15, 28 December 2018 (UTC)
etc. "<some property>" might = "domain of application", or some similar label. Jheald (talk) 14:22, 27 December 2018 (UTC)
•  Oppose given current label, samples, per comments above. --- Jura 10:35, 29 December 2018 (UTC)
• @Jura1: C'est quoi le souci précisément sur cette proposition ? Je supposais avoir compris la subtilité la première fois mais maintenant que tu votes contre après le changement que tu suggérais, je me rends compte que non. Thierry Caro (talk) 11:35, 29 December 2018 (UTC)
• J'aimais bien l'idée initiale, mais pas les exemples. J'aurais aligné les exemples et la description sur le libellé, pas le contraire. --- Jura 11:39, 29 December 2018 (UTC)
• C'est-à-dire ? Si tu as deux minutes, je veux bien que tu suggères un ensemble exemple / description / libellé qui t'irait et me permettrait de comprendre à quoi tu penses. Thierry Caro (talk) 11:47, 29 December 2018 (UTC)
• L'exemple #3 va bien tel quel. Les autres de façon indirecte avec P805 comme suggéré ci-dessus. --- Jura 11:50, 29 December 2018 (UTC)
• OK. Merci. Je ne vois pas directement la différence. En fait, ma proposition confondait opération et méthode au départ parce que je ne voyais pas trop la différence et c'est toujours un peu le cas. Pour moi les exemples se valent à peu près. Thierry Caro (talk) 11:59, 29 December 2018 (UTC)
• Je pense pour le premier, les opérations détaillées ("méthodes"?) sont listées à w:Service_(motor_vehicle)#Common_maintenance. --- Jura 12:03, 29 December 2018 (UTC)
• D'accord. Donc si je comprends tu veux qu'on liste toute une série d'éléments très précis du style `remplacement de la culasse`, etc. ? Bon, a priori je ne suis pas contre cette précision mais alors la déclaration ira sur l'élément de la culasse. Pour celui de l'automobile en général, c'est bien un élément sur son entretien en général que l'on veut lister prioritairement. Thierry Caro (talk) 21:40, 29 December 2018 (UTC)
• Peut-être il y a un moyen de les résumer, mais je ne vois pas l'utilité d'une déclaration qui dit principalement que la "maintenance operation" pour "car" est "car maintenance", bien que cet élément puisse aussi être lié. --- Jura 07:57, 31 December 2018 (UTC)

### story by

Under discussion
Description person(s) who have "story by" credits in a film Item "Story by" in en:Template:Infobox film instances of human (Q5) Natural Born Killers (Q748986) → Quentin Jerome Tarantino (Q3772) Straight Outta Compton (Q18154625) → Alan Wenkus (Q4708025) Inside Out (Q6144664) → Pete Docter (Q357627)

#### Motivation

Different from storyboard artist (P3275) because that property is a small title while this property is equivalent to screenwriter (P58). Hddty. (talk) 02:55, 20 December 2018 (UTC)

#### Discussion

Notified participants of WikiProject Movies --- Jura 06:04, 20 December 2018 (UTC)

• screenwriter (P58) is sometimes used for that. Have a look at the query for qualifiers and their values I added at Property talk:P58 --- Jura 06:04, 20 December 2018 (UTC)
•  Oppose There is already author (P50) David (talk) 07:40, 20 December 2018 (UTC)
•  Comment - I would support a property for people involved into story development apart from screenplays. This would be quite useful for many animated films (especially the ones produced before the 1980s) which often are (were) not based on a screenplay and for which the use of screenwriter (P58) to indicate the people involved in story development is actually quite misleading. author (P50) does not really cover this because not all of the people contributing to the story were writers (part of them contributed with visual ideas or with short written sketches of plot elements). Could this property be used also for "weaker" credits than "story by" like "story adaptation", "story direction", "story development", etc.? - Valentina.Anitnelav (talk) 16:20, 29 December 2018 (UTC)
• @Hddty.: What do you think? -Valentina.Anitnelav (talk) 12:51, 6 January 2019 (UTC)
• @Valentina.Anitnelav: I think those credits needs its own property because per Help:Qualifiers "a statement should still provide useful data even without a qualifier". --Hddty. (talk) 03:58, 7 January 2019 (UTC)
• @Hddty.: We could rename this property just to "story" instead of "story by". This makes it a bit more flexible in terms of the various ways people contribute to the story. I don't think that every credit string deserves an own property (there are probably not many films with a story director). Qualifiers should be used to clarify in what way the person contributed to the story. The statement would still provide useful information without a qualifier, it would just not be that accurate. - Valentina.Anitnelav (talk) 06:31, 7 January 2019 (UTC)

### preparation instructions

Under discussion
Description instructions for the recipe cooking (Q38695) Multilingual text (not available yet) Wikibook recipes Warm Black Bean Salad with Kale and Tomatoes (Q59862818) → "In a medium saucepan, heat oil over medium heat for 2-3 minutes. Add onion, garlic, and a pinch of salt into the pan. Cook and stir 2-3 minutes or until onion is tender." (en) MISSING MISSING

#### Motivation

This way we can make Cookbook recipes more machine readable. NMaia (talk) 18:45, 18 December 2018 (UTC)

#### Discussion

• Is the intention to put together some kind of machine-readable language for such instructions? The example seems to be written in a (non-structured) human language, and would not be structured data... --Yair rand (talk) 16:05, 19 December 2018 (UTC)
• IMO what's important is not so much the text in the instructions, but the fact that they are intructions, and given in a certain order for the reader. I don't see how it would be useful to make the instructions themselves machine-readable, since we're not going to have robots preparing full meals anytime soon, but it could be useful as an instant answer for a search engine, for instance. NMaia (talk) 19:30, 19 December 2018 (UTC)
•  Comment Hmm, this really doesn't seem like the right place for this. However, to pursue a bit further (and it might help if you added additional examples) - for a recipe you have a list of ingredients, for which we have has part (P527) with qualifiers for amount etc., and then a sequence of preparation instructions. For the example recipe you've linked there are actually a sequence of 3, so with this property you would presumably add 3 statements with this property, with a series ordinal (P1545) qualifier to order them? ArthurPSmith (talk) 19:05, 20 December 2018 (UTC)
• That's how I envisioned it, yes. NMaia (talk) 12:26, 22 December 2018 (UTC)
•  Oppose I don't see a reason to introduce plain text into Wikidata for such a minor purpose.
People do prepare meals with now with Alexa (who's basically a robot for this purpose) but machine-readability is also important to allow automatic translation and analysis of the data. ChristianKl❫ 11:22, 21 December 2018 (UTC)

### yield

Under discussion
Description how much of a product is generated from the process Yield (Q777948) Quantity {{{2}}} in en:b:template:recipesummary chemical reactions, food recipes Warm Black Bean Salad with Kale and Tomatoes (Q59862818) → 4 Q60038053 MISSING MISSING

#### Motivation

Helps better describe Cookbook recipes. NMaia (talk) 13:27, 22 December 2018 (UTC)

### Distinguishing property

Under discussion
Description qualifier for property constraint. Same as separator (P4155) but for properties with distinct values constraint (Q21502410). Property Wikidata property (Q18616576) taxon name (P225): property constraint (P2302) distinct values constraint (Q21502410) → [Use wikidata should recognize as distinct with the above] (different Codes) Aa (Q9137908) and Aa (Q28101) (different Codes) Salacia coronata (Q2512062) and Salacia coronata (Q20088116) Full list: (>11000) MISSING MISSING remove the need to list exceptions manually on taxon name (P225) separator (P4155)

#### Motivation

Currently, a property with distinct values constraint (Q21502410) must have every single exception listed manually. With a property like taxon name (P225), this causes enough exceptions listed that trying to add one freezes the page. I'm proposing a property that would be the equivalent of separator (P4155), but for use with distinct values constraint (Q21502410) instead of single value constraint (Q19474404). In this case, the property would probably be different from (P1889) or a new "nomenclatural homonym" property. Circeus (talk) 03:22, 23 December 2018 (UTC)

#### Discussion

•  Comment I'm probably missing something, but why doesn't separator (P4155) work for this too? ArthurPSmith (talk) 15:06, 26 December 2018 (UTC)
• Let's just say explanations how to get something like that to work are pretty scarce on Wikidata (a constraint anti-violation like this, I'm given to understand, is not "programmed" within the property pages, for starters). Besides, I'm pretty sure if I went ahead and started trying to edit taxon name (P225), I'd get admin warnings, if only because I wouldn't have that much idea how to go about it. At least this actually gets eyes pointed at the issue. Circeus (talk) 21:34, 27 December 2018 (UTC)
•  Comment I added what I assume to be the proposed use in the template above. Maybe 1 or 2 items that currently have the same taxon name should be listed too. Supposedly a distinguishing property could be parent taxon (if both taxa are in different hierarchies). Simply "different from" and a link to the other uses might do to.
A difference to separator (P4155) could be that the value of this qualifier wouldn't actually be a qualifier of taxon name (P225), but just another property on the item.
@Ivan A. Krestinin, Lucas Werkmeister: any idea how we could make this work? --- Jura 14:35, 28 December 2018 (UTC)
•  Comment maybe we could call this "distinguishing statement" (or "distinct-making statement"?). For the two cases under #1 it would be parent taxon (P171). --- Jura 16:32, 28 December 2018 (UTC)
• @Jura1: I don’t understand that example, sorry. As far as I can tell, Solanum cardiophyllum (Q950868) and Solanum cardiophyllum Dunal (1852) (Q59424086) (currently) have the same parent taxon (P171), so how would this help to distinguish them? --Lucas Werkmeister (WMDE) (talk) 16:41, 28 December 2018 (UTC)
• Good point. @Circeus: what property/statement/qualifier would work? --- Jura 16:44, 28 December 2018 (UTC)
• different from (P1889) could work here. --- Jura 16:54, 28 December 2018 (UTC)
• I was under the impression that different from (P1889) requires that someone believes the two items to be the same. If that is not the case, then it is a perfectly cromulent (L40594) property for this purpose, obviously. Circeus (talk) 19:16, 28 December 2018 (UTC)
• It's not entirely clear to me what the two items are about, but didn't Dunal think so? --- Jura 19:59, 28 December 2018 (UTC)
• No. What happens with nomenclatural homonyms is that someone mistakenly reuses a name and uses it for a different taxon. They're not (usually) confusing the two taxa (since they're likely not aware the name exists at all), just unaware that the name cannot be used for the new taxon they are assigning a name to. Circeus (talk) 20:09, 28 December 2018 (UTC)
• [ETA] different from (P1889) is not meant as a subproperty, is it? Separator and this require a subproperty to check for, not a direct property of the item itself. Circeus (talk) 11:51, 31 December 2018 (UTC)
• Separator does indeed, but for this I think it would be interesting to use an actual statement to check (thus "distinct making-statement"). Otherwise one would just repeat content already on the item. --- Jura 12:16, 31 December 2018 (UTC)

Notified participants of WikiProject Taxonomy --Succu (talk) 21:19, 28 December 2018 (UTC)

• This property is not necessary for things like Solanum cardiophyllum (Q59424086). In cases like this, the first priority is to discourage very strongly that such items are created. They decrease the value of Wikidata, only causing confusion. Secondly, if such items are created, they should not have a "taxon name" as this is not the name of a taxon, but rather the opposite: a name that may not be used for a taxon. If they don't have a "taxon name", they don't need a qualifier for that property.
1. Solanum Cardiophyllum was necessary as the target of replaced synonym (for nom. nov.) (P694) at Solanum boldoense (Q17400584).
2. If we follow your argument, then we literally cannot use replaced synonym (for nom. nov.) (P694) ever because its target should never be created.
3. The main reason for this argument is not single-code names (though there are no doubt enough of them to justify it due to replaced synonym (for nom. nov.) (P694)), but hemihomonyms, which are the bulk of problem-causing exceptions at taxon name. You would know this if you'd taken the time to actually read the proposal.
4. You can't even use nomenclatural status (P1135) (hah. there's the distinguishing subproperty I need!) as a direct property of an item.
Circeus (talk) 11:51, 31 December 2018 (UTC)
"Necessary" is a big word for a replaced synonym; it is not as if it is a basionym (which is necessary; lots of basionyms still missing). There are cases where a replaced synonym is quite prominent and definitely should be included.
I did read the proposal. It is indeed not possible to add further names to P225 (not many anyway): it was full quite awhile ago. But I am not clear how this proposal is supposed to help in this respect.
But indeed perhaps nomenclatural status (P1135) should be used for statements rather than for qualifiers.
- Brya (talk) 18:12, 31 December 2018 (UTC)
I repeat myself: I am not super knowledgeable with the inner-working of constraint, and it is possible that separator (P4155) does the jo, but no one has explicitly confirmed that. The point is that if this can be worked directly into the constraint definition of taxon name (P225), there will be no need to manually list exceptions (and indeed the entire list could be removed from there), since merely having the appropriate subproperty on these elements will prevent them triggering the constraint in the first place. Circeus (talk) 00:20, 1 January 2019 (UTC)
I think the need for a feature exists independently of the optimal way of handling cases like Solanum cardiophyllum Dunal (1852) (Q59424086). Maybe we can replace the sample above and you might want to continue the discussion on the relevant wikiproject. --- Jura 09:01, 1 January 2019 (UTC)
I have a hard time wrapping my head around this, so I will take the coward's way out: if this does what it aims to do, I am in favour. If it does not do this, I am against. - Brya (talk) 06:12, 4 January 2019 (UTC)
How does it help to reduce constraint violations? We have Code of nomenclature (P944)}, so  Oppose. --Succu (talk) 06:47, 4 January 2019 (UTC)
• It's a way to define a query that would find actual distinct value violations. Maybe <qualifier value> should be P944. What query would you use to find them? --- Jura 08:58, 4 January 2019 (UTC)
This one (for Aa). --Succu (talk) 09:17, 4 January 2019 (UTC)

### Wikiapiary entry

Under discussion
Description links to the entry of this MediaWiki site/extension/skin WikiApiary (Q26252471) External identifier MediaWiki website (Q15633582), MediaWiki extension (Q6805426) and MediaWiki skin (Q21996535) alphabetical English Wikisource (Q15156406) → Wikisource_(en) Extension:VisualEditor (Q21679100) → Extension:VisualEditor Minerva Neue (Q22713032) → Skin:Minerva_Neue https://wikiapiary.com/ Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. every MediaWiki sites, extensions and skins as of now, 269654 sites, 269827 extensions, and 65535 skins always incomplete (Q21873886) https://wikiapiary.com/wiki/\$1 maybe

#### Motivation

Many MediaWiki stuffs are collected by this site, so why not? --125.36.185.115 03:22, 25 December 2018 (UTC)

#### Discussion

•  Support David (talk) 07:42, 25 December 2018 (UTC)
•  Oppose just one property for three different concepts is too confusion for us to be useful. --Liuxinyu970226 (talk) 11:37, 25 December 2018 (UTC)
•  Oppose per Liuxinyu970226 (but I would support three separate properties, given the quantities involved). As a meta issue, we should decide at which point we stop combining IDs like this, and split them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:58, 27 December 2018 (UTC)

### representative image

Under discussion
Description unfitting image to be used because a better alternative does not exist or is not available due to legal restrictions Commons media file "image" Great Belt Bridge rail accident (Q60331170) → File:DSB IC4 70 at Aarhus H.jpg MISSING MISSING collage image (P2716), image (P18)

#### Motivation

A lot of Wikipedia articles, especially articles about events, use images that are not actually of the article subject. Jc86035 (talk) 17:03, 3 January 2019 (UTC)

#### Discussion

•  Comment I think it would be good to come up with another label. --- Jura 17:22, 3 January 2019 (UTC)
• Agree with Jura on the label being a bit confusing (eg a portrait is the best "representative image" there is!) but  Support the idea in general. Andrew Gray (talk) 20:46, 3 January 2019 (UTC)
•  Support the idea David (talk) 09:31, 4 January 2019 (UTC)
•  Comment "placeholder image", "archive image", "file image", .. isn't going to work either. How about "image of a component similar to actual"? --- Jura 11:31, 4 January 2019 (UTC)
@Jura1: I think that would be okay. It would be better if it were shorter but I can't think of a way to do so. Jc86035 (talk) 16:49, 6 January 2019 (UTC)
•  Support "Related image", perhaps. Jheald (talk) 15:44, 7 January 2019 (UTC)
•  Support Edward (talk) 16:14, 7 January 2019 (UTC)
•  Support. Thierry Caro (talk) 01:45, 8 January 2019 (UTC)
•  Comment another point to sort out before creation: what could be suitable as a placeholder image added with this property?
Do we want a notable work of an artist? (likely not, item for a notable work should hold it). Do we want the usual "no free image available, please upload one" placeholder image? (neither). For films, can we continue to add images of cast at some event in P18 (likely yes). --- Jura 11:02, 8 January 2019 (UTC)
@Jura1: I think a notable work could be appropriate but I'm not sure. I would use this property for the film case (P18 would ideally show a frame from the film, or the film's poster; ideally the entirety of the film itself would be in video (P10)). Only some Wikipedias use the "no free image available" image, and they don't really add any value to the item. Jc86035 (talk) 13:38, 8 January 2019 (UTC)

### Crew united person ID

Under discussion
Description Identifier for persons on Crew united Crew united (Q1139837) External identifier `|1=` in de:template:Crew united Name \d+ Joachim Steinkamp (Q1452981) → 118621 Anette Hellwig (Q529519) → 26150 Neelesha Barthel (Q1171155) → 11765 Use in sister projects: [de] • [en] • [es] • [fr] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd]. eventually complete (Q21873974) https://www.crew-united.com/de/profilansichten/?IDM=\$1 Wikidata:Property proposal/Crew united Titel

#### Motivation

like many other person identifiers this should be in wikidata Queryzo (talk) 21:53, 6 January 2019 (UTC)

#### Discussion

•  Support David (talk) 07:58, 7 January 2019 (UTC)
• I added ID at the end of the property name as is standard with our external ID properties. I changed name to ID for similar reason as the description doesn't speak bout names. Furthermore, I would like a description that says something about what crew-united happens to be and  Oppose otherwise. ChristianKl❫ 12:27, 12 January 2019 (UTC)
See de:Crew United, it is the platform for the professional film- and television branch and therefor some of the standard web links in dewiki, where we have 2.000+ implementations. Queryzo (talk) 13:00, 12 January 2019 (UTC)
@Queryzo: I don't want to see something. I want a description for the property in it's description field. ChristianKl❫ 10:40, 13 January 2019 (UTC)
I don't see the point yet, the properry is - like many others - for cast & crew in film business. Queryzo (talk) 06:07, 17 January 2019 (UTC)

### number of articles

Under discussion
Description How many articles a Wikipedia language edition has Number (not available yet) English Wikipedia (Q328) → 5,782,014 French Wikipedia (Q8447) → 2,070,417 MISSING some Wikipedia or meta

#### Motivation

(I am sorry, I can speak English a little bit)

Lot of Wiki have old data. This qualifier help in the future, that the data is always up to date. B.Zsolt (talk) 22:44, 7 January 2019 (UTC)

#### Discussion

•  Support David (talk) 06:52, 8 January 2019 (UTC)
•  Comment for the last discussion see Wikidata:Property proposal/Number of articles. --Pasleim (talk) 09:02, 10 January 2019 (UTC)
•  Support, I disagree with Andyhas parts of the class (P2670) is not flexible enough for this kind of data. For example, a statement can be qualified further with date, which is a very important part of data. (Qualifying the has parts of the class (P2670) statement with the date is semantically incorrect: it means that at that point, this Wikipedia contained articles; it may contain kittens or countries or anything else tomorrow.) Actually the properties mentioned there are (except for number of households (P1538)) static values, which don’t change over time, so a qualifier is more sufficient for them than for Wikipedia articles. —Tacsipacsi (talk) 21:46, 10 January 2019 (UTC)
•  Support Palotabarát (talk) 11:37, 11 January 2019 (UTC)
•  Question Why not use number of pages (P1104)? Thanks. Mike Peel (talk) 16:25, 14 January 2019 (UTC)
•  Question Is it necessary to have this information 'statically' in Wikidata? Isn't an information available via the API? (I wonder if someone will update this information frequently how it would affect the history of the object) --Sabas88 (talk) 21:15, 14 January 2019 (UTC)
•  Oppose I don't think the arguments in the previous discussion have been addressed. ArthurPSmith (talk) 20:34, 15 January 2019 (UTC)

## Wikidata property

### value hierarchy property

Under discussion
Description property which specifies less precise items than the indicated value for which statements using the subject property would still be true Property Wikidata property (Q18616576) transitive property (Q18647515) instance of (P31) → subclass of (P279) headquarters location (P159) → located in the administrative territorial entity (P131) occupation (P106) → subclass of (P279) afflicts (P689) → anatomical location (P927) add to a bunch of properties and use in tools, see below

Note: we have considered various labels for this property: "property for implied values", "transitive over", "refinement hierarchy" and currently "value hierarchy property". All these variations are used in the discussion below. − Pintoch (talk) 21:40, 15 January 2019 (UTC)

#### Motivation

I would be interested in expressing that a given property (such as subclass of (P279)) is used to determine how values of another property (instance of (P31)) can be refined. This is a pattern that we use at various places in Wikidata:

Potentially this property could be multi-valued if there are multiple refinement hierarchies in place (but I can't think of an example right now). I am not very happy with the label so I hope others have better ideas.

The idea behind introducing such a property would be to make it easier for data import tools (such as OpenRefine) to respect these hierarchies natively (for instance, when adding to an item, any unsourced statement could be safely deleted, I think).

This could also potentially improve the constraint system: for instance, if we have an item requires statement constraint (Q21503247) which requires , then the constraint system could also accept (because it is more precise). As far as I am aware this behaviour is only available for instance of (P31)/subclass of (P279) via type constraint (Q21503250) currently. @Lucas Werkmeister (WMDE): I have no idea if it is feasible (and in which case you could prefer another syntax for this information)? − Pintoch (talk) 15:09, 8 January 2019 (UTC)

@Jean-Frédéric, Olivier LPB: you have requested this feature at Help_talk:Property_constraints_portal/ItemPintoch (talk) 15:14, 8 January 2019 (UTC)

#### Discussion

•  Support would a label something like "property over which this is transitive" make sense? But yes, this seems like a very useful abstraction to provide a structured mechanism for. ArthurPSmith (talk) 19:36, 8 January 2019 (UTC)
• This can get complicated. occupation (P106) is only transitive over subclass of (P279) until outside the occupation class tree. --Yair rand (talk) 23:45, 8 January 2019 (UTC)
• Good point. But values outside the occupation class tree are already forbidden by a value type constraint (Q21510865), so maybe we can say that the implication only holds if the broader value is acceptable with respect to other constraints? Or we could indicate the containing class with a qualifier? Anyway, for both applications mentioned (data import and constraint violations), this should not be an issue. − Pintoch (talk) 06:57, 9 January 2019 (UTC)
•  Support David (talk) 12:53, 9 January 2019 (UTC)
•  Comment New label ("transitive over") works for me! ArthurPSmith (talk) 16:28, 10 January 2019 (UTC)
• @ArthurPSmith: given MisterSynergy's reaction below, I have the feeling that this label is too close to "transitive" and might cause confusion for others. Maybe something like "refinement hierarchy" would be better - it would also rule out values like sibling (P3373) which are symmetric properties. − Pintoch (talk)
•  Wait How do other ontologies handle this? Where is prior art? Especially, when it comes to naming this relationship?
```ChristianKl ❪✉❫ 18:23, 10 January 2019 (UTC)
```
• @ChristianKl: yes indeed surely this has been formalized in other places. I will investigate. − Pintoch (talk) 20:12, 10 January 2019 (UTC)
• @ChristianKl: I have asked around and it does not seem to have a particular name, it is just a particular case of an OWL construct: property chains. People in graph theory or other fields of math might have names for that particular relation, but I am not sure how to look for it (and it is likely to be as obscure as any other name we come up with, TBH). − Pintoch (talk)

However, it would be wrong to say that .
So, position held (P39) is transitive over subclass of (P279) but not over part of (P361) (and both subclass of (P279) and part of (P361) are transitive).
So this notion of "X transitive over Y" is distinct from "Y transitive". Do you agree? Maybe the new label is causing confusion? − Pintoch (talk) 20:12, 10 January 2019 (UTC)
If you prefer symbolic statements over prose:
• Q is transitive when ${\displaystyle \forall xyz,xQy\land yQz\Rightarrow xQz}$
• P is transitive over Q when ${\displaystyle \forall xyz,xPy\land yQz\Rightarrow xPz}$
Pintoch (talk) 20:58, 10 January 2019 (UTC)
Another counterexample found by sparqling around: sibling (P3373) is transitive. child (P40) is transitive over sibling (P3373) (if X has child Y and Y has sibling Z, then X has child Z), but mother (P25) is not transitive over sibling (P3373) (if X has mother Y and Y has sibling Z, then surely Z is is not X's mother!). − Pintoch (talk) 23:47, 10 January 2019 (UTC)
@Pintoch: I don't think so. Halfsiblings frequently are siblings. ChristianKl❫ 07:16, 11 January 2019 (UTC)
@ChristianKl: yes that is true − this example is not something we would want to have anyway for the two applications mentioned above (because sibling (P3373) is symmetric, so it cannot be seen as a refinement hierarchy like the other examples). I just hope it helps MisterSynergy grasp the difference with transitivity a bit better (in particular, the fact that mother (P25) is not transitive over sibling (P3373) is still a counterexample of his claim, I think). − Pintoch (talk) 07:52, 11 January 2019 (UTC)
Yeah, I understand. However, this is the same problem that User:Yair_rand mentioned above and which you acknowledged, just in a much more obvious sense. Transitivity of a property Y (e.g. part of (P361)) used in value items of property X (e.g. position held (P39)) holds only as long as you stay within the range of X (value type constraint (Q21510865) we say at Wikidata). It works for a couple of steps for occupations and then breaks down, but barely for parthood relations which are typically very messi at Wikidata. It works practically always for the proposed headquarters location (P159)located in the administrative territorial entity (P131), as the range of the latter is completely contained within the range of the former; the problem does not really matter for the proposed instance of (P31)subclass of (P279), as instance of (P31) does not have a defined range.
There is another, independent problem with parthood relations in particular, in contrast to other transitive properties (mereology (Q1194916) is the research field that studies parthood relations). For parthood relations transitivity is typically assumed within mereology, but there is research in the community about whether this is generally valid or not (see here). Consider for instance these (fictional) claims:
Although both claims would be acceptable for Wikidata and part of (P361) is transitive, you clearly would not infer that
< Pintoch's big toe > part of (P361) < Wikidata admin corps >
. The problem is that parthood relations are only transitive under certain circumstances, for example in a local meronomy (such as “Pintoch's body parts” or “Wikimedia project entites”). However, parthood relations are not generally transitive.
I still do not think that this proposed property should be created. The range problem raised by Yair_rand would have to be addressed with extra efforts based on existing value type constraint (Q21510865) claims on properties anyway (so the proposed property does not add new value), and the parthood problem would rather be solved by removing the transitivity from part of (P361)/has part (P527). (I still have to have a look at the sibling (P3373) problem, though.) —MisterSynergy (talk) 10:30, 11 January 2019 (UTC)
@MisterSynergy: you rightly point out that transitivity itself is often messy. I would argue that this is not just true for part of (P361): very often, long chains of subclass of (P279) also give nonsensical results when we follow them high up into very abstract concepts. That's inevitable: we are building a knowledge graph, not a math textbook.
Let's step back and look at the motivation of the proposal. What I mean with this proposal is that many properties tend to have one designated property for their refinement hierarchy. It seems to me that this pattern is pretty pervasive, but we tend to only acknowledge this for the instance of (P31)/subclass of (P279) pair. Why?
It would be massively useful if the constraint system could handle other such hierarchies. Typically when working with human (Q5), the fact that we discourage subclasses of human (Q5) makes the type system useless there. Have you ever wanted to enforce things like "every item with an ORCID iD (P496) should have occupation (P106) researcher (Q1650915), or any subclass of it"? Now, I could propose to add a parameter to the constraints definition so that we could provide subclass of (P279) there, but I think this would be misguided as this information is really determined by the property used for the required statement. So I think this should be stored in a generic way, outside the constraint system. Now I would very much welcome any other suggestion about how to represent this. − Pintoch (talk) 10:54, 11 January 2019 (UTC)
Also (sorry for the long reply!), it seems to me that there might still be a conceptual misunderstanding here: in the abstract, the fact that a property Q is transitive really does not mean that "x P y Q z" implies "x P z" for any property P. This is wrong both in mathematics and in ontology design. So there is nothing to "fix" about part of (P361) being transitive in this regard. It turns out that most of the transitive properties we have in Wikidata are containment relations, where this tends to hold often,, but that does not have to be the case. For instance, imagine we had a property called "hates". The fact that "MisterSynergy hates cauliflower (Q23900272)" really does not imply that "MisterSynergy hates vegetable (Q11004)", even if the chain of subclass of (P279) is totally correct. − Pintoch (talk) 11:41, 11 January 2019 (UTC)
Now  Neutral, as I do not want to stand in the way too much. I changed my mind after a second read of this proposal and its comments. The transitivity does no longer seem to be the critical aspect of this property, and I really hope that this term does not appear in the potential property label. It is also worth to mention that it may be useful for refinements, i.e. looking *down* along a hierarchy for potentially better/more specific values, which pretty much avoids the discussed problems that arise when going *up* a hierarchy towards more general values. —MisterSynergy (talk) 11:53, 13 January 2019 (UTC)
Yes, it could be interesting to have something for implications which are going down a hierarchy. I cannot think of an example though (beyond my "hates" example above, maybe). − Pintoch (talk) 15:21, 14 January 2019 (UTC)
I'm not sure if the above can of worms is what ChristianKl intended to open, but the question of how other ontologies deal with this again seems relevant. I remember some peculiarities with transitivity in SKOS - there are both the relations "broader" and "broaderTransitive", and "broaderTransitive" is declared as a superproperty of "broader" (and note this does NOT make "broader" transitive, despite the fact that "superproperty" like "superclass" is itself transitive). There's a discussion of some of this (in a more general case) here. It all kind of hurts the brain a bit... ArthurPSmith (talk) 14:06, 11 January 2019 (UTC)
@ArthurPSmith: I don't think that properties like this should be trivally created. We should generally follow existing standards and only invent our own if we have good reasons to invent the wheel anew. ChristianKl❫ 10:46, 13 January 2019 (UTC)
@ChristianKl: I totally agree. That being said, it seems to me that there is no established RDF predicate for this in the usual namespaces. The reason for that is that this information is best expressed in OWL, not in RDF directly. Wikidata has not engaged much with OWL so far - the project has followed a different route by storing ontological information in the same data model as the data itself. For instance we have inverse of (P1696), and we use statements such that , which intrinsically don't do anything (Wikibase does not give them any special meaning, the query service does not infer any triples from them, and so on). Storing property constraints as statements on the property is another example. So this is why I proposed this property: it seems to be in line with the current customs of storing ontological information as statements on properties. That being said, it would obviously be much better if we had generic support for constructs like property chains, which would be much more expressive. But that is a much larger project, and we might want to think twice before construing these concepts in the Wikibase data model (maybe this is something we want to store elsewhere?) − Pintoch (talk) 11:03, 13 January 2019 (UTC)
•  Comment Ok, it sounds like we need to settle on a non-confusing label (and if we can find a label somebody else has used, all the better). I was looking at a sample of the item-valued properties we have; for many of them this whole discussion simply does not apply (there's no "refinement hierarchy" or transitivity that would be associated with person-valued properties like head of government (P6) or director (P57), and I can't think of one that would apply for unitary entity values like country (P17) either.) For the ones associated with a physical location, for example place of birth (P19), then we're clearly interested in the location-based hierarchy that Wikidata manages via located in the administrative territorial entity (P131). For some others, subclass of (P279) seems to apply (for example for language-valued properties like official language (P37)). For employer (P108) I am not sure if we have a consistent refinement hierarchy - parent organization (P749) perhaps, but also part of (P361), owned by (P127)? Fundamentally I think what we're looking for is the way in which the domain of the property value (class, place, language, organization, etc.) is hierarchically modeled in Wikidata. So would a label like "domain hierarchy property" make sense? ArthurPSmith (talk) 14:20, 14 January 2019 (UTC)
Yes, I also expect that subclass of (P279) and located in the administrative territorial entity (P131) would be the most common values for this property. Concerning the label, does "domain" generally refer to the target value? Intuitively, for me it would refer to the subject item. (Maybe by a vague mathematical analogy with the domain of a function, although statements aren't functions) So it would be more intuitive for me to have something else like "range", "value" or "target". − Pintoch (talk) 15:21, 14 January 2019 (UTC)
Oh! Yes, I was thinking "domain" in the generic sense of type of item. Maybe "value hierarchy property"? ArthurPSmith (talk) 17:10, 14 January 2019 (UTC)
I think that would be quite clear indeed! − Pintoch (talk) 17:21, 14 January 2019 (UTC)
I attempted to update the label and description in English in the proposal - ok now? ArthurPSmith (talk) 20:33, 15 January 2019 (UTC)
Yes, thanks! I am adding a note to explain the variations of labels in the discussion. − Pintoch (talk) 21:40, 15 January 2019 (UTC)
•  Comment as far as constraint checks are concerned: any kind of transitivity hurts performance (“type” and “value type” are among the most expensive constraint checks by far) and caching (we can’t invalidate all cached results if an item buried somewhere in the chain is edited, that’s why you’ll see “this result may be outdated” on some type / value type check results). --Lucas Werkmeister (WMDE) (talk) 17:27, 14 January 2019 (UTC)
Thanks! Yes I can imagine this would be expensive to run. So it makes all the more sense to store this information outside the constraint system. I would still be interested in this to ease data imports. − Pintoch (talk) 20:07, 14 January 2019 (UTC)

### inverse label

Under discussion
Description label of the inverse relationship of a property Monolingual text properties with item datatype instance of (P31) → has instance (en) subclass of (P279) → superclass of (en) place of birth (P19) → born here (en)

#### Motivation

While some properties have an inverse property it is unlikely that we will ever have for all properties with item datatype an inverse. Nevertheless, some tools display inverse relationships even if an explicit inverse property is missing, e.g. reasonator, sqid, derivedstatements. In future, such a functionality could even be implemented in Wikidata itself. To improve these tools it would be good to store the label of the inverse relationship on the property page, see examples above. --Pasleim (talk) 17:03, 14 January 2019 (UTC)

#### Discussion

On problem of this solution is that we might end up with 20 balues in different languages. That takes up space. Additionally if we need qualifiers we have to copy them again for every language.

Notified participants of WikiProject PropertiesChristianKl❫ 09:40, 16 January 2019 (UTC)

I agree that this will take up some space but I don't think this is sever. Property pages like Europe PlayStation Store ID (P5971) and Wolfram Language entity code (P4839) have far more statements. --Pasleim (talk) 10:05, 16 January 2019 (UTC)
On space - is this what the proposed "multilingual text" datatype was supposed to cover? It does seem like it would be sensible to allow a property to have values that work like the label and description values, allow for one string value in each language. ArthurPSmith (talk) 18:27, 16 January 2019 (UTC)
Yes, that was the point of the "multilingual text" datatype that we still don't have. ChristianKl❫ 19:20, 17 January 2019 (UTC)