Wikidata:Property proposal/Generic

Property proposal: Generic Authority control Person Organization
Creative work Place Sports Sister projects
Transportation Natural science Lexeme Wikimedia Commons

See alsoEdit

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. 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.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. 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 2021/03.


value group numberEdit

   Under discussion
Description(qualifier only) an higher level of series ordinal used to separate various lists already with series ordinal (P1545)
Data typeString
Example 1(Q3595028) fanqie (P5523) (Q2391630) (series ordinal (P1545)=1, value group number=1), (Q55806623) (series ordinal (P1545)=2, value group number=1)
Example 2(Q3595028) fanqie (P5523) (Q2391630) (series ordinal (P1545)=1, value group number=2), (Q55806688) (series ordinal (P1545)=2, value group number=2)
Example 3MISSING
Planned useUse as a qualifier of fanqie (P5523) and ideographic description sequences (P5753)


See User_talk:Ivan_A._Krestinin#Bot_edits_on_P5523 as the background of the proposal. GZWDer (talk) 16:24, 18 July 2019 (UTC)


Item Equivalence Fanqie (initial) Fanqie (final) References
A Guangyun (Q2189818)
A Jiyun (Q35792)
A Hongwu Zhengyun (Q10958946)
B Guangyun (Q2189818)
B Jiyun (Q35792), Hongwu Zhengyun (Q10958946)
C Guangyun (Q2189818)
C Jiyun (Q35792), Hongwu Zhengyun (Q10958946)
D Guangyun (Q2189818)
D Jiyun (Q35792)

There are 9 pairs of data, each consisting of an initial and final character, and these 9 pairs can be further grouped into four equivalent pairs of data (A,B,C,D). Are there any existing properties that can be used to handle this situation? KevinUp (talk) 21:00, 18 July 2019 (UTC)

Perhaps the value group number can be modified to "A1, A2, A3, B1, B2, C1, C2, D1, D2" or "1a, 1b, 1c, 2a, 2b, 3a, 3b, 4a, 4b" to mark the equivalence of certain data sets? KevinUp (talk) 21:12, 18 July 2019 (UTC)

Arthur Rubin
Nomen ad hoc
The Anome
Daniel Mietchen
  Notified participants of WikiProject Mathematics

for suggestions on how to handle this situation. The proposed property may also have other applications. KevinUp (talk) 19:35, 20 July 2019 (UTC)
  •   Comment @KevinUp: is the suggestion here to have a general mechanism to handle two-dimensional indexing, not just something specific to these characters? That sounds like a reasonable thing to do in principle, but in practice the items would still show up as a one-dimensional list within the Wikidata UI. "Series ordinal" doesn't have to be just a number, you could for example combine letters and numbers, or have two numbers separated by a comma or other special character. Is this really needed? ArthurPSmith (talk) 18:49, 22 July 2019 (UTC)
    @ArthurPSmith: Yes, the idea is to have a general mechanism to handle two-dimensional indexing that can be applied not just to these characters. In the examples given above, "value group number" is used to indicate that group 1, which is represented by (Q2391630) and (Q55806623) and group 2, which is represented by (Q2391630) and (Q55806688) are distinct groups that are not the same. The "value group number" does not indicate any rank but is used to indicate distinction. KevinUp (talk) 20:40, 22 July 2019 (UTC)
    To add another layer of complexity, in the table I have prepared for the item "笈", there are four different groups (A,B,C,D) and each group can be described by more than one method, e.g. in group D, (Q55414074) (series ordinal 1) + (Q54873157) (series ordinal 2) and (Q54879270) (series ordinal 1) + (Q54873157) (series ordinal 2) are equivalent, so we could perhaps use a second character in the value group number, e.g. "4a", "4b" to indicate equivalence of the subgroups a and b within group 4. KevinUp (talk) 20:40, 22 July 2019 (UTC)
  • If you are using series ordinal like 3a or 3.4, they are not much machine readable or queryable. Although this proposal (with only one property) does not work well in more than two dimensions.--GZWDer (talk) 20:58, 22 July 2019 (UTC)
    @GZWDer: To solve the issues of [1] series ordinal such as 3a or 3.4 not machines readable [2] the property in this proposal not working well in more than two dimensions, I suggest the following: KevinUp (talk) 17:45, 25 July 2019 (UTC)
    1. Replace fanqie (P5523) with two new properties: initial fanqie character and final fanqie character (as originally suggested by you) - This is because initial and final fanqie have different properties, i.e. the initial character shares the same initial consonant while the final character shares the same vowel, consonant ending and tone with that of the queried item.
    2. Use series ordinal (P1545) for groups A,B,C,D in the example above (this would indicate that the fanqie readings are distinct).
    3. Apply the proposed property (value group number/group ordinal) to values that have the same series ordinal. This is analogous to A1, A2, A3 in the example above.
    For fanqie, values with the same series ordinal but different value group number/group ordinal are similar in a way, e.g. 其,極,忌 (initial fanqie from A1, A2, A3) all share the same initial consonant in Middle Chinese. KevinUp (talk) 17:43, 25 July 2019 (UTC)
  • Thanks for the responses. So now I'm wondering, where did the proposed label "value group number" come from? Is that a common term used for these character representations, or is that something GZWDer came up with? If we are to do this I think I'd prefer a shorter name if possible. "group ordinal" perhaps? ArthurPSmith (talk) 19:19, 23 July 2019 (UTC)
    No, it's not a common term used for these character representations. I also prefer a shorter name such as "group ordinal" as long as it has the meaning "higher level of series ordinal". KevinUp (talk) 17:43, 25 July 2019 (UTC)
  • I remembered a similar situation at disjoint union of (P2738), where different sets are saved. A special value list values as qualifiers (Q23766486) is used as a dummy value and actual list is saved as qualifier. It might be applicable here. It will look like (Q77040173) fanqie (P5523) list values as qualifiers (Q23766486) / follows (P155) (Q55414074) / followed by (P156) (Q54873157).  – The preceding unsigned comment was added by Midleading (talk • contribs) at 10:16, December 2, 2019‎ (UTC).

part numberEdit

   Under discussion
Descriptionthe item's part number
Representsidentifier (Q853614)
Data typeExternal identifier
Allowed unitsa string that contains numbers and/or letters
Example 1AMD Phenom II X6 1090T (Q66481199) → HDT90ZFBK6DGR (OEM number), HDT90ZFBGRBOX (boxed number)
Example 2AMD Ryzen Threadripper 2990WX (Q56062941) → YD299XAZUIHAF (OEM number), YD299XAZAFWOF (boxed number)
Example 3Core i5-760 (Q15223620) → BV80605001908AN (OEM number), BX80605I5760 (boxed number, english version), BXC80605I5760 (boxed number, english version)
Sourceen:Part number
Planned useAdd to every item for which a part number can be found


While working on CPUs, I noticed that this property does not seem to exist. I had primarly CPUs in mind, but I'm sure there are a lot more items that have a part number in real life.
However, as shown in the example, there can be more than one part number for the same productname. So you have to be able to add some sort of referece to the information (eg. "OEM" or "boxed" or something like that) --D-Kuru (talk) 17:22, 16 August 2019 (UTC)


Wildly boy
ZI Jony
Ivan A. Krestinin
Jonathan Groß
Pablo Busatto
Thierry Caro
Tinker Bell
  Notified participants of WikiProject Properties Tobias1984
Ruud Koot
Daniel Mietchen
Tinker Bell
Jasc PL
Tris T7
Peb Aryan
FWVH (passionné d'informatique et d'électronique)
Sylvain Leroux
  Notified participants of WikiProject Informatics Visite fortuitement prolongée (talk) 19:06, 18 August 2019 (UTC)

  •   Question It’s unclear to me if this is really workable. It seems reading the enwiki article that the consumer of the product may use a different number than the producer itself for example. Your difference in the part number type may come either of this, for example if the processor is used on, say, a samsung laptop and samsung gave its own part number something like
    ⟨ Samsung laptop model XYZ ⟩ has part (P527)   ⟨ processor I42 ⟩
    part number search ⟨ ABCDEF ⟩
(in such a case we don’t have to discriminate between the user part number to the manufacturer one because it’s used by a user in a design)
Or … there is several numbers because there is subdesigns by the manufacturer of the same processor, in which case it may be possible to subclass the processor model item with fresh new items to reflect that, with their own properties and values to reflect the differences. author  TomT0m / talk page 19:25, 18 August 2019 (UTC)
As far as I know the CPU type has a unique ID that changes under some conditions. The manufacturer is not such a condition - at least as far as I know. Since the ID is unique to every processor type I switched the datatype to external-id. It seems that the different numbers are more to indicate which segment of the global market is targeted. If the CPUs ID is ABC1 in the boxed version you will not find an appropriate CPU when it is labled ABC2. Even they are actually the same die under the hood. I don't think that a new item is really the route to go if there is just a different ID, but all other values stay the same. You don't create a new item for every version of some program, do you? --D-Kuru (talk) 20:58, 20 August 2019 (UTC)
  Question Is this at all related to Global Trade Item Number (P3962)? See also the discussion on this old proposal. ArthurPSmith (talk) 17:50, 19 August 2019 (UTC)
Yes and now I would say. The part number is not the European Article Number. There is no bar code on the processor. But it's shares some properties since it's also a unique ID for every product. --D-Kuru (talk) 21:00, 20 August 2019 (UTC)
  •   Support given that it's distinct from the EAN. ChristianKl❫ 07:46, 30 August 2019 (UTC)
  •   Question for me it's unclear if it is different from the stock-keeping unit (Q399757) given by the manufacturer? Dom (talk) 09:39, 22 September 2019 (UTC)
stock keeping units are retailer codes that track price, manufacturer and product information of the product and are used to track sales. The part number is more like a barcode. An individual code for certain product types. Since it's not about tracking - at least not that I know - they are different in my opinion --D-Kuru (talk) 16:26, 25 November 2019 (UTC)
  Support. Thanks for the explanation. We probably need to add it in the property once it is created to disambiguate between both properties. GNUtoo (talk) 20:47, 20 June 2020 (UTC)
  Question Currently the linked CPU page use serial number (P2598) which is explicitly not for that purpose: "Not a product code or model number". To me it seems a property that can be used together with existing stock-keeping unit (Q399757), part number (Q3879409) and item number (Q57446692) is needed.  – The preceding unsigned comment was added by F-ludwig (talk • contribs).
Good point. I added corresponding property constraints at Property:P2598#P2302. --- Jura 11:31, 19 July 2020 (UTC)
  •   Strong oppose subject item is in source field: part number (Q3879409) ; not "property" domain ; RegEx field empty ; etc. I give this opinion to avoid that a new property is created in this way, sorry. —Eihel (talk) 00:25, 23 August 2020 (UTC)

verifiability of propertyEdit

   Under discussion
DescriptionVerifiability of this property, one of "Verified", "Human verifiable", "no value"
Data typeItem
Allowed values"Verified", "Human verifiable", "no value"
Example 1stated in (P248) → "Verified"
Example 2imported from Wikimedia project (P143) → "Human verifiable"
Example 3retrieved (P813) → no value
Example 4reference URL (P854) → "Verified"
Planned useSourcing SPARQL query
Robot and gadget jobsno


We need a way to enforce that results from Wikidata query service are reliably sourced. Currently there is no simple way to require higher reliability standard in Wikidata query service than "wdt". And this means unsourced statements or statements imported by bots from Wikipedia will appear in query result. Simply requiring a source be provided doesn't work, because it can be imported from Wikimedia project (P143) Wikipedia (Q52). Requiring any sources other than imported from Wikimedia project (P143) doesn't work either, because imported from Wikimedia project (P143) can be accompanied by retrieved (P813), and retrieved (P813) triple will be matched by SPARQL software as a valid source. Not to mention we are starting to have new identicals of imported from Wikimedia project (P143), such as Wikimedia import URL (P4656) and inferred from (P3452).

Using this new property, we can write SPARQL query that require the data be properly sourced. Example:

SELECT ?item ?value ?reliablesource ?reference WHERE {
  ?item p:P31 [ps:P31 ?value;
               a wikibase:BestRank;
               prov:wasDerivedFrom [?reliablereference ?reference]].
  ?reliablesource <> <>;
                  wikibase:reference ?reliablereference.

Alternatively, we can link the new items "Verified" or "Human verifiable" to properties using existing properties, for example instance of (P31) or has quality (P1552). But using a new property we can even define a hierarchy of reliability. For example if statement "Verified" next lower rank (P3729) "Human verifiable" exists, we can write the following SPARQL query to require the result having at least one source even if it is linked to Wikipedia (Q52), but do not include unsourced statements or bogus sources, for example a reference with only retrieved (P813):

SELECT ?item ?value ?reliablesource ?reference WHERE {
  ?item p:P31 [ps:P31 ?value;
               a wikibase:BestRank;
               prov:wasDerivedFrom [?reliablereference ?reference]].
  ?reliablesource <>/wdt:P3729* <>;
                  wikibase:reference ?reliablereference.

Midleading (talk) 12:28, 10 December 2019 (UTC)

Data Model: There are multiple ways to model source reliability. We should decide which one we want to use.

  1. "Generic reliable source" > "Unreliable source", as proposed above.
  2. "Reliable source from trusted organizations and governments" > "Generic reliable source" > "Unreliable source". Defines a multi-level reliability hierarchy. More levels can be added if necessary.
  3. "Reliable source of science", "Reliable source of law", "Reliable source of medicine", "Reliable source of biblography", "Generic reliable source", "Unreliable source". Defines reliability by area.
  4. "Primary source", "Secondary source", "Tertiary source", "Generic reliable source", "Unreliable source".

Also we need to discuss the criterion used to define this property, is it about verifiability or is it about reliability? Midleading (talk) 08:06, 11 December 2019 (UTC)


  •   Support, seems interesting. Nomen ad hoc (talk) 18:29, 10 December 2019 (UTC).
  •   Support I think it would be very useful. --Tinker Bell 20:28, 10 December 2019 (UTC)
  •   Support David (talk) 07:01, 11 December 2019 (UTC)
  •   Comment doesn't reliability/verifiability attach to the source, not the way in which it is referenced (i.e. why is this a property to be attached to reference properties?) I can link just about anything I want with reference URL (P854), that doesn't mean it's either reliable or verifiable! (for example if the website domain has disappeared it can probably no longer be verified...) This doesn't feel like the right approach to modeling this. To identify types of reference properties it would probably be better to just subclass Wikidata property to indicate a source (Q18608359), no? ArthurPSmith (talk) 20:03, 11 December 2019 (UTC)
Using a subclass technically works, but the new items used to specify property verifiability are subclass of Wikimedia internal item (Q17442446), as they are specific to Wikidata. The properties themselves are subclass Wikidata property to indicate a source (Q18608359) but not indirect subclass of Wikimedia internal item (Q17442446). Also, this new property uses parent relationship next higher rank (P3730)next lower rank (P3729) which is different from subclass of (P279). This property doesn't indicate the results are indeed reliable, the statement can still be incorrect or vandalized, but the reference is listed in query result which you can verify by consulting sources. Without this property, you will be overwhelmed by huge list of values without means to verify.--Midleading (talk) 02:25, 12 December 2019 (UTC)
Properties are specific to Wikidata too, I'm not sure what your point is there. Here's specifically what I'm suggesting: create new items like "Wikidata property to indicate a verified source", "Wikidata property to indicate a human-verifiable source" as subclasses of Wikidata property to indicate a source (Q18608359), and make stated in (P248) an instance of the first, imported from Wikimedia project (P143) an instance of the second, and leave retrieved (P813) as it is. You can relate the new items with next lower rank (P3729) etc. relationships if you like, and a modified version of your SPARQL will work the same way, but using the subclass relation instead of a new property. ArthurPSmith (talk) 18:25, 12 December 2019 (UTC)
I don't think properties are specific to Wikidata because many of Wikidata property to indicate a source (Q18608359) have an external equivalent property, for example publication date (P577) = schema:datePublished . Making them an instance of Wikimedia internal item (Q17442446) is just like saying universe (Q1) is instance of "Wikipedia article". I'm fine with using subclass instead of a new property, provided we maintain the ontology stable so that we aren't forced to use ugly/slow "?reliablesource wdt:P31/(wdt:P279|wdt:P3729)* wd:Q123456789" and/or VALUES statement in next years, and the new subclass can't be used to infer the properties are Wikimedia-only.--Midleading (talk) 05:29, 13 December 2019 (UTC)
They're already listed as instances of Wikidata property to indicate a source (Q18608359) so whether or not you consider them Wikimedia-only, making them instances of subclasses of that won't change anything in that respect. Also have many existing items that were created for purposes like this and should remain stable - for example all the property constraint-related items. ArthurPSmith (talk) 18:47, 13 December 2019 (UTC)
@Midleading: That property exist to express a relationship that's defined by policy. This policy wants to say things about what sources are reliable in the absence of policy. A datamodel of how we think about source reliability should be codified in policy and RfC approved. ChristianKl❫ 11:23, 4 September 2020 (UTC)
Wikidata:Living_people exists because we protect the rights of living people. If an user violates that policy, he or she might be warned or blocked. But this one? I may violate this "reliable sources" policy, if defined, any time. Nobody would be blocked. I don't like such a useless policy being codified. If such a policy would be defined, it is the statement in the reference that matters, not the property itself. --Midleading (talk) 05:32, 5 September 2020 (UTC)
As explained from the start, this doesn't work because 1. there are references which combine imported from Wikimedia project (P143) and retrieved (P813) 2. there is other imported from Wikimedia project (P143) equivalent, for example, Wikimedia import URL (P4656). --Midleading (talk) 05:32, 5 September 2020 (UTC)
  Oppose I don't get the benefits from this proposal tbh. There should be no credibility differences between bot edits and human edits. If there are low quality bot edits, request the bot to be blocked. If you do not want to use information imported from Wikimedia projects, filter for imported from Wikimedia project (P143). -- Dr.üsenfieber (talk) 09:10, 12 September 2020 (UTC)
  •   Oppose Filter out statements which are backed only by reference properties which you don't find reliable. If needed, it would also be possible to make reference properties instance of (P31) {some type of classification system for reference properties} if there is a reasonable classification system in existence. --Dhx1 (talk) 14:03, 21 December 2020 (UTC)
  Oppose as per Dr.üsenfieber. --FocalPoint (talk) 09:14, 14 February 2021 (UTC)

recipient (aliases: to, intended recipient, receiver, target, beneficiary, awardee)Edit

   Under discussion
Descriptionperson, group, or organization to which the given entity is directed, given, or sent
Data typeItem
Example 1pitch (Q1063937) recipient catcher (Q1050571)
Example 2Orteig Prize (Q1930819) recipient Charles Lindbergh (Q1618)
Example 3Zimmermann Telegram (Q154091) recipient Heinrich von Eckardt (Q1599502)
Example 4consumer complaint (Q1473099) recipient consumer organization (Q1329436)
Example 5Alaska Purchase (Q309029) instance of (P31) purchasing (Q1369832) / of (P642) Alaska (Q797) / recipient United States of America (Q30)
See alsoPossible parent properties:
  • participant (P710) or significant person (P3342) (these do not specify a role without adding a qualifier)
  • Possible sub-properties:

    Other similar properties:


    To express a major thematic relation that is not well addressed by existing properties (as noted in the "See also" field). Swpb (talk) 19:48, 26 December 2019 (UTC)


    •   Support David (talk) 06:04, 27 December 2019 (UTC)
    •   CommentIs it the same as addressee (P1817)?--Midleading (talk) 09:13, 27 December 2019 (UTC)
      • addressee (P1817) at present only covers one of several use cases of the proposed property, but I would not be opposed to a radical expansion of its definition (really, turning it into the proposed property), rather than creating a new property, if folks like that idea. Swpb (talk) 14:31, 27 December 2019 (UTC)
    •   Oppose Widen winner (P1346) instead. Nomen ad hoc (talk) 17:30, 27 December 2019 (UTC).
      • That makes no sense. This is for items that are transferred between parties. Winning an event may involve the transfer of a prize to the winner, but often does not. If we were to turn that property into this one, someone would immediately propose a new "winner" property exactly like the old one, and with good reason – these are not at all the same concept. If any property were appropriate to expand into this role, it would be addressee (P1817), certainly not winner (P1346). I gather from Wikidata:Property proposal/general law that your preference is to shoehorn new uses into existing properties whether they fit there or not. In both these cases, not. Swpb (talk) 18:04, 27 December 2019 (UTC)
    •   Support but I would also support expanding the definition of addressee (P1817) if that's the consensus here. ArthurPSmith (talk) 21:28, 30 December 2019 (UTC)
    •   Oppose I think all usecases are already covered --- Jura 10:15, 20 January 2020 (UTC)
      • Please elaborate by expressing the example statements with existing properties. Without major expansion (e.g. of addressee (P1817) as discussed above), the existing properties simply do not work. Would you allow addressee (P1817) to be changed as described? Swpb (talk) 20:34, 21 January 2020 (UTC)
        • Notably by award received (P166), addressee (P1817) you apparently don't want to see in the "see also" section. I know it makes it more difficult to argue the added value of the property. BTW: first time a proposer deleted valid content from a proposal. --- Jura 20:36, 21 January 2020 (UTC)
          • addressee (P1817) is discussed above; please comment accordingly: would you allow it to be radically expanded for this role? In it's current form, it is explicitly limited to letters and notes. And award received (P166) takes a completely different class as values, namely awards, not people who receive them – its mention was a non-sequitur and presumably an accident. And no, you don't get to edit my proposal; the discussion section is good enough for everyone else, and it will be good enough for you. Swpb (talk) 20:40, 21 January 2020 (UTC)
            • Do you understand that you are proposing an inverse property for award received (P166)? --- Jura 20:48, 21 January 2020 (UTC)
              • 1) I am not, and 2) if I were, that wouldn't be an argument against. That's also a remarkably different argument from your initial one; I certainly hope your personal feelings towards me aren't the real factor here. Swpb (talk) 20:49, 21 January 2020 (UTC)
                • You might want to have a look at the item used as value in the second sample above, notably the statements at Q1618#P166. --- Jura 20:53, 21 January 2020 (UTC)
                  • And the four examples that have nothing to do with prizes? Covering a use case is not the same as being limited to that use case; which again, wouldn't be a problem anyway. Swpb (talk) 20:57, 21 January 2020 (UTC)
                    • 2 are covered by addressee (P1817). The first by "participant" with object has role. This has the advantage that the pitcher doesn't get omitted. The last one seems to be an error. --- Jura 21:01, 21 January 2020 (UTC)
                      • Ah, so 60% of the examples are not covered by addressee (P1817), unless we expand it! For the third time: are you for that? (Unsurprisingly, I don't find your takes on examples #1 and #5 compelling either, but at least they're valid opinions.) Swpb (talk) 21:05, 21 January 2020 (UTC)
                        • Given that we have 453,654 items with award received (P166), it's likely that 95% of actual Wikidata uses are covered.
    BTW, small correction: 1 is covered by P1817. It's unclear how "consumer complaint" recipient "consumer organization" is covered even by this proposal.
    Maybe you could explain how the seller and the pitcher is meant to be included. --- Jura 21:13, 21 January 2020 (UTC)

    author  TomT0m / talk page Mbch331 (talk) Jobu0101 (talk) Tubezlob (🙋) Flycatchr Koxinga (talk) Fuzheado (talk) Mfchris84 (talk) Manu1400 (talk) Daniel Mietchen (talk) Nomen ad hoc (talk) 07:53, 16 November 2019 (UTC) Valentina.Anitnelav (talk) 16:32, 6 January 2021 (UTC) ミラP@Miraclepine 19:01, 1 March 2021 (UTC)   Notified participants of WikiProject Award @GerardM:

    There is no use case for it. It increases bloat in Wikidata. For years now we have found that a user interface like Reasonator shows perfectly well all known instances of recipients of an award. It is safe to say that the best remedy for this perceived need is a user interface Consider bloat, there are awards with over 500 recipients.. Additionally you gain a major pain; synchronising and error checking on duplicate entries (they are the same information). Thanks, GerardM (talk) 06:27, 22 January 2020 (UTC)
    I don't like to use the same property for diverse purposes (addressee, buyer, winner, target, ...). They will probably raise issues when the property is to be translated into every languages, and introduce unwanted items for property users. Can we discuss each of these usecases separately?--Midleading (talk) 13:42, 26 February 2020 (UTC)

      Support I like the idea of having more general relations to use as a fallback while we're waiting for more specific properties to be added. --Cdo256 (talk) 05:13, 9 September 2020 (UTC)

    armament usedEdit

    Descriptionarmament used to commit an act
    Representsweapon (Q728)
    Data typeItem
    Allowed valuesany P31/P279 of weapon (Q728)
    Example 1armament used → AGM-114 Hellfire (Q271930) as qualifier under manner of death (P1196) assassination (Q3882219)
    Example 2MISSING
    Example 3MISSING
    Planned useas qualifier for describing weapons used for assassinations and targeted killings see e.g. Qasem Soleimani (Q892014)
    See alsoarmament (P520), Wikidata:Property proposal/equipment used


    Enables better modeling of targeted killings, equipment and weapon used.--So9q (talk) 15:12, 5 January 2020 (UTC)


    • It doesn't fit. "equippable weapon item for the subject" this is wrong when we are trying to model that this armament was used to kill someone, not that someone was equipped with the armament when killed. See the example. manner of death (P1196) assassination (Q3882219) + qualifiers ordered by=donald trump + armament=hellfire missile is not clear. Who is equipped with the armament? Donald Trump? Armament is used as a main value to e.g. describe the weaponry a military aircraft be equipped with, see (talk) 19:58, 6 January 2020 (UTC)
    • It seems clear enough to me. But maybe some others should weigh in on how this should be modeled... ArthurPSmith (talk) 16:34, 13 January 2020 (UTC)

    next level in hierarchyEdit

       Ready Create
    Descriptionqualifier: indicates the value at the next hierarchy level which is true for this item, when more than one is possible at the next level
    Data typeItem
    Domainqualifier only in transitive property (Q18647515) with hierarchy (Q188619)
    Example 1111
    Example 2
    Example 3
    Planned usefor select only right values in cases like AB → (C and D) where C is right for A but D isn't
    See alsoterritory overlaps (P3179)


    The question arose here. On the example of geographic hierarchical properties like located in the administrative territorial entity (P131), there are cases when at one level of the hierarchy there are two correct values but only one of them are correct for referencing item from lower hierarchy level. The proposed property will help to make the right choice in the case of such switches. We could do the opposite and indicate for each of the values a list of items corresponding to it from the lower level but in case of Atlanta (Q23556) it will be thousands of streets, non-profit organizations, monuments, schools, cafes etc. So best way to resolve it at the items of monuments or cafes.

    I am sure that this can be useful not only for territorial properties like part of (P361). Сидик из ПТУ (talk) 12:40, 28 January 2020 (UTC)3333333333


    •   Support Since geographic relationships are not always one-to-one (given the examples above), located in the administrative territorial entity (P131) needs to be able to be qualified with a specific "parent" administrative territory. For example, after a natural disaster, I need to be able to search for all museums in a specific county. Without having a qualifier like "hierarchy switch", many museums will show up as being in the wrong county. And as Сидик из ПТУ points out, this qualification may also apply to other hierarchical/transitive properties. -- Clifflandis (talk) 14:02, 5 February 2020 (UTC)
    •   Support. --Mitte27 (talk) 06:41, 14 February 2020 (UTC)
    •   Support certainly make sense Ghuron (talk) 06:16, 15 February 2020 (UTC)

    Tobias1984 (talk) TomT0m (talk) Genewiki123 (talk) Emw (talk) 03:09, 9 September 2014 (UTC) Ruud 16:15, 9 December 2014 (UTC) Emitraka (talk) 14:32, 14 October 2015 (UTC) Bovlb (talk) 19:10, 21 October 2015 (UTC) Peter F. Patel-Schneider (talk) 22:21, 23 October 2015 (UTC) ArthurPSmith (talk) 15:51, 5 November 2015 (UTC) Daniel Mietchen (talk) 20:53, 3 January 2016 (UTC) Harmonia Amanda (talk) 22:00, 27 February 2016 (UTC) Lechatpito (talk) Andrawaag (talk) 14:42, 13 April 2016 (UTC) ChristianKl (talk) 16:22, 6 July 2016 (UTC) Cmungall Cmungall (talk) 13:49, 8 July 2016 (UTC) Cord Wiljes (talk) 16:53, 28 September 2016 (UTC) DavRosen (talk) 23:07, 15 February 2017 (UTC) Vladimir Alexiev (talk) 07:01, 24 February 2017 (UTC) Pintoch (talk) 22:42, 5 March 2017 (UTC) Fuzheado (talk) 14:43, 15 May 2017 (UTC) YULdigitalpreservation (talk) 14:37, 14 June 2017 (UTC) PKM (talk) 00:24, 17 June 2017 (UTC) Fractaler (talk) 14:42, 17 June 2017 (UTC) Andreasmperu Diana de la Iglesia Jsamwrites (talk) Finn Årup Nielsen (fnielsen) (talk) 12:39, 24 August 2017 (UTC) Alessandro Piscopo (talk) 17:02, 4 September 2017 (UTC) Ptolusque 01:47, 14 September 2017 (UTC) Gamaliel (talk) --Horcrux (talk) 11:19, 12 November 2017 (UTC) MartinPoulter (talk) Bamyers99 (talk) 16:47, 18 March 2018 (UTC) Malore (talk) Wurstbruch (talk) 22:59, 4 April 2018 (UTC) Dcflyer (talk) 07:50, 9 September 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) Ninokeys (talk) 00:05, 5 October 2018 (UTC) Buccalon (talk) 14:08, 10 October 2018 (UTC) Jneubert (talk) 06:02, 21 October 2018 (UTC) Yair rand (talk) 00:16, 24 October 2018 (UTC) Tris T7 (talk) ElanHR (talk) 22:05, 26 December 2018 (UTC) linuxo Gq86 Gabrielaltay Liamjamesperritt (talk) 08:44, 21 June 2019 (UTC) ZI Jony Ivanhercaz (Talk) 11:07, 15 July 2019 (UTC) Gaurav (talk) 22:39, 24 August 2019 (UTC) Meejies (talk) 04:38, 29 August 2019 (UTC) Iwan.Aucamp SilentSpike (talk) Tfrancart (talk) Sylvain Leroux TiagoLubiana (talk) 15:12, 2 December 2019 (UTC) Albert Villanova del Moral (talk) 15:43, 6 February 2020 (UTC) Clifflandis (talk) 15:10, 18 February 2020 (UTC) --Tinker Bell 16:48, 23 March 2020 (UTC) SM5POR Mkbergman (talk) 19:17, 10 July 2020 (UTC) Toni 001 (talk) 11:03, 11 July 2020 (UTC) The-erinaceous-one (talk) 22:02, 31 August 2020 (UTC) Cdo256 (talk) 06:26, 8 September 2020 (UTC) Antoine2711 (talk) 17:22, 25 September 2020 (UTC) Rehman 07:15, 12 October 2020 (UTC) Susanna Giaccai (talk) 07:22, 22 October 2020 (UTC) Nomen ad hoc So9q (talk) 10:17, 4 January 2021 (UTC) Simon Cobb (User:Sic19 ; talk page) 18:29, 8 January 2021 (UTC)   Notified participants of WikiProject Ontology

    •   Oppose given the discussion on Wikidata:Project chat and the alternatives explained there. Essentially this qualifier would encourage users to add incorrect statements to the "parent" item. --- Jura 09:39, 15 February 2020 (UTC)
    •   Support This will allow to model the situation en e.g. Georgia, USA as viewed as almost everyone else does it. See also my summary of the discussion in Project chat in Special:Diff/1116318285. --Dipsacus fullonum (talk) 06:58, 16 February 2020 (UTC)
    •   Oppose This propoal assumes that administrative divisions are always organised as a linear hierarchy. Many countries however know branching hierarchies where two or more administrative divisions are subordinated to the same division. In such cases, one can add multiple located in the administrative territorial entity (P131) claims because there are multiple most local admin territories. --Pasleim (talk) 12:30, 16 February 2020 (UTC)
      • So, there will be several (two) administrative divisions for Atlanta (Fulton and DeKalb). Georgia will still not be the most local for Atlanta, nor will Fulton for Patch Works Art & History Center (Q76461608). Сидик из ПТУ (talk) 13:43, 16 February 2020 (UTC)
        • You might want to re-read the discussion on project. BTW territory overlaps (P3179) was made for that. --- Jura 13:51, 17 February 2020 (UTC)
          • As I read Wikidata:Property proposal/territory overlapse that isn't true. P3179 was made to: (quote) representing overlapse between territorial entities arising from distinct classifications. Administrative vs religious is one (as with administrative subdivisions of countries vs dioceses), administrative vs political (as is the case with american special districts), geographical vs administrative (landforms vs countries or cities). (end quote) I note the emphasis on different classification types. In the case Georgia, USA municipality and country belongs to different levels of the same type of classification. The municipalities is considered to be in one or more counties, where the counties isn't considered to be in municipalities. In such cases this proposed hierarchy switch will be best to describe the situation. In other cases like the examples in P:P3179 that property is better. So we need both. --Dipsacus fullonum (talk) 15:52, 17 February 2020 (UTC)
      • This makes sense, if you relax the requirement/assumption that only the "most local" value should go in P131. But it may be tempting for people to delete the "redundant" P131 value if they don't realise why it's there. Ghouston (talk) 08:38, 17 February 2020 (UTC)
    •   Oppose Jura points out above that this qualifier will encourage people to add incorrect assertions. I would go further and say that it is only useful in the case when people have added incorrect assertions. While Atlanta certainly overlaps two counties, it is false to say that it lies either "physically within" or "under the administrative control of" either of them. If we want to be able to identify the containing county of some specific landmark within Atlanta, we can simply assert it directly (without requiring a qualifier), or find some intermediate region such as a neighbourhood. Bovlb (talk) 21:54, 18 February 2020 (UTC)
    Not that P30 matters, but the English label for P30 has just "continent", not "located in continent". --- Jura 11:20, 19 February 2020 (UTC)
    The burden of proof (Q1535975) on those who deny the hierarchy (municipality of Georgia (Q76514543)county of Georgia (Q13410428)Georgia (Q1428)). Atlanta seat of Fulton county (but also partly in DeKalb county, how can we say that Atlanta on the same level with counties after this? Are you going to claim that articles County (United States) (Most counties have subdivisions which may include townships, municipalities and unincorporated areasSome municipalities are in multiple counties) and Local government in the United States (Most states and territories have at least two tiers of local government: counties and municipalities) are wrong? Сидик из ПТУ (talk) 12:35, 19 February 2020 (UTC)
    Oh, you know — there are many labels and aliases of P131 in many languages have not in but true. And counties perfectly match with Wikidata usage instructions (P2559) of located in the administrative territorial entity (P131) in Atlanta case. Сидик из ПТУ (talk) 12:35, 19 February 2020 (UTC)
    I suppose we will keep disagreeing on that. --- Jura 17:31, 19 February 2020 (UTC)
    WikiData is not a separate project, the data from it is used in different language sections of Wikipedia, so you should evaluate your proposal to see if the templates created in the language sections will break. Maybe for you this is another abstract question, for me everything looks different. It seems to me that you "disagree" without a proper level of argumentation at a practical level. Carn (talk) 14:19, 20 February 2020 (UTC)
    The question is you aren't doing the opposite as you are intending: by adding a complex additional element, you just to make sure that it works for a single outside projects that may not have implemented things correctly. --- Jura 20:19, 3 March 2020 (UTC)
    The approach in which some cities of Georgia have in P131 county while others have a state should be attributed to incorrect ones in the first place.
      Support --AleUst (talk) 14:55, 19 February 2020 (UTC)
      Support, administrative territories are quite well represented as an ascending hierarchy, and this correction would make it work even better. Wikisaurus (talk) 16:33, 19 February 2020 (UTC)

    ──────────────────────────────────────────────────────────────────────────────────────────────────── The good point of this debate is the highlights a problem: While I'm sympathetic to the problems faced by ruwiki infobox designers, it mainly illustrates that Wikidata should try to provide a basic infobox and breadcrum navigation as otherwise we keep getting requests from wikis that make use of our data in a somewhat sub-optimal way and attempt to tweak the data to their usecase. We already did that in other fields and should to it for that too. --- Jura 13:37, 21 February 2020 (UTC)

    At first, Wikivoyage doesn't use Wikidata for breadcrumb navigation. Secondly, I see Example: Europe > Russia > Southern Russia > North Caucasus > Dagestan where Europe, Southern Russia and North Caucasus are not administrative territorial entity (Q56061) at all. And Russia is not only in Europe too so Europe > Russia > Siberia > Krasnoyarsk Krai > Krasnoyarsk (region) > Krasnoyarsk is simply wrong. Сидик из ПТУ (talk) 13:48, 21 February 2020 (UTC)
    I think we understood that earlier in the discussion (please re-read the comment above by DerFussi if you haven't done so), but it's a feature that should be supported directly through Wikidata statements. I think it's useful even for projects/users other than Wikivoyage. --- Jura 13:52, 21 February 2020 (UTC)
    OK. In this case, if we somehow build a hierarchy through Russia then we definitely need a switch in order to choose Asia for Krasnoyarsk and Europe for St. Petersburg. Сидик из ПТУ (talk) 13:56, 21 February 2020 (UTC)
    •   Support The best way now. - Kareyac (talk) 11:16, 21 February 2020 (UTC)
    • @Сидик из ПТУ, Clifflandis, Mitte27, Ghuron, Carn, Pasleim: @Bovlb, Kareyac, Jura1, Dipsacus fullonum: @DerFussi, RolandUnger, Ghouston: I have altered the English proposed name per a discussion above; please comment below if that changes your view on this proposal. ArthurPSmith (talk) 18:42, 21 February 2020 (UTC)
      • It was one or more of several values and I suggest leaving this wording just in case. For example, when two of the three values are true. Сидик из ПТУ (talk) 19:17, 21 February 2020 (UTC)
      • My objection was structural, and about the misuse of P131, so I'm afraid your fix doesn't help me. Thanks for trying. Cheers, Bovlb (talk) 16:34, 25 February 2020 (UTC)
    •   Comment I have another suggestion, which would be to use another P131 statement as a qualifier on the P131 statement, instead of defining a new property. Maybe it would be easier to use that trying to remember the name of the obscure property that changes the hierarchy, and it would still be distinguishable from a redundant P131. Ghouston (talk) 22:21, 21 February 2020 (UTC)
      • Yes, I also proposed to do so from the very beginning, however, this requires special documentation so that users understand in which cases such a qualifier is needed and in which it is unwanted. I believe that a special property allows users to better understand what function it performs. Сидик из ПТУ (talk) 08:58, 22 February 2020 (UTC)
    •   Comment how to we determine what the next level of the hierarchy is? Wouldn't it rather be "alternate hierarchy"? --- Jura 09:30, 22 February 2020 (UTC)
      • It must be one or more of the values that are specified in a similar property at the item to which we add the qualifier. Сидик из ПТУ (talk) 10:39, 22 February 2020 (UTC)
        • Yeah, so "alternate hierarchy" fits it better. --- Jura 10:41, 22 February 2020 (UTC)
          • Maybe I do not understand the subtleties of the wording in English but, otherwise, there are no differences from a typical case, county of Georgia (Q13410428) are always the next level of hierarchy for municipality of Georgia (Q76514543). The qualifier allows us to make a choice of several alternative values. Сидик из ПТУ (talk) 10:46, 22 February 2020 (UTC)
            • From the discussion, I get the impression that you assume a pyramidal organization of different government entities and likely an infobox that can't handle alternatives. --- Jura 10:52, 22 February 2020 (UTC)
              • Yes, proposed property is for resolve this. Сидик из ПТУ (talk) 11:45, 22 February 2020 (UTC)
                • Sure, but it's better to fix the infobox than to try to change the underlying data. --- Jura 17:10, 22 February 2020 (UTC)
                  • The infobox algorithm just relies on the fact that Wikidata will follow the rule "You only need to add the most local admin territory". The most local admin territories for Atlanta are Fulton and DeKalb and this is in line with the main point of view of most serious sources. Сидик из ПТУ (talk) 17:58, 22 February 2020 (UTC)
    •   Comment If we are going to say (for example) that Atlanta is in both Fulton and DeKalb counties then, yes, we need something like this. But I think that's just bad modeling and a patch to get around it. When geographical entities overlap like this, the city is no more in the county than the county is in the city. I believe that Atlanta, Fulton County, and DeKalb County are each in Georgia; that Atlanta overlaps with Fulton County and DeKalb County; and that any given point in Atlanta is either in Atlanta and in Fulton County, or in Atlanta and in De Kalb County. The fact that a county is somehow "higher-level" than a city does not change this. Five counties of New York State each coincide with boroughs of New York City: this is the one case I know of in the U.S. where counties are proper subsets of cities. Are we really going to say that New York City is in Kings, Queens, New York, Richmond, and Bronx counties rather than vice versa? - Jmabel (talk) 16:20, 22 February 2020 (UTC)
    Сидик из ПТУ and I were just discussing New York City over at Property talk:P131#Possible change of usage. Although the two situations aren't legally analogous, I believe they might be ontologically similar enough that a solution that applies to one ought to apply to the other. —Scs (talk) 16:56, 22 February 2020 (UTC)
    Yes, we read articles about borough of New York City (Q408804) yesterday[3][4][5], it emphasizes that they are unique to the United States and are parts of the NYC now. Сидик из ПТУ (talk) 17:58, 22 February 2020 (UTC)
    @Jmabel:, how would you write the location linearly, e.g., in the infobox for c:Category:Baltimore Block on Commons? The question is whether to put the city or county first, or come up with some other way of writing it. Ghouston (talk) 22:35, 22 February 2020 (UTC)
    @Ghouston: By tradition, in the U.S. (with the exception of New York City) we list city before county regardless of containment, but that's a matter of tradition, not data modeling. I think it might make sense to have a query know that as a rule for U.S. places (should be possible to enforce based on "instance of"), rather than to have to say in doesn't really mean in.
    By the way, New York is a mess in this respect. Pretty much any New Yorker would say that Morningside Heights is in Manhattan, not that it is in New York County, or that Park Slope is in Brooklyn, not that it is in Kings County. As for Richmond County / Borough of Richmond: almost everyone calls it "Staten Island"; after more than 300 years, the effort to give it an English rather than a Dutch name never really stuck. - Jmabel (talk) 23:44, 22 February 2020 (UTC)
    If the query “all cities of the county Fulton” doesn’t return Atlanta then this is a bad base and it doesn’t matter how the data modeling was. If Britannica says in then we follow this as most users who expect that for all the cities of Georgia, a generally accepted order is kept in line with the real situation. As for the local names of the places in New York, I can say the same thing about Moscow, where the districts got their names from the villages, and then these villages ended up in other districts. But it all suggests that New York boroughs are seen as part of the city as a priority and they are named on the English Wikipedia as Manhattan, Brooklyn, Queens, The Bronx and Staten Island. There are not separate articles about Kings or Richmond. Everything is clear here. Сидик из ПТУ (talk) 07:14, 23 February 2020 (UTC)
    There's a broader question here, which is: who or what is (or are) the primary user(s) of Wikidata? If it's people browsing our database, as if it were a stylized and highly-structured Wikipedia, then it makes sense to worry about what Britannica says, or what a reasonable New Yorker would say, and to try to have the presented data match that somehow. But if our data is primarily being used by computers running SPARQL queries, or by Wikipedia as it renders infoboxes, then we should favor a data model that fosters clean, consistent, general-purpose SPARQL queries and Lua templates and the like. —Scs (talk) 12:20, 23 February 2020 (UTC)
    Dozens of Wikipedia language sections and a number of other Wikimedia projects need a supported hierarchy for a property. Q18008533 is a Lua module and it is popular, this switch will be useful to it, but, of course, it is required to return the correct sequences like Atlanta→Fulton→Georgia. Сидик из ПТУ (talk) 08:50, 24 February 2020 (UTC)
    • I think the point is that you can't write a single SPARQL query; in the general case you have to write a little program, with some loops and if statements, that issues a number of SPARQL queries and makes decisions based on any next level in hierarchy qualifiers it finds. (To be perfectly clear, suppose the question is not, "Show me everything in DeKalb County (Q486398)", but rather, "Show me everything in County X".)
    This isn't necessarily a fatal flaw, but it does need to be acknowledged.
    Overlaps are obviously a mess. I suspect we can have either a data model that's closer to the "real world" but requires more-complicated algorithms to query, or a "refactored" model that's easy to query because it interposes some extra, artificial, constructed entities (like "portion of Atlanta within DeKalb county"), but not both. —Scs (talk) 12:08, 23 February 2020 (UTC)
    Using of "portion of Atlanta within DeKalb county" will make it difficult to work with queries such as "select all Atlanta bus stops". In any case, it’s better to work with real data than to add unobvious database tricks to the imperfection of the world. Alternatives to switch are similar to Procrustean bed (Q10991776). Сидик из ПТУ (talk) 08:50, 24 February 2020 (UTC)
    @Сидик из ПТУ: How does an interposed subentity of Atlanta make it harder to find all Atlanta bus stops? —Scs (talk) 13:06, 24 February 2020 (UTC)
    At least we need to order unobvious where in Atlanta-DeKalb or Atlanta-Fulton. And queries may be to select all bus stops in the capitals of each state or to select all Gerogia bus stops with their cities or select count of bus stops by city, etc. And what P131 is correct for it? If counties then we lose Atlanta in our hierarchy and can’t easily select this city along with other state capitals. If Atlanta then we lose any effect of this. A completely different conversation that such administrative territorial entity (Q56061) do not actually exist so this may lead to misinformation of the users. Сидик из ПТУ (talk) 13:25, 24 February 2020 (UTC)
    This proposed qualifier is another such trick. I think we'd just stick to the initially suggested solution (add both Atlanta and DeKalb county statements to the bus stop item, but the most local entities) queries remain simple. --- Jura 10:26, 24 February 2020 (UTC)
    This will make it impossible to build a hierarchy without a strong knowledge base wired into the algorithm and this will be a false statement that destroys the general logic. By the way, the property can be used without minus and queries like "select all bus stops in county" may contain the requirement to display the most local units for this stops (expected only cities). Maybe somebody can add to my query all organisations where next level of P131 contains only one county. Сидик из ПТУ (talk) 10:57, 24 February 2020 (UTC)
    Actually, using this qualifier assumes that the qualifier is used in a given level of the hierarchy, thus requiring users to write a program to identify it as Scs mentions. --- Jura 11:02, 24 February 2020 (UTC)
    Using P131 assumes that the most local admin territory for the bus stops of Atlanta is Atlanta, not counties. Сидик из ПТУ (talk) 11:08, 24 February 2020 (UTC)
    You mean, you assume that. --- Jura 11:08, 24 February 2020 (UTC)
    The reverse situation will complicate both the algorithms on Lua and the operation of SPARQL-queries when they need to work with the hierarchy. Сидик из ПТУ (talk) 11:27, 24 February 2020 (UTC)
    I guess it's debatable if "wdt:P131*" is more complicated than the program combined with the qualifier query you linked in some diff, but personally, I find more simpler. --- Jura 11:30, 24 February 2020 (UTC)
    Without following the rule of "most local admin territory" cheap hierarchy building will not be possible, however this feature is used in various Wikimedia projects very widely, it's much more relevant than the one-off SPARQL-queries for Georgia like was discussed here. The loss of hierarchy will entail the loss of many other opportunities while the qualifier, on the contrary, creates them. Сидик из ПТУ (talk) 11:45, 24 February 2020 (UTC)
    Here we identified that there are actually two "most local admin territories" to be considered (unless "part of Atlanta in DeKalb county" is created) and infoboxes can handle this. It is known that the ruwiki one doesn't do that and apparently ruwiki lacks the resources to keep it in shape .. so we keep getting these requests here. --- Jura 11:52, 24 February 2020 (UTC)
    There are two "most local admin territories" for Atlanta (Fulton & DeKalb), it matches to sources. There is one "most local admin territory" for Patch Works Art & History Center (Q76461608) (Atlanta). The machine cannot be taught to choose the "most local admin territory" from two or more values without detailed knowledge base. No one will learn the algorithm to select from the list first the city, then the county and finally the state since several thousand such tasks have accumulated over the history of mankind. We suggest improving the functionality, you suggest destroying it. Сидик из ПТУ (talk) 12:11, 24 February 2020 (UTC)
    And the creation of artificial concepts that do not exist in the real world, such as "part of Atlanta in DeKalb county" will make work with Atlanta more difficult. It's not valid administrative territorial entity (Q56061), work with similar items in contrast to the documented property will be less handy and, again, will require a solid knowledge base. Сидик из ПТУ (talk) 12:18, 24 February 2020 (UTC)
    • I don't think people are willing to dismiss transitivity so easily -- it's arguable that we do need it and should strive to preserve it. And North Yorkshire (Q23086) is no counterexample -- if anything it's proof that (a) real-world political subdivisions are confusing, irregular, and difficult, and (b) people have been representing them improperly in Wikidata for a while, meaning we really need some cleanup and a proper fix (whatever that may be). In particular, North Yorkshire is a ceremonial county of England (Q180673) and, therefore, not strictly an administrative subdivision. [See Wikipedia Subdivisions of England: "For non-administrative purposes, England is wholly divided into 48 counties, commonly known [...] as ceremonial counties".] But you probably can't use North Yorkshire (Q23086) as part of your primary P131 hierarchy -- it's guaranteed to fail. (Just look at the comment -- right in Q23086's description! -- directing you over to North Yorkshire (Q21241814), which actually is an administrative subdivision, and which does not encompass e.g. Redcar and Cleveland (Q1434448), meaning it'd be much easier to use Q21241814 as part of a proper, nonoverlapping hierarchy.)
    Can you say a little more about what you mean when you say "not allowing hierarchies to be done"? The argument for enforcing pure transitivity on P131 is that it makes P131 act like the mathematical operator subset (Q177646), meaning that simple wdt:P131* queries always yield proper results. In this sense saying that Patch Works is in Fulton County, or that Atlanta is in Georgia, is perfectly fine. I think your objection to these relations is that you can't list all cities in Fulton County by doing a simple wdt:P131 wd:Q486633 query, or something, but I'm really not sure.
    Have we asked the folks over at WikiProject Country subdivision for their advice on all this? I bet they've put some thought into how best to resolve these situations. [Footnote: I've now asked them.]—Scs (talk) 13:01, 1 March 2020 (UTC)
    Firstly, neither I nor Russian Wikipedia in general came up with the use of ceremonial county of England (Q180673) at located in the administrative territorial entity (P131). As I understand it, the British themselves began to fill out the data in this way. I am not opposed to clarifying this issue, although the ceremonial counties have changed the form of government over time and I fully admit that at the moment the phrase "Most ceremonial counties are, therefore, entities comprising local authority areas, as they were from 1889 to 1974" is correct. We can argue about the powers of the Queen of the United Kingdom, Governor General of Canada (Q390776) or Lord Lieutenant (Q914752) but if the existing hierarchies are in most cases useful then I do not see an error in such an interpretation where ceremonial county of England (Q180673) in located in the administrative territorial entity (P131).
    Secondly, I think that following the main sources we should consider Atlanta a city in Fulton County (and also in DeKalb County) and make the appropriate statements. I consider it will be a bad decision to be guided in the first place by the rule "is completely in" and state Georgia for Atlanta at P131 with counties for other cities. It will simply be a false statement that the municipality of Atlanta is on the same hierarchy level as the counties. Сидик из ПТУ (talk) 10:38, 2 March 2020 (UTC)
    Ah, okay, now I get it: You want P131 to mean "is an administrative subdivision of". That makes sense.
    Or, stated another way, P131 represents a direct child relationship, and the proposed new property simply represents a grandchild relationship, for use in cases where we can't properly describe the situation with two ordinary child relationships. (Indeed, we've got some similarly redundant tags for people. Normally we represent human grandchildren as a pair of child (P40) properties, and siblings as two people having the same parent(s), but if we don't have an entity for the parent, we can use kinship to subject (P1039) along with grandchild (Q3603531), sibling (Q31184), etc.) —Scs (talk) 16:36, 2 March 2020 (UTC)
    P.S. When I said "you probably can't use Q23086 as part of your primary P131 hierarchy", I was not referring to you or the Russian Wikipedia; I meant "anybody". But the fact that "the British themselves began to fill out the data in this way" doesn't prove much, either -- as JMabel mentioned in another thread, we shouldn't automatically let popular folksonomies drive our more-precise taxonomic work here. 19:18, 2 March 2020 (UTC)
    And looking at the real situation, it seems that the warning in the description does not forbid the use of North Yorkshire (Q23086) in the P131 but something like different from (P1889). Сидик из ПТУ (talk) 15:16, 2 March 2020 (UTC)
    •   Comment Scs wrote: (quote) I think the point is that you can't write a single SPARQL query; in the general case you have to write a little program, with some loops and if statements, that issues a number of SPARQL queries and makes decisions based on any next level in hierarchy qualifiers it finds. (To be perfectly clear, suppose the question is not, "Show me everything in DeKalb County (Q486398)", but rather, "Show me everything in County X".) (end quote)
    That is not true. Here is single SPARQL query using the proposed query for a search for items in an arbitrary administrative unit:
    # SPARQL code to find items in an arbitrary administrative unit, called Q800000000,
    # using the proposed qualifier, called P8000
    SELECT ?item
      VALUES ?searched_unit { wd:Q800000000 }
        ?item wdt:P131* ?searched_unit .                 # located in the searched unit 
        ?item wdt:P131*/p:P131/pq:P8000 ?other_unit .    # unless next level in hierarchy is a unit
        ?other_unit wdt:P131/^wdt:P131 ?searched_unit .  # at same level in the hierarchy
        FILTER (?other_unit != ?searched_unit)           # and different from the sought unit
    Try it! --Dipsacus fullonum (talk) 15:47, 26 February 2020 (UTC)
    Thank you. I apologize for my naïveté about the potential power of complex SPARQL queries. —Scs (talk) 11:32, 27 February 2020 (UTC)
    • It's essentially two queries which works here because there are not too many items involved and P8000 doesn't exist. For testing, Sandbox-Item (P369) can be used.
    I'm curious to see the version for "all bus stops in Georgia by county". According to an addition on Property talk:P131 this would work for that as well. --- Jura 09:52, 29 February 2020 (UTC)
    @Jura1: Here is a version for all bus stops in Georgia by county as requested:
    # Find all busstops in Georgia by county
    SELECT DISTINCT ?busstop ?county
      ?busstop wdt:P31 wd:Q953806 .       # is busstop
      ?busstop wdt:P131+ ?any_county .    # located in county
      ?any_county wdt:P31 wd:Q13410428 .  # which is a county of Georgia, USA
      OPTIONAL {
        ?busstop wdt:P131*/p:P131/pq:P8000 ?switched_county . # the true county if present
        ?switched_county wdt:P31 wd:Q13410428 .               # if it is a county of Georgia, USA
      BIND(COALESCE(?switched_county, ?any_county) AS ?county)
    Try it! --Dipsacus fullonum (talk) 12:17, 29 February 2020 (UTC)
    • Does it assume that the qualifier would be placed on a known layer and the layer is always in the same place of the matrix?
    Would this work if the county was a French department and the French municipality had a switch to the relevant department?--- Jura 09:56, 1 March 2020 (UTC)
    Answer to first question: No. Answer to second question: As I understand English Wikipedia a French municipality (commune) is in only one department. But even if that isn't the case, then the next levels in the French administrative hierarchy are cantons and arrondissements, so a commune should never have the proposed qualifier with a value of a department. Please read the description the proposal ("the value at the next hierarchy level"). But anyway, even with a double incorrect use of the qualifier, the query could be changed to give busstops in France by department, and work. --Dipsacus fullonum (talk) 12:09, 1 March 2020 (UTC)
    I don't think the problem at Wikidata_talk:WikiProject_France/Communes#Communes_multi-départementales is solved. --- Jura 13:02, 1 March 2020 (UTC)
    I don't understand French, but as I understand the point using machine translation of the discussion, the French communes is always in exactly one department, but which department have changed over time. If that is correct, then this proposed qualifer will not be usable for french communes. Instead the values for P131 somewhere in the property chain should use time qualifers as start time (P580) and end time (P582). If you want help with queries with time qualifiers, please ask in Wikidata:Request a query. --Dipsacus fullonum (talk) 14:17, 1 March 2020 (UTC)
    If I recall correctly, there were several problems: one is that they changed over time (not important here), another that that some users include intermediate administrative layers that strech across several departments. It's a similar problem as the Atlanta one, at least if Atlanta had boroughs. --- Jura 20:19, 3 March 2020 (UTC)
    Until 2015, France had two parallel hierarchies of administrative-territorial units. One of them consisted only of cantons, and the other was and remains perfectly transitive. To build a second hierarchy according to it, it is enough to simply indicate arrondissement of France (Q194203). Сидик из ПТУ (talk) 10:42, 4 March 2020 (UTC)
    I think you could make an argument to add it as a qualifier to those properties, sure. If you wanted to query all of the people born in DeKalb County (Q486398), you could get results of people who were born in Atlanta (Q23556) with a qualifier of next level in hierarchy of DeKalb County (like someone born at Emory University Hospital (Q5373728), which is in Atlanta and DeKalb County). I could also see it being useful for historical cases, where someone was born in a city when it had a different administrative territorial entity in the next level in the hierarchy. The statement would be true, and it would also make querying easier. Clifflandis (talk) 15:06, 27 February 2021 (UTC)
    The question is about entries like the place of birth of George Washington: Q23#P19 which is currently given as Westmoreland County (Q494413) and qualified with "Great Britain" and "Colony of Virginia". It's not something I advise on doing, but it seems to be a usecase for this qualifier as well. Apparently, these kind of qualifiers are added by ruwiki users to ensure their infobox can easily find the items. At some point there was a bot adding them, but it was blocked as it was considered not suitable approach. Users still keep adding them manually though. --- Jura 08:14, 28 February 2021 (UTC)
    I don't think this proposed hierarchy switch qualifier should be used in cases like Q23#P19. The qualifiers there isn't really necessary since the correct administrative units and country can be found from Westmoreland County (Q494413) together with the time of birth. But if qualifiers are used at Q23#P19 anyway the hierarchy switch would make no sense. In such cases you would need to use located in the administrative territorial entity (P131) as the qualifier. By instead using the hierarchy switch qualifier there would be no indication that the value is an administrative unit and it wouldn't be clear what the qualifier was about. --Dipsacus fullonum (talk) 12:14, 28 February 2021 (UTC)
    Is there anything in the proposal that excludes its use? Why not also use P131 as qualifier in the samples of the proposal above? --- Jura 15:15, 28 February 2021 (UTC)
    Yes, undefined meaning excludes it use that way. Is there anything in the proposal that justifies its use as qualifier to place of birth (P19)? No! How should a hierarchy switch qualifier to George Washington (Q23) place of birth (P19) Westmoreland County (Q494413) be interpreted? There would no indication about what kind of hierarchy it is refering to. --Dipsacus fullonum (talk) 15:30, 28 February 2021 (UTC)
    Actually, "transitive property" excludes it. So location (P276) or located on terrain feature (P706) would be ok, but not P19 [6]. --- Jura 15:44, 28 February 2021 (UTC)
    @Jura1: do you think there's enough of a use case to support this qualifier for P131, or do you think it's still inappropriate? I'm curious if the conversation over the last year has shifted your opinion any, or if your concerns still stand. Thanks! Clifflandis (talk) 15:30, 2 March 2021 (UTC)
    Russian Wikipedia community opposes the located in the administrative territorial entity (P131) and country (P17) to be added as qualifiers to place of birth (P19) and place of death (P20). The historically correct hierarchy chain for our infoboxes is calculated taking into account the dates of birth and death. So we do not need any qualifiers for Q23#P19. Proposed property needed only for cases like with Atlanta with two next levels in hierarchy at the same time, not for historical cases. Сидик из ПТУ (talk) 09:45, 4 March 2021 (UTC)

    Fails compliance withEdit

       Under discussion
    Descriptionfails compliance of the test defined in the associated item
    Data typeItem
    Example 1Hackers (Q13908) → "fails compliance with" → Bechdel test (Q4165246)
    Example 2instant-runoff voting (Q1491219) → "fails compliance with" → monotonicity criterion (Q6902035)
    Example 3Copeland's method (Q5168347) → "fails compliance with" → independence of irrelevant alternatives (Q3150644)


    We need the opposite of complies with (P5009) to state when an item doesn't comply with the criterion associated with an item. For example:

    Could someone create a "fails compliance with" property? -- RobLa (talk) 02:49, 31 January 2020 (UTC)


    Summary of Wikidata:Project_chat/Archie/2020/01 conversation: this is what was discussed over at Wikidata:Project chat/Archive/2020/01 as part of the "Reasonably quick way to resolve 'non-compliance property' issue?" topic back in January/February. User:Jura1 suggested modeling this after test taken (P5021) and test score (P5022), allowing us to specify other options besides "complies", "doesn't comply". User:Ghouston suggested instead that we can add qualifiers to this new property if we need to move beyond binary compliance/non-compliance. User:Ls1g suggested a change to the data model to allow statements which negate any existing property, and links to this paper: "Negative Statements Considered Useful" - Hiba Arnaout, Simon Razniewski, and Gerhard Weikum.

    • Comment - Please edit the summary above if you believe there is a problem with it. I'd still prefer taking User:Ghouston's approach as I understand it, which would mean creating a "Fails compliance with" property. -- RobLa (talk) 05:21, 1 April 2020 (UTC)

    • @Jura1:, can you give details of how you think it should be done? You want to replace complies with (P5009) with a new property, such that there's only a single property for defining compliance? Then the statement itself would be meaningless without interpreting the qualifiers, which would make it harder to write queries. Ghouston (talk) 09:56, 3 February 2020 (UTC)
      • I think the explanation on project chat is fairly clear. Please comment there if you think it needs more input. --- Jura 09:58, 3 February 2020 (UTC)
      • @Ghouston:, thank you bringing the conversation to this proposal page. I agree with you that queries seem a lot easier with the addition of "fails compliance with" than queries involving a new regime modeled after test taken (P5021) and test score (P5022). This page seems like a better place to discuss alternatives to "fails compliance with" than the omnibus project chat page. -- RobLa (talk) 18:08, 3 February 2020 (UTC)
    • @Jura1: I don't think it's correct to say that compliance is not binary. A voting system either complies with a criterion or it doesn't; there is no in-between. The reason that table has cells other than Yes or No is because it combines closely-related voting systems into the same row, and closely-related criteria into the same column. In other words, some of the rows in that table are actually classes of voting systems rather than instances of voting systems. Omegatron (talk) 18:56, 9 February 2020 (UTC)
    •   Oppose. There should be a better data model for both this and complies with (P5009) in such cases. Jura1's suggestion looks workable. --Yair rand (talk) 21:47, 5 February 2020 (UTC)
    • Is there any precedent for a statement that's meaningless without interpreting the qualifiers? I can't think of one, but I don't know them all. It would be like X <compliance> Y. Ghouston (talk) 22:21, 5 February 2020 (UTC)
      @Ghouston: disjoint union of (P2738) only allows list values as qualifiers (Q23766486) as a value. --Yair rand (talk) 22:48, 5 February 2020 (UTC)
      • I don't think it's meaningless. It's like the "test taken" mentioned on Project Chat or "significant event". We know that's a valid criterion/test/event for the item, we just don't have full details. The approach seems more suitable for non-binary content like the voting systems description that is planned.
        Also, I don't get why Bechtel test is mentioned. It isn't even used with the other property. --- Jura 23:03, 5 February 2020 (UTC)
    •   Support - These are binary criteria, and so "test score" or "degree of compliance" or other qualifiers are irrelevant and make queries overly complex. "change to the data model to allow statements which negate any existing property" might be fine, too, but maybe more complicated to use. Omegatron (talk) 14:20, 20 December 2020 (UTC)
    •   Weak support. While "compliance" is binary, Wikidata properties explicitly allows "unknown" and "no value", and implicitly "we don't care" / "there is no verifiable info about this" (by not including a statement). So it will be helpful to have a property to record notable instances of test failures. I also think we should require references for uses of this property so we don't collect irrelevant "failures" and can back ourselves up if people complain we're bad-mouthing them. ("Weak" because I won't have time to help curate this property, but I support whoever wants to do this.) Deryck Chan (talk) 14:22, 1 January 2021 (UTC)

    Wallacegromit1, focus on media historiography and works from the Global South Valentina.Anitnelav (talk) 14:12, 16 November 2020 (UTC) Blue Rasberry (talk) 23:59, 21 December 2020 (UTC) Nomen ad hoc   Notified participants of WikiProject Media Representation

    •   Comment We spoke about this at Wikidata_talk:WikiProject_Media_Representation#Fails_compliance_with and we would rather use Yair rand's and Jura's method (using test taken (P5021) or another, similar property that is not restricted to humans with a new qualifier outcome or test result). While Bechdel test results may be modelled using complies with/fails compliance with, this is not true for many other tests (we need a "not applicable" for some tests and some tests don't deliver a "fail" or "pass" result but just a score). The test taken (P5021) and test outcome approach has the advantage to be more flexible. Please have a look at the model presented at the discussion mentioned above to have an overview about tests that don't fit into the complies with/fails compliance with model and how we could model them after test taken (P5021) and test outcome. So please don't use the Bechdel test (Q4165246) as an example for this property as we are not going to model Bechdel test results like that.
    That said I won't oppose this property. I even think that complies with/fails compliance with could be useful for us as a qualifier. There are tests that require certain criteria (e.g the Riz Test) or a number of criteria (e.g. the Feldman test) to be met. To be able to make it explicit which criteria are met and which not is, besides other advantages, necessary so that we can meet a minimal standard of sourcing (e.g. while there will be few sources for a certain film that it meets the Feldman test there are enough sources which can be used to decide if a film has a female screenwriter). We are currently using criterion used (P1013) to record the criteria which were crucial for the outcome but this does not fit nicely all tests - sometimes it may seem a bit shoehorned. So could we use this as a qualifier? In this case I would support this. @RobLa: (as this proposal is quite old...) - Valentina.Anitnelav (talk) 12:45, 5 January 2021 (UTC)

    Unicode character (item)Edit

       Under discussion
    DescriptionUnicode character representing the item
    Data typeItem
    Domaininstance of (P31)subclass of (P279)* → letter (Q9788)
    Example 1A (Q9659) → See Q9659#P487, each value will be a new item
    Example 2B (Q9705) → See Q9705#P487, each value will be a new item
    Example 3C (Q9820) → See Q9820#P487, each value will be a new item
    Planned usenew items will be created for current values of Unicode character (P487) on instance of (P31) of letter (Q9788). The current values of Unicode character (P487) and Unicode hex codepoint (P4213) will be moved to these new items.
    See alsocode (P3295), Unicode character (P487) and Unicode hex codepoint (P4213)


    Currently Wikidata does not differ abstract symbols A (Q9659) and specific characters representing the symbols. So it may be meaningful to create new items for these Unicode characters. Unicode character (P487) and Unicode hex codepoint (P4213) will be moved to these new items and then a single value constraint will be set.

    Note this does not affect any item about single characters like (Q3595028).GZWDer (talk) 22:02, 11 March 2020 (UTC)


    •   Comment How will this be different from Unicode character (P487)? And how come the name of the property is "Unicode character (item)" - why is there "(item)" in it? Iwan.Aucamp (talk) 16:37, 12 March 2020 (UTC)
      •   Oppose I get it now. I don't think this makes that much sense. For one the name does not make sense, if this were to be done you should make it rather "represented by character set code" - so it could potentially be more broad so it can cover Morse code (Q79897) and Unicode (Q8819) - but I think you first have to try and get some consensus on the data model here. Iwan.Aucamp (talk) 16:43, 12 March 2020 (UTC)
      • The disambiguator is needed as we can't have two identical labels for properties. --- Jura 21:30, 12 March 2020 (UTC)
    •   Comment Do we have any items for individual unicode codepoints right now? I don't see that there's a real structural need for an item for each one, but some of them may be notable in themselves. On the other hand, for those notable ones (none of the "A's" count I think) what would point to them with a property like this? ArthurPSmith (talk) 17:26, 12 March 2020 (UTC)
    •   Comment @ArthurPSmith: See Wikidata:Requests for permissions/Bot/GZWDer (flood) 3. In most cases, I do not want to reuse items like 𐓃 (Q66360724) for unicode character, as the character does not correspond to single Unicode character (it correspond to two, U+104C3 and U+104EB). This property will not have single value and unique value constraint, while (after migration) Unicode character (P487) and Unicode hex codepoint (P4213) will. "structural need for an item for each one": Each specific character itself has various properties (Unicode character property (Q1853267)) that can not be expressed without dedicated item (example).--GZWDer (talk) 17:44, 12 March 2020 (UTC)
    •   Comment @Iwan.Aucamp: This is really not a new idea and there's some discussion. I am only going to work on this currently (after a break of 18 months) as Unicode 13.0 is released recently.--GZWDer (talk) 17:51, 12 March 2020 (UTC)
      •   Comment @GZWDer: I cleaned up the proposal a bit. I still think this should be more generic though, at the very least I would like to see some actual real example items? Presumably the subject items would be instance of (P31) of Unicode character (Q29654788) which is subclass of (P279) of character (Q32483)? Could we not call this property "codepoint (item)" rather? (see Code point and also maybe code (P3295)) then it is a bit broader than just Unicode (Q8819)? If so I would change to support, I get the need. Iwan.Aucamp (talk) 18:28, 12 March 2020 (UTC)
      •   Comment @GZWDer: "Character" is such an overloaded term and the existing labels lead to confusion. Just explaining that a Unicode Character is not *just* a latin alphabetical character is hard! Please try to disambiguate the meaning upfront, something along the lines of Unicode Code Point (item), Unicode Abstract Character (item), and Unicode Character Encoding (external-identifier | string). -indo (talk) 02:34, 5 November 2020 (UTC)
        • @Iwan.Aucamp, Indolering: In this proposal, it means "abstract characters encoded by the Unicode Standard".--GZWDer (talk) 05:05, 5 November 2020 (UTC)
        • @Iwan.Aucamp: What does that mean? Is there a list of abstract characters somewhere? I'm not being facetious, I'm learning Unicode and this is driving me crazy! Here are all of the potential definitions I could find:
          • Unicode Glossary definition for Abstract Character: "A unit of information used for the organization, control, or representation of textual data. (See definition D7 in Section 3.4, Characters and Encoding.)"
          • Definition 7 in Section 3.4 "A unit of information used for the organization, control, or representation of textual data." followed by a list of vague bullet points, including the following:
            • "The abstract characters encoded by the Unicode Standard are known as Unicode abstract characters."
            • "Abstract characters not directly encoded by the Unicode Standard can often be represented by the use of combining character sequences."
          • The example in Chapter 2 Section 4 figure 2.5 shows how 3 different combinations of code points that all map to a single "abstract character", which (at least in this instance) appears to be a single common grapheme.
            • But that can't be right, because of this bullet point in Section 3.4 definition 7, "An abstract character does not necessarily correspond to what a user thinks of as a “character” and should not be confused with a grapheme."
          • This Character Encoding Model technical note mentions something close to what you are looking for, an Abstract Character Repertoire, "defined as a set of abstract characters to be encoded, normally a familiar alphabet or symbol set. The word abstract just means that these object are defined by convention."
          • But you don't want something that is defined by convention, you want the encoded abstract characters, which sound like a Coded Character Set, "defined to be a mapping from a set of abstract characters to the set of non-negative integers. ... The Unicode concept of the Unicode scalar value (cf. D28, in chapter 3 of the Unicode Standard) is explicitly this code point, used for mapping of the Unicode repertoire."
          • But that's not it either, as a Unicode Scalar Value is just, "Any Unicode code point except high-surrogate and low-surrogate code points. In other words, the ranges of integers 0 to D7FF16 and E00016 to 10FFFF16 inclusive."
        • Please correct me if I am wrong, but I don't think there is a set of "encoded abstract characters", there are just code points (the Universal Coded Character Set) and transformation rules (Universal Transformation Format) which can be used to map between code points that one might consider equivalent. If that's the case, then you shouldn't have a Unicode Abstract Character item at all and use Unicode Code Point terminology
    •   Comment Some symbols may also have multiple characters, like $ (Q11110).--GZWDer (talk) 18:31, 12 March 2020 (UTC)
      •   Comment @GZWDer: If we are trying to duplicate unicode maybe the lexeme namespace is better for this? It seems like in many of these cases you have a character with several different forms (uppercase vs lowercase) which is captured for example in Lexeme:L20817 (though they probably should not be all under "English" language). ArthurPSmith (talk) 18:56, 12 March 2020 (UTC)
        •   Comment @ArthurPSmith: a Unicode character is not a lexeme as it only correspond to a specific writing system, not a specific language. For example, the letter "a" is used in more than 100 languages, but have only one codepoint (if we restrict it to normal small case letter). In a letter point new lexemes about letters actually used in a specific language may be created (e.g. A and a are same letter and will have one lexeme), which is out of scope of the current task.--GZWDer (talk) 19:01, 12 March 2020 (UTC)
          • It's possible to have languages such as "mul". Lexemes have the advantage that they don't require multiple labels nor description. --- Jura 21:30, 12 March 2020 (UTC)
            Sample at (L61046) --- Jura 09:53, 14 March 2020 (UTC)
    •   Comment I could never really figure out the purpose of Unicode character (P487). It's being used in at least four or five different ways. The above would fix that and it could become an external-id property. --- Jura 21:30, 12 March 2020 (UTC)
    •   Strong support I never understood why Unicode characters were mixed with the glyphs and concepts they represented. --Tinker Bell 06:16, 15 March 2020 (UTC)
      • @Tinker Bell: It's a little 'meta' I think, but I feel like I don't understand what is the actual subject of an item that is "about" a Unicode character. GZWDer's proposal is, I think, only to use this property where a current item has more than one Unicode character value. So for example for Chinese characters, there is only 1 Unicode character, so the item and the Unicode character are equivalent. Does that mean the "concept" of that character and the Unicode character are the same, or distinct? For the letter 'A' example, Unicode differentiates upper- and lower-case, and also those other special conditions that are sort of the letter 'A' in other contexts. So in each case where a new item would be created, that item would be "about" the conceptual context of the use of that letter, not specifically or exclusively about it as a Unicode character. Right? Or is that not the point here? ArthurPSmith (talk) 18:37, 16 March 2020 (UTC)
        • It is meaningless to split items about character and glyph of Chinese characters, as Unihan database (using Unicode character as primary key) is about the glyphs. Usually different values (contexts) may be differed by object has role (P3831).--GZWDer (talk) 18:41, 16 March 2020 (UTC)
    •   Question can we change this to lexeme datatype per suggestion above? --- Jura 02:06, 28 March 2020 (UTC)
      • I don't think so - a lexeme may still cover multiple character or sequences of characters. For example ? have seven characters; but they should be in one (translingual) lexeme unless thay are semantically different.--GZWDer (talk) 09:13, 29 March 2020 (UTC)
        • Well, the idea is to use lexemes like (L61046) mentioned above. They would exactly be that. --- Jura 09:15, 29 March 2020 (UTC)
          • In addition, lexemes can not handle characters not in Unicode normalized form, like 著 (U+FA5F) (Q55726748) and 著 (U+2F99F) (Q55738328). I don't think we should have lexemes for them as they have no independent meaning.--GZWDer (talk) 09:22, 29 March 2020 (UTC)
            • It's possible that initially not all can be included. The namespace is still under development and eventually a way can be found. We didn't use items either when no lexemes were available. As each character has a definition, this can be included as S1. The problem with using items is that they require needless repetition of labels and descriptions. Lexemes have all that already included. --- Jura 09:28, 29 March 2020 (UTC)
              • However still some lexemes for symbols may cover multiple characters such as X (L19342). I don't see the point for creating additional lexemes for individual characters with no additional meaning.--GZWDer (talk) 09:43, 29 March 2020 (UTC)
                • I don't think existing entities in some languages should be replaced. They can use the proposed property to point to entities like (L61046) as well. I don't think the question whether or not to create these is much different from the question of creating them as items. If you don't see the point of one, it's unclear why you would want to create the others. Given the 5 or so ways Unicode character (P487) is used, people clearly have problems with the current structure and the more formal approach of the L-namespace could help. --- Jura 09:52, 29 March 2020 (UTC)
                  • An item may easily tie to an specific Abstract Character, while a lexeme is a unit of lexical meaning, comprising a set of Abstract Characters with same semantic meaning. I don't think we should have lexemes for characters with no independent semantic meaning. For CJKV characters, I do not favor creating translingual lexemes for them - English Wiktionary deprecated translingual definitions long ago. --GZWDer (talk) 10:35, 29 March 2020 (UTC)
                    • I think you are mixing "lexeme" and Lexeme: --- Jura 10:53, 29 March 2020 (UTC)
                      • Lexemes should be created for symbols like X (L19342), and if we also create lexemes for individual characters, we will 1. unnecessarily duplicate the definitions and 2. make users confused.--GZWDer (talk) 11:17, 29 March 2020 (UTC)


    • Can you explain what you think would be duplicated? How users could be confused? (L291359) explains clearly what it's about. For (Q87524936) users would have to find the right language to read the alias to understand what it's about. Seems much more confusing to me. --- Jura 04:43, 31 March 2020 (UTC)

    I have following addition reasons:

    1. You can not add sitelinks to lexemes, so items like Face with Tears of Joy (Q33836537) and (Q3595028) will exist.
    2. Some characters have Unicode aliases (See [7] p924). aliases can not be added to lexemes either.
    3. We will anyway have lexemes for symbols like ( ) - this is a matching pair, and individual characters ( and ) - as a symbol, ( corresponding to multiple codepoints. Users may confuse the symbol with individual Unicode characters if both have lexeme.
    4. Not every Unicode character has meaning, and Unicode names are only names, which does not always tell the meaning of character (like 𗊓 (Q87589786)), and sometimes even unrelated to the meaning. They only exist as aliases, not as definitions.

    --GZWDer (talk) 19:19, 31 March 2020 (UTC)

    • I think it should be possible to solve these too. BTW, I'm not sure if Face with Tears of Joy (Q33836537) should actually have been merged with Q87581513, at least not in the logic you presented above. --- Jura 14:46, 4 April 2020 (UTC)
    Each item is about an "Abstract Character" which may be encoded in multiple codesets (including Unicode). For example, "A" is a Unicode character which is (equals to) "Abstract Character" encoded in Unicode, and the same "Abstract Character" may also be encoded elsewhere. most emojis are also "Abstract Characters", some are encoded in Unicode, some are not. There will be only one item for each "Abstract Character" wherever it is encoded. I think this property should be limited to "Abstract Character" encoded in Unicode (as unencoded "Abstract Characters" are potentially infinite - this is why we have private use area (Q11152836).)--GZWDer (talk) 20:53, 5 April 2020 (UTC)
    •   Support Ok, I think I get the point here, yes let's do this. ArthurPSmith (talk) 19:53, 1 April 2020 (UTC)
    •   Comment There is just too much redundancy in the suggested datatype: compare item at [8] (~900 triples) and lexeme at [9] (~20 triples) --- Jura 14:46, 4 April 2020 (UTC)
      • I don't think this is how we should concern, given the number of Unicode character is limited.--GZWDer (talk) 20:43, 5 April 2020 (UTC)
        • It's a massive redundancy due to a problem in the modeling. Besides, Query Server has problems dealing with them. Items become difficulte to edit when they have a larger number of triples. --- Jura 15:20, 7 April 2020 (UTC)
    •   Strong support per Tinker Bell. Also there should probably be an inverse statement. 1234qwer1234qwer4 (talk) 15:03, 7 April 2020 (UTC)
    • An alternative proposal now at Wikidata:Property proposal/Unicode character --- Jura 15:20, 7 April 2020 (UTC)
    •   Oppose given the redundancy of the proposed datatype. --- Jura 13:20, 13 April 2020 (UTC)
    •   Oppose in favor of Jura's proposal; if we cannot implicitly or explicitly force a single label--a single triple--to be shown for all languages in the interest of efficiency, then this only promotes more bloat. Mahir256 (talk) 00:35, 18 April 2020 (UTC)
    •   Weak support I strongly support spliting Unicode characters from concepts. Perhaps there is an existing property that could be used. --Matěj Suchánek (talk) 11:06, 4 September 2020 (UTC)

    number of deceased by period in this location/countryEdit

       Under discussion
    Descriptionnumber of deaths per year in this country or other geographic region
    Data typeQuantity
    Domaindemographics of country or region (Q23983664)
    Example 1demographics of France (Q1172523) → 614000 in 2018
    Example 2demographics of Italy (Q1800338) → 633133 in 2018
    Example 3demographics of the United States (Q1965974) → 2813503 in 2017
    Expected completenessat least one value for the latest available year per country


    Should be possible to query the death per country. And not to be confused with number of deaths (P1120) which stand for a specific event, not a whole country. Bouzinac (talk) 18:14, 21 March 2020 (UTC)


    •   Comment I would suggest renaming it to 'number of deceased by period'. In this case, the qualifier point in time (P585) should be required. --Tinker Bell 16:36, 22 March 2020 (UTC)
    •   Support - Given that it is renamed to something more specific. If it just for geographic locations i would suggest something like 'deceased by period in location'. Husky (talk) 22:53, 24 March 2020 (UTC)
    •   Comment I'm a bit worried to have another series of properties with countless values on country items. How about placing this on items like demographics of France (Q1172523) ? --- Jura 13:24, 27 March 2020 (UTC)
      Why not but would it be possible for an wikiarticle of country X to search that number ?Bouzinac💬✒️💛 15:10, 3 February 2021 (UTC)
      • Do we currently have that type of data in country articles? If needed, you could add an item-based property "demographics of topic", similar to economy of topic (P8744). --- Jura 13:57, 13 February 2021 (UTC)

    quantification instructionEdit

       Under discussion
    Descriptioninstruction according to which the ingredient should be quantified
    Representsquantification instruction (Q89895195)
    Data typeItem
    Allowed valuesup to taste (Q89895024),until cup is full (Q89895393) (more?)
    Example 1Bloody Mary (Q207711)made from material (P186)Tabasco sauce (Q335016) → [this property] → up to taste (Q89895024)
    Example 2Warp 10 (Q87586496)made from material (P186)Upper 10 (Q7898449) → [this property] → until cup is full (Q89895393)
    Example 3Russian Spring Punch (Q26883085)made from material (P186)sparkling wine (Q321263) → [this property] → until cup is full (Q89895393)


    most recepies prescribe precise amounts for each ingredient. in these cases we can simply use quantity (P1114) to depict the amount. But some recepies also contain an instruction about how to find the correct quantity: such as the offical recepie for Boody Mary: Tabasco, Celery Salt, Pepper (Up to taste). Loominade (talk) 12:11, 9 April 2020 (UTC)

    Vladimir Alexiev
    Tris T7 TT me
      Notified participants of WikiProject Food


    •   Comment @Loominade: in the meantime, there was Wikidata:Property_proposal/descriptive_solubility created as descriptive solubility (P8459). I suppose I'd support this if more likely values were given. --- Jura 10:54, 18 July 2020 (UTC)
      • Jura1 can you please give an example? --Loominade (talk) 07:49, 20 July 2020 (UTC)
        • You just mentioned up to taste (Q89895024) and until cup is full (Q89895393). If there were more, I might support the proposal. See the series of values given for descriptive_solubility for comparison. --- Jura 07:51, 20 July 2020 (UTC)
          • this is everything that i was able to come up with. will need to read some recipes. if you have an idea for a possible value, let me know. --Loominade (talk) 08:03, 20 July 2020 (UTC)
      •   Oppose I tried to think of more values, but all I came up with are qualitative (rather than quantitative) instructions: heat water "until boiling," cook "until golden brown," stir solution "until solute is completely dissolved," mix batter "until smooth," when using shampoo: "repeat as necessary." Perhaps we could broaden the scope of this property to include those, somehow, otherwise there doesn't seem to be enough demand for the proposed quality. You might also want to ping the Chemistry project; they might have suggestions. The-erinaceous-one (talk) 22:15, 13 September 2020 (UTC)

    local timeEdit

       Under discussion
    Representsqualifier for properties that have a date
    Data typeItem
    Allowed valuestime of the day (Q1260524)
    Example 1Valentina Blackhorse (Q92079066) date of death (P570) 23 April 2020 → 22:22 (Q55812761)
    Example 2Barack Obama (Q76) date of birth (P569) 4 August 1961 → 19:24 (Q55812651)
    Example 32019 Whakaari / White Island eruption (Q77929275) point in time (P585) 9 December 2019 → 14:11 (Q55811653)
    Example 4see query for 1100 others
    Planned usereplace refine date (P4241) in
    See alsorefine date (P4241)


    The obituary for Valentina Blackhorse (Q92079066) makes it clear that there is cultural significance given to the time at which this person died. Defining this in Wikidata is not possible at the moment. 1Veertje (talk) 18:03, 16 May 2020 (UTC)


    ah, that works. Thank you. I'll add "local time" as an alias there. 1Veertje (talk) 21:50, 19 May 2020 (UTC)
      Support   Comment To me the qualifier seem valid as people might know the local time but not the whole system that it refers to (Example: UTC time, GPS time, sun time, etc) nor the characteristics (time zone, etc). And I don't see how to do it with refine date (P4241) but I could have missed something. Maybe there is another way to do it but no one suggested it yet and I didn't find any. GNUtoo (talk) 20:02, 20 June 2020 (UTC)
    @GNUtoo: Any time you want can be specified with refine date (P4241) as long as there is an Wikidata item to represent it and you can make a new one if you need one does not already exist. This proposal specifies the same data type Item so it is no different. —Uzume (talk) 02:00, 12 December 2020 (UTC)
    @Uzume: Do you have any examples that are already using refine date (P4241)? GNUtoo (talk) 17:57, 11 January 2021 (UTC)
    @GNUtoo: How about the examples from above: Q92079066#P570, Q76#P569, Q77929275#P585? You will notice refine date (P4241) is specifically allowed as an allowed qualifiers constraint (Q21510851) on many if not most of the properties with a Point in time entity type (see Special:ListProperties/time): Property:P39#P2302, Property:P108#P2302, Property:P569#P2302, Property:P570#P2302, Property:P571#P2302, Property:P577#P2302, Property:P582#P2302, Property:P1636#P2302, Property:P2031#P2302, Property:P2032#P2302, and some Quantity ones too: Property:P2196#P2302, Property:P2402#P2302, Property:P2437#P2302. And that is just a quick list I threw together and is certainly not complete. —Uzume (talk) 19:51, 11 January 2021 (UTC)
    Thanks. So practically speaking to do a 100% functional equivalent of "local time" you need to add a time to some time property, like date of birth (P569) → 01/01/2001 and add refine date (P4241)local time (Q3883775) as qualifier? If that's the case, I've another question: As the depth of qualifiers is limited (you can't have an infinite depth of qualifiers on qualifiers on qualifiers, etc) are there cases where something like date of birth (P569) → 01/01/2001 + refine date (P4241)local time (Q3883775) doesn't work and a local time qualifier is really needed? GNUtoo (talk) 20:31, 12 January 2021 (UTC)
    @GNUtoo: I honestly cannot say I understand what you are asking. As for the "depth of qualifiers" goes there is no such thing. Wikibase entities like items and properties can have an arbitrary number of statements making claims using properties (including multiple with the same properties). Each statement can further have an arbitrary number of qualifiers but qualifiers do not have any qualifiers themselves (so does that make the effective "depth" one?). In addition each statement can have an arbitrary number of references where each reference is a collection of an arbitrary number of property-value entries. Since there can be be as many claims as needed with as many qualifiers as needed there is no effective limit, save resource limitations (we do not have infinite computing resources so there are always limits there). —Uzume (talk) 17:02, 21 January 2021 (UTC)
    •   Support even if other qualifiers would be needed. --- Jura 16:41, 26 May 2020 (UTC)
      @Jura1: And just how would that be any different from refine date (P4241)? —Uzume (talk) 02:00, 12 December 2020 (UTC)
      • values are a subset and eventually may be converted to the Wikibase time values. Something that isn't possible for almost all other values currently used with P4241. --- Jura 07:55, 12 December 2020 (UTC)
    •   Comment I'll stay in my position: creating a property requires a minimum of 2 examples and the proposal specifies to include 3 examples. (and property creators shouldn't vote for - in that sense IMHO) —Eihel (talk) 09:01, 28 August 2020 (UTC)
    •   Oppose As per GZWDer, this can already be accomplished via refine date (P4241). —Uzume (talk) 02:00, 12 December 2020 (UTC)

    approval of subjectEdit

       Under discussion
    Descriptionused as reference; url of page where the subject of the statement expresses that they want this information to be stored in Wikidata
    Data typeURL
    Example 1MISSING
    Example 2Gereon Kalkuhl (Q64555761) e-mail address (P968) XY (This property as reference)
    Example 3MISSING


    For some privacy relevant statements it's useful to be able to store explicit permission of the subject of an item that we store the information. ChristianKl❫ 12:02, 24 May 2020 (UTC)


    •   Support: sounds indeed useful. Nomen ad hoc (talk) 18:35, 24 May 2020 (UTC).
    •   Comment I agree that this is a worthwhile question, but wonder if this couldn't be accomplished by using the talk page (since such authorization can also, in principle, be retracted). I also wonder if there's any way to have the main label from the item page appear on the talk page (and in watchlists). I've had discussions about whether or not ethnicity/religous tagging is appropriate on en.wp before, and am a bit concerned about the gotcha' logic used to say that "if you complain about being categorized as an X on Wikipedia (religion/ethnicity)" you will be so categorized if you say you are a non-observant X. (cf. this BLP/N thread). SashiRolls (talk) 18:39, 24 May 2020 (UTC)
      • There are two separate issues: (1) What should our Living People-policy be? (2) How should we store information about approval. This discussion is supposed to be about (2). I think I will soon start another RfC to amend the Living People-policy to add another status for cases like phone numbers and email addresses. ChristianKl❫ 19:20, 24 May 2020 (UTC)
        • Yes, in the original discussion you link it was suggested this be done on the talk page. What is the advantage of encoding this as a queryable predicate? Would it be an obligatory qualifier on say, phone number, twitter ID, ethnicity, religion, etc.? And for the larger question, is the permission (whether on the TP or encoded into the predicates of the item) reversible/oversightable? SashiRolls (talk) 19:32, 24 May 2020 (UTC)

    Wildly boy
    ZI Jony
    Ivan A. Krestinin
    Jonathan Groß
    Pablo Busatto
    Thierry Caro
    Tinker Bell
      Notified participants of WikiProject Properties ChristianKl❫ 19:21, 24 May 2020 (UTC)

    I do have a deeper problem: Since Wikidata is in CC-0, the data may be reused by third-party service. I think we should somehow indicate whether the user agree the data to be copied to or reused in arbitrary third-party websites (which also includes those not in good proposes). At least not Evil is not what CC-0 intended.--GZWDer (talk) 19:26, 24 May 2020 (UTC)
    Therefore I think we should have a dedicated system to record consents and non-consents. If someone consents to publish private information they should explicitly agree for any reuse of 3rd-party (and conversely, Wikidata may include private information with a consent in third-party website if such website is endorsed by consensus. But what about conflicting statement, viz. Someone do agree to publish private information in another website but not in Wikidata, and data may be imported from that website to Wikidata.)--GZWDer (talk) 19:33, 24 May 2020 (UTC)
    I won't pretend to understand this, maybe you will (understand it). (prior art?) SashiRolls (talk) 20:56, 24 May 2020 (UTC)
    Second thought: I may support this but I do not think this should be the primary way to register approval or consent. Problems are 1. It is not easy to check whether the approval is authentic and 2. The value may be easily distorted. I think the better approach is signed statements.--GZWDer (talk) 19:40, 25 May 2020 (UTC)

    floor areaEdit

       Under discussion
    Descriptionthe area of the floor of a building
    Data typeQuantity
    Domainarchitectural structure (Q811979)
    Allowed unitssquare metre (Q25343)
    Example 1Q96278337 → 12 square metre (Q25343)
    Example 2Palace of Versailles (Q2946) → 63154 square metre (Q25343) [10]
    Example 3MISSING
    Planned usedescribing lean-tos
    See alsoWikidata:Property_proposal/sleeping_capacity Wikidata:Property_proposal/floor_material


    This is less subjective than sleeping capacity. Maybe this is superfluous when we can add area -> 12m2 -> applies to part -> floor --So9q (talk) 14:56, 14 June 2020 (UTC)

    This is useful when I'm adding campsites with lean-to shelters to describe the shelters floorsize without having to create a new part-of item just for the lean-to only to describe the area of the floor.--So9q (talk) 14:07, 17 June 2020 (UTC)


    It's the same. It's not unhindered floor space, besides unhindered is a hard to define because you can sleep with legs under a table/bench quite easily so I abandoned that and instead model as benched lean-tos. The data consumers will have no way of determining whether you can sleep in the benched lean-to though (short of having an AI a foto from the front).--So9q (talk) 14:11, 17 June 2020 (UTC)
    • For what it's worth, we only have about three items that use "determination method: floor area" (query), so it looks like "area" isn't really being used for this purpose. I would support this if it's clear that it's able to be used for all kinds of floor area, not just the context of sleeping areas in shelters? Andrew Gray (talk) 22:58, 17 June 2020 (UTC)
    • Yes it is for all kinds. --So9q (talk) 21:10, 18 June 2020 (UTC)
    •   Oppose Should we follow the same criteria for every sizing dimension ? For instance, Q12514#P2049 or Q44991996#P2048. I don't think so. Regarding area, you may use Q9188#P2046 formua, too. A good use of qualifiers reduces the number of ultra-specific properties. Amadalvarez (talk) 11:20, 4 September 2020 (UTC)
    •   Support Could give a better discrimination with area (P2046). --Fralambert (talk) 22:10, 26 September 2020 (UTC)

    sorting weightEdit

       Under discussion
    Descriptionwhen listing multiple properties, properties with a higher sorting weight are supposed to be shown before properties with lower sorting weight
    Data typeNumber (not available yet)
    Example 1instance of (P31) → 100000
    Example 2subclass of (P279) → 9999
    Example 3occupation (P106) → 1000


    We have currently multiple cases where properties have to be sorted. When displaying the normal properties and external-id properties on a page they have to be sorted.

    When suggesting properties to the user according to properties for this type (P1963) there's a need for sorting. The proposed property can be used as a qualifer to help sort that list.

    For qualifiers we might have in future a solution that uses sources the suggested qualifiers from qualifier for this property (P8379) where the sort order can also be specified with this property.

    Wildly boy
    ZI Jony
    Ivan A. Krestinin
    Jonathan Groß
    Pablo Busatto
    Thierry Caro
    Tinker Bell
      Notified participants of WikiProject Properties ChristianKl❫ 10:40, 27 June 2020 (UTC)


    •   Support seems reasonable though I guess it can be a bit controversial as to what the right value should be. Iwan.Aucamp (talk) 12:19, 27 June 2020 (UTC)
    • Couldn't we just use MediaWiki:Wikibase-SortedProperties for this? Having two different sorting schemes feels like it's going to get complicated. Andrew Gray (talk) 14:11, 27 June 2020 (UTC)
    • I don't think Wikibase-SortedProperties is a good solution for multiple reasons and that it would be best to deprecate it sooner or later.
    Having the data within properties makes it easier to discover how the sorting works for Wikidata users.
    We will have federated Wikibase properties in the future. Having a concept of sorting weight allows sorting of properties from different Wikibases in a consistent manner without having to define all the sorting in one Wikibase.
    Finally, I want a way that can be set more context dependent on properties for this type (P1963) and qualifier for this property (P8379). ChristianKl❫ 18:08, 27 June 2020 (UTC)
    I think there's an argument to be made for centralised sorting being better - with values on a per-property basis, it's much harder to group similar properties together, ensure they are kept in a consistent order, and so on. It feels to me like it would be more difficult to get a broad overview this way around, though I take your point about federated properties. But to be honest I don't really have a strong opinion, whatever works is fine. :)
    I'm still not clear how this property would work, though - is the idea we create the property now and then develop a sorting mechanism which would use it? Andrew Gray (talk) 18:48, 30 June 2020 (UTC)
    • There is already some sort of "weighted sorting" being done by the Wikibase (?) software when adding properties to items. Does that not suffice? —MisterSynergy (talk) 17:06, 27 June 2020 (UTC)
    The goal is to have a system where it's easier for users to change the sorting oder. ChristianKl❫ 18:09, 27 June 2020 (UTC)
    The community managed approach does not work particularly well with MediaWiki:Wikibase-SortedProperties, as opposed to the built-in suggestion mechanism. As far as I understand, the software sort of anticipates the best order of suggested properties based on the data present in an item. This seems much more sophisticated than a static list, where users might even try to push their favorite properties to the front. —MisterSynergy (talk) 18:56, 27 June 2020 (UTC)
    It feels to me like there's some issue with it being intransparent of how the system actually works. Do you know whether it's documented somehow?
    I think it would be great if it would both be documented and also possible for humans to decide what the best order happens to be. ChristianKl❫ 20:27, 27 June 2020 (UTC)
    It's called property suggester (Q86989962) (related: Extension:PropertySuggester (Q30101250), Extension:WikidataEntitySuggester (Q21679299), Help:Suggesters and selectors#Property suggester, …). You can use these items to search for more documentation on or phabricator—I am not aware whether there is enough of it, however. —MisterSynergy (talk) 20:41, 27 June 2020 (UTC)
    • Is this intended to apply to identifiers too? In general I'd like to see further information about how these priorities should be decided. --99of9 (talk) 02:16, 28 June 2020 (UTC)
    Yes, the idea would be that it can also be used to sort identifiers. ChristianKl❫ 08:55, 30 June 2020 (UTC)
    The idea is to specify semantics about how sorting priorities can be expressed here. Later, when there are disagreements about how to decide the priority in a certain domain we can create policy to solve that. ChristianKl❫ 17:11, 20 November 2020 (UTC)

    booking URLEdit

       Under discussion
    Descriptionofficial URL of the item that allows reservation of a seat, service or ticket related to this item
    Representsbooking (Q64883416)
    Data typeURL
    Example 1Bagatti Valsecchi Museum (Q838986)
    Example 2Cinema Arcobaleno (Q37158251)
    Example 3Principe di Savoia (Q7245128)
    Expected completenessalways incomplete (Q21873886)
    See alsowebsite:booking on OpenStreetMap


    This property could be useful for Wikivoyage so that one could buy tickets or booking a room without looking through the website. If a specific property is already set/could be set (e.g. hotel ID (P3607)), it must be used ★ → Airon 90 07:49, 20 July 2020 (UTC)


    • Mhhh... Isn't it a bit too close to "commercial"/"advertising" ? Bouzinac (talk) 08:30, 20 July 2020 (UTC)
    Airon90 Do not modify the interventions of other contributors, please. —Eihel (talk) 20:01, 28 August 2020 (UTC)
    •   Support. That said, your second example leads me to nowhere and probably needs some fixing. Thierry Caro (talk) 00:30, 21 July 2020 (UTC)
    •   Support Google Maps has this feature. We should have it too. NMaia (talk) 14:17, 22 July 2020 (UTC)
    •   Strong oppose I think this is a bad idea as someone who edits OSM a lot and isn't personally a fan of the website:booking tag or similar website namespace tags. Since booking url's change way to often. Plus, the word "booking" is semi-ambiguous and widely different depending on the culture anyway. Which you really have to watch out for with these types of things. For instance in America we don't really consider buying a ticket to tour an art gallery "booking" something. Whereas, it seems like you do from one of your example links. Also, say you add the property to something like a casino that contains hotel, restaurant, bar, and an event center. It's rather ambiguous as to which one of those the booking url applies to or if it's just the casino. Those kinds of confusions happen all the time in OSM. Which is why the website:booking tag has been around since like 2011, but has never really been adopted. It is kind of commercialish to like Bouzinac said. There's also no end to the possible sub url's once you go there. Everyone knows what an official url is and it's usually pretty easy to get to booking page. So, it's better just to stick to the official url. --Adamant1 (talk) 10:00, 11 August 2020 (UTC)
      • «Since booking url's change way to often». First, citation needed. Second, even official websites change and/or disappear (that is why URL archives exist): should we remove the property official website (P856) because it could change, even «too often»?
      • «Plus, the word "booking" is semi-ambiguous and widely different depending on the culture anyway». I'm Italian and we use the verb "prenotare". If the problem is the label, we can decide which is the best one for this property. You cannot oppose without giving a hint about how to fix this problem.
      • «Also, say you add the property to something like a casino that contains hotel, restaurant, bar, and an event center. It's rather ambiguous as to which one of those the booking url applies to or if it's just the casino» Like in OpenStreetMap you map separately hotel, restaurant, bar and casino, even in Wikidata you create single items which will have their own "booking url"
      • «Everyone knows what an official url is and it's usually pretty easy to get to booking page» Let's delete official blog (P1581), web feed URL (P1019), calendar feed URL (P6818), terms of service URL (P7014), privacy policy URL (P7101) and many other property then. Let's use just official website (P856) and one can get info by looking at the site or its source code.
      --★ → Airon 90 17:22, 28 August 2020 (UTC)
    •   Weak oppose Do Wikidata need to start advertising.? Seems to be not a good idea.-❙❚❚❙❙ GnOeee ❚❙❚❙❙ 14:11, 11 August 2020 (UTC)
    Gnoeee many Wikivoyage already have contact details of this type, IMHO. —Eihel (talk) 10:04, 28 August 2020 (UTC)
    •   Weak support as we have a property for the other url, it might be worth having a generic one. --- Jura 16:33, 16 August 2020 (UTC)
      • Not really a priority for the project. --- Jura 06:01, 4 September 2020 (UTC)
    The proponent finds my changes adequate, but does not change the proposal. In addition, the fields are not filled to the best. I change my opinion. —Eihel (talk) 20:14, 28 August 2020 (UTC)
    @Eihel: I said "When I have spare time I will look for another example in order to replace the first one". Now I had spare time before working again and I found another example to replace the first one.
    What do you mean with "the fields are not filled to the best" and why don't you propose a change? We are working together for Wikidata, not judging one's work in an eternal competition :) I hope you will help me in fill the fields to the best and change your mind again --★ → Airon 90 07:10, 29 August 2020 (UTC)

    @Airon90, Thierry Caro, NMaia:

    •   Question Should the label include "official", possibly with a single value constraint? Or should we allow ticket resellers and scalpers? --- Jura 21:46, 28 August 2020 (UTC)
    @Jura1: For sure this proposal is about the *official* booking URL. I am not sure about single value constraint (I don't like generalizations), maybe we can set this constraint and work on eventual errors. --★ → Airon 90 07:10, 29 August 2020 (UTC)
    • Can we add something in the description so that we only end up the organizer's or accommodation's booking system in the property and not every website that allows to book rooms in a given hotel or anybody that resells tickets they just siffoned out of the main url. --- Jura 10:32, 29 August 2020 (UTC)
    @Jura1: I tried my best by putting "Official" in the sentence. If somebody wants to rephrase the description in order to better transmit the meaning of the proposal is welcome! --★ → Airon 90 12:49, 3 September 2020 (UTC)
    Ok. I changed it slightly. --- Jura 15:55, 3 September 2020 (UTC)

    certified asEdit

       Under discussion
    Descriptionstates that an item has a certain certification
    Representscertification (Q374814)
    Data typeItem
    Allowed valuesany instance of certification (Q374814) or its subclasses
    Example 1Kastel Koz (Q97716007)Grand site de France (Q1154112)
    Example 2Bill Gates (Q5284)Microsoft Certified Professional (Q1072814)
    Example 3Klaus Gablenz (Q1744899)Project Management Professional (Q1192593)
    Planned useI plan to assign it to some items, but I am suggesting it primarily because of its general value
    Expected completenessno
    See alsoapproved by (P790), relevant qualification (P4968), award received (P166)


    I believe this property is missing. There's a number of certifications available on Wikidata, but currently I cannot see how to link any objects that bear this certification. approved by (P790) is the nearest I could find, but I think it's not quite suitable. Suggested English alias: "has certification" If I am overseeing something, please let me know. (Also, I am not quite sure how reference/subject item is meant in this template. Hope I got it right.) -- H005 (talk) 11:42, 27 July 2020 (UTC)


    How does this relate to relevant qualification (P4968)? ChristianKl❫ 11:06, 31 July 2020 (UTC)

    Thanks for pointing that out, I didn't know about this property. However, I do not think it fits the purpose, as its object is restricted to industries/professions/people - a certification can be applied to anything - and its subject is a profession/skill, and not restricted to certifications. Also, it doesn't really state that someone/-thing has this qualification, it merely states that this is relevant to the object. -- H005 (talk) 08:07, 2 August 2020 (UTC)

    I'd appreciate any further comments/votes. -- H005 (talk) 09:15, 10 August 2020 (UTC)

    would it not make sense to have a property "has certificaction" and then a link to the certification item? BrokenSegue (talk) 23:37, 7 September 2020 (UTC)

    Well, that is actually the proposal, just that you are suggesting a different name. Both names would be fine to me. -- H005 (talk) 10:17, 8 September 2020 (UTC)
    •   Support --Tinker Bell 01:40, 17 September 2020 (UTC)
    • Not ready. BrokenSegue suggested "has certification" and I don't see that this has been rejected the property is ready to be created as "certified as". ChristianKl❫ 19:12, 8 November 2020 (UTC)

    Signal numberEdit

       Under discussion
    Descriptionphone number for this person or organization used by the Signal app for secure communications
    RepresentsSignal (Q19718090)
    Data typeExternal identifier
    Allowed values\d{10}
    Example 1Ken Klippenstein (Q97940221)tel:2025101268
    Example 2Micah Lee (Q15834986)tel:4159420460
    Example 3Muck Rack (Q57500196)tel:2125001883
    Planned useUse it on Ken Klippenstein (Q97940221)
    See alsophone number (P1329), fax number (P2900), TDD number (P8659)


    Ken Klippenstein offers up his Signal number for submitting tips and leaks, so I wanted to add it to his Wikidata item somehow. QRep2020 (talk) 06:26, 31 July 2020 (UTC)

    edit: The larger motivation here is that we should take advantage of the Wikidata knowledge graph to propagate the means of interacting with journalists, activists, etc. in a safe, end-to-end encrypted fashion. The graph already lists, for instance, the NY Times, yet it does not state how to contact the paper if one wishes to do so securely and secretively. Someone like Ken Klippenstein is urging whistleblowers and the like to reach out to him if they have information the public ought to know and so I think adding a property for editors to use to facilitate such efforts is a small price to pay for a positive social impact at large. QRep2020 (talk) 01:55, 12 October 2020 (UTC)


    •   Comment You should link the examples to Wikidata items that you propose they are for. See other property proposals for how to do this. ArthurPSmith (talk) 17:04, 31 July 2020 (UTC)
    •   Comment @ArthurPSmith, QRep2020: I've fixed some things in the proposal. Also, I think the right datatype is URI, not external identifier. --Tinker Bell 01:37, 3 August 2020 (UTC)
      •   Comment I've read some articles that suggested a person could get a Signal number without using an actual phone number so I was not sure how to classify. In any case, thank you to everyone for helping me with this as it is my first Wikidata property suggestion! QRep2020 (talk) 03:47, 3 August 2020 (UTC)
    •   Question Do we have that many Signal users among our entries? --NMaia (talk) 09:47, 1 September 2020 (UTC)
    •   Comment Any other thoughts or questions? I really think adding this property would contribute to the service. QRep2020 (talk) 17:44, 18 November 2020 (UTC)
      •   Support Listing contact addresses of individual people on Wikidata is complicated from a privacy perspective but not any different then phone numbers that we are already storing. ChristianKl❫ 13:47, 1 December 2020 (UTC)
    •   Oppose I do not see a good reason for this. Why not just use the existing properties and some qualifiers, e.g., either phone number (P1329) or streaming media URL (P963) (with RFC 3966: The tel URI for Telephone Numbers (Q47467363) Uniform Resource Identifier scheme (Q37071)) and qualifier of (P642) Signal (Q19718090)Uzume (talk) 02:53, 12 December 2020 (UTC)
      •   Comment Please entertain the following reasons, Uzume and others: There is a separate Property for a fax number (fax number (P2900)) from the one for a telephone number (phone number (P1329)) which suggests there is already a point to distinguishing in Wikidata how different telephone "lines" function. Additionally, organizations often list their Signal numbers as is without qualifying them as also being telephone numbers of theirs, e.g. Finally, I'd argue the qualifier route allows data extractors, everyone from scrapers to Google itself, to easily ignore such a "this is for Signal" note and therefore promotes the possibility of the number appearing elsewhere qua a regular telephone number when perhaps its owner only ever uses the number for Signal messaging and nothing else (perhaps via the method explored at QRep2020 (talk) 04:34, 19 December 2020 (UTC)


       Under discussion
    Descriptiontranscription of text from an advertisement
    Data typeMonolingual text
    Example 1Heresies 4 Gaysweek advertisement URI (ex.$127/178,50,1044,859/full/0/default.jpg) has copy "No excuses. No apologies. No compromises. Quite simply a real honest-to-God newspaper. Gaysweek."
    Example 2Heresies 6 Feminist Studies advertisement URI (ex.$119/214,1865,2090,1204/full/0/default.jpg) has copy "For information about submitting manuscripts or artwork for publication, write to the managing editor"
    Example 3Heresies 6 DYKE A Quarterly advertisement URI (ex.$120/230,2209,1148,871/full/0/default.jpg) has copy "A Magazine of Lesbian Culture and Politics Featuring Essays, Analysis and Interviews"
    Example 4Heresies 6 Gibbous RISING advertisement URI (ex.$125/894,2319,696,784/full/0/default.jpg) has copy "Gibbous RISING is not only the description of a partial moon becoming whole, but signifies the growth of women and the rising recognition of feminism and liberation."
    Planned useWe intend to use this property as part of our work with FemNet to represent advertisement copy (from the feminist publication Heresies ( in our linked data triples.
    See alsocatchphrase (P6251), motto text (P1451)


    My name is Joel. (This is my first time editing or proposing anything to Wikidata!) I am a research assistant with the FemNet project at the University of Alberta in Edmonton, Alberta, Canada. The goal of this project is to eventually represent all the advertisements from the feminist publication Heresies in linked data triples. In doing preliminary triple writing we are currently using as many Wikidata properties as possible in our data.

    One case, however, for which we could not find a suitable property in Wikidata was for "advertisement copy" - that is, advertisement text usually in the form of an advertising publication's self-description or solicitation to a prospective subscriber/reader. My proposal above attempts to demonstrate how we would like to use this property. As can be seen, the value of this property would essentially be the advertisement copy as a string literal; I hope that "monolingual text" was the right choice for this use case. (If someone reviewing this proposal can think of an alternate way that our project could represent advertisement copy using preexisting properties in Wikidata, we would also be open to that.)

    Thank-you, Jblech (talk) 17:58, 2 August 2020 (UTC)


    Valentina.Anitnelav Thierry Caro Shisma (talk) Arlo Barnes (talk) Tsaorin (talk) 16:37, 12 November 2019 (UTC) Nomen ad hoc   Notified participants of WikiProject Narration

    •   Comment this looks interesting, it seems like we already have motto text (P1451), motto (P1546) and catchphrase (P6251). I wonder whether it would make sense to adopt one of these? I see that none of them really match what you want to do since an advertisement slogan isnt really a motto and isnt really a catchphrase. However, given that catchphrase (P6251) only has 300 uses, it seems like a potential idea to extend this -- especially since it seems difficult to distinguish between "advertisement" and simply "well known for" and probably these instances often overlap. --Hannes Röst (talk) 14:34, 6 August 2020 (UTC)
    Ex 1) <Heresies 4 Gaysweek advertisement> <catchphrase (P6251)> <No excuses. No apologies. No compromises. Quite simply a real honest-to-God newspaper.>
    However, most of what we’re trying to capture do not work with the “catchphrase” property. A much greater number of our advertisements simply describe the things they are advertising, and so are not best captured with the predicates motto text (P1451) or catchphrase (P6251). In the example #2 in our original proposal, for instance, we use the proposed “advertisement copy” as a way to describe the following phrase, found in an advertisement for the periodical Feminist Studies: “For information about submitting manuscripts or artwork for publication, write to the managing editor." This is neither a motto nor a catchphrase.
    Here are another couple of examples:
    Ex 2) <Heresies 4 Gaysweek advertisement> <Advertisement Copy> <Gaysweek is mailed in an envelope. Our subscription list is confidential. The list is not sold, rented, traded or released to anyone at any time.>
    Ex 3) <Heresies 6 Frontiers advertisement> <Advertisement Copy> <Frontiers is published three times a year by a collective of women in association with the women studies program at the University of Colorado. For the past two years we have produced a journal which integrates the best of academic work with more popular writing.>
    We thought about proposing a property that would have much broader use like “description,” but we think this would actually be too broad, and probably not particularly useful as a property. “Advertisement copy,” as we’ve proposed it, would be a way to describe phrases, descriptions, and text that may not be commonly used (and so not a catchphrase (P6251)) and that might not be a motivation or a sentence associated with the artifact being advertised (and so not a motto text (P1451)).
    Note that the objects here (“Gaysweek is mailed in an envelope…” in Ex 2; or “Frontiers is published three times a year…” in Ex 3) are string literals.
    --Jblech (talk) 21:39, 10 November 2020 (UTC)
    •   Comment Do users have any further thoughts on what we have proposed above?
    --Jblech (talk) 17:19, 1 December 2020 (UTC)
    •   Comment I wonder if it might make more sense to have a property that's a sort of variant of published in (P1433), being 'advertised in the publication' that could be applied to the product or organisation described by the ad, with quotation or excerpt (P7081) or quotation (P1683) as a reference or qualifier. But it all depends on the desired data model. Tangent, but does FemNet have a Wikidata item? If so, you could link a Wikiproject to that to track progress on the items/properties you are interested in. Arlo Barnes (talk) 23:35, 6 August 2020 (UTC)
    •   Comment Thanks so much for this response as well. We will definitely consider creating a Wikidata Item for our project! With regards to quotation or excerpt (P7081) and published in (P1433), however, they are not appropriate to the problem we’re facing here, which is to find ways to describe text in an advertisement. In some cases, the advertisement copy that we want to describe is in fact a quotation, in which case we use quotation or excerpt (P7081). For instance, an endorsement of a magazine is treated as a quotation.
    published in (P1433) is helpful for thinking about the relationship between an advertisement and a magazine. Excerpt is an interesting possibility, though our goal is not to select an excerpt from the advertisement, but rather to represent the text that an advertiser decided to use to describe their product. For these reasons, quotation or excerpt (P7081) and published in (P1433) don’t quite describe what we’re going for.
    --Jblech (talk) 21:39, 10 November 2020 (UTC)
    •   Comment Do users have any further thoughts on what we have proposed above?
    --Jblech (talk) 17:19, 1 December 2020 (UTC)
    •   Comment Thanks so much for this response, too. Wikidata defines inscription (P1684) as “inscriptions, markings and signatures on an object.” This does not capture the specific “thing” that we identify here, which is text that is part of an advertisement.
    --Jblech (talk) 21:39, 10 November 2020 (UTC)
    I do see a point in extending the definition and scope of inscription (P1684) a bit, to encompass (short) transcripts of texts in documents and on objects in general. Then it would be possible to model your examples for instance as follows (or similar - we can be flexible in constructing this):
    inscription (P1684)
      No excuses. No apologies. No compromises. Quite simply a real honest-to-God newspaper. Gaysweek. (English)
    object has role (new Wikidata item to be created for the concept 'advertisement copy')
    1 reference

    add value
    What do you think of such an approach? If such a type of construct would not work, could you explain why? Thanks :-) Spinster 💬 10:35, 5 January 2021 (UTC)
    •   Comment Do users have any further thoughts on what we have proposed above?
    --Jblech (talk) 17:19, 1 December 2020 (UTC)
    • When it comes to examples it would be good to refer to actual items where the properties would be used.
    It's worth nothing that plenty of data within Wikidata isn't triples but higher dimensional (it has qualifiers and references). ChristianKl❫ 14:12, 10 August 2020 (UTC)
    •   Question @Jblech: I heard about your property proposal because I'm an advisor to the LINCS project, which this proposal is related to, if I'm not mistaken. In order to help the community decide on this property proposal, would you be willing and able to give a bit more context? What kind of data would you plan to import to Wikidata and why? Why would you like that data (including the advertisement copy you mention in the property proposal) to live on Wikidata? Would the data be stored elsewhere too, and if so, where? Thanks :-) Spinster 💬 10:14, 5 January 2021 (UTC)

    image of entranceEdit

       Under discussion
    Descriptionimage of the access point of an architectural structure, vehicle, territorial entity, road or other space
    Representsentrance (Q1137365)
    Data typeCommons media file
    Domainarchitectural structure (Q811979), vehicle (Q42889), road (Q34442), street (Q79007), designation for an administrative territorial entity (Q15617994)
    Allowed values(?i).+\.(jpg|jpeg|png|svg|tif|tiff|gif|xcf)|
    Example 1Notre-Dame de Paris (Q2981) 
    Example 2Père Lachaise Cemetery (Q311) 
    Example 3Red Square (Q41116) 
    Example 4Great Pyramid of Giza (Q37200) 
    Example 5Dōtō Expressway (Q867944) 
    Example 6Tesla Model S (Q1463050) 
    Example 7Bombardier Regio 2N (Q572856)   
    Example 8California (Q99) 
    Example 9Naucelle (Q1141399) 
    Example 10
    Planned uselink all the already existing images with the corresponding items and maybe create a parameter for the Infoboxes on Commons
    Expected completenessalways incomplete (Q21873886)
    See alsoimage of interior (P5775)


    We already have properties for different types of images such as image of interior (P5775), that is similar to this proposal. This property, on the other hand, could be used both for enclosed spaces and open spaces. In addition, many access points to certain buildings are quite notable and this could also be used for an image of the entrance to a city for example. Bringing this together with image (P18) and qualifiers is not the best solution since an entrance is not really a general representation of an item and a separate property would be very useful and suitable, while not being totally restricted. Moreover, it would let us add multiple images if several entrances exist and add a qualifier for the Commons category which refers to the entrance. Baidax (talk) 17:27, 4 August 2020 (UTC)


    1.   Support Pamputt (talk) 17:43, 10 August 2020 (UTC)
    Yes, there are border crossings and even US states often have a sign "Welcome to California" (I guess that qualifies as entrance ?). --Hannes Röst (talk) 14:52, 11 August 2020 (UTC)
    I added two examples concerning administrative territorial entity (Q56061). I was indeed thinking of photos of roads with an entrance sign. However, this should not be confused with place name sign (P1766) which only represents the sign and not the image of the border with a general view (ideally). Baidax (talk) 11:43, 15 August 2020 (UTC)
    Unless there is a border control, you can really enter an administrative territorial entity anywhere. Adding the road is a car-centric bias. Perhaps another subproperty called image of car entrance? Ainali (talk) 11:56, 15 August 2020 (UTC)
    @Ainali: Indeed, I imagine this for cases where there is an entrance visible with a sign, a border control or a city gate (Q82117). Regarding the different entrances, the type can be specified and for the roads we can use applies to part (P518) road transport (Q516739) without having to create a subproperty. I also changed the example of the border on the ground to avoid ambiguities. The latest examples don't question everything else: I put them only for the purpose of expanding the use of the property to the most global level possible. If they are really that ambiguous, they can be removed to leave only those of buildings and objects. Baidax (talk) 01:30, 17 September 2020 (UTC)
    •   Comment Regarding the regexp, shouldn't all allowed bitmap files on Commons be included? Ainali (talk) 19:07, 10 August 2020 (UTC)
    Indeed, the expression included all files but didn't appear correctly, the string that appeared was not even correct. I added a <nowiki> tag. Thank you for pointing it out! Baidax (talk) 11:15, 15 August 2020 (UTC)
    •   Comment the entrance from the inside sample seems a bit odd Bombardier Regio 2N (Q572856)  --- Jura 20:53, 10 August 2020 (UTC)
      • Maybe that could go for an "image of exit" property. @Baidax: can we remove it? --- Jura 06:08, 13 August 2020 (UTC)
    In reality, this is more of a property for the access point. I chose a more meaningful name because most of the access points are the same for entrances and exits or if we take the example of museums, this can often be changed. I think it is simply possible to add multiple values and to specify if needed with qualifiers. In addition, the case you are talking about simply concerns the back of the same access point, a similar case that exists for the Père Lachaise Cemetery (Q311) that I have used as an example. But if you find it relevant, could you provide specific examples please? Baidax (talk) 13:15, 15 August 2020 (UTC)
    I liked the idea of a view of the entry. It makes it easier for visitors to look for them. I'm not sure if mixing it with the "exit" (in the same property) would be good. You probably don't want too many values with the same property. For Père Lachaise Cemetery (Q311), File:Père-Lachaise - entrée principale 02.jpg suggests that your sample is fine. Maybe a gallery would make the samples easier to read. (sample). I'm less convinced by File:Baarle Street Border.jpg in either case. --- Jura 13:27, 15 August 2020 (UTC)
    I agree, this is semantically an exit and as long as the property is called image of entrance I will   Oppose until this example is removed. Ainali (talk) 08:08, 14 February 2021 (UTC)
    •   Comment I suppose I'd support if this was limited to images that someone resemble an entrance, notably not: images of the entrance in the exit direction (A), mere border markings (B). --- Jura 11:36, 5 September 2020 (UTC)
    @Jura1: I changed the last image which was a bit ambiguous. Did you know that an entrance can also be used as an exit? (File:Cimetière du Père Lachaise entrée principale (vue ext.).jpg shows the same gate but from the other side) In fact, I should have called the proposal "image of an access point" so it would clearly indicate that it can be used for entrance and exit. I have provided two examples for a single item but a single value may be enough although two values may also be possible for some cases where it is relevant. The principle should mainly apply to buildings, anyway. I tried here to vary the examples to show the level of possible use. Should I rename the proposal somehow? Baidax (talk) 01:47, 17 September 2020 (UTC)
    I think the label should be somehow consistent with the images. If you want entrances, it's currently fine. If you are looking for entrances and exits, it might need a different one. The later would probably increase the number of values further, which somehow makes it less useful as a property for Wikidata. --- Jura 07:59, 22 September 2020 (UTC)
    •   Weak support why not. That said, I think that ideally we should only use image (P18) with qualifiers and/or Commons data ; but this ship has sailed a long time ago (we now have hundreds of specific properties "image of" the flag, the coats of arms, the logo, the seal, in winter, by night, and so on) so there is no reason to deny this specific proposal. Cheers, VIGNERON (talk) 10:49, 6 October 2020 (UTC)
    •   Question @Baidax, Pamputt, Ainali, Hannes Röst, Jura1, VIGNERON: Since August 2020, where are we? This proposal seems to result in a creation. Is type constraint necessary? RegEx could be (?i:.+\.(jpg|jpeg|png|svg|tif|tiff|gif|xcf)). Creation or closure?    Eihel (talk) 02:37, 14 February 2021 (UTC)
      • @Eihel: we probably should ask for more point of view on the Wikidata:Project chat. Cheers, VIGNERON (talk) 09:46, 14 February 2021 (UTC)
      • Despite the outline of ways to address the problems with the proposal, it hasn't really advanced. As there doesn't seem to be much support in its present form (wordy or not, supports seem to be limited to mere votes as they don't address any of the concerns), I suppose a property creator would close it as stale. Maybe all the better, as a sign "you are leaving Florida" as "image of entrance" for Florida would make Wikidata look odd. --- Jura 19:43, 14 February 2021 (UTC)
      • @Eihel: I am in priciple supportive of a property like this, but as long as it also includes exits (like this proposal currently does) I'm opposed. Ainali (talk) 18:21, 21 February 2021 (UTC)
    •   Support, an important property for illustrating.--Arbnos (talk) 14:35, 21 February 2021 (UTC)
      • @Arbnos: what's your view on the images of exits? --- Jura 15:11, 21 February 2021 (UTC)

    is/has been in war withEdit


    To make possible to directly query which country is experiencing existing or old wars. Bouzinac (talk) 16:09, 6 August 2020 (UTC)


      Comment I like the idea of being able to query for this. But wouldn't it be better to improve the modelling of the war items instead? Country items are already notoriously cluttered and this would add dozens of statements to those. Belteshassar (talk) 20:18, 7 August 2020 (UTC)

    Well, the current existing countries / regimes are much big, true, but they have had few wars, or be them countable on fingers of a hand :) French Fifth Republic (Q200686) has only had fought (to my knowledge) two wars : Algerian War of Independence (Q200790) and Gulf War (Q37643). Bouzinac (talk) 06:02, 8 August 2020 (UTC)
    I was thinking of Sweden (Q34) and Denmark (Q35), but I now realize that they are very much outliers Belteshassar (talk) 15:44, 8 August 2020 (UTC)
      Strong oppose Belteshassar is right that this would add many statements to country items. Looking at the list of wars the USA has fought, there are dozens of wars and many of the wars have multiple opponents. Additionally, since many wars involve more than two countries, using the proposed property would lead to an extreme amount of redundancy as each combatant would need to be duplicated for each country on the opposing side. If four countries are allied against three countries, then this property would require 24 statements (4x3+4x3), whereas putting this information all on one page should only need seven statements. — The Erinaceous One 🦔 04:37, 23 September 2020 (UTC)
    SELECT ?item ?itemLabel 
      ?item wdt:P31/wdt:P279* wd:Q198.
      ?item wdt:P710 wd:Q986.
      SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }

    Try it!

    Also I think each war should be able to get its own item so I think listing them on the country page does not really help, it actually makes it more difficult to maintain since somebody may forget to add it to the country page. Overall we are talking about 3799 entries (as of yet) that need to be kept up to date with the entries of instance war. However, in this case where the data is already modelled and present in the database, adding inverse properties is really more convenience and does not help much in terms of modelling, but it leads to a lot of maintenance effort without really providing anything of use. And yes, some countries have a lot of wars, eg. with Ottoman Empire (Q12560) 70 followed by United States of America (Q30) with 61 -- you need a lot of fingers on your hand for that (see ). --Hannes Röst (talk) 16:29, 17 August 2020 (UTC)

    Hi Hannes Röst (talkcontribslogs), well, has it that there would have been 119 conflicts involving the USA. So OK, my argument, the one stating there would be few statements, was surely a bit thoughtless. But I still think that property would be useful because with your sparql example, you cannot clearly state if Eritrea (Q986) is ongoing a war or not, without a very complicated sparql query. Shouldn't wikidata be simple to query, even if it takes a bit of maintenance. There is not so much war that have been fought between states. That Quora] replies there would have been a total of 10,000 wars in the whole history. It's quite a big number but Wikidata can handle that, I'm sure. There are many list of wars in wikidata that would help populate that property. Bouzinac (talk) 19:20, 17 August 2020 (UTC)
    I think its actually very easy and I am happy to help you look for that since you can look for a property
    SELECT ?item ?itemLabel 
      ?item wdt:P31/wdt:P279* wd:Q198.
      ?item wdt:P710 wd:Q30.
      FILTER NOT EXISTS { ?item wdt:P582 ?endtime}
      SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
    Try it!
    while in your proposal you would have to look for a qualifier which is actually harder to do in SPARQL. The query above shows 4 ongoing wars for the USA (one is a false positive), but also highlights the dangers of duplicating data as you suggest: it will be very easy for a war using your new property to not have an end time (P582) but have it in the item or the other way around -- data consistency suffers from duplication. I agree that Wikidata can handle to enter the data twice, but the danger is that it takes humans to maintain these entries. Secondly, I think wars are so important that they should be their own item and not properties. --Hannes Röst (talk) 00:56, 18 August 2020 (UTC)
    @Hannes Röst: One thing I struggle with currently is how to model if countries were adversaries or allies in a war. Take Six-Day War (Q49077) as an example, How do I express that Israel (Q801) was at war with Egypt (Q79), but Egypt (Q79) was not at war with Jordan (Q810)? Belteshassar (talk) 06:02, 18 August 2020 (UTC)
    @Belteshassar: very good point, this is currently lacking. I see two solutions here: if its a "normal" war with 2 sides then we could simply use something more descriptive than participant (P710) with a list of countries, either there is a new property for this or we use qualifiers. In this case we could for example group the participants as such: Six-Day War (Q49077) participant (P710) Israel (Q801) / series ordinal (P1545) "1", Six-Day War (Q49077) participant (P710) Egypt (Q79) / series ordinal (P1545) "2", Six-Day War (Q49077) participant (P710) Jordan (Q810) / series ordinal (P1545) "2" and maybe we can come up with a better property than series ordinal (P1545) (maybe "allied faction"). That seems to work for wars with N faction where each faction is behaving the same way. Maybe there are more complex cases where country A in faction 1 is at war with country B in faction 2 but not country C in faction 2? In that case you would need proper modelling of bilateral behaviour and then you probably need a property as described above. For example, there were 3 days when the US was at war with Japan but not Germany and Italy (see and so to properly model that you would need bilateral modelling, I agree. This is a good point and if the intent is to model on this level of detail I am happy to remove my objection. --Hannes Röst (talk) 14:15, 18 August 2020 (UTC)
    Hi all, happy to have started an interesting topic. What about modelling Kingdom of Italy (Q172579)+Finland (Q33) in the context of World War II (Q362)? It was first against Allies of the Second World War (Q329888) and then fought with Allies of the Second World War (Q329888). Simply having participant (P710) might be not enough specific to help describe which country was at war with which country.
    Another example is this list : there is countries that are "technically" currently ongoing a war : they did not formalize a peace truce/treaty. Bouzinac (talk) 20:34, 18 August 2020 (UTC)
    I think that the property needs some modification to really model what we want, but we are moving in the right direction. I think with my proposal we could still model Kingdom of Italy (Q172579)+Finland (Q33) for example: World War II (Q362) participant (P710) Finland (Q33) / series ordinal (P1545) "1" / start time (P580) "start" using start time (P580) and end time (P582) for the time it was in faction 1 and then World War II (Q362) participant (P710) Finland (Q33) / series ordinal (P1545) "2" / start time (P580) "start" using start time (P580) and end time (P582) for the time it was in faction 2. So it would be possible. However, I had another idea: we can use existing items of the type Egypt–Jordan relations (Q21686822) and Egypt–Israel relations (Q574821) to model wars. It seems like the actual correct place for a m:n relationship to me and being at war is a type of diplomatic relation between two countries. I have tried this here: and here
    Secondly, I realized that there are actually 2 distinct concepts: (i) the diplomatic state between two countries (when they did declare war against each other and when they signed a peace treaty / armistice), (ii) participation in actual campaigns where they fought against other countries in a coalition with allies and adversaries. those may not overlap as Bouzinac has shown. In the case of Egypt-Israel it seems that the state of war existed from 1948 to 1979 while during that time they fought multiple wars. So the state of war/peace should be distinct from any particular war they fought in (and we should model both). So I think we could model this as Egypt–Israel relations (Q574821) significant event (P793) State of war (Q942343) but it would be better to have a new property instead of significant event (P793) whould would apply to instances of bilateral relation (Q15221623)} and would be called "state of bilateral relationship" with a few allowed instances (armistice, peace, war etc) and qualifiers could be used. On top of that we can model participation in *specific* wars through Egypt–Israel relations (Q574821) significant event (P793) Yom Kippur War (Q49100) and use qualifiers for that. Unfortunately there would be some duplication with whatever is in the war item Yom Kippur War (Q49100) so we need to make sure that this is consistent. Any thoughts? @Bouzinac, Belteshassar: --Hannes Röst (talk) 14:23, 20 August 2020 (UTC)
    Property populationEdit

    I would perhaps use this dataset to help populate that property, if this creation is accepted. (not sure yet about the copyright issue). Bouzinac (talk) 12:39, 19 August 2020 (UTC)

    •   Oppose We already have enough properties that get used on countries so that the loading time is often inhibited. The information can be well stored in items about the individual wars. ChristianKl❫ 15:56, 24 August 2020 (UTC)
    I don't agree with your arguments. The size / load issue should not be used as an argument to deny eligibility for a property (= do you mean you wish to ban new properties usable on countries items?) Bouzinac (talk) 19:31, 24 August 2020 (UTC)
    I don't think that we should create properties to store information that can easily stored outside of country items in country items. ChristianKl❫ 20:53, 24 August 2020 (UTC)
    I agree especially since we already have items for all / most bilateral relations. --Hannes Röst (talk) 18:01, 3 September 2020 (UTC)
    As I pointed out above some countries have more than 60/70 wars of which each one has presumeably one or more participant, so we are easily talking about adding hundreds of elements to some items. --Hannes Röst (talk) 18:02, 3 September 2020 (UTC)
    • I can understand your oppositions. I just find it a (small) shame because, for a said country X, it's different between querying whom has been in war with X // and reading in the Q of X whom has he been in war with. Query has the drawback of relying on data quality of many war and just looking to this query, supposed to give all current war, gives way much false positives. Whatever. Bouzinac💬✒️💛 19:27, 23 September 2020 (UTC)

    Editio PrincepsEdit

       Under discussion
    Descriptionused for the date that a manuscript was first edited and published in a scholarly publication
    Representseditio princeps (Q1249682)
    Data typePoint in time
    Example 1Carmina Burana (Q253716) → the editio princeps would have its own Q-number and could be linked with Bibliothek des Litterarischen Vereins in Stuttgart (Q856542) with the more specific reference "Carmina Burana. Lateinische und deutsche Lieder und Gedichte einer Handschrift des XIII. Jahrhunderts aus Benedictbeuern auf der k. Bibliothek zu München", ed. by J. A. S. [i. e. Johann Andreas Schmeller], in: Bibliothek des literarischen Vereins in Stuttgart XVI, 1, Stuttgart 1847.
    Example 2Florentine Codex (Q1106019) (this item is technically not a manuscript--the manuscript and editio princeps have been confused)
    Example 3P. Hamb. bil. 1 (Q18086975) (this has publication times of 1936 and 1989, which confuses the production of the papyrus with the subsequent editio princeps and then subsequent scholarly edit)
    Planned useI would like to include the Dura Europos papyrus collection, specifying date of creation as well as date of Editio princeps.
    See alsoyear of taxon publication (P574)


    I am just querying examples of manuscripts and their dates of publication and I see that the property of publication publication date (P577) is being used inconsistently for the date that the manuscript was created by a scribe and the date for when it was first edited and published in print. So there are plenty of ancient manuscripts that are coming up as being published in 1800BCE and others coming up in the 1990s. The later dates obviously refer to scholarly editions of the manuscript. I wonder if it would be helpful to disambiguate these two types of publication: publication date (P577) for initial creation/release/publication and a new property (Editio princeps) for when the work was first published by an editor.  – The preceding unsigned comment was added by Valeriummaximum (talk • contribs) at 12:50, August 9, 2020‎ (UTC).


    •   Comment I think the idea is not bad, but the Data Type is wrong. It should be an item for said scholarly publication. Circeus (talk) 12:46, 12 August 2020 (UTC)
      • I absolutely see your point. I suppose wiki editors can already use P747 for subsequent publications and editions. But I still think we need a property to distinguish the date for the production of the original item and the date for the editio princeps of it, because editors are using publication date inconsistently.Valeriummaximum (talk) 21:19, 13 August 2020 (UTC)
      Comment I agree there is a confusion between editio princeps (Q1249682) (describing the publication, not the year) and a property like year of taxon publication (P574) - basically what you are looking for is year of taxon publication (P574) for manuscripts, correct? In that case, why not expand the definition of year of taxon publication (P574) or create a parent property "described in year" which year of taxon publication (P574) is a subproperty? Actually now that I think about it, I would suggest to increase the scope of year of taxon publication (P574) (assuming taxonomy people are ok with this) or create a parent property for year of taxon publication (P574) and at the same time create a new property for first description (Q1361864) / editio princeps (Q1249682). --Hannes Röst (talk) 00:48, 18 August 2020 (UTC)
    •   Support, an important property for books.--Arbnos (talk) 14:51, 21 February 2021 (UTC)

    type of archaeological siteEdit

       Under discussion
    Descriptiontype of archaeological sites
    Representsarchaeological site (Q839954)
    Data typeItem
    DomainArchaeological sites like Q12907041 and Q20568298
    Example 1Q20566506human settlement (Q486972)
    Example 2Q12911618Q12910132, necropolis (Q200141)
    Example 3Q20570108hillfort (Q744099)
    Example 4Q12905665hoard (Q164099)
    SourceThe lists of archaeological sites in Macedonia are contained in this template.
    Planned useI plan to use this property to add statement on the type(s) of the archaeological sites (e.g. human settlement (Q486972), Q12910132, hoard (Q164099) etc.) in Macedonia. My first idea was to add the data with instance of (P31) along with archaeological site (Q839954) but this would be inappropriate because these are, in fact, types of archaeological site (Q839954).
    Number of IDs in source4,000+
    See alsotime period (P2348) (for historical record)


    I proposed the creation of this property in order to store more data in a neat way. Kiril Simeonovski (talk) 13:11, 14 August 2020 (UTC)


    • How is this relationship called in archaeological research? ChristianKl❫ 21:34, 17 August 2020 (UTC)
    •   Comment I wonder whether the correct modelling would be "item 1" -> site of -> "item 2" where "item 1" describes the archaeological site while item 2 describes the historic reality (eg a settlement, hillfort etc). Thus there should probably be two items for each site: one to describe the dig happening in the present (or multiple digs) and one for the initial historic occurence? So maybe instead of "type" we need something that describes the relationship "site of" ? --Hannes Röst (talk) 01:00, 18 August 2020 (UTC)
    That seems superior to me, as you likely want to store further information about the site in many cases like the time when the human settlement was active and it's population. ChristianKl❫ 13:03, 18 August 2020 (UTC)
    The information about the period from which the site dates back is stored using time period (P2348). However, the use of a property like "site of" might work well because the ultimate point is to store data on the subclasses of archaeological site (Q839954).--Kiril Simeonovski (talk) 06:30, 19 August 2020 (UTC)
    That's not what time period (P2348) is defined to do. It's about the timeframe in which the subject (which is the archaeological site) exists. ChristianKl❫ 15:17, 24 August 2020 (UTC)
    •   Support This is a very necessary property. I edit these items and we struggle entering what those archaeological sites actually are. It is too generic to leave it as it is. --B. Jankuloski (talk) 12:09, 4 September 2020 (UTC)
    •   Oppose Given the current modelling time period (P2348) gets used wrongly. We need a property that links an archaeological site to the relevant settlement that it uncovers. ChristianKl❫ 00:47, 10 November 2020 (UTC)
    ChristianKl I don't see how does your reasoning relate to this property proposal. An archaeological site is usually not part of any larger settlement but a place where archaeological artifacts have been found or unearthed. That place may be located in someone's private property (e.g. field, yard) or on a state-owned land (e.g. mountain, cave). In its broadest sense, there are several dozens of archaeological types from coinage and utensils to aqueducts and ancient cities, which are used as a standardised typology to describe the archaeological sites in the Archaeological map of the Republic of Macedonia published by the Macedonian Academy of Sciences and Arts. The aim of this proposal is to create a property similar to instance of (P31) that will have to avoid an overuse of it in a specific context. As for the settlements where these places are located, the items do already employ location (P276). And if you think that time period (P2348) is used wrongly, you are welcome to suggest a more suitable property instead of using it as an argument to oppose an unrelated property proposal (the improvement of these items should be discussed elsewhere).--Kiril Simeonovski (talk) 09:23, 25 November 2020 (UTC)
    For each archaeological site the archaeological is a different entity (and thus deserves a different item) then the settlement/aqueducts or whatever was uncovered. This proposal encourages conflating both entities into one item. That conflation produces problems with statements such as the one for the time period. ChristianKl❫ 18:43, 27 November 2020 (UTC)

    applies to form or aspect (qualifier only)Edit

       Under discussion
    Descriptionform or aspect of an item to which the statement applies
    Data typeItem
    Example 1Republic of Venice (Q4948) demonym (P1549) veneciano (Spanish) / applies to form or aspect masculine singular (Q47088290) (masculine singular (Q47088290) is a form of the demonym (Q217438))
    Example 2water (Q283) color (P462) white (Q23444) / applies to form or aspect ice (Q23392) (ice (Q23392) is a form of water (Q283))
    Example 3motherboard (Q4321) has part (P527) central processing unit (Q5300) / applies to form or aspect single-board computer (Q944780) (single-board computer (Q944780) is a form of motherboard (Q4321))
    Example 4oxygen (Q629) radius (P2120) 60 picometre / applies to form or aspect atomic radius (Q483788) (atomic radius (Q483788) is an aspect of oxygen (Q629))
    Example 552-hertz whale (Q452) frequency (P2144) 52 hertz / applies to form or aspect animal communication (Q1434121) (animal communication (Q1434121) is an aspect of the 52-hertz whale (Q452))
    Example 6Sistine Chapel (Q2943) creator (P170) Baccio Pontelli (Q576325) / applies to form or aspect design (Q82604) (design (Q82604) is the aspect of Sistine Chapel (Q2943) that Baccio Pontelli (Q576325) contributed)
    Planned usemigration of appropriate statements from applies to part (P518)
    See alsoapplies to part (P518) (see motivation)


    There are many other examples of the types represented above, particularly the first. Currently, these cases mostly use applies to part (P518), and while its aliases reflect that (in English at least), many of its labels and descriptions do not. I recently tried to change the English label to reflect the full scope of use, and was reverted on the basis that the broader definition was too imprecise. But as it stands, applies to part (P518) is used in many statements where its current label(s) are not accurate. So as I see it, we need to either:

    1. Achieve a consensus that applies to part (P518) is the right property for these statements, and that its labels and descriptions should be expanded accordingly, OR;
    2. Create this proposed property to absorb the cases that are outside the scope of applies to part (P518), and narrow down the latter's aliases, labels, and descriptions in all languages to reflect it's narrower scope.

    I don't have a strong preference between these options, but it seems clear to me that one of them must happen.

    As the proposed property is essentially a split from applies to part (P518), there are many statements ready to be switched to the new property immediately, although it may not be trivial to identify them all. Swpb (talk) 19:35, 31 August 2020 (UTC)


    @Swpb: There's an issue here: does the qualification apply to the subject of the original statement, or to its object? (Or indeed to the property relation). Using the same qualifier for all three requires human 'common-sense' knowledge to be brought to the statement for the meaning to be interpret. That's why subject has role (P2868) and object has role (P3831) (the latter in fact proposed by you) are available to clarify the distinct role that the subject or object are playing in the main statement, which seems quite close to what you are seeking here (particularly "applies to aspect"). So for the Sistine Chapel example, using object has role (P3831) = "designer" would be the way that creator (P170) or contributor to the creative work or subject (P767) tend to be qualified at the moment (allowing values like draughtsman, cartographer, etcher, engraver, etc to be captured from catalogue sources). Also, the oxygen example criterion used (P1013) or determination method (P459) would seem more specific. So I think the first way forward here might be to widen the understanding of subject has role (P2868) and object has role (P3831) to cover "subject/object has role or form", and then to ask whether there are any cases remaining that would still not be well treated. Jheald (talk) 10:44, 8 September 2020 (UTC)

    @Jheald: applies to part (P518) is also ambiguous in this way (subject/object referent); if separation is needed (and I agree that it is), shouldn't we split applies to part (P518) as well? To me, adding "or form" to subject has role (P2868)/object has role (P3831) seems at least as significant an expansion as adding "form" or "aspect" to applies to part (P518), and would lead to some awkward expressions: how would you handle my example 5, for example? 52-hertz whale (Q452) frequency (P2144) 52 hertz / object has role or form animal communication (Q1434121)? To me, that seems as clear as mud. TO me, "aspect" and "part" seem closely related, "form" a little less so, and "role" least related of all. It seems like maximum clarity would call for six properties:
    1. applies to part or aspect of subject
    2. applies to part or aspect of object
    3. applies to form of subject
    4. applies to form of object
    5. subject has role (P2868)
    6. object has role (P3831)
    What do you think? Swpb (talk) 18:18, 9 September 2020 (UTC)

    blocked on the territory ofEdit

       Under discussion
    Descriptionadministrative unit, where this web-resource is blocked (de-jure or de-facto)
    Representswebsites and client-applications, i. e. instances of subclasses network service (Q1640628), software (Q7397)
    Data typeItem
    Domainadministrative territorial entity (Q56061)
    Example 1
    Example 2
    ⟨ LinkedIn (Q213660)      ⟩ blocked on the territory of search ⟨ Russia (Q159) ⟩
    start time (P580)   ⟨ 17 November 2016 ⟩
    Example 3
    ⟨ (Q3090589)      ⟩ blocked on the territory of search ⟨ Belarus (Q184) ⟩
    start time (P580)   ⟨ 12 August 2012 ⟩
    Example 4
    ⟨ Wikipedia (Q52)      ⟩ blocked on the territory of search ⟨ Russia (Q159) ⟩
    start time (P580)   ⟨ 24 August 2015 ⟩
    end time (P582)   ⟨ 25 August 2015 ⟩
    statement is subject of (P805)   ⟨ blocking of Wikipedia in Russia (Q21636163)      ⟩
    Example 5
    ⟨ Telegram (Q15616276)      ⟩ blocked on the territory of search ⟨ Iran (Q794) ⟩
    start time (P580)   ⟨ 30 April 2018 ⟩


    Internet censorship (Q22696) is a common thing for today for billions of people. Let's add a property to indicate, why and during which period LinkedIn personal profile ID (P6634) and LinkedIn company ID (P4264) does not work for people in Russia, and Facebook (Q355) in China. Specific Wikipedia language editions may also decorate these resources with templates like ru:Шаблон:Ссылка заблокирована Роскомнадзором --Lockal (talk) 20:18, 31 August 2020 (UTC)


    •   Comment do you mean "blocked" as being unable to read or to write/send stuffs ? Anyhow, that should be sourced. And be clear to the extent of the blockading : does it applies to citizens on this territory? Can a tourist Russian edit Wikipedia when he's abroad ? With his computer or his nickname....? Bouzinac (talk) 20:30, 31 August 2020 (UTC)
      By "blocked" I mean that there was either federal/regional court decision or a specific document from an executive body with the rights to block Internet resources (e. g. 2018 block of Telegram in Russia (Q51991992)), or there were no official documents, but the fact of blocking was recorded by the mass media (e. g. block of Wikipedia in Turkey (Q29597631)). Indeed, all these cases should be sourced. There are common procedures and legislative acts for blocking web-resources like ru, tr, by - all of them are targeted to internet, content and service providers, and only on the territory, where this document is in force. There is no split for foreign/local users, afaik. This property is applicable only for websites, not for people, organizations, medicines, etc. --Lockal (talk)
      •   Oppose
    1. See Wikidata:Property proposal/banned in - may be a duplicate?
    2. And also, such information is not easy to verify (especially with start time (P580)). For example, the start time (P580) of the first example is wrong.

    --GZWDer (talk) 08:20, 1 September 2020 (UTC)

    •   Oppose use prohibits (P8739) as now done in blocking of Wikipedia in Russia (Q21636163) ChristianKl❫ 12:49, 2 December 2020 (UTC)
      @ChristianKl:, your suggestion does not answer the problem, described in the Motivation section. How Wikidata clients (like Russian Wikipedia) could use it to mark web-resources, not available in Russia? --Lockal (talk) 19:26, 2 December 2020 (UTC)
      With my model you can write a SPARQL query that asks whether website X was prohibited in jurisdiction X and if so from when to when. ChristianKl❫ 19:36, 2 December 2020 (UTC)
      Ignoring the fact that SPARQL queries can not be run from Lua/Scribunto (i. e. maybe a bot can update pages on schedule), I don't see it as very feasible, to create "blocking of <resource> in <countryname>" items for each instance of blocking event of notable websites. For end users it would be then much easier to just store list of blocked resources as a wikipage instead of structured data. --Lockal (talk) 20:17, 2 December 2020 (UTC)

    Liturgical categoryEdit

       Under discussion
    DescriptionThe category of the liturgical celebration of a saint, blessed or other feast day, e.g. "confessor", "martyr".
    Data typeItem
    Example 1Robert Bellarmine (Q298664) -> feast day: 17 September -> part of General Roman Calendar -> additional info: liturgical cat. = bishop and Doctor of the Church
    Example 2Robert Bellarmine (Q298664) -> feast day: 13 May -> part of Tridentine Calendar -> additional info: liturgical cat. = confessor-bishop and Doctor of the Church
    Example 3Saints Cosmas and Damian (Q76486) -> feast day: 26 September -> part of General Roman Calendar -> additional info: liturgical cat. = martyrs
    Example 4Saints Cosmas and Damian (Q76486) -> feast day: 27 September -> part of Tridentine Calendar -> additional info: liturgical cat. = martyrs
    Planned useFor the start, I want to add this information for the feasts contained in the Tridentine Calendar (Q7883976) and the General Roman Calendar (Q13012667).
    See alsoWikidata:Property_proposal/Liturgical_rank

    Example on test-WD: testwikidata:Q212740


    This would be a qualifier for "feast days" to indicate the category into which a celebrated saint belongs.

    For example, there are (see en:Calendar_of_saints#History), for the Tridentine Calendar (Q7883976): "Martyrs, Confessors who were bishops, Doctors of the Church, Confessors who were not Bishops, Abbots, Virgins, Non-Virgins", while for the Calendarium Romanum Generale (1969) (Q98782022): "Martyrs (with special formulas for missionary martyrs and virgin martyrs), Pastors (subdivided into bishops, generic pastors, founders of churches, and missionaries), Doctors of the Church, Virgins, and (generic) Saints (with special formulas for abbots, monks, nuns, religious, those noted for works of mercy, educators, and [generically] women saints)."

    I propose to call it "category", instead of "common" (common (Q1120307)): while commonly, it will coincide with the Common (lat.: Commune), there are also exceptions, e.g. Mary Magdalene (Q63070) whose category is "Penitent" in Tridentine Calendar (Q7883976), which is not a Common there; or Michael, Gabriel and Raphael, archangels (Q98782976), whose category is "Archangels", which is also not associated with a Common. --MF-W 16:01, 1 September 2020 (UTC)


    Nojhan Yair rand Runner1928 TomT0m Capankajsmilyo ArthurPSmith John Carter Nomen ad hoc Tris T7 TT me Epìdosis Peter17 Bargioni Geogast  Notified participants of WikiProject Religions Maybe someone from this project can help- Valentina.Anitnelav (talk) 16:35, 6 October 2020 (UTC)

    level of professionalnessEdit

       Under discussion
    Descriptionlevel of competition generally associated with this item
    Data typeItem
    Domainhuman (Q5), organization (Q43229), event (Q1656682), award (Q618779)
    Allowed valuesprofessional, amateur, collegiate, semi-professional, pro–am, youth
    Example 12019 NFL season (Q60526042) → professional
    Example 2Duke Blue Devils men's basketball (Q4171772) → collegiate
    Example 3USL League Two (Q976491) → amateur
    Example 4AT&T Pebble Beach National Pro-Am (Q298589) → pro–am
    Planned usefor classifying sports, competitions, awards, etc in a clear way
    See alsocompetition class (P2094)


    Right now, there doesn't seem to be a clear consistent way to classify whether a team/league/event/etc is pro, amateur, or whatever else. I deal with a lot of college sports items, and I've noticed that there's no consistent way to distinguish collegiate teams. Sometimes it gets set in the sport (P641) field (e.g. college basketball (Q48890) instead of or in addition to basketball (Q5372)), sometimes it gets set in instance of (P31) (e.g. college sports team (Q18558301), NCAA Division I women's basketball team (Q54190181)), sometimes you could follow the parent club (P831) property and find a university and college sports club (Q2367225) instance (not ideal since that's another item lookup), and sometimes there's no clear indication at all. This seems like a really basic fact that ought to be easy to determine for any sports-related item (in the same way that sport (P641) and competition class (P2094) are).

    For the 6 allowed values I picked (pro/amateur/collegiate/semi-pro/pro-am/youth), my assumption is that we'd create new items for most/all of them. There are existing items that kind of work (professional (Q702269), amateur (Q455595), college sports (Q5146583), semi-professional sports (Q4371047), pro–am (Q7252932), youth sports (Q599867)). However, some of these are sports-specific, and I'd like to see this property also being used for awards/competitions/etc outside the realm of sports.

    The 6 values I picked are definitely up for debate. I think this property should be limited to a fairly short list of allowed values so that it's not cumbersome to use (we have competition class (P2094) for expressing greater complexity), but exactly what's on that list may need to be tweaked. IagoQnsi (talk) 00:49, 23 September 2020 (UTC)


    •   Support This sounds good to me. Some other values that would make sense are "middle school," "high school," "inter-mural collegiate." Maybe "pick-up" too, but I can't think of a case where that would be used. Regarding the label, "level of professionalness" is quite clunky, but I also don't have a better a better suggestion. — The Erinaceous One 🦔 05:50, 23 September 2020 (UTC)
      • @The-erinaceous-one: In the interest of keeping the list of values for this property as short as possible, I'd lean towards not adding those values. Middle/high school would fit under "youth", and intramural collegiate fits under "amateur". My concept for this property is to be extremely general, in the same vein as manner of death (P1196). More precise classifications can be accomplished with competition class (P2094). –IagoQnsi (talk) 16:38, 11 October 2020 (UTC)
    •   Oppose; this is exactly the same problem that we are solving with competition class (P2094) (eligibility criteria to enter an event as a participant), and I think we should use that property to cover this aspect as well. I would not require and re-definition of competition class (P2094); a few new value items are sufficient actually. —MisterSynergy (talk) 09:09, 23 September 2020 (UTC)
      • @MisterSynergy: We definitely could use competition class (P2094) for this, true. The reason I wanted a new property, however, is that competition class (P2094) is a somewhat complex property that allows a wide range of values, which makes it harder to do simple queries with. If you're trying to do a query for items related to collegiate sports in general (i.e. not any particular sport), for example, you'd have to either need to use a hardcoded list of all the college sports (e.g. college basketball (Q48890), college football (Q1109032), college sports (Q5146583)), or your query would have to retrieve the value item of the competition class (P2094) claim to check if it's a college sport, which is more complex and expensive. Having a separate property with a very limited set of values makes retrieval easier. –IagoQnsi (talk) 16:15, 23 September 2020 (UTC)
        • Querying with competition class (P2094) is actually pretty efficient, as it is a transitive property. This means that you neither need a hardcoded list in the query, nor do you need to make complex restrictions regarding the values of P2094 to use it.
          Experience shows that the proposed property will probably not be used with "a very limited set of values" even if this is the initial intention; also that edit count hunters will likely pour it to a large amount of items even if it does not fit at all (happened with P2094 as well); and that data users will not know whether to use P2094 or this one or both. Having a second "competing" property for a very similar purpose like an existing one is usually a bad idea here. —MisterSynergy (talk) 17:09, 23 September 2020 (UTC)
          • @MisterSynergy: Having manner of death (P1196) and cause of death (P509) seems to work okay. Much like P1196, I'm imagining this property having a one-of constraint limiting the possible values. If the constraint is widely ignored, we could have a bot enforce it by removing invalid entries. –IagoQnsi (talk) 16:38, 11 October 2020 (UTC)
            • Removing "invalid entries" is an extremely tedious task and quite quickly you run into conflicts if you do so. I’d rather not rely on this option. —MisterSynergy (talk) 19:36, 11 October 2020 (UTC)
    • On second thought: Perhaps "pro-am" should be eliminated, and pro-am events should instead be classed as both "professional" and "amateur". Otherwise we might end up seeing more and more values created to specify every possible combination of the existing values. And maybe "semi-pro" should go too – it's really just a subclass of "pro". –IagoQnsi (talk) 16:43, 11 October 2020 (UTC)
      • Well, "youth" does not fit here either as it is already a facet of the P2094 values, leaving "professional" and "amateur". —MisterSynergy (talk) 19:36, 11 October 2020 (UTC)
        • @MisterSynergy: The idea is that every item which has P2094 should also be able to be classified under this new property (much like how every item with "cause of death" can also have "manner of death"). P2094 is where the detailed descriptor can go (i.e. "U-16 association football" or "middle school golf" or whatever), whereas this new property contains the broad category ("youth"). The goal is to enable more general queries. If you want to filter a query to only professional sports, for example, you have to dig deep into every P2094 object to figure out whether or not that item is a professional class or not. This property would make such queries much more feasible. –IagoQnsi (talk) 12:57, 20 October 2020 (UTC)
          • This is clearly not a good idea. Actually, for most sport events the "level of professionalness" is no factor at all; athletes can compete regardless of their status. It appears to me that this sort of distinction is made in the US and a few other countries, but by far not everywhere in the world. It is certainly a bad idea to add it to anything that has already a P2094 if it is not a factor in most cases.
            Besides that, you can already now query for something like "only professional sports" easily. Since professionalness is not yet incorporated in P2094, I use under-23 sport (Q14510042) here to demonstrate it: a query as simple as SELECT ?item WHERE { ?item wdt:P2094* wd:Q14510042 } lists you all items that have a competition class item with the Under-23 age class facet---obviously with no deep digging required. Once again, P2094 is a transitive property for exactly that reason, and adding the professionalness to it is really simple. ---MisterSynergy (talk) 13:22, 20 October 2020 (UTC)
    •   Oppose As per the above discussion, I am in favor of building ou competition class (P2094) rather than having a very similar property. --Mad melone (talk) 11:21, 26 October 2020 (UTC)

    Unicode nameEdit

       Under discussion
    Descriptionofficial character name by Unicode consortium
    Data typeString
    Template parameterОригинал/Оригинал2/Оригинал3/Оригинал4 в ru:Шаблон:Графема
    Allowed values[A-Z0-9 -]+
    Example 1ז (Q15159) → HEBREW LETTER ZAYIN
    Example 2ט (Q15163) → HEBREW LETTER TET
    Example 3ק (Q19131) → HEBREW LETTER QOF
    Planned usein ru:Шаблон:Графема/Викиданные
    Robot and gadget jobsImport from, character for lookup from Unicode hex codepoint (P4213), Unicode character (P487)
    See alsoUnicode hex codepoint (P4213), Unicode character (P487)

    MotivationEdit 19:59, 11 October 2020 (UTC)


    inaugural addressEdit


    To make Wikidata more complete this will make it possible to connect new position held with the the items of the speech Salgo60 (talk) 08:33, 21 October 2020 (UTC)


      Comment interesting idea, but maybe it is possible to model the semantic message directly in the item of the speech: Nelson Mandela's inaugural address (Q19070822) significant event (P793) inauguration (Q1417098) / of (P642) President of South Africa (Q273884) (or you even create an totally new and separate item for the specific inauguration - as every you like!) in combination with the already set speaker (P823)-statement you should be able to query all different combinations (where has spoken an address starting presidency of south africa or for which positions Nelson Mandela had given an inaugral address etc. --Mfchris84 (talk) 09:41, 21 October 2020 (UTC)

    Thanks I have right now focus on Swedish Academy (Q207360) and the people having a position like seat 15 of the Swedish Academy (Q96600412) and then I felt the speech should be connected to the position but as you said maybe there are better models... don't hesitate to change the proposal - Salgo60 (talk) 10:02, 21 October 2020 (UTC)
    Apart from inagural addresses, I guess a few acceptance speeches could also have items, e.g. Barack Obama's Nobel Peace Prize acceptance speech (Q21436489). Especially for US presidents I imagine there are speeches held on a wide variety of occasions. This model does indeed seem more flexible. Belteshassar (talk) 19:39, 21 October 2020 (UTC)
    No, this makes no sense, significant event (P793) is meant to have the thing that had it as the significant event as the subject. For an inaugural speech (Q10536399) significant event (P793) inauguration (Q1417098) would be soo off. --CamelCaseNick (talk) 01:36, 28 October 2020 (UTC)

      Comment As shown by your examples, many people think of an inauguration as ascending to political office. But an inauguration can be any ceremony that installs a person to any position (often used in academia but could be any society). (It also doesn't have to be a person; there are inaugural programs or inaugural lectures - more typical of academia or societies). - Kosboot (talk) 15:03, 21 October 2020 (UTC)

      Comment This is too specific. We would handle more cases if we changed the proposal to "gave address" with "inaugural" put in a qualifier. — The Erinaceous One 🦔 07:29, 28 October 2020 (UTC)

    Ukrainian national romanizationEdit

       Under discussion
    Descriptionromanized Ukrainian text method for Ukrainian text (transliteration from Ukrainian Cyrillic alphabet to Latin alphabet)
    RepresentsUkrainian National System (Q94489556)
    Data typeString
    Template parameterAny title or name in a Ukrainian subject, including official romanized name for Ukrainian place names.
    DomainAny Ukrainian text. Geography and biography. Lexemes and forms. Should be tagged with uk-Latn.[11]
    Allowed valuesAny text. Ukrainian alphabet romanized matches the regex [a-ik-pr-vyzA-IK-PR-VYZ ]+, but text may also include punctuation, foreign-language text, etc.
    Example 1universe (Q1): всесвіт → vsesvit
    Example 2Kyiv (Q1899): Київ → Kyiv
    Example 3Viktor Yushchenko (Q1459699): Віктор Андрійович Ющенко → Viktor Andriiovych Yushchenko
    Example 4Ukrainian National System (Q94489556): Про впорядкування транслітерації українського алфавіту латиницею → Pro vporiadkuvannia transliteratsii ukrainskoho alfavitu latynytseiu
    Sourcew:en:Romanization of Ukrainian, United Nations Romanization System in Ukraine (PDF), PCGN Romanization of Ukrainian (PDF)
    Planned useMarking official Latin-alphabet place names in Ukraine. Importing or validating them from Ukraine’s open data portal Transcluding them into the “name_official” field in infoboxes on en.Wikipedia.
    See alsoSixteen other instances of Wikidata property for transliteration system (Q20085670): Query. Subject item of this property: Ukrainian National System (Q94489556). Other romanization systems for Ukrainian (subjects): ALA-LC romanization for Ukrainian (Q100903064), BGN/PCGN romanization of Ukrainian (1965 system) (Q56345230), German romanization of Ukrainian (Duden) (Q56343745), ISO 9 (Q913336).


    This is necessary for using romanized Ukrainian in most contexts. I want to get Ukrainian official Latin-alphabet names into en.Wikipedia articles. Michael Z. 2020-10-29 03:35 z 03:35, 29 October 2020 (UTC)

    Technical descriptionEdit

    This standard is mandated for official documents in Ukraine, including passports, geographical names and maps, public signage, street names, transit, etcetera. Initial version was adopted by Ukraine in 1994, current version enacted into law in 2010, adopted by the United Nations in 2012, and the BGN/PCGN in 2019, so it is widely used and here to stay. Adopted in en.Wikipedia for geographic names in 2008 and almost everything else in 2019. This is a simple and accessible transcription method, based on English phonemes (kh, ts, ch, sh, shch, iu/yu, ia/ya, not ch, c, č, š, šč, ju, ja of European “international” schemes), foregoing diacritics, and designed for international use. It is not reversible to derive the original Cyrillic text. It could be reliably generated by an algorithm.


    • Why not but please specify it's an English romanisation (zh for this romanisation whilst it would be j in French, for instance). Bouzinac💬✒️💛 10:40, 29 October 2020 (UTC)
      I alluded to it, but now I’ve added more technical description. I would like to see other romanizations added as well, including European “international” ones in addition to ISO 9:1995 (P2183), as well as national ones like the French Dictionnaire de la langue française and German Duden and DIN. Michael Z. 2020-10-29 15:00 z 15:00, 29 October 2020 (UTC)
    • Trimmed the description. It's way too long. NMaia (talk) 06:11, 2 November 2020 (UTC)
    • Looking the English descriptions of similar properties ( ), I'm trying to figure out which one has the optimal one describing the expected value. To follow them, maybe "romanization according to the Ukrainian National System" or "representation according to the Ukrainian National System of transliteration of Cyrillic text to Latin script" could work. I think it helps to clearly identify the method used in the description. BTW, the property value is the result, not the method itself. As long as it fits in the field, I wouldn't worry about it being too long. Given the state of descriptions of similar properties, I'd move ahead and improve them later on. Unless there is some good reason why these two aren't needed, I'd support their creation. --- Jura 14:03, 6 November 2020 (UTC)
      Ah, this description will appear in the context of using this property. That wasn’t evident from the proposal form. I wrote it for evaluators of this proposal. I’ll give it a bit of thought and maybe revise. Michael Z. 2020-11-06 15:18 z 15:18, 6 November 2020 (UTC)
      • I edited some of the other descriptions. For query with the items for the system: . Maybe @Nikki: who proposed some of the other properties wants to comment. --- Jura 07:42, 7 November 2020 (UTC)
        • Thank you. Distilling each respective property’s description:
          1. <system> transliteration of a <language> text (usually to be used as a qualifier)
          2. reading of a <language> name in <script>
          3. reading of a <language> name in <script>
          4. romanization of <language> with <system>
          5. romanisation following <system> of <language>
          6. romanized <language> following <system>
          7. transliteration of text from <script> to Latin script according to <system>
          8. Latin transliteration of <script> text (used as qualifier)
          9. conversion of text to alternate script (use as a qualifier for monolingual text statements; please use specific property if possible)
          10. transliteration from <script> to Latin script with <system>
          11. official <country> transliteration method for <language>
          12. transliteration from <language> to Latin script with <system>
          13. representation of a IPA phoneme in <script>
          14. transliteration from <script> to Latin script following <system>
          15. representation according to <system> for transliterating <set of scripts>
          16. transliteration of <script> and <set of scripts>
          17. transcription of name in <script>
        • Each of those is a noun phrase. Most can be interpreted as referring to the converted text representation, one to the underlying original-language expression, and one to a method of text conversion.
        • On the other hand, I wonder if it might be clearer to make the noun implicit, and refer to application of the method, for example, label: romanized by the Ukrainian National System; description: text transliterated from the Ukrainian Cyrillic alphabet to the Latin alphabet according to the Ukrainian National System of 2010. This may help understand how to use the property as a qualifier on derived text, and also clearly distinguishes it from the method, Ukrainian National System (Q94489556)Michael Z. 2020-11-07 22:46 z 22:46, 7 November 2020 (UTC)

    ALA-LC romanization for UkrainianEdit

       Under discussion
    Descriptionromanization method for Ukrainian text (transliteration from Ukrainian Cyrillic alphabet to Latin alphabet)
    RepresentsALA-LC romanization for Ukrainian (Q100903064)
    Data typeString
    Template parameterIn any cited Ukrainian-language reference source, to represent title, author, place of publication, etc.
    DomainAny Ukrainian text. Bibliographic data. Lexemes and Forms. Should be tagged with uk-Latn or uk-Latn-alalc97.[12]
    Allowed valuesAny text. Ukrainian alphabet romanized matches the regex [a-iĭïk-pr-vyzA-IĬÏK-PR-VYZ ͡ʹ]+, but text may also include punctuation, foreign-language text, etc. (Not sure how regex handles that combining double inverted breve ͡ (Q87498562), which occurs in combinations i͡e I͡e I͡E z͡h Z͡h Z͡H t͡s T͡s T͡S i͡u I͡u I͡U i͡a I͡a I͡A)
    Example 1universe (Q1): всесвіт → vsesvit
    Example 2Kyiv (Q1899): Київ → Kyïv
    Example 3Viktor Yushchenko (Q1459699): Віктор Андрійович Ющенко → Viktor Andriĭovych I͡ushchenko
    Example 4Ukrainian National System (Q94489556): Про впорядкування транслітерації українського алфавіту латиницею → Pro vpori͡adkuvanni͡a transliterat͡siï ukraïns′koho alfavitu latynyt͡sei͡u
    Sourcew:en:Romanization of Ukrainian, Library of Congress Ukrainian (PDF)
    Planned useAdding transliterations of Ukrainian-language reference citations.
    See alsoSixteen other instances of Wikidata property for transliteration system (Q20085670): Query. Subject item of this property: ALA-LC romanization for Ukrainian (Q100903064). Other romanization systems for Ukrainian (subjects): BGN/PCGN romanization of Ukrainian (1965 system) (Q56345230), German romanization of Ukrainian (Duden) (Q56343745), ISO 9 (Q913336), Ukrainian National System (Q94489556).


    This is necessary for bibliographic data about Ukrainian-language sources. Michael Z. 2020-10-29 03:35 z 03:35, 29 October 2020 (UTC)

    Technical descriptionEdit

    This is a standard of the American Library Association and Library of Congress, used in English-language library catalogues, by publishers, etc. in the USA, UK, Canada, and elsewhere. This is a precise transcription method, based on English phonemes (kh, t͡s, ch, sh, shch, i͡u, i͡a, not ch, c, č, š, šč, ju, ja of European “international” schemes). Unknown whether it is reversible to derive the original Cyrillic text. It could be reliably generated by an algorithm.


    number of Internet usersEdit

       Under discussion
    Descriptionnumber of people able to connect to the Internet
    Data typeNumber (not available yet)
    Domainhuman settlement (Q486972) et country (Q6256)
    Allowed valuesdevrait être inférieur à la valeur de population (P1082)
    Allowed unitsde 0 à 10000000000
    Example 1Afghanistan (Q889) → 33300000 for year 2019[1] < estimate (Q37113960) >
    Example 2Armenia (Q399) → 2930450 for year 2019[2] < estimate (Q37113960) >
    Example 3Azerbaijan (Q227) → 10127874 for year 2019[3] < estimate (Q37113960) >
    Example 4Cameroon (Q1009) → 20387939 for year 2017[4] < estimate (Q37113960) >
    Expected completenessalways incomplete (Q21873886)
    See alsoliterate population (P6499)


    To show the broader access to Internet among countries and among time. Bouzinac💬✒️💛 20:17, 11 November 2020 (UTC)


    • I have modified the label to make it more clear.--GZWDer (talk) 21:29, 11 November 2020 (UTC)
    •   Oppose for storing this information in the proposed way. It adds too much data/country item and increaes the size of country items too much. ChristianKl❫ 00:16, 12 November 2020 (UTC)
    •   Oppose on the country item per Christian but   Neutral if added to the "Internet in (place)" item. Mahir256 (talk) 00:43, 12 November 2020 (UTC)
    •   Comment I fail to see why literate population (P6499) should be fine and this isnt? Maybe the problem is not the property but the data model of Wikidata here? --Hannes Röst (talk) 16:00, 15 November 2020 (UTC)
    •   Support on "demographics of" items. @GZWDer, ChristianKl, Bouzinac: what do you think? --- Jura 12:05, 18 December 2020 (UTC)
    I would be okay with the domain of "demographics of" and corresponding type constraints. ChristianKl❫ 12:16, 18 December 2020 (UTC)

    adjacent toEdit

       Under discussion


    We already have a few specific properties for adjacency, but instead of creating a new property for every different type of item that adjacency applies to, this would be a general property for all types for which there is not already a more specific one in existence (see the three related, specific properties linked above). Exact context of adjacency would depend on the exact type of item it is applied to, so no need for elaborate constraints on this property. It would become the parent property for the three properties already extant. Josh Baumgartner (talk) 10:32, 19 November 2020 (UTC)


    •   Comment I think we already had similar proposals, e.g. Wikidata:Property proposal/monument in the near. --- Jura 12:42, 20 November 2020 (UTC)
      • Thanks for bringing that one up. Adjacency cannot be calculated by coordinates and indicates a particular relationship between two entities, so while I understand the discussion there, it is not particularly relevant to this one. Josh Baumgartner (talk) 12:25, 21 November 2020 (UTC)
    Mona Lisa (Q12418) being otherwise located in a relative adjacent location of Jupiter Hurling Thunderbolts at the Vices (Q18573249) ?
    • If items have a physical contact point connects with (P2789) is our property that specifies that relationship. ChristianKl❫ 18:20, 20 November 2020 (UTC)
      • Thanks for pointing that one out, it would probably do nicely for example 1. Not so sure it would work for 2, 3 & 4. Josh Baumgartner (talk) 12:25, 21 November 2020 (UTC)
        • Can you explain why you think this example works better for those examples (I'm not familiar with those examples)? What's the shared point in contact? ChristianKl❫ 20:44, 21 November 2020 (UTC)


       Under discussion
    DescriptionNumeric identifier of mediawiki article
    RepresentsMediaWiki Page ID (Q83336089)
    Data typeQuantity
    Example 1Bilbo Baggins (Q185737)Fandom article ID (P6262)lotr:Bilbo_Baggins
    [curid] → 64
    Example 2computer (Q68)English Vikidia ID (P7829)Computer
    [curid] → 5744
    Example 3Brother (Q56605466)WikiTrek ID (P8344)Brother
    [curid] → 16216
    Expected completenessalways incomplete (Q21873886)
    Robot and gadget jobscheck all statements that point to external wikis and retrieve their curid
    See alsonamed as (P1810)


    analogue to Twitter user numeric ID (P6552). in Wikidata:Property proposal/All the Tropes identifier User:Pamputt suggested that a curid would be more stable and would enable us to keep mediawiki based properties up to date. --Shisma (talk) 19:35, 29 November 2020 (UTC)


    Assuming all the appropriate has quality (P1552) tags are filled in, there are 61 with the page-title approach and only 6 with the curid approach.
    Also, for what it's worth, I agree with Tinker Bell that this is semantically a string, not a number. Vahurzpu (talk) 17:55, 8 December 2020 (UTC)
    •   Support --- Jura 09:52, 18 December 2020 (UTC)

    provides HTML microdataEdit

       Under discussion
    DescriptionThe external page contains the following HTML microdata (the data may only string)
    RepresentsMicrodata (Q3312185)
    Data typeProperty
    Example athlete ID (P3427)height (P2048) (height), place of birth (P19) (birthPlace)
    Example 2Catholic Hierarchy person ID (P1047)date of birth (P569) (birthDate), date of death (P570) (deathDate)
    Example 3WikiTree person ID (P2949)spouse (P26) (spouse)
    See alsoWikidata:Property proposal/provides JSON-LD data


       Under discussion
    Description(qualifier only) the property used in the external page
    Data typeString
    Example 1see above
    Example 2MISSING
    Example 3MISSING


    A scaled-down and more realizable version of Wikidata:Property proposal/provides data. Note this only applies to some sites; many others does not use HTML microdata (e.g. PubMed ID (P698), PubChem CID (P662), VIAF ID (P214)) and is not applicable. GZWDer (talk) 23:51, 29 November 2020 (UTC)


    provides JSON-LD dataEdit

       Under discussion
    DescriptionThe external page provides data in JSON-LD format
    RepresentsJSON-LD (Q6108942)
    Data typeProperty
    Example 1Movie Walker film ID (P2509)country of origin (P495) (countryOfOrigin)
    Example 2MusicBrainz place ID (P1004)coordinate location (P625) (geo)
    Example 3GameSpot ID (P5494)publication date (P577) (datePublished)
    Example 4Semantic Scholar paper ID (P4011)author (P50) (author)
    See alsoWikidata:Property proposal/provides HTML microdata

    JSON-LD propertyEdit

       Under discussion
    Descriptionsee above
    Data typeString
    Example 1see above
    Example 2MISSING
    Example 3MISSING
    Formatter URL$1


    Another spin-off of Wikidata:Property proposal/provides data. GZWDer (talk) 00:02, 30 November 2020 (UTC)


    does not have causeEdit


    Going through complementary property (P8882), I noticed that we have complementary properties for many, but not for "has cause". While one could probably model some with has cause (P828) and deprecated rank, in other cases, this might not be optimal. Please help complete the above proposal, it could use more samples. (Add your motivation for this property here.) --- Jura 12:38, 2 December 2020 (UTC)


    • So just to clarify, is this supposed to represent that X is proven by quality research, or generally agreed among experts, to not be caused by Y? Like e.g. autism (Q38404) -> "does not have cause" -> vaccine (Q134808)? -- Btcprox (talk) 10:56, 4 December 2020 (UTC)
      • Maybe the difference to has cause (P828) is that the focus of the reference would generally be to exclude a particular cause, whereas one for a deprecated has cause (P828)-statement could mean that it isn't conclusively shown to be caused by that. The usual referencing requirements applies. --- Jura 10:54, 7 December 2020 (UTC)
    •   Support, an important property for causes.--Arbnos (talk) 15:36, 21 February 2021 (UTC)

    conductor forEdit

       Under discussion
    Descriptionthe subject allows the object to flow through
    Data typeItem
    Example 1gas pipe (Q55753892): pipe for the passage of gasgas (Q11432): one of the four fundamental states of matter
    Example 2artery (Q9655): blood vessel that carry blood away from the heartblood (Q7873): organic fluid which transports nutrients throughout the organism
    Example 3electrical conductor (Q124291): material that allows the flow of electrical currentelectricity (Q12725): physical phenomena associated with the presence and flow of electric charge


    I was searching for a way to express that blood flows through arteries and found that we currently lack a property to describe this relation. I'm not 100% sure that conductor is the best word and open to other suggestions. ChristianKl❫ 13:13, 4 December 2020 (UTC)

    Daniel Mietchen
    Simon Villeneuve
    Toni 001
    Marc André Miron
      Notified participants of WikiProject Physics Tobias1984
    Doc James
    Daniel Mietchen
    Andrew Su
    Projekt ANA
    Pavel Dušek
    Was a bee
    Chris Mungall
    Dr. Abhijeet Safai
    Sami Mlouhi
    Netha Hussain
    Abhijeet Safai
    Shani Evenstein
    ZI Jony
      Notified participants of WikiProject Medicine


      Comment why not adapt that carries (P2505) property ? They don't have same fields but look to be carrying same idea. Bouzinac💬✒️💛 17:47, 4 December 2020 (UTC)
    Given the examples of the property it seems to be something different. Tioga Pass (Q2436036) carries (P2505) California State Route 120 (Q758090) but Tioga Pass (Q2436036) <conductor for> motor car (Q1420) would match the relationship in my proposed property. ChristianKl❫ 21:32, 4 December 2020 (UTC)

    reason for normal rankEdit

       Under discussion
    Descriptionqualifier to allow the reason to be indicated why a particular statement should have normal rank (and not preferred nor deprecated rank). Avoid using it when there is no statement with another rank nor a qualifier that might induce people to set deprecated rank. Sample use: a statement with an "end date" (P582) would generally have normal rank and not deprecated rank, nor should it be deleted nor overwritten
    Data typeItem
    Domainstatement and claims with normal Help:Ranking#rank (not preferred or deprecated)
    Allowed valuesstatement no longer current (Q103841141) or other
    Example 1United States of America (Q30) member of (P463) UNESCO (Q7809)
    qualified with → statement no longer current (Q103841141)
    Example 2Brazil (Q155) member of (P463) Latin Union (Q123209)
    qualified with → statement no longer current (Q103841141)
    Example 3Ronan Huon (Q654520) date of birth (P569) 1922
    qualified with → new item for "less precise value"
    Example 4Dalia Mya Schmidt-Foß (Q66490714) Instagram username (P2003) californiadalia
    qualified with → statement no longer current (Q103841141)
    Example 5Worle Library and Children's Centre (Q55163610) coordinate location (P625) 51°21'39.474"N, 2°55'35.922"W
    qualified with → statement no longer current (Q103841141)
    See alsoHelp:Ranking


    It seems to me that preferred rank is generally more easily understood than normal rank for statements that are no longer current. While we have reason for preferred rank (P7452), we lack a qualifier for this. Obviously, it shouldn't be added to any statement with normal rank. See the description for when to use it. Please help improve it. (Add your motivation for this property here.) --- Jura 10:49, 5 December 2020 (UTC)


    •   Support Fit nicely with our semantics to give reasons for the other ranks. ChristianKl❫ 11:25, 5 December 2020 (UTC)
    •   Oppose I see no need. United States of America (Q30) has more than 50 statements with member of (P463). Some of the currently valid statements have preferred rank, and some have normal rank. That is not good as it means it is harder to find the statements with normal rank. One of the most asked questions about SPARQL queries is why it doesn't find some statements. The answer usually is that the query find statements of "best rank", and the statement in question have normal rank, but other statements with preferred rank are the best rank.
    I think it would be better to just give all statements here normal rank. It is too hard to maintain having dozens of statements with preferred rank for the same property. When new statements are added, many users will not set the rank from the default normal rank.
    Do you have any other kind of examples where it would be relevant to give a reason for normal rank? --Dipsacus fullonum (talk) 11:45, 5 December 2020 (UTC)
    Q30 just seems messy. Q155#P463 has it mostly right. That ranks can change isn't really a reason not to use them. We actually do have ranks because one should change the rank and not the statement itself. Maintaining them on countries is really trivial if not done manually. Statements with end dates are frequently misunderstood and either deleted, overwritten or deprecated. --- Jura 11:55, 5 December 2020 (UTC)
    •   Comment Maybe it would be better if this property was simply "reason for rank," to give it more flexibility. I'd also allow editors to explain why a statement is marked as preferred or obsolete. NMaia (talk) 09:24, 8 December 2020 (UTC)
      • Supposedly, we could do that and replace the other. We'd have to make sure the rank can be deduced from the item used as value, otherwise we loose a way to check if the rank matches the reason. --- Jura 14:20, 8 December 2020 (UTC)
        • I like the fact that reason for deprecation spells out deprecation. It makes it easier to see that the item is infact deprecated. ChristianKl❫ 11:52, 9 December 2020 (UTC)
    • @Moebeus, Ayack, SilentSpike, SixTwoEight, YULdigitalpreservation: @Tagishsimon, Nomen ad hoc, Tinker Bell, Ghouston: as you participated in preferred rank property proposal, what's your view on this? --- Jura 11:58, 9 December 2020 (UTC)
      Sorry, I can't see the need of that.   Neutral therefore. Nomen ad hoc (talk) 13:22, 9 December 2020 (UTC).
      • I don't see the need of that. However, I like NMaia's comment. --Tinker Bell 18:53, 9 December 2020 (UTC)
    •   Weak support While I'm not fully sold on the need, I certainly don't see any harm. Moebeus (talk) 12:12, 9 December 2020 (UTC)
    •   Neutral Hmm, I'm unsure. I do like the it allows intention to be captured in the data which makes it less prone to misunderstanding. However, what I don't like is that the application of this qualifier would be selective (i.e. there's always a reason a statement has a specific rank, be we wouldn't want to be adding this to every statement ever - I think the reasons will basically all boil down to "the data is valid"). In general, awareness of how ranks are intended to be used should be improved site-wide (i.e. editors need to stop deleting accurate data just because it has a temporal component to it). --SilentSpike (talk) 21:34, 9 December 2020 (UTC)
      • One way of raising the awareness is reverting an edit and adding this qualifier. How do you usually do it? --- Jura 07:31, 11 December 2020 (UTC)
    •   Comment The motivation section sounds like this property would be more "reason this is not preferred rank" - if this is created, would that be a better label? I assume we have no need for a "reason this is not deprecated rank" property? ArthurPSmith (talk) 19:39, 10 December 2020 (UTC)
      • That would be when users try to add deprecated rank incorrectly, or outright delete nor overwrite a statement. I'm not sure if I should be linking to specific edits here, but I suppose all of you have come across such edits. --- Jura 07:31, 11 December 2020 (UTC)
        • I added some from a P2241 cleanup --- Jura 13:57, 17 December 2020 (UTC)
    •   Oppose This does not seem necessary. reason for deprecation (P2241) is not just about deprecation rank but as can be seen its original proposal it is a reason why it is not the top rank. If there are preferred statements, you can add reason for deprecation (P2241) to any statement that is not preferred to provide a reason why those statements are not preferred, regardless if they are of normal or deprecated rank. I personally think reason for preferred rank (P7452) ought to remove "rank" from the label so it can just provide a reason why a statement is preferred over others, regardless of the actual rank (if there are no preferred ranked statements the normal ones are clearly preferred over deprecated rank ones, etc.). In fact perhaps it would be best if we stepped away from using the same terminology as the ranks are named, e.g., maybe "reason for statement deprecation" and "reason for statement preference" would be better labels. —Uzume (talk) 06:21, 11 December 2020 (UTC)
      • I think in the meantime reason for deprecation (P2241) is only for deprecated rank (see its current description). I'm not convinced that the suggested relative use of the term (and preferred) would help users. --- Jura 07:31, 11 December 2020 (UTC)
        • @Jura1: I do not see the word "rank" anywhere in its current English description (I did not try to grok the myriad of other languages) and the original proposal is quite clear: Wikidata:Property proposal/Archive/38#P2241. —Uzume (talk) 07:47, 11 December 2020 (UTC)
          • The discussion in 2015 was somewhat short. For quite some time, there is a complex constraint [14] for that and I added it to the domain [15]. --- Jura 08:05, 11 December 2020 (UTC)
            • @Jura1: The complex constraint was added after you changed the domain. I wonder how that works when the property is used in a non-qualifier sense. It should be noted the constraints specifically allow its property scope (P5314) as main value (Q54828448) and further it is an instance of (P31) Wikidata property for properties (Q22582645) so presumably this was intended for providing a reason for an entire property to be deprecated and not just specific statements. As far as I know only statements have rankings. I do not thing you did us any service by changing the domain resulting in the complex constraint being developed by @Matěj Suchánek:. It seems you confused things more by focusing on ascribing some sort of meaning to Wikibase statement rankings. —Uzume (talk) 01:28, 12 December 2020 (UTC)
                • I fixed the domain when it was created. Anyways, let's try to stick with the original scope of this discussion: the proposal above. --- Jura 07:43, 12 December 2020 (UTC)
      • @Uzume: If people start using reason for deprecation (P2241) for statements that aren't deprecated that likely leads to increased confusion about ranks and what it means to be deprecated and should be avoided. ChristianKl❫ 10:58, 11 December 2020 (UTC)
        • @ChristianKl: Perhaps (depending on ones point of view) but methinks it is more confusing to introduce another property to label deprecated statements at a normal rank as well as preferred statements at a normal rank. This proposed property could be confusingly interpreted either way. If you look at any dictionary "normal" is always a sticky abstract definition. A reason for normalcy seems even more confusing. Methinks what you are looking for is something more along the lines of "reason for historic statement" to keep people from removing/deleting statements that do not represent the current situation. I personally see this as exactly what reason for deprecation (P2241) was originally intended for. It is unfortunate it got boxed and conflated by the Wikibase statement ranking names. You say it might cause confusion and I won't argue that. There is plenty of room for confusion due to the naming of the Wikibase ranks. However, you will find it much harder to craft machine queries (Wikibase is all about machine readable data) for "outdated" statements since there is no single qualifier property to label them with. Methinks if anything you are creating a system where the data can be more confusingly misinterpreted. From my point of view the Wikibase statement ranks have done much damage. Instead of considering "best" statements by Wikibase rank, we should be considering "best" by qualifiers. —Uzume (talk) 16:18, 11 December 2020 (UTC)
          • @Uzume: Statements at a normal level are not deprecated. Just because Berlin has a population of 3,644,826 in 2019 doesn't mean that the statement that it had a population of 3,644,826 in 2018 is deprecated. It's still a true statement that Berlin had a population of 3,644,826 in 2018.
    An outdated statement has either point in time (P585) or end time (P582) as qualifiers and you can easily query for both if you care about timing.
    If you want to filter more directly you can filter for statement that have start time (P580) but no end time (P582). ChristianKl❫ 16:37, 11 December 2020 (UTC)
    @ChristianKl: I totally agree. My point is that the Wikibase statement rankings have no defined and solid meaning and frankly they shouldn't as that is what qualifiers are for. I really do not think we should have qualifiers that are trying to lock in their meaning. Just add the meaning via qualifiers to begin with. This is why I am opposed to this property proposal as it targets a property for a specific Wikibase statement ranking attempting to give the rankings some more solid meaning when the meaning should be all in the qualifiers and thus we do not need to consider even trying to assign or define meaning to rankings (they are inflexible). We would be far better off having Wikibase ranks removed (and during the interim replaced with a rank qualifier until we can manually replace them with more appropriate qualifers).
    If people start using reason for deprecation (P2241) for statements that aren't deprecated that likely leads to increased confusion about ranks and what it means to be deprecated and should be avoided.
    There is your problem right there. What does "deprecation" even mean? Dictionaries will tell you it means disapproval for something, i.e., it is the opposite of "preference" or "best". But what do any of those really mean? Well they are context dependent. If you want to know the current populate of Berlin, the population from 2018 is deprecated. If you want to know what it was in 2018, then the 2018 statements are preferred, right? So I take objection with deprecated and preferred to begin with but this is only made worse by trying to shoehorn meaning into Wikibase statement rankings. Do you want meaning controlled by the Wikibase software or by Wikidata community and the statements they curate? As soon as you attempt to assign meaning to such a field you give it power. Let's not give power to a very small and inflexible Wikibase statement ranking system and instead embrace qualifiers that we can design and assign meaning to. —Uzume (talk) 17:37, 11 December 2020 (UTC)
    If I want to know the current population of Berlin then I don't disapprove if someone tells me "the population from 2018 is X". It's not the answer to the question I asked but it's not a wrong answer. Deprecation is for statements that are actually wrong.
    The ability to get single values to queries via wdt is quite useful and we essentially would get rid of that if we would get rid of ranks. ChristianKl❫ 18:22, 11 December 2020 (UTC)
    @ChristianKl: If something is actually wrong it would be better to correct it or remove/delete it than mark it with some sort of deprecation. As for your other assertion about getting single values, as far as I know there is no interface that guarantees such a thing. There are things like mw.wikibase.getBestStatements that return a set of statements filtered by "best" rank. It would be easy enough to have different qualifier based filters instead. I believe something similar can be done in SPARQL queries. There is nothing wrong with having multiple statements with the same claim/property and the same rank—even if that rank is preferred or the highest rank. Different statements might be preferred for different reasons. In fact we have reason for preferred rank (P7452) for such but there again, I question its value as preference is context dependent and thus the meaning should be all in the qualifiers and how you choose to use them. Ascribing meaning to Wikibase ranks is asking for trouble since it will invariably mean one thing in one context/claim, etc. and a different thing elsewhere over and over again effectively conflating and convoluting things. —Uzume (talk) 00:54, 12 December 2020 (UTC)
    @Uzume: Throwing away the research about how claims that serious source make are wrong is very wasteful. Let's say a date of birth (P569) claim is wrong in VIAF and we have a bot that regularly imports data from VIAF. If we just remove the data it will be readded the next time the bot runs. If we deprecate the value it doesn't get readded as normal rank and the people over at VIAF have a chance to notice that a human editor over at Wikidata found that the value is false, so that VIAF can fix their data.
    wdt never returns more then one value. It just gives the truthy value. Seperately, the truthy values seem to be valuable enough that enough people download the dumb of the truthy values that WMDE regularly publishes that dumb separately from the full Wikidata data.
    @ChristianKl: Yes, and that is another type of "deprecation". Just how many should be supported and will every user be schooled on them all? I agree what you are saying about tagging values from external sources that we know to be questionably incorrect is a good thing. But I think we can more flexibly do that with qualifiers rather than depending on Wikibase rankings and trying to ascribe any special meanings to such. I cannot say I have considerable experience with SPARQL query semantics but even there I question the value of assigning meaning to Wikibase statement ranks. —Uzume (talk) 01:39, 12 December 2020 (UTC)
    It's not another type of deprecation. It's the standard deprecation that one does on Wikidata when one finds a wrong claim with a serious source. ChristianKl❫ 02:02, 12 December 2020 (UTC)
    @ChristianKl: This would seem to say otherwise: Special:Search/haswbstatement:P31=Q27949697. Despite your claim, there seem to be a large number (141 by my count) of reasons for deprecation. There is also a slightly shorter list here list of Wikidata reasons for deprecation (Q52105174). Quite a number of those have little to nothing to do with inaccuracies from a source. —Uzume (talk) 06:46, 12 December 2020 (UTC)
    The point of the rank is that a user doesn't have to know about all those possible qualifier values to use them. They would need to know more if we would get rid of ranks. ChristianKl❫ 12:43, 12 December 2020 (UTC)
    •   Comment Interesting discussion as we seem to come to different conclusions about the same question. --- Jura 08:05, 11 December 2020 (UTC)
    •   Comment Just for the scope of this discussion: I added links for "normal", "preferred", "deprecated" and "rank" to the proposal. Maybe we can discuss what "deprecation" means elsewhere --- Jura 07:49, 12 December 2020 (UTC)
    • Template:Commment looks like there is no consensus for this. So, I suppose one must add a "reason for preferred rank" to every preferred statement instead. --- Jura 16:40, 8 January 2021 (UTC)
    • Is there a reason we need separate properties for each rank? Couldn't we rename reason for deprecation (P2241) to "reason for current rank" (and then get rid of reason for preferred rank (P7452))? - Nikki (talk) 14:28, 29 January 2021 (UTC)
      • I   Support Nikki's proposal. --Tinker Bell 23:43, 29 January 2021 (UTC)
      • The point was discussed above. --- Jura 08:05, 30 January 2021 (UTC)

    value is one ofEdit

       Under discussion
    Descriptionqualifier for P1963 that specifies which items and their subclasses are valid values when the object of P1963 is used with instances of P1963's subject
    Data typeItem
    Example 1brain region type (Q103843052) properties for this type (P1963) anatomical location (P927)brain (Q1073)
    Example 2organ region type (Q103938415) properties for this type (P1963) part of (P361)organ (Q712378)
    Example 3MISSING


    Note: What valid means can depend on has quality (P1552).

    In the quest to support metaclasses better in Wikidata I want syntax to specify their meaning better. It's part of the nature of being a brain region that the region is located in the brain. This property is intended to allow to specify this relationship explicitely.

    In other cases the property can be used to present the user with suggestion when they use the object property of the properties for this type (P1963) statement. ChristianKl❫ 13:51, 5 December 2020 (UTC) Tobias1984 (talk) TomT0m (talk) Genewiki123 (talk) Emw (talk) 03:09, 9 September 2014 (UTC) Ruud 16:15, 9 December 2014 (UTC) Emitraka (talk) 14:32, 14 October 2015 (UTC) Bovlb (talk) 19:10, 21 October 2015 (UTC) Peter F. Patel-Schneider (talk) 22:21, 23 October 2015 (UTC) ArthurPSmith (talk) 15:51, 5 November 2015 (UTC) Daniel Mietchen (talk) 20:53, 3 January 2016 (UTC) Harmonia Amanda (talk) 22:00, 27 February 2016 (UTC) Lechatpito (talk) Andrawaag (talk) 14:42, 13 April 2016 (UTC) ChristianKl (talk) 16:22, 6 July 2016 (UTC) Cmungall Cmungall (talk) 13:49, 8 July 2016 (UTC) Cord Wiljes (talk) 16:53, 28 September 2016 (UTC) DavRosen (talk) 23:07, 15 February 2017 (UTC) Vladimir Alexiev (talk) 07:01, 24 February 2017 (UTC) Pintoch (talk) 22:42, 5 March 2017 (UTC) Fuzheado (talk) 14:43, 15 May 2017 (UTC) YULdigitalpreservation (talk) 14:37, 14 June 2017 (UTC) PKM (talk) 00:24, 17 June 2017 (UTC) Fractaler (talk) 14:42, 17 June 2017 (UTC) Andreasmperu Diana de la Iglesia Jsamwrites (talk) Finn Årup Nielsen (fnielsen) (talk) 12:39, 24 August 2017 (UTC) Alessandro Piscopo (talk) 17:02, 4 September 2017 (UTC) Ptolusque 01:47, 14 September 2017 (UTC) Gamaliel (talk) --Horcrux (talk) 11:19, 12 November 2017 (UTC) MartinPoulter (talk) Bamyers99 (talk) 16:47, 18 March 2018 (UTC) Malore (talk) Wurstbruch (talk) 22:59, 4 April 2018 (UTC) Dcflyer (talk) 07:50, 9 September 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) Ninokeys (talk) 00:05, 5 October 2018 (UTC) Buccalon (talk) 14:08, 10 October 2018 (UTC) Jneubert (talk) 06:02, 21 October 2018 (UTC) Yair rand (talk) 00:16, 24 October 2018 (UTC) Tris T7 (talk) ElanHR (talk) 22:05, 26 December 2018 (UTC) linuxo Gq86 Gabrielaltay Liamjamesperritt (talk) 08:44, 21 June 2019 (UTC) ZI Jony Ivanhercaz (Talk) 11:07, 15 July 2019 (UTC) Gaurav (talk) 22:39, 24 August 2019 (UTC) Meejies (talk) 04:38, 29 August 2019 (UTC) Iwan.Aucamp SilentSpike (talk) Tfrancart (talk) Sylvain Leroux TiagoLubiana (talk) 15:12, 2 December 2019 (UTC) Albert Villanova del Moral (talk) 15:43, 6 February 2020 (UTC) Clifflandis (talk) 15:10, 18 February 2020 (UTC) --Tinker Bell 16:48, 23 March 2020 (UTC) SM5POR Mkbergman (talk) 19:17, 10 July 2020 (UTC) Toni 001 (talk) 11:03, 11 July 2020 (UTC) The-erinaceous-one (talk) 22:02, 31 August 2020 (UTC) Cdo256 (talk) 06:26, 8 September 2020 (UTC) Antoine2711 (talk) 17:22, 25 September 2020 (UTC) Rehman 07:15, 12 October 2020 (UTC) Susanna Giaccai (talk) 07:22, 22 October 2020 (UTC) Nomen ad hoc So9q (talk) 10:17, 4 January 2021 (UTC) Simon Cobb (User:Sic19 ; talk page) 18:29, 8 January 2021 (UTC)   Notified participants of WikiProject Ontology


    has surfaceEdit

       Under discussion
    Descriptionthe object is the 2-dimensional surface that partly or completely surrounds the subject in 3-dimensional space
    Data typeItem
    Example 1deltoid muscle (Q130243)surface of deltoid (Q66591974)
    Example 2liver (Q9368)surface of liver (Q66509673)
    Example 3organ (Q712378)surface of organ (Q66515789)
    See alsohas boundary (P4777)


    We currently have no way to model the relationship between deltoid muscle (Q130243) and surface of deltoid (Q66591974) ChristianKl❫ 19:38, 6 December 2020 (UTC)

    ChristianKl (talk) 14:41, 8 July 2016 (UTC) Iwan.Aucamp (talk) 15:13, 22 March 2020 (UTC) Was a bee (talk) 14:48, 23 September 2017 (UTC) Okkn (talk) 02:20, 25 October 2017 (UTC) JS (talk)   Notified participants of WikiProject Anatomy


    •   Support I assume this could be applied to mathematical, as well as biological, objects? ArthurPSmith (talk) 19:24, 7 December 2020 (UTC)
      • @ArthurPSmith: In the current wording it works with 3-dimensional mathematical objects. I'm not sure whether mathematicians define the term surface also for objects that are not 3-dimensional.

    Arthur Rubin
    Nomen ad hoc
    The Anome
    Daniel Mietchen
      Notified participants of WikiProject Mathematics ChristianKl❫ 19:49, 7 December 2020 (UTC)

    •   Support --Tinker Bell 19:37, 7 December 2020 (UTC)
    • I talked with a friend who's a mathematician and now I specified it a bit better. Additionally, I made it explicit that sometimes the surface is not completely surrounding for cases like the surface of the heart that gets pierced by an artery/vein. ChristianKl❫ 18:20, 8 December 2020 (UTC)
    • I switched it to be more open for surfaces that don't completely surround the object. ChristianKl❫ 18:09, 10 December 2020 (UTC)
    •   Oppose How is the proposed property different than has boundary (P4777)? If we want to create a new property specifically for biological items, I'm fine with that, but in mathematical items we should use has boundary (P4777). As far as the mathematical definition of a surface, we define a surface as a two-dimensional space. A surface, however, can be embedded in higher dimensional spaces. So, a sphere is two-dimensional because if you zoom in on the surface it has no thickness--it looks like a 2D plane. We often represent a sphere in three dimensions, however. But we could also put it in four-dimensional space, five-dimensional space, etc. — The Erinaceous One 🦔 09:26, 14 December 2020 (UTC)
    @The-erinaceous-one: has boundary (P4777) was created with idea that it's what you get when you project a 3D entity on a 2D plane. It's intented to be the relationship between Walls of Jerusalem (Q2918723) and Old City (Q213274). ChristianKl❫ 12:47, 14 December 2020 (UTC)
    @ChristianKl: I see. The mathematical definition of "boundary" is much broader than the meaning of has boundary (P4777) that you described because the boundary of an object can n-dimensional with n >= 0 (depending on the object). Semantically, I've never heard anybody say "a <mathematical object> has surface <x>" so it doesn't make sense to try to shoehorn mathematical objects into the proposed property. I would much rather broaden the definition of has boundary (P4777) to allow for mathematical objects in more than two dimensions. — The Erinaceous One 🦔 00:43, 23 December 2020 (UTC)
    @The-erinaceous-one: For objects in the physical world there's a massive difference between being surrounded when you project into 2D and being surrounded in 3D and it doesn't really make sense to model them with the same relation. ChristianKl❫ 01:35, 23 December 2020 (UTC)
    @ChristianKl: I just don't see the number of dimensions as a quality that merits a new property. There are four dimensional objects that have boundaries too. Would we need another new property? In fact, on hyperball (Q3776995) there is the statement: hyperball (Q3776995) has boundary (P4777) n-sphere (Q306610). This means that different instances Q3776995 will have boundaries of various dimensions. How would you propose modeling this? — The Erinaceous One 🦔 12:04, 23 December 2020 (UTC)
    Given the current definition of has boundary (P4777) that comes from it's property discussion hyperball (Q3776995) has boundary (P4777) n-sphere (Q306610) is clearly wrong.
    The relationship between cell (Q7868)cell surface (Q189094) is not the same as the one between Walls of Jerusalem (Q2918723)Walls of Jerusalem (Q2918723). Both cell (Q7868) and Walls of Jerusalem (Q2918723) happen to be items that exist in 3D reality, so it's not possible to unambiguously interfer which meaning is intended when the same property is used. ChristianKl❫ 20:42, 23 December 2020 (UTC)
    @ChristianKl: I think we need reconsider the details of has boundary (P4777). The current description is unclear. The first part says, "element that's on the two dimensional border that surrounds the subject," but the second part says, "the limit of an entity." The meaning of the two parts, together, is ambiguious. The first part states a narrower usage of "has boundary" you described, whereas the second part indicates a broader usage that is in line with the mathematical usage of the "boudary." Additionally, in the has boundary (P4777) property proposal, there wasn't discussion regarding the dimension of the boundary; you mention it once, but nobody else commented on it before the property was created. In other words, there wasn't a consensus at the time that "has boundary" only applies to 2D objects with a 1D boundary (or a 2D projection of a 3D object). (Side note: if we determine P4777 should only apply to a border in a 2D projection, then the description should say, "element on the one-dimensional border that surrounds the subject," since a curve in a plane is a one-dimensional obejct.)
    If we go with the narrow meaing of P4777 then I have two concerns. The first is that it destroys its utiltiy as a mathematical property. Replacing it with "has surface" is better than nothing but it is contrary to the semantics used within mathematics. Secondly, I am concerned about restricting has boundary (P4777) to only the 2D case causes the property to arbitrarily include some types of political/legal boundaries and exclude other types. In particular, consider a fictional Sci-Fi universe with boundaries between nations "X" and "Y" in outer space. The "X-Y boundary" would be a 2D boundary in 3D space and the relationship between "X" and "X-Y boundary" is exactly the same as the relationship between "the US" and the "US-Mexico border." Similar cases also arise in the real world when you consider the vertical boundaries of a piece of property or nation [16]. Allowing P4777 to use the broader meaning would increase its usefulness without requiring a proliferation of properties.
    Regarding the ambiguity you mentioned, I don't see this being a real source of confusion (for humans). It is usually clear when we talk about the boundary of a geographic item, we are talking about the boundary of the projection on the map. If it's not clear, we could make it explicit by adding a qualifier along the lines of United States has border US-Mexico border / with respect to map projection. — The Erinaceous One 🦔 12:30, 26 December 2020 (UTC)

    insufficiently precise valueEdit

       Under discussion
    Descriptionqualifier for P1963 that specifies which items are not precise enough
    Data typeItem
    Example 1anatomical structure type (Q103813670) properties for this type (P1963) anatomical location (P927)body (Q170494)
    Example 2MISSING
    Example 3MISSING


    While techincally all cells are located within the body, anatomical structure type (Q103813670) should only apply to those entities that have a more specific location within the body. This is my attempt for creating syntax to express this. ChristianKl❫ 07:56, 8 December 2020 (UTC) ChristianKl (talk) 14:41, 8 July 2016 (UTC) Iwan.Aucamp (talk) 15:13, 22 March 2020 (UTC) Was a bee (talk) 14:48, 23 September 2017 (UTC) Okkn (talk) 02:20, 25 October 2017 (UTC) JS (talk)   Notified participants of WikiProject Anatomy


    applies when property is usedEdit

       Under discussion
    Descriptionqualifier for P1963(properties for this type), that specifies that P1963 only count when the instance of P1963's subject has a statement with the following property
    Data typeProperty
    Example 1anatomical line type (Q104012628) properties for this type (P1963) length (P2043)found in taxon (P703)
    Example 2anatomical surface type (Q103919392) properties for this type (P1963) area (P2046)found in taxon (P703)
    Example 3human (Q5)properties for this type (P1963) place of birth (P19)date of birth (P569)


    For a given species a anatomical line type (Q104012628) like radial border of forearm (Q66572540) has an average length. Having a length seems to be part what the nature of a line is about. However speaking of length makes less sense when not speaking about a specific species. This syntax is indended to qualify this.

    Apart from that it can only be used in cases where properties for this type (P1963) gets used for suggesting properties to a user. In a case like human (Q5) this means that it's easier to give a user good suggestions. ChristianKl❫ 15:20, 10 December 2020 (UTC) Tobias1984 (talk) TomT0m (talk) Genewiki123 (talk) Emw (talk) 03:09, 9 September 2014 (UTC) Ruud 16:15, 9 December 2014 (UTC) Emitraka (talk) 14:32, 14 October 2015 (UTC) Bovlb (talk) 19:10, 21 October 2015 (UTC) Peter F. Patel-Schneider (talk) 22:21, 23 October 2015 (UTC) ArthurPSmith (talk) 15:51, 5 November 2015 (UTC) Daniel Mietchen (talk) 20:53, 3 January 2016 (UTC) Harmonia Amanda (talk) 22:00, 27 February 2016 (UTC) Lechatpito (talk) Andrawaag (talk) 14:42, 13 April 2016 (UTC) ChristianKl (talk) 16:22, 6 July 2016 (UTC) Cmungall Cmungall (talk) 13:49, 8 July 2016 (UTC) Cord Wiljes (talk) 16:53, 28 September 2016 (UTC) DavRosen (talk) 23:07, 15 February 2017 (UTC) Vladimir Alexiev (talk) 07:01, 24 February 2017 (UTC) Pintoch (talk) 22:42, 5 March 2017 (UTC) Fuzheado (talk) 14:43, 15 May 2017 (UTC) YULdigitalpreservation (talk) 14:37, 14 June 2017 (UTC) PKM (talk) 00:24, 17 June 2017 (UTC) Fractaler (talk) 14:42, 17 June 2017 (UTC) Andreasmperu Diana de la Iglesia Jsamwrites (talk) Finn Årup Nielsen (fnielsen) (talk) 12:39, 24 August 2017 (UTC) Alessandro Piscopo (talk) 17:02, 4 September 2017 (UTC) Ptolusque 01:47, 14 September 2017 (UTC) Gamaliel (talk) --Horcrux (talk) 11:19, 12 November 2017 (UTC) MartinPoulter (talk) Bamyers99 (talk) 16:47, 18 March 2018 (UTC) Malore (talk) Wurstbruch (talk) 22:59, 4 April 2018 (UTC) Dcflyer (talk) 07:50, 9 September 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) Ninokeys (talk) 00:05, 5 October 2018 (UTC) Buccalon (talk) 14:08, 10 October 2018 (UTC) Jneubert (talk) 06:02, 21 October 2018 (UTC) Yair rand (talk) 00:16, 24 October 2018 (UTC) Tris T7 (talk) ElanHR (talk) 22:05, 26 December 2018 (UTC) linuxo Gq86 Gabrielaltay Liamjamesperritt (talk) 08:44, 21 June 2019 (UTC) ZI Jony Ivanhercaz (Talk) 11:07, 15 July 2019 (UTC) Gaurav (talk) 22:39, 24 August 2019 (UTC) Meejies (talk) 04:38, 29 August 2019 (UTC) Iwan.Aucamp SilentSpike (talk) Tfrancart (talk) Sylvain Leroux TiagoLubiana (talk) 15:12, 2 December 2019 (UTC) Albert Villanova del Moral (talk) 15:43, 6 February 2020 (UTC) Clifflandis (talk) 15:10, 18 February 2020 (UTC) --Tinker Bell 16:48, 23 March 2020 (UTC) SM5POR Mkbergman (talk) 19:17, 10 July 2020 (UTC) Toni 001 (talk) 11:03, 11 July 2020 (UTC) The-erinaceous-one (talk) 22:02, 31 August 2020 (UTC) Cdo256 (talk) 06:26, 8 September 2020 (UTC) Antoine2711 (talk) 17:22, 25 September 2020 (UTC) Rehman 07:15, 12 October 2020 (UTC) Susanna Giaccai (talk) 07:22, 22 October 2020 (UTC) Nomen ad hoc So9q (talk) 10:17, 4 January 2021 (UTC) Simon Cobb (User:Sic19 ; talk page) 18:29, 8 January 2021 (UTC)   Notified participants of WikiProject Ontology


    WMF hosted image that could be added to CommonsEdit

       Under discussion
    Descriptionurl of an image that could be added or moved to Wikimedia Commons from another WMF wiki
    RepresentsProject:Moving files to Commons (Q104205600)
    Data typeURL
    Allowed valuesURL to images at Wikipedia and other WMF wikis:
    Example 1Jacob Bunn (Q104008565)
    Example 22014 Mount Everest avalanche (Q16448748)
    Example 3MISSING
    See also
    • Commons compatible image available at URL (P4765): image with Commons compatible copyright status is available at the following URL. It could be uploaded to Commons to illustrate the item
    • Wikimedia import URL (P4656): URL of source to indicate the page or revision of an import source from another Wikimedia project (except actual references, such as Wikisource source texts). Use instead of "reference URL" (P854)


    Following the discussion at Wikidata:Property proposal/Commons compatible image available at URL (non-artwork) about the existing Commons compatible image available at URL (P4765), the above seems a more suitable set of images that could be handled with the same tools. (Add your motivation for this property here.) --- Jura 12:07, 14 December 2020 (UTC)


    property related to this topicEdit


    User_talk:GZWDer#Why_replace_the_template_for_Wikiprojects? suggesting moving contents of property navboxes to some Wikidata item. But I am not sure the data should go to the subject item or items about specific classes of Wikidata properties. @Jura1, ChristianKl:.GZWDer (talk) 21:11, 17 December 2020 (UTC)

    • Con for Option 1: this will blow up existing items about main topic (e.g. there are several hundred properties about a topic). In addition the main topic item may be very large (country item may be several MB) and it may (or may not) be inefficient to use them in navboxes.
    • Con for Option 2: we will need to create several hundred new items for property classes (one for each row of navbox). Currently "property classes" are already ill-managed and this may open a floodgate to create very narrow classes.

    --GZWDer (talk) 21:19, 17 December 2020 (UTC)


    •   Comment How about items like Template:Anatomy properties (Q104230796) ? --- Jura 21:50, 17 December 2020 (UTC)
      • @Jura1: This does not handle specific rows.--GZWDer (talk) 21:52, 17 December 2020 (UTC)
        • The values could be qualified. --- Jura 21:55, 17 December 2020 (UTC)
          I added a couple of sandbox statements to the item. --- Jura 07:07, 18 December 2020 (UTC)

    Religious leadershipEdit

       Under discussion
    Descriptionleader for a religious organization
    Representsreligious leader (Q15995642)
    Data typeItem
    Allowed valuesinstances of human (Q5)
    Example 1A Casa dos Caboclos (Q104419272) → Jandira Maria Santos e Santos
    Example 2Aba Funjá (Q104419273) → Eurivaldina Pereira
    Example 3Abaça Amazi (Q104419274) → Aida Almeida Costa
    Planned useI'm currently working on uploading over 1.1k items regarding Candomblé terreiros (temples) in Bahia, Brazil. If this proposal is accepted, I'll add this property to all of them.
    See alsoWikidata:Property proposal/Regente, Wikidata:Property proposal/Nação_(candomblé)


    A candomblé terreiro's (temple) leader is it's religious leader. This property will allow us to enunciate who is the person responsible for leading a terreiro, which is an essential part of describing a terreiro's structure.


    •   Oppose string is not suitable for storing a person. Creating items about the individual people is the better approach and we already have plenty of leadership properties that can be used. If none of the existing one's are suitable, please explain why they aren't. ChristianKl❫ 23:16, 23 December 2020 (UTC)
    •   Comment I agree that string is not ideal. What other property could be used to express this relationship? NMaia (talk) 03:05, 24 December 2020 (UTC)
      • director / manager (P1037) does fullfil the requirements. If there are more specific requirements those should be expressed. ChristianKl❫ 13:28, 24 December 2020 (UTC)
        • @ChristianKl, NMaia: Thank you for the input! We don't have any information whatsoever on these people other than their name. Is creating individual items still the best approach in such cases? I've tweaked the proposal so that it's more clear (apologies for that) and also has a broader scope. It's meant to differ from director / manager (P1037) in that it applies to people who act as religious leaders. VStocco (WMB) (talk) 17:13, 5 January 2021 (UTC)
          • Yes, individual items are still the best approach. Just because you don't know anything more then their names doesn't mean that other people won't add more information to the items of the people. Wikidata is not about adding an isolated data set but a place where different items can get connected. ChristianKl❫ 20:41, 5 January 2021 (UTC)
          • If I understand right then Candomblé terreiro (Q3208559) is something like a temple. Does it have a spiritual leader that's separate from the worldly leader? If so I can see how a new property makes sense. If it just has one leader I don't see why the property should be more specific. ChristianKl❫ 12:12, 7 January 2021 (UTC)
            • I have switched the data type to item. And, yes, precisely! Candomblé terreiro (Q3208559) is a place of worship for the Camdomblé religion. Liderança / leader is how they refer to their priests. This leader is responsible for both religious and secular activities. It would seem improper to have a church's head priest listed as the location's manager. It comes across as a fully worldly activity -- it would give users the wrong impression. Likewise, a user accessing Abaça Amazi (Q104419274) and seeing "Aida Almeida Costa" as it's director / manager (P1037) would very likely assume that Aida is the one responsible for managing the day-to-day aspects of the location itself, and not the religious rites held at that place. VStocco (WMB) (talk) 11:58, 11 January 2021 (UTC)


       Under discussion
    DescriptionGuiding orixá or nkisi adopted by the subject
    Data typeItem
    DomainCandomblé terreiro (Q3208559)
    Allowed valuesinstances of Orisha (Q290460), Nkisi (Q1460155) and Caboclo (Q104439732)
    Example 1A Casa dos Caboclos (Q104419272)Ogun (Q255116)
    Example 2Aba Funjá (Q104419273)Oshun (Q1851943)
    Example 3Abaça Amazi (Q104419274)Oshun (Q1851943)
    Planned useI'm currently working on uploading over 1.1k items regarding Candomblé terreiros (temples) in Bahia, Brazil. If this proposal is accepted, I'll add this property to all of them.
    Robot and gadget jobsRobots can check if the property is being used to designate an Orisha (Q290460), Nkisi (Q1460155) or Caboclo (Q104439732) as regent of an item.
    See alsoWikidata:Property proposal/Liderança, Wikidata:Property proposal/Nação_(candomblé)


    Candomblé terreiros (temples) usually have one or more guiding orixá, who is the deity of their worship. This is an essential part of a terreiro's characterization. The closest existing property I could find is patron saint (P417), which is exclusive to Christianity.


    Candomblé nationEdit

       Under discussion
    Descriptionsegment of the Candomblé religion from which the terreiro originated
    RepresentsNation (candomblé) (Q10335893)
    Data typeItem
    Domaininstances of Candomblé terreiro (Q3208559)
    Allowed valuesinstances of Nation (candomblé) (Q10335893)
    Example 1A Casa dos Caboclos (Q104419272)Candomblé Ketu (Q104439218)
    Example 2Aba Funjá (Q104419273)Ijexá (Q104439225)
    Example 3Abaça Amazi (Q104419274)Candomblé Bantu (Q104439226)
    Planned useI'm currently working on uploading over 1.1k items regarding Candomblé terreiros (temples) in Bahia, Brazil. If this proposal is accepted, I'll add this property to all of them.
    See alsoWikidata:Property proposal/Regente, Wikidata:Property proposal/Liderança


    In the context of candomblé, nation distinguishes different segments within the religion. It differs from country of origin (P495) in that it doesn't refer to a geographic location, but rather a culture, or group of people from which that specific practice of candomblé was originated. A candomblé terreiro's (temple) nation is essential to its characterization, as it reflects different dialects and rituals that might take place in said location.  – The preceding unsigned comment was added by VStocco (WMB) (talk • contribs) at 14:11, December 23, 2020‎ (UTC).


    •   Oppose with those names. The English word nation has a lot to do with nationality and is problematic for the reasons discussed in ChristianKl❫ 23:12, 23 December 2020 (UTC)
    •   Support I took the liberty of tweaking the labels. NMaia (talk) 02:57, 24 December 2020 (UTC)
      • I think this still needs an explanation of what a candomble nation happens to be in the property description. ChristianKl❫ 13:25, 24 December 2020 (UTC)
    •   Support The topic that this property touches is very fragile and marginalized. This property, and the others correlated to it are very important to preserve this knowledge. I made few adjustments. Good contributions, Ederporto (talk) 07:26, 7 January 2021 (UTC)

    YouTube custom URLEdit

       Under discussion
    DescriptionCustom URL of the YouTube channel of a person or organisation. Google documentation for it can be found here.
    Data typeString
    Domainhuman (Q5), organization (Q43229)
    Allowed values[a-zA-Z-_0-9]+
    Example 1Brown Eyed Girls (Q483253) → officialBEG (site:
    Example 2Greenpeace (Q81307) → Greenpeace (site:
    Example 3 
    Formatter URL$1
    See alsoYouTube channel ID (P2397)


    The YouTube channel can either have a username, a channel ID, or a custom URL. Channel ID already has a property for it, and it's somewhat related to the username, since one can find the ID from the username. Custom URL, on the other hand, is a completely independent user-created name, so it requires a separate property for it. It is also used as a template parameter on Wikipedia, as can be seen here. —capmo (talk) 16:07, 28 December 2020 (UTC)


    •   Comment we had this at Wikidata:Property proposal/YouTube Username ID (plus a series of proposals discussed there). --- Jura 16:46, 28 December 2020 (UTC)
      Hi Jura, I understand the problem behind having multiple values for a single entity, but that's what we have bots for. Regular Wikipedia users won't make the conversion from the friendlier username or custom URL to the cumbersome channel ID in the articles they edit. We should import whichever value is informed in Template:YouTube and then a bot can do the conversion. —capmo (talk) 22:18, 28 December 2020 (UTC)
      Actually, there is a bot that does that. No additional property needed. --- Jura 10:44, 30 December 2020 (UTC)
      That's good. I know that the username -> channel ID conversion is feasible, but does it also convert custom URL into channel ID? If so, then I concur that this property won't be necessary. —capmo (talk) 22:21, 30 December 2020 (UTC)
      • @Mbch331: what do you think? If not, it can still be added   Oppose --- Jura 23:11, 31 January 2021 (UTC)
      • @Jura1: if you enter the full custom url, it will be converted to the correct channel id. My bot doesn't use the API, but fetches the information from the source code of the website. Mbch331 (talk) 11:40, 1 February 2021 (UTC)
    •   Comment The custom URL can be converted into YouTube channel ID (P2397) very easily. In the example, you got Brown Eyed Girls (Q483253) → officialBEG (site: but by simply searching the name on YouTube ( and clicking into the channel again or reloading the channel site, you can find the YouTube channel ID (P2397) (UCepFAcPmJZz46lJN5gdv1Cg). Sun8908 💬 02:38, 5 January 2021 (UTC)
      Thanks for the test, Sun8908. I think a bot will be able to do this conversion pretty easily. I just don't see the problem in having this info stored locally at wikidata. See for example the case of duplicate VIAF records for a single person. If both VIAF IDs are stored on an item, eventually they get merged at too and a bot removes the merged ID from the item here. The same could be done with YouTube channel identifiers: all three ones could be allowed on wikidata, and a bot would deal with the conversions to channel ID (the only one that's guaranteed to be unique). Then, the username/custom URL could be removed, or kept for historical reasons. —capmo (talk) 13:45, 5 January 2021 (UTC)
      @Sun8908: You can do that much easier by opening page code and search for <link rel="canonical" href="; moreover this tag is standardized in web. And given that 1) Youtube itself considers only /channel/ ids as canonical and 2) it is trivial to convert slug to channel id, the situation differs from Twitter user numeric ID (P6552). And due to low added value and all above-mentioned,   Weak oppose. --Lockal (talk) 08:11, 8 January 2021 (UTC)
      Oh! I just found that Help:P2397 also states that by viewing any video on the channel and clicking on the user name below it, the URL will become Maybe an explanation of converting custom URL to channel ID can be added to the help page. I think another property would be redundant, thus,   Oppose. Sun8908 💬 07:20, 27 February 2021 (UTC)
    •   Support Assuming that some people have or will have some use of that new property in Wikidata. It seems useful per se as there doesn't seem to be another way to express that information. GNUtoo (talk) 20:49, 12 January 2021 (UTC)
    •   Weak oppose I dont really see the value of this, using the channel id we can already map between our Q items and the youtube channel. What additional value does this bring that we did not have before? Why not use a qualifier for the youtube channel such as pseudonym (P742), name (P2561), nickname (P1449) or alternate names (P4970) which all seem to cover exactly this case. --Hannes Röst (talk) 17:50, 4 March 2021 (UTC)

    last name(s) stated asEdit

       Under discussion
    DescriptionThe last name(s) of the author
    Data typeString
    Template parameter'last-N' parameter in en:Template:Cite Q
    Allowed valuesOnly as qualifiers of author name string (P2093) and author (P50)
    Example 1The South Pole Telescope (Q55893751) author name string (P2093) → John Ruhl → 'Ruhl'
    Example 2The South Pole Telescope (Q55893751) author name string (P2093) → Peter A. R. Ade → 'Ade'
    Example 3Prostetic Rehabilitation of an Eye Globe: Case Report (Q89819389) author name string (P2093) → Clovis Lamartine de Moraes Melo Neto → 'de Moraes Melo Neto'
    Example 4Tear Strength Analysis of MDX4-4210 and A-2186 Silicones with Different Intrinsic Pigments Incorporated by Mechanical and Industrial Methods (Q92616544) author (P50) → Marcelo Coelho Goiato → 'Goiato'
    Example 5An EAR-motif-containing ERF transcription factor affects herbivore-induced signaling, defense and resistance in rice. (Q52725820) author name string (P2093) → Yonggen Lou → 'Lou' (N.B. author's entry is Lu Yonggen (Q9116274) in Chinese name order)
    SourceBibtex references
    Planned useImplementation in Template:Cite Q
    Robot and gadget jobsI will propose a task for Pi bot that will populate this
    See alsostated as (P1932)
    Single value constraintyes


    We have been working on Template:Cite Q improvements over the last few months. One request has been particularly challenging: how do we go from author names in the 'First Last' format to 'Last, First'? This is particularly important so that we can match different citation styles in use in articles, which seems to be a blocking issue for using Cite Q more widely.

    We currently store author names in stated as (P1932), however it is impossible to automatically determine the first/last name parts of these strings. The good news is that this information is held in the bibtex references for the publications, so we can import it from there, but we need to have a suitable property to import it to.

    This would be set as a qualifier of author name string (P2093) and author (P50) (it is important that it is within the publication item due to technical limitations with fetching values from items linked by author (P50)). Only one qualifier would be used for each author, multiple surnames would be contained in a single value.

    Values would be imported by bot (I will propose a bot task to do this if this property is accepted). It is accompanied by a property proposal for the first name(s) (Wikidata:Property proposal/Author first names). It could either supplement or replace stated as (P1932) (I have no preference either way).

    Thanks. Mike Peel (talk) 18:26, 28 December 2020 (UTC)

    Mattsenate (talk) 13:11, 8 August 2014 (UTC)
    KHammerstein (WMF) (talk) 13:15, 8 August 2014 (UTC)
    Mitar (talk) 13:17, 8 August 2014 (UTC)
    Mvolz (talk) 18:07, 8 August 2014 (UTC)
    Daniel Mietchen (talk) 18:09, 8 August 2014 (UTC)
    Merrilee (talk) 13:37, 9 August 2014 (UTC)
    Pharos (talk) 14:09, 9 August 2014 (UTC)
    DarTar (talk) 15:46, 9 August 2014 (UTC)
    HLHJ (talk) 09:11, 11 August 2014 (UTC)
    Blue Rasberry 18:02, 11 August 2014 (UTC)
    JakobVoss (talk) 12:23, 20 August 2014 (UTC)
    Finn Årup Nielsen (fnielsen) (talk) 02:06, 23 August 2014 (UTC)
    Jodi.a.schneider (talk) 09:24, 25 August 2014 (UTC)
    Abecker (talk) 23:35, 5 September 2014 (UTC)
    Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:21, 24 October 2014 (UTC)
    Mike Linksvayer (talk) 23:26, 18 October 2014 (UTC)
    Kopiersperre (talk) 20:33, 20 October 2014 (UTC)
    Jonathan Dugan (talk) 21:03, 20 October 2014 (UTC)
    Hfordsa (talk) 19:26, 5 November 2014 (UTC)
    Vladimir Alexiev (talk) 15:09, 23 January 2015 (UTC)
    Runner1928 (talk) 03:25, 6 May 2015 (UTC)
    Pete F (talk)
    econterms (talk) 13:51, 19 August 2015 (UTC)
    Sj (talk)
    addshore 17:43, 18 January 2016 (UTC)
    Bodhisattwa (talk) 16:08, 29 January 2016 (UTC)
    Ainali (talk) 16:51, 29 January 2016 (UTC)
    Shani Evenstein (talk) 21:29, 5 July 2018 (UTC)
    Skim (talk) 07:17, 6 November 2018 (UTC)
    PKM (talk) 23:19, 19 November 2018 (UTC)
    Ocaasi (talk) 22:19, 29 November 2018 (UTC)
    Trilotat Trilotat (talk) 15:43, 16 February 2019 (UTC)
    Alessandra Boccone