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/05.

GeneralEdit

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
Domainany
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)

MotivationEdit

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

DiscussionEdit

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)

Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Nomen ad hoc
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Haansn08
Xenmorpha
John Samuel
Jeremy Dover
  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).

armament usedEdit

   abandoned
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

MotivationEdit

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

DiscussionEdit

  • 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 https://www.wikidata.org/wiki/Q816695.--So9q (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)

  Support I think this could be used for armanents used to affect non-human items, so this can be used where armament (P520) cannot. ERBuermann (talk) 17:52, 6 May 2021 (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)

MotivationEdit

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

DiscussionEdit

  •   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) Luis.ramos.pst.ag 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) Andrew Eells (User:AndrewEells ; talk page) 15:35, 7 April 2021 (UTC) RShigapov 9:48, 8 April 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
WHERE
{
  VALUES ?searched_unit { wd:Q800000000 }
  {
    ?item wdt:P131* ?searched_unit .                 # located in the searched unit 
  }
  MINUS
  {
    ?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
WHERE
{
  ?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)

MotivationEdit

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)

DiscussionEdit

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)

MotivationEdit

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)

DiscussionEdit

  •   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

MotivationEdit

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)

DiscussionEdit

  •   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)
  •   Comment How do we handle other demographic information, like births, voting eligible population, employed, etc? I'd like to be consistent with those (if they exist). JesseW (talk) 14:21, 19 March 2021 (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 https://w.wiki/aZs
See alsorefine date (P4241)

MotivationEdit

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)

DiscussionEdit

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)

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

MotivationEdit

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.

ChristianKl
ArthurPSmith
d1g
JakobVoss
Jura
Jsamwrites
MisterSynergy
Salgo60
Harshrathod50
Wildly boy
ZI Jony
Ederporto
99of9
Danrok
Eihel
Emw
Fralambert
GZWDer
Ivan A. Krestinin
Jonathan Groß
Joshbaumgartner
Kolja21
Kristbaum
MSGJ
Mattflaschen
MichaelSchoenitzer
Nightwish62
Pablo Busatto
Paperoastro
PinkAmpersand
Srittau
Thierry Caro
Tobias1984
Vennor
Yellowcard
Ivanhercaz
DannyS712
Tinker Bell
Bodhisattwa
Iwan.Aucamp
Cunme
NAH
Gnoeee
The-erinaceous-one
-akko
  Notified participants of WikiProject Properties ChristianKl❫ 10:40, 27 June 2020 (UTC)

DiscussionEdit

  •   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)
  •   Support I support this --Uni3993 (talk) 07:29, 8 March 2021 (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 mediawiki.org 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)

certified asEdit

   Under discussion
Descriptionstates that an item has a certain certification
Representscertification (Q374814)
Data typeItem
Domainitem
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)

MotivationEdit

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)

DiscussionEdit

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)
  •   Support, an important property for education.--Arbnos (talk) 17:43, 27 April 2021 (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
Domainproperty
Allowed values\d{10}
Example 1Ken Klippenstein (Q97940221)tel:2025101268
Example 2Micah Lee (Q15834986)tel:4159420460
Example 3Muck Rack (Q57500196)tel:2125001883
Sourcehttps://en.wikipedia.org/wiki/Signal_(software)
Planned useUse it on Ken Klippenstein (Q97940221)
See alsophone number (P1329), fax number (P2900), TDD number (P8659)

MotivationEdit

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)

DiscussionEdit

  •   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. https://www.nytimes.com/tips. 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 https://theintercept.com/2017/09/28/signal-tutorial-second-phone-number/). QRep2020 (talk) 04:34, 19 December 2020 (UTC)
  •   Oppose I am convinced by Uzume's suggestions to use a qualifier. The existence of one redundant property fax number (P2900) doesn't mean we should create another. And creating a separate property for some phone numbers just makes it harder for users of our data to understand it, not easier. JesseW (talk) 21:08, 14 March 2021 (UTC)

Edit

   Under discussion
Descriptiontranscription of text from an advertisement
Data typeMonolingual text
Example 1Heresies 4 Gaysweek advertisement URI (ex. https://iiif.archivelab.org/iiif/heresies_04$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. https://iiif.archivelab.org/iiif/heresies_06$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. https://iiif.archivelab.org/iiif/heresies_06$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. https://iiif.archivelab.org/iiif/heresies_06$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 (https://archive.org/details/heresies_magazine)) in our linked data triples.
See alsocatchphrase (P6251), motto text (P1451)

MotivationEdit

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)

DiscussionEdit

Valentina.Anitnelav Thierry Caro Shisma (talk) Arlo Barnes (talk) Tsaorin (talk) 16:37, 12 November 2019 (UTC) Nomen ad hoc SilentSpike (talk) 10:40, 9 May 2021 (UTC)   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)

MotivationEdit

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)

DiscussionEdit

  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)

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)

MotivationEdit

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).

DiscussionEdit

  •   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)

ПобудаEdit

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)

DiscussionEdit

  • 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)

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
⟨ change.org (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 ⟩

MotivationEdit

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)

DiscussionEdit

  •   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)

curidEdit

   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)

MotivationEdit

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)

DiscussionEdit

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 1AS.com 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

itempropEdit

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

MotivationEdit

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)

DiscussionEdit

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

MotivationEdit

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)

DiscussionEdit

  •   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 [11] for that and I added it to the domain [12]. --- 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)
  •   Comment 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

MotivationEdit

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) Luis.ramos.pst.ag 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) Andrew Eells (User:AndrewEells ; talk page) 15:35, 7 April 2021 (UTC) RShigapov 9:48, 8 April 2021 (UTC)   Notified participants of WikiProject Ontology

DiscussionEdit

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)

MotivationEdit

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

DiscussionEdit

  •   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.

Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Nomen ad hoc
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Haansn08
Xenmorpha
John Samuel
Jeremy Dover
  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 [13]. 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

MotivationEdit

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

DiscussionEdit

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)

MotivationEdit

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) Luis.ramos.pst.ag 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) Andrew Eells (User:AndrewEells ; talk page) 15:35, 7 April 2021 (UTC) RShigapov 9:48, 8 April 2021 (UTC)   Notified participants of WikiProject Ontology

DiscussionEdit

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
Domainany
Allowed valuesURL to images at Wikipedia and other WMF wikis:
https://.+(mediawiki|wik(i(books|(m|p)edia|news|quote|source|versity|voyage)|tionary))\.org/wiki/File:.+
Example 1Jacob Bunn (Q104008565)https://en.wikipedia.org/wiki/File:JacobBunn.jpg
Example 22014 Mount Everest avalanche (Q16448748)https://en.wikipedia.org/wiki/File:Everest3d_qbd_2014116.jpg
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). Permalinks are preferred.

MotivationEdit

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)

DiscussionEdit

property related to this topicEdit

MotivationEdit

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)

DiscussionEdit

  •   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é)

MotivationEdit

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.

DiscussionEdit

  •   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)

  Comment Can the distinction between secular and religious leadership be handled with a qualifier, maybe something like scope=religious? JesseW (talk) 13:59, 19 March 2021 (UTC)

  •   Support. Mas o rótulo deveria ser "liderança religiosa", para não confundir e ser usado em relação a situações de lideranças em outros campos. --Luan (talk) 03:24, 24 March 2021 (UTC)

RegentEdit

   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é)

MotivationEdit

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.

DiscussionEdit

  •   Support --Luan (talk) 03:23, 24 March 2021 (UTC)

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

MotivationEdit

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).

DiscussionEdit

  •   Oppose with those names. The English word nation has a lot to do with nationality and is problematic for the reasons discussed in https://www.wikidata.org/wiki/Wikidata:Property_proposal/nationality_(cultural_identity). 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)
  •   Support --Luan (talk) 03:22, 24 March 2021 (UTC)
  •   Strong support This is a really helpful proposal. Prburley (talk)

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: https://www.youtube.com/c/officialBEG)
Example 2Greenpeace (Q81307) → Greenpeace (site: https://www.youtube.com/c/Greenpeace)
Example 3 
SourceYouTube
Formatter URLhttps://www.youtube.com/c/$1
See alsoYouTube channel ID (P2397)

MotivationEdit

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)

DiscussionEdit

  •   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: https://www.youtube.com/c/officialBEG) but by simply searching the name on YouTube (https://www.youtube.com/results?search_query=Brown+Eyed+Girls) 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 viaf.org 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="https://www.youtube.com/channel/...; 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 https://www.youtube.com/channel/.... 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)
      Comment The custom URL is the only information found in a couple of Wikipedia articles I've seen. If this property is available here, I'll gladly add such information to the corresponding Wikidata item, but I won't take the time to make the tedious conversion to channel ID, which could well be done by a bot. That's the only motivation behind my request above. —capmo (talk) 16:00, 16 March 2021 (UTC)

last name(s) stated asEdit

   Ready Create
Descriptionqualifier to provide string representation of family or primary sorting portion of name as represented in a bibliographic reference file (for example BibTeX)
Data typeString
Template parameter'last-N' parameter in en:Template:Cite Q
Domainwork (Q386724)
Allowed valuesany string that may appear in a name (including spaces and periods)
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

MotivationEdit

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)
TomT0m
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)
NAH
Iwan.Aucamp
Alessandra Boccone
Pablo Busatto (talk) 05:40, 23 June 2020 (UTC)
Blrtg1 (talk) 17:20, 23 July 2020 (UTC)
Kosboot (talk) 21:32, 23 July 2020 (UTC)
Matlin (talk) 09:38, 11 August 2020 (UTC)
Carrierudd(talk) 11:44, 3 November 2020 (UTC)
So9q (talk) 11:35, 16 January 2021 (UTC)
pdesai (talk) 16:00, 8 February 2021 (UTC)
  Notified participants of WikiProject Source MetaData and LeadSongDog (talk) 21:42, 23 March 2016 (UTC)
RobLa-WMF (talk) 01:24, 25 March 2016 (UTC)
Kosboot (talk) 20:45, 30 March 2016 (UTC)
Sydney Poore/FloNight♥♥♥♥ 15:10, 14 April 2016 (UTC)
Peaceray (talk) 18:40, 28 April 2016 (UTC)
PKM (talk) 16:29, 1 May 2016 (UTC)
Aubrey (talk) 12:42, 25 August 2016 (UTC)
Chiara (talk) 12:47, 25 August 2016 (UTC)
Marchitelli (talk) 19:02, 1 September 2016 (UTC)
YULdigitalpreservation (talk) 17:44, 9 December 2016 (UTC)
Satdeep Gill (talk) 14:59, 2 February 2017 (UTC)
Raymond Ellis (talk) 16:06, 1 April 2017 (UTC)
Crazy1880 (talk) 18:21, 16 June 2017 (UTC)
T Arrow (talk) 07:55, 22 June 2017 (UTC)
GerardM (talk) 08:25, 30 July 2017 (UTC) With a particular interest of opening up sources about Botany and opening up any freely licensed publications.
Clifford Anderson (talk) 18:26, 11 August 2017 (UTC)
Jsamwrites (talk) 07:52, 27 August 2017 (UTC)
Krishna Chaitanya Velaga (talk) 09:52, 19 September 2017 (UTC)
Capankajsmilyo (talk) 18:32, 19 September 2017 (UTC)
Hsarrazin (talk) 20:41, 15 October 2017 (UTC)
Mlemusrojas (talk) 10:15, 6 December 2017 (UTC)
Samat (talk)
Ivanhercaz   (Talk) 20:27, 25 December 2017 (UTC)
Simon Cobb (User:Sic19 - talk page) 21:20, 21 January 2018 (UTC)
Mahdimoqri (talk) 20:22, 26 March 2018 (UTC)
Maria zaos (talk) 18:45, 9 April 2018 (UTC)
Jaireeodell (talk) 14:07, 23 April 2018 (UTC)
Egon Willighagen (talk) 12:29, 10 May 2018 (UTC)
RobinMelanson (talk) 2:13, 25 November 2018 (UTC)
Vladimir Alexiev (talk) 03:02, 4 December 2018 (UTC) interested, in particular because of TRR project https://m.wikidata.org/wiki/Q56259739
Maxlath (talk) 18:36, 6 January 2019 (UTC)
Dcflyer (talk) 21:38, 26 January 2019 (UTC)
Trilotat Trilotat (talk) 15:39, 16 February 2019 (UTC)
Mfchris84 (talk) 05:37, 18 April 2019 (UTC)
Salgo60 (talk)
Walkuraxx (talk) 14:58, 18 July 2019 (UTC)
NAH
FULBERT (talk) 17:14, 10 November 2019 (UTC)
Wolfgang8741 (talk) 20:35, 19 April 2020 (UTC)
Csisc (talk) 17:46, 26 April 2020 (UTC)
Phoebe (talk) 16:26, 24 September 2020 (UTC)
Bitofdust (talk) 16:15, 20 January 2021 (UTC)
Dick Bos (talk) 07:52, 23 March 2021 (UTC)
  Notified participants of WikiProject Source MetaData/More

DiscussionEdit

  • I would rather add "Last names string" property, so it may also be used in Wikidata items directly when family name (P734) doesn't have a corresponding Wikidata item. Adamant.pwn (talk) 18:53, 28 December 2020 (UTC)
  •   Support Will be useful for author name string (P2093) case. Сидик из ПТУ (talk) 20:05, 28 December 2020 (UTC)
  •   Support NMaia (talk) 12:38, 29 December 2020 (UTC)
  •   Question Can't that info be obtained from given name (P735) and family name (P734), and other properties like patronym or matronym for this person (P5056) and second family name in Spanish name (P1950)? --Tinker Bell 01:57, 30 December 2020 (UTC)
    • It doesn't work for some languages. For example, we have three Russian words for Michael (Q4927524) (Майкл / Михаэль / Микаэль) since in Russian, pronunciation is taken into account when translating names (Майкл for English, Михаэль for Deutsch). You can also see on interwiks in which other languages the names of Michael Schumacher (Q9671) and Michael Owen (Q128829) are spelled differently. Сидик из ПТУ (talk) 08:08, 30 December 2020 (UTC)
      • @Сидик из ПТУ: The current proposal looks to me like it intends to store names written in one alphabet and not multiple one's. If there's an intended distinction between alphabets the datatype of string instead of monolingual string (with datatypes like mul-lat) would be more appropriate. ChristianKl❫ 10:16, 2 January 2021 (UTC)
    • @Tinker Bell: Possibly that could be used as an input to populate the proposed property, but they can't be used instead of the property for several reasons. First, the information has to be in the item for the article, not in subarticles, due to the 400 item limit when loading Wikidata items in Lua. Second, the author name strings won't always have matching items, particularly as they have to combine multiple last names, and and they may differ between items for the same person as stated as (P1932) does. Thanks. Mike Peel (talk) 12:34, 31 December 2020 (UTC)
      • We generally follow in Wikidata the principle that minimizing storage data is more important then minimizing page rendering time. I opened a post on the https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Is_the_400_Wikidata_items_per_page_limit_a_good_idea? about it (and the answer should likely be awaited before deciding on this proposal). ChristianKl❫ 10:32, 2 January 2021 (UTC)
        • @ChristianKl: That doesn't make sense when using Wikidata information in the wikimedia projects. I already get complaints on Commons about the speed of the infobox there, and the more items you have to load then the slower things get. Thanks. Mike Peel (talk) 11:31, 2 January 2021 (UTC)
          • It's a bit unclear to me why this can't be cached. ChristianKl❫ 12:21, 2 January 2021 (UTC)
            • It doesn't matter why it's unclear to you. The reality is that it isn't cached and that's the situation we are working with. At present, we can serve up to 400 citations in a page if we fetch the information from Wikidata. If we have have to lookup information from each author's entry on Wikidata for each source as well, that will rapidly shrink the number of citations we can serve per page, making Wikidata unsuitable as a repository for citations. That's a huge waste of the potential usage for 25,000,0000+ entries on Wikidata, for no good reason that I can ascertain. --RexxS (talk) 16:32, 7 January 2021 (UTC)
  • In how many items are you planning to import this via bot? Only those used with citeQ or all tens of millions of academic papers? In what alphabets will data be added? ChristianKl❫ 10:29, 2 January 2021 (UTC)
    • @ChristianKl: Ultimately, all of them. Existing Cite Q uses might be prioritized, but the template should work with any paper item. It should probably be stored in the alphabet used in the paper, but mostly my work would focus on latin languages anyway. Thanks. Mike Peel (talk) 11:31, 2 January 2021 (UTC)
  •   Comment A more informative name for the property might be "last name stated as", making clear the analogy with stated as (P1932) as to how the property should be used. Jheald (talk) 17:22, 4 January 2021 (UTC)
    @Jheald: Agreed, adopted. Thanks. Mike Peel (talk) 21:14, 5 January 2021 (UTC)
  •   Comment I appreciate Mike's efforts in this regard, but I fear this is not going to resolve the problem, only kick it further down the road. We have names with Tussenvogels, singular names, and others that don't fit the "first last" pattern. I also agree with Jheald, regarding "stated as". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:06, 5 January 2021 (UTC)
    @Pigsonthewing: Yes, and this proposal should be able to cope with this? Or should we just give up on Cite Q development? Thanks. Mike Peel (talk) 21:14, 5 January 2021 (UTC)
    False dichotomy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 7 January 2021 (UTC)
    If a source has each editor name with a qualifier "Author last names" and "Author first names", we can use them to generate a citation using firstN and lastN. If the author has a mononym then we can use lastN or fallback to authorN. Having both properties makes the information set larger, while preserving the existing subset, and that's no barrier to coding. As for a "false dichotomy", I'm somewhat in disagreement. I doubt that much more meaningful development can be done on CiteQ until we have a reliable means of generating first and last names. --RexxS (talk) 16:24, 7 January 2021 (UTC)
  •   Support While being here, I would also suggest separate properties for middle names, as well as for pre- and postfixes. Easier to introduce them now while the WD model is still very much work in progress than at a later point in time... Regarding the property names, I suggest to avoid the words "first" and "last" in them because they imply a certain Western naming notation and even there depend on context. While still not perfect, the "given name"/"surname" name pair is semantically better and suits more cases without implying a particular display order, see f.e.
(matthiaspaul) --92.209.72.111 20:09, 7 January 2021 (UTC)
The idea with these properties is that middle/pre/post-fixes are stored within the 'first' and 'last' name strings, which is how it is commonly done in bibtex for references, and in reference templates on-wiki (e.g., Citation expects firstN/lastN parameters). Splitting them out into different properties here would add more complexity than I think we need, and it can be done in Lua if needed. Naming them as 'given name'/'surname' would also invite more complexity than is needed (e.g., second surnames). Let's keep things as simple as possible given the situation please. Thanks. Mike Peel (talk) 17:19, 8 January 2021 (UTC)
@Mike Peel: Not every localized version of en:Template:Citation works the same way. For example, editors are advised to pass |author= rather than |first= and |last= into vi:Bản mẫu:Chú thích in the case of a Vietnamese or Chinese name. – Minh Nguyễn 💬 08:51, 15 January 2021 (UTC)
  •   Comment There are already a bunch of name-related properties, not just given and family name, and it isn't always obvious how to arrange these properties either in running text or bibliographically. For example, consider the names in Wikidata:Property proposal/Vietnamese middle name. While I'm encouraged that this proposal calls for the property to be used only as a qualifier on author name string (P2093), I'm concerned that it doesn't explicitly order the name parts in the case of author (P50). Consumers like en:Template:Cite Q would benefit from a more explicit "bibliographic name" and/or "sorting name" qualifier. (Its Vietnamese translation would benefit greatly because it wouldn't need to guess whether to display the name as "Family, Given Middle" or "Family Middle Given" based on the author's ethnicity or the original language of the non-anglicized form of their first name.) A "bibliographic name" property wouldn't be mutually exclusive of the property proposed here, but it seems necessary for achieving what seems to be the goal behind the proposal. – Minh Nguyễn 💬 08:51, 15 January 2021 (UTC)
  •   Support, an important property for people.--Arbnos (talk) 17:56, 21 February 2021 (UTC)
  •   Support Lastname, Firstname has been the major barrier to the use of cite Q (a template which is quite fantastic). MargaretRDonald (talk) 21:31, 29 April 2021 (UTC)
  • @Mike Peel: Can you please respond to the suggestion of a "bibliographic name"/"sorting name" property from Minh Nguyễn above? That seems like an ideal solution to me that handles all potential problems. ArthurPSmith (talk) 17:01, 30 April 2021 (UTC)
    @ArthurPSmith: The convention is always to split into last/first if there is a split for references, which is why I've proposed these properties in that form. If you want a "sorting name" then you could create it by combining the properties. Any chance of creating these properties soon, please? I have some free time this weekend that I could use to start populating them. Thanks. Mike Peel (talk) 19:31, 30 April 2021 (UTC)
    I'm afraid I don't see a complete consensus here; this is not ready. If the source material for this is always going to be BibTeX references, then perhaps the property name should include that? (edit:) Or at least the description, which is currently woefully inadequate. Otherwise I simply find this proposal will be confusing. ArthurPSmith (talk) 19:37, 30 April 2021 (UTC)
    @ArthurPSmith: I'm not sure I understand, there are plenty of support votes here? It's a long-solved problem in academia, but it's not specific to bibtex, just look at the reference section of any paper. The natural thing to do is to split it into last/first parts, as strings, which is what is proposed. Thanks. Mike Peel (talk) 19:42, 30 April 2021 (UTC)
    There are many name systems (some mentioned in this discussion - for more see this page) where "last/first parts" is not a natural subdivision of a person's name. You need to be much more specific about what the purpose and use of this property is. Right now the label and description are far too vague and it will be misused/misunderstood. ArthurPSmith (talk) 19:54, 30 April 2021 (UTC)
    • @ArthurPSmith: Then don't use these properties for those cases? Although I can't see what rule in that link this proposal breaks. I can't see how to simultaneously make this proposal broader to handle more cases and more specific/less vague? Mike Peel (talk) 20:00, 30 April 2021 (UTC)
  • @Mike Peel: I have updated the description to cover what I think you are trying to do here. Do you agree with this? Note we also need to have Wikidata usage instructions provided to specify what you had as allowed values: "Use only as qualifier for author name string (P2093) or author (P50)" ArthurPSmith (talk) 20:45, 30 April 2021 (UTC)

first name(s) stated asEdit

   Ready Create
Descriptionqualifier for string representation of given or secondary sorting portion of a name as represented in a bibliographic reference file (for example BibTeX)
Data typeString
Template parameter'first-N' parameter in en:Template:Cite Q
Domainproperty
Allowed valuesany string that may appear in a name (including spaces and periods)
Example 1The South Pole Telescope (Q55893751) author name string (P2093) → John Ruhl → 'John'
Example 2The South Pole Telescope (Q55893751) author name string (P2093) → Peter A. R. Ade → 'Peter A. R.'
Example 3Prostetic Rehabilitation of an Eye Globe: Case Report (Q89819389) author name string (P2093) → Clovis Lamartine de Moraes Melo Neto → 'Clovis Lamartine'
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 → 'Marcelo Coelho'
Example 5An EAR-motif-containing ERF transcription factor affects herbivore-induced signaling, defense and resistance in rice. (Q52725820) author name string (P2093) → Yonggen Lou → 'Yonggen' (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

MotivationEdit

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 first names 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 last name(s) (Wikidata:Property proposal/Author last 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)
TomT0m
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)
NAH
Iwan.Aucamp
Alessandra Boccone
Pablo Busatto (talk) 05:40, 23 June 2020 (UTC)
Blrtg1 (talk) 17:20, 23 July 2020 (UTC)
Kosboot (talk) 21:32, 23 July 2020 (UTC)
Matlin (talk) 09:38, 11 August 2020 (UTC)
Carrierudd(talk) 11:44, 3 November 2020 (UTC)
So9q (talk) 11:35, 16 January 2021 (UTC)
pdesai (talk) 16:00, 8 February 2021 (UTC)
  Notified participants of WikiProject Source MetaData and LeadSongDog (talk) 21:42, 23 March 2016 (UTC)
RobLa-WMF (talk) 01:24, 25 March 2016 (UTC)
Kosboot (talk) 20:45, 30 March 2016 (UTC)
Sydney Poore/FloNight♥♥♥♥ 15:10, 14 April 2016 (UTC)
Peaceray (talk) 18:40, 28 April 2016 (UTC)
PKM (talk) 16:29, 1 May 2016 (UTC)
Aubrey (talk) 12:42, 25 August 2016 (UTC)
Chiara (talk) 12:47, 25 August 2016 (UTC)
Marchitelli (talk) 19:02, 1 September 2016 (UTC)
YULdigitalpreservation (talk) 17:44, 9 December 2016 (UTC)
Satdeep Gill (talk) 14:59, 2 February 2017 (UTC)
Raymond Ellis (talk) 16:06, 1 April 2017 (UTC)
Crazy1880 (talk) 18:21, 16 June 2017 (UTC)
T Arrow (talk) 07:55, 22 June 2017 (UTC)
GerardM (talk) 08:25, 30 July 2017 (UTC) With a particular interest of opening up sources about Botany and opening up any freely licensed publications.
Clifford Anderson (talk) 18:26, 11 August 2017 (UTC)
Jsamwrites (talk) 07:52, 27 August 2017 (UTC)
Krishna Chaitanya Velaga (talk) 09:52, 19 September 2017 (UTC)
Capankajsmilyo (talk) 18:32, 19 September 2017 (UTC)
Hsarrazin (talk) 20:41, 15 October 2017 (UTC)
Mlemusrojas (talk) 10:15, 6 December 2017 (UTC)
Samat (talk)
Ivanhercaz   (Talk) 20:27, 25 December 2017 (UTC)
Simon Cobb (User:Sic19 - talk page) 21:20, 21 January 2018 (UTC)
Mahdimoqri (talk) 20:22, 26 March 2018 (UTC)
Maria zaos (talk) 18:45, 9 April 2018 (UTC)
Jaireeodell (talk) 14:07, 23 April 2018 (UTC)
Egon Willighagen (talk) 12:29, 10 May 2018 (UTC)
RobinMelanson (talk) 2:13, 25 November 2018 (UTC)
Vladimir Alexiev (talk) 03:02, 4 December 2018 (UTC) interested, in particular because of TRR project https://m.wikidata.org/wiki/Q56259739
Maxlath (talk) 18:36, 6 January 2019 (UTC)
Dcflyer (talk) 21:38, 26 January 2019 (UTC)
Trilotat Trilotat (talk) 15:39, 16 February 2019 (UTC)
Mfchris84 (talk) 05:37, 18 April 2019 (UTC)
Salgo60 (talk)
Walkuraxx (talk) 14:58, 18 July 2019 (UTC)
NAH
FULBERT (talk) 17:14, 10 November 2019 (UTC)
Wolfgang8741 (talk) 20:35, 19 April 2020 (UTC)
Csisc (talk) 17:46, 26 April 2020 (UTC)
Phoebe (talk) 16:26, 24 September 2020 (UTC)
Bitofdust (talk) 16:15, 20 January 2021 (UTC)
Dick Bos (talk) 07:52, 23 March 2021 (UTC)
  Notified participants of WikiProject Source MetaData/More

DiscussionEdit

  • I would rather add "First names string" property, so it may also be used in Wikidata items directly when given name (P735) doesn't have a corresponding Wikidata item. Adamant.pwn (talk) 18:53, 28 December 2020 (UTC)
    P. S. it's kind of inconvenient to discuss this and Wikidata:Property proposal/Author last names separately, is there anything that can be done about it? Adamant.pwn (talk) 18:58, 28 December 2020 (UTC)
    I wasn't sure how to propose two properties at once, I'm happy for them to be merged if that's possible. Thanks. Mike Peel (talk) 19:05, 28 December 2020 (UTC)
  •   Support Will be useful for author name string (P2093) case. Сидик из ПТУ (talk) 20:18, 28 December 2020 (UTC)
  •   Support NMaia (talk) 12:38, 29 December 2020 (UTC)
  •   Oppose given name (P735) and family name (P734) should be used to get the data about the names. ChristianKl❫ 22:17, 29 December 2020 (UTC)
  •   Comment Do we have a database of "bibtex references for the publications" somewhere? This seems highly unlikely. I don't see how this property would ever be widely enough supported to be generally useful. Maybe for some limited subset of published works, but as a general solution it seems quite infeasible. If you look for example at PubMed records, they list author names as strings in a rather wide variety of manners - "First Last", "F. Last", "Last F", "Last, First", etc, (and with middle names and multi-component last names it gets much worse) and that's a database that has at least some level of curation. It's just very hard to handle the huge variety of source materials that are out there in a reliably consistent fashion. I agree that something like Сидик из ПТУ's "situation-dependent name string" might be a better step here. ArthurPSmith (talk) 20:21, 30 December 2020 (UTC)
    • @ArthurPSmith: At least in astronomy there is Astrophysics Data System (Q752099), which provides Bibtex references like [14]. Probably it is going to be slightly different between different databases, so it's going to be tricky to do this for all article items immediately, but it should be possible in the longer term, even if we have to come up with some interface that lets humans select which format has been used for each item and then a script can fill it in based on that. Thanks. Mike Peel (talk) 12:41, 31 December 2020 (UTC)
      • If you try adding a citation via Citoid starting from the document's url, for example, you will almost invariably get first name, last name parsed accurately. The information is out there, and if Citoid can retrieve it, then there's no reason why a bot can't do the same. PubMed throws away author information because it's an aggregator service and it's simpler to do that for its purposes, which is why it's not a good starting point for creating citations. --RexxS (talk) 16:39, 7 January 2021 (UTC)
  •   Support While being here, I would also suggest separate properties for middle names, as well as for pre- and postfixes. Easier to introduce them now while the WD model is still very much work in progress than at a later point in time... Regarding the property names, I suggest to avoid the words "first" and "last" in them because they imply a certain Western naming notation and even there depend on context. While still not perfect, the "given name"/"surname" pair is semantically better and suits more cases without implying a particular display order, see f.e.
(matthiaspaul) --92.209.72.111 20:11, 7 January 2021 (UTC)
The idea with these properties is that middle/pre/post-fixes are stored within the 'first' and 'last' name strings, which is how it is commonly done in bibtex for references, and in reference templates on-wiki (e.g., Citation expects firstN/lastN parameters). Splitting them out into different properties here would add more complexity than I think we need, and it can be done in Lua if needed. Naming them as 'given name'/'surname' would also invite more complexity than is needed (e.g., second surnames). Let's keep things as simple as possible given the situation please. Thanks. Mike Peel (talk) 17:19, 8 January 2021 (UTC)
  •   Support Lastname, Firstname has been the major barrier to the use of cite Q. Th use of this would start to override the objections MargaretRDonald (talk) 21:32, 29 April 2021 (UTC)
  •   Comment Adjusted description to match updated description for last name proposal. Note wikidata usage instructions should indicate: Only use as qualifiers of author name string (P2093) and author (P50) ArthurPSmith (talk) 18:10, 2 May 2021 (UTC)

FLOSS usage policy URLEdit

   Under discussion
DescriptionURL for free/libre open source use policy or guideline of an entity
Data typeURL
Domaininstance of/subclass of organization (Q43229)
Example 1Swedish Social Insurance Agency (Q3372219)[15]
Example 2Association for Progressive Communications (Q743611)[16]
Example 3OpenStreetMap Foundation (Q6542248)[17]
Planned useadd all policies I can find to items
See alsohttps://www.wikidata.org/wiki/Wikidata:Property_proposal/service_status_information_URL

MotivationEdit

FLOSS policies are found in at least two government agencies and numerous non-profit organizations (see example above) So9q (talk) 12:20, 2 February 2021 (UTC)

DiscussionEdit

  Support --Lectrician1 (talk) 17:21, 2 February 2021 (UTC)

  •   Comment This is very interesting and potentially very useful. How do we do for countries where there are laws for FLOSS (like Italy and Bulgaria). Then there are no "policy" at all but the same law for all public agencies in the country. Ainali (talk) 19:04, 2 February 2021 (UTC)
  • No idea, had no idea it was mandated by law to use FLOSS. I think it's out of scope of this property. Maybe we should model that too but on the country item.--So9q (talk) 11:55, 3 February 2021 (UTC)
  • Wait, is this only intended for what kind of software an organization use? I was thinking it was more important to document the policies of the software they develop or contribute to. But perhaps we can use it for both using of (P642) as a qualifier? (Whatever we choose, the description needs to be perfectly clear.) Ainali (talk) 22:52, 21 February 2021 (UTC)
  • If it's only for their use, I suggest suggest we rename it to FLOSS usage policy URL and the description to "URL for policy or guideline of an entity's usage of free/libre open source software". Ainali (talk) 09:34, 13 March 2021 (UTC)
@Ainali: Done, see below.
  •   Comment Do we want to define what open source is for this property (like policies that prescribe a license defined as open by Open Source Initiative (Q845918)), or should we allow policies that call themselves open whatever license they use? And should the licenses be recorded as qualifiers? Ainali (talk) 20:56, 4 February 2021 (UTC)
  • In the case of FK above there is no specific licenses mentioned. To record something like that we would need a new property like "policy recommends" -> OSI approved license.--So9q (talk) 10:25, 5 February 2021 (UTC)
  • I was thinking copyright license (P275) but that might be perceived as applying to the policy itself. But even if we don't have a qualifier, what do you think about the proposed constraint? Ainali (talk) 13:04, 5 February 2021 (UTC)
  • @ainali: You raise an interesting point. Maybe a qualifier "recommends" -> "OSI approved licences only", "recommends" -> licenses both with and without OSI approval, "recommends" -> no licences. Then we don't force the world into our model and you can still query for policies that recommend OSI-licenses. Currently there is no such property though.--So9q (talk) 22:52, 24 February 2021 (UTC)
@So9q: Could you clarify this proposal regarding Ainali's question, so we can get it made? JesseW (talk) 18:30, 9 April 2021 (UTC)
@JesseW: Done, see below.
  •   Support, an important property for sites.--Arbnos (talk) 21:14, 21 February 2021 (UTC)

Marked as ready, multiple supports, no particular objections. JesseW (talk) 04:02, 8 April 2021 (UTC)

@JesseW: I removed the Ready mark since I'll   Oppose until we clarify if this intended for the policy for use of FLOSS, development of it or both. We better solve that question before we create the property. Ainali (talk) 19:32, 8 April 2021 (UTC)
@Ainali: Makes sense; I wasn't sure from your comment if you intended to block the proposal, or if it was something that could be addressed later. Thanks for clarifying. JesseW (talk) 23:09, 8 April 2021 (UTC)
To be clear, I absolutely think we need a property or two for this. I just want us to get it right from the start after seeing what mess it becomes if you after just a few weeks of using it realize that people use a property differently. Ainali (talk) 06:51, 9 April 2021 (UTC)
Adopted your suggestion to limit the scope for use of FLOSS which is the intention of the FK example that originated this property. We need another property for FLOSS development policies like this one IMO [18]--So9q (talk) 15:14, 10 April 2021 (UTC)
I discussed a bit with Abbe98 and another approach would be to just use one property, but with mandatory qualifier to point out which one it is. A qualifier could be of (P642) and it could then look like:
Swedish Social Insurance Agency (Q3372219) FLOSS URL policy https://github.com/Forsakringskassan/riktlinje-oppenkallkod/blob/master/riktlinje.md / of (P642) use (Q1724915)
An item with different URL's have two statements, and if there is just one URL for both, it can be one URL with two qualifiers.
This would save us from creating many properties and make it easier to find all organizations that have some policy. Ainali (talk) 19:37, 10 April 2021 (UTC)

Template applies categoryEdit

MotivationEdit

I'd like to better link templates to the categories that they apply. "Category's main topic" and "topic's main category" aren't supposed to be used for this. Please note that a symmetrical property "Category applied by template" should also be created - I'm not sure how to properly do a group proposal but it doesn't make much sense to only have one without the other. Elliot321 (talk) 21:11, 18 February 2021 (UTC)

Update: I've been made aware of template or module that populates category (P4329), so the inverse is no longer necessary. Elliot321 (talk) 21:19, 18 February 2021 (UTC)

DiscussionEdit

  •   Support --Tinker Bell 02:08, 20 February 2021 (UTC)
  •   Support --Lectrician1 (talk) 01:59, 21 February 2021 (UTC)
  •   Question One problem I could see here is that we usually don't have items for very specific versions of templates that are 100% identical across all Wikimedia projects. Often enough, they just group templates with very similar purposes and designs but with different implementations. Especially navigational templates or infoboxes. Which also means that not all versions linked on an item necessarily apply the same categories - or any categories at all. Categories are something that every project maintains for themselves and category structures can vary widely across projects. So how are cases handled where the template used on one WM project adds category A, but the version used on a different project adds category B? Or cases where the category added is dependent on the template parameters used? I'd rather not end up with a situation where such information is added purely based on how a template works on just one project (e.g. the English WP). --Kam Solusar (talk) 20:41, 22 February 2021 (UTC)
    • Multiple values should work in those cases (though with rare exceptions this type of thing should be standardized across Wikis). Elliot321 (talk) 02:01, 23 February 2021 (UTC)
  •   Support, an important property for categorization.--Arbnos (talk) 23:31, 15 March 2021 (UTC)

English Everipedia IDEdit

   Ready Create
Descriptionidentifier for content on English Everipedia
RepresentsEveripedia (Q44960346)
Data typeExternal identifier
Domainhuman (Q5), entity (Q35120), matter (Q26256810), wiki (Q171)
Example 1Wikipedia (Q52)Wikipedia
Example 2Astro Li (Q83899926)Astro_Li
Example 3Na Ha-eun (Q20944949)na-haeun
Example 4Jovarel Callum (Q99284197)jovarel-callum
Example 5Capital Move (Q84003845)Capital_Move
Sourceeveripedia.org
Planned usePutting value to topics which are available on English Everipedia.
Expected completenessalways incomplete (Q21873886)
Formatter URLhttp://everipedia.org/wiki/lang_en/$1
See alsoProperty:P6262

MotivationEdit

Everipedia is wiki-based online encyclopedia, currently available in 4 languages: English, Chinese, Korean, and Spanish. Since its English version is the largest English-language encyclopedia by number of pages, it can collaborate together with other sources to further enriching Wikidata through its extensive coverage of reliable and valid information. This property will be comparable with, for example, Fandom article ID (P6262) or Namuwiki ID (P8885), among others. BellaYunita (talk) 05:28, 19 February 2021 (UTC)

DiscussionEdit

  • See Wikidata:Project_chat/Archive/2020/02#Is_Wikidata's_purpose_to_provide_links_to_every_(open)_wiki? - this is one of examples I mentioned.--GZWDer (talk) 06:58, 19 February 2021 (UTC)
  •   Support Very useful property for one of the largest non-WMF wikis. — Sagotreespirit (talk) 23:35, 11 March 2021 (UTC)
    • @Sagotreespirit:, it seems that "largest" is mostly because it's a copy from Wikipedia. --- Jura 10:33, 12 May 2021 (UTC)
  •   Support, an important property for connectivity.--Arbnos (talk) 19:03, 22 April 2021 (UTC)
  •   Comment I don't understand how you intend the formatter URLs (or the ID's themselves) to work. Does Everipedia sometimes have the same concept in multiple languages, so you would have multiple id's for one Wikidata item? And Wikidata's UI has no support for "$1"/"$2"-style formatters, only one parameter is allowed. An id like "en/Wikipedia" with formatter http://everipedia.org/wiki/lang_$1 might work, unless the "$2.everipedia.org" language prefix is essential? ArthurPSmith (talk) 17:44, 23 April 2021 (UTC)
    •   Comment Please take a look at the Fandom article ID, it is allowed to have even 3 parameters, i.e. https://$2.fandom.com/$1/wiki/$3. The "$2.everipedia.org" language prefix is indeed essential, any link without the prefix will be redirected to English version "everipedia.org/wiki/lang_en/$1". BellaYunita (talk) 06:43, 25 April 2021 (UTC)
      • @BellaYunita: I don't know what happened to Fandom article ID (P6262) but those formatter URL's with $2 and $3 are non-functional, the UI is only using the 'https://community.fandom.com/w:c:$1' formatter. If you have something like that for Everipedia that should be used. The Wikidata UI has no mechanism for handling the $2 etc. portions of ID's at present. ArthurPSmith (talk) 15:46, 26 April 2021 (UTC)
        • @ArthurPSmith: Due to limited ability of the UI regarding formatter URL, I have revised this property proposal as English Everipedia ID, along with its formatter URL. Separate property proposals for each of other languages version will be made. BellaYunita (talk) 12:20, 1 May 2021 (UTC)
  •   Comment Is there any significant amount of original content on here? Of the four examples given, three seem to be more or less straight copies of enwiki content. I'm not sure whether that would really be useful enough to justify a property. Andrew Gray (talk) 13:17, 1 May 2021 (UTC)
    • @Andrew Gray: Of course there are some 'straight copies', but actually more (English) Everipedia articles are not even available on Wikipedia, therefore impossible for them to be copies. Examples have been revised to reflect this fact. BellaYunita (talk) 10:24, 2 May 2021 (UTC)
  • Ignoring the copied articles it's basically a fandom.com page for crypto and random things. It's more useful looking than Golden ID (P7502) which is only the former (\s). Not a great website but as long as nobody tries linking all the mirror pages I think it's probably fine. I do like how their article on wikipedia complains about the use of bots when right now I see bots injecting copyright violations into everipedia. Actually...maybe this website is worse than golden and fandom. BrokenSegue (talk) 19:17, 7 May 2021 (UTC)
  •   Oppose I generally support adding properties for other wikis, even in cases like this, but the copyright situation seems to be really bad for Everipedia. Per c:Commons:Village pump/Copyright/Archive/2018/02#Everipedia using multimedia content from this project (credit to Animalparty for digging up that link), nearly every page on the site is a copyright violation because they don't use proper attribution for CC-licensed content. At the very least, it might be worth getting an opinion from WMF legal as to whether the measures in en:WP:COPYVIOEL are just enwiki being paranoid or something that ought to be followed globally. Vahurzpu (talk) 17:23, 8 May 2021 (UTC)
    After taking a look at meta:Wikilegal/Linking Legal Considerations, it appears that to violate copyright law we'd have to encourage people to follow the links and infringe, which isn't really the purpose of an external identifier property. I'm not going to straight-up support, but I'm withdrawing my oppose and re-marking this as ready. Vahurzpu (talk) 23:41, 13 May 2021 (UTC)

Commons incompatible image URLEdit

MotivationEdit

I would like to have images of all murders, killers and druglords and sometimes they are hard/impossible to find in Commons or with a free license so I can use Commons compatible image available at URL (P4765).

I propose we add a constraint so that this is not used on item which already have Commons compatible image available at URL (P4765) or image (P18) or other image property.

For examples see the old property proposal or copy them in here.--So9q (talk) 06:54, 27 February 2021 (UTC)

DiscussionEdit

  •   Oppose There are so many images that aren't compatible with Commons licensing that this would be never-ending, subject to spam, and not particularly useful (no pathway to bring them into compatibility with Commons without waiting 100 years or so). Thanks. Mike Peel (talk) 18:25, 1 March 2021 (UTC)
  •   Oppose A proprietary file (we don't have to limit with P18) can be linked doing <item> image (P18) somevalue / URL (P2699) <uri> / copyright license (P275) proprietary license (Q3238057). And as I said above, we could store the copyright end date with P3893 --Tinker Bell 01:33, 6 March 2021 (UTC)
  •   Oppose This has been discussed and rejected at least 6 times before. Please stop proposing this property every few months. -- Dr.üsenfieber (talk) 13:30, 25 March 2021 (UTC)
  •   I'm marking this as abandoned now. I am adding described at URL instead on objects that are missing free photos, so others can click there to see what we are missing.So9q (talk) 07:30, 26 March 2021 (UTC)
    • @So9q: I'd consider that an abuse of described at URL (P973). The community has decided multiple times that we do NOT want this links. Please don't use properties in a way that make no sense ontologically. Quoting from described at URL (P973): This is to be used to provide links to reliable external resources that are not the item's official website, when no relevant "authority control" property exists. Using this property to hotlink nonfree images is totally unacceptable in my opinion. -- Dr.üsenfieber (talk) 05:59, 11 April 2021 (UTC)
@Dr.üsenfieber: Thanks for the heads up. I'll add useful described as URLs only as you suggest.--So9q (talk) 04:01, 12 April 2021 (UTC)

consequence of textEdit

   Under discussion
Descriptionlegislative or executive or other text that was the cause of the statement
Data typeItem
Domainfor use as a qualifer on statements, most commonly on significant event (P793), dissolved, abolished or demolished date (P576), etc.
Allowed valueswork (Q386724)
Example 1Coldingham (Q68815157) significant event (P793) boundary change (Q28953942)consequence of text = Local Government (Scotland) Act 1889 (Q6664029)
Example 2copyhold (Q1990719) dissolved, abolished or demolished date (P576) 31 December 1925consequence of text = Law of Property Act 1925 (Q6503425)
Example 3Cambridge Health Authority (Q105087660) dissolved, abolished or demolished date (P576) 1 April 1996consequence of text = The Health Authorities (England) Establishment Order 1996 (Q99880206)
Planned usegeneral use; use for consequences of various UK legislative acts and statutory instruments (User:Tagishsimon)
Robot and gadget jobsreplace uses of has cause (P828), end cause (P1534), has immediate cause (P1478) where their values are texts
See alsofoundational text (P457), has cause (P828), end cause (P1534)

SynonymsEdit

  • "effective text", "effected by", "legislative cause", "result of legislation"

MotivationEdit

We have a property (foundational text (P457)) for legislation, charters, treaties, executive orders etc that bring an item into being; but no similar property for such texts that cause an item to end, or change its state. This proposal would create that property.

The proposal arises out of discussion with User:Tagishsimon when I was looking for such a property. Tagishsimon has recently been doing a lot of systematic work on UK legislative acts and examples of UK Statutory Instrument (Q7604686) and their effects. But without a property like this, he said he was merely using stated in (P248) in a reference to indicate the legislative cause of events, such as at Q105087660#P576. This is unsatisfactory, because a reference could be any text that describes an action that has happened, not necessarily its cause.

It would be useful to be able to identify this very specific type of relation, from effect to legislative cause, and therefore to have a property for it. Jheald (talk) 08:07, 4 March 2021 (UTC)

DiscussionEdit

  • Proposed. Jheald (talk) 08:07, 4 March 2021 (UTC)
  •   Comment Are you planning to propose a similar movement of "foundational text" uses to qualifiers, as a parallel to what is proposed here? Mahir256 (talk) 16:29, 4 March 2021 (UTC)
@Mahir256: I hadn't thought of that. But probably not -- it doesn't seem to be broke, so don't fix it. I suppose the difference with "consequence of text" is that that needs to be a qualifier, because it needs to be attached to a statement to indicate what was the consequence. Whereas for foundational text (P457) the result of the text is the whole item. Jheald (talk) 16:36, 4 March 2021 (UTC)
There's a case to be made for the creation of a 'dissolutional text' property to match 'foundational text', but this proposal does not argue that case. 'Consequence of text' may not be a dissolution. Per JH, 'foundational text' is understood (by me, at least) to be the text that brought the item into being, and it is quite happy as a main property. --Tagishsimon (talk) 16:41, 4 March 2021 (UTC)
  • Support per nom. I have probably hundreds of UK SIs which dissolve institutions previously established by another SI. No very clear way to indicate that the SI effected the dissolution. end cause (P1534) and has cause (P828) are being employe to specify why the dissolution happened - e.g. b/c amalgamation, business failure. An 'effected by' or 'consequence of text' qualifier will allow me to point to the instrument that effected the dissolution. UK SIs which dissolve things, and note that many acts of parliament also dissolve things, such as large sets of local statutory bodies. --Tagishsimon (talk) 16:37, 4 March 2021 (UTC)
  •   Support Seems sensible, and well explained. JesseW (talk) 14:44, 28 March 2021 (UTC)

applicantEdit

   Under discussion
Descriptiongrant, program or other entity to which the given person, group or organisation is applying to
Data typeItem
Domainitems
Example 1NFDI4Ing (Q98380344) applicant RWTH Aachen University (Q273263)
Example 2SFB 874 (Q7389939) applicant Ruhr University Bochum (Q309948)
Example 3SFB 884: Political Economy of Reforms (Q48975701) applicant University of Mannheim (Q317070)
See also

MotivationEdit

With the property "applicant", research projects can be described in greater detail. The property could also be used in other domains with calls or tenders.  – The preceding unsigned comment was added by 95.168.138.91 (talk • contribs) at 10:10, March 4, 2021‎ (UTC).

DiscussionEdit

Daniel Mietchen DarTar Ppgardne Michael Cochez Alexander Doria Maximilianklein Renepick Lambert Heller Beat Estermann Cornelia Flavia Veja Tobias1984 Silvio Peroni Alastair Dunning Aubrey Snipre Andrew Su Karima Rafes Alen Vodopijevec Henry Rzepa Scott Edmunds Emw Matthiassamwald Missvain Vladimir Alexiev Petermr WiseWoman Jodi.a.schneider NavinoEvans Jan van Oort Andy Mabbett Konrad Foerstner Egon Willighagen Ben Moore Z. Ainali HLHJ Ale Abdo a.k.a. Solstag jibe-b GuZ-MPG Kristina Hettne Lilaroja Runner1928 Almondega lv_ra Finn Årup Nielsen (fnielsen) Rudy Patard ArthurPSmith Diana de la Iglesia Netha Pintoch OdileB YULdigitalpreservation Lozana Rossenova Jonathan Brier a.k.a. wolfgang8741 Jneubert econterms T0mpr1c3 Vladimir Alexiev Ivanhercaz Trilotat Benjamenta Nomen ad hoc Tris T7 TT me Simon Cobb Alessandro Marchetti sky Juliansteinb Maria zaos Josephguillaume Cavernia GoEThe Pamputt TiagoLubiana iopensa Walkuraxx   Notified participants of WikiProject Wikidata for research

co-applicantEdit

   Under discussion
Descriptiongrant, program or other entity to which the given person, group or organisation is co-applying to
Data typeItem
Domainitems
Example 1NFDI4Ing (Q98380344) co-applicant Research Centre Jülich (Q697111)
Example 2SFB 874 (Q7389939) co-applicant University of Düsseldorf (Q317032)
Example 3SFB 884: Political Economy of Reforms (Q48975701) co-applicant GESIS – Leibniz Institute for the Social Sciences (Q1485220)
See also

MotivationEdit

With the property "co-applicant", research projects can be described in greater detail. The properties "applicant" and "co-applicant" reflect distinctions in applicants' status made by many research funding organisations.  – The preceding unsigned comment was added by Havre-kakor (talk • contribs) at 10:27, March 4, 2021‎ (UTC).

DiscussionEdit

  •   Support--LukasCBossert This is a property that is most welcome, since it enables to differentiate the different roles of institutions in the funding constellation of research projects. As far as I can see there is no other property that would describe this specific role. I do vote for this. LukasCBossert (talk) 10:45, 4 March 2021 (UTC)
  •   Support--Hannes Röst (talk) 02:42, 5 March 2021 (UTC)
  • Why not use "applicant"? --- Jura 13:25, 5 March 2021 (UTC)
  • In some cases, applicants are distinguished by status (applicant / co-applicant). This is very common in research funding, for example. Having both properties would allow for more detailed descriptions of research projects, and potentially other areas as well. --- Havre-kakor
    • The qualifier object has role (P3831) can be used to describe the status of an applicant. --- Jura 17:34, 5 March 2021 (UTC)
      • not really, there are usually two distinct categories of applicants and they have specific roles and duties. Its not really the case that a co-applicant is a type of applicant but there are two distinct types of applicants: "applicant" and "co-applicant". We could try and model this with qualifiers as "primary applicant" and "co-applicant" but it would be wrong to say that one is a subset of the other. --Hannes Röst (talk) 03:28, 16 March 2021 (UTC)
        • Maybe the label of the property proposed at Wikidata:Property proposal/applicant needs improvement. Obviously, the actual designation for the role of an applicant can vary, but we shouldn't create a new property each time. --- Jura 05:01, 16 March 2021 (UTC)
  •   Oppose use the property "applicant" once it's created. --- Jura 20:28, 15 March 2021 (UTC)

Repairability IndexEdit

   Under discussion
DescriptionThe reparability index indicates the extent to which a product can be repaired. The reparability index has been mandatory in France since January 1, 2021 when purchasing new appliances.
RepresentsRepairability (Q30748592)
Data typeNumber (not available yet)
Domainitem (Q56599248, Q21065099)
Allowed values0 – 1
Example 1iPhone XS (Q56599248) → 0.47 (https://www.indicereparabilite.fr/produit/apple-iphone-xs-a1921-2/)
Example 2Samsung Galaxy A41 (Q97223473) → 0.8 (https://www.indicereparabilite.fr/produit/smartphone-samsung-galaxy-a41/)
Example 3MacBook Pro 16-inch (Q78982844) → 0.63 (https://www.indicereparabilite.fr/produit/ordinateur-portable-apple-macbook-pro-16-pouces-a2141/)
Example 4Q106612435 → 0.83 (https://www.darty.com/nav/achat/informatique/ordinateur_portable-portable/portable/lenovo_yoga_7_14itl5.html)
Sourcehttps://www.indicereparabilite.fr/
Planned useCreate data objects for all products stated in https://www.indicereparabilite.fr and add the Repairability Index.
Applicable "stated in"-valueRepairability Index (Q105809009)

MotivationEdit

The reparability index describes a product in terms of its reparability/sustainability. The index makes different products of a product category comparable. Tobias (talk) 11:39, 7 March 2021 (UTC)  – The preceding unsigned comment was added by Augentier307 (talk • contribs) at 12:39, March 7, 2021‎ (UTC).

DiscussionEdit

I think we should name this property something more specific to that website or whoever it is that is doing the scoring. BrokenSegue (talk) 17:12, 7 March 2021 (UTC)
I agree, the name should be specific about the source. ChristianKl❫ 18:33, 11 March 2021 (UTC)
+1--So9q (talk) 09:20, 13 March 2021 (UTC)
I agree that we should make the name more specific, and that being said, if the change is made I like this property proposal. Ainali (talk)
  • Note I added the missing signature of the user who created this proposal (based on page history). I have no idea where the "Tobias" signature came from. ArthurPSmith (talk) 18:50, 12 March 2021 (UTC)

formed at the same time asEdit

   Under discussion
Descriptionitem that appeared at the same time by the same process, or a related process
Data typeItem
Domainitem (for example, fossils (in particular by fossilization by external mold (Q105906455) et fossilization by internal mold (Q105906508) process), twins stars, mountains,
Allowed valuesQid, list accepted
Example 1any fossil by internal mold (Q105888936) with fossil by external mold (Q105888779) when we have both fossils.
Example 2HD 186302 (Q59121867) with Sol (Q525), with presumably (Q18122778) qualifier
Example 3External massif (Q3297714) with Vosges Mountains (Q187843), Rhenish Massif (Q313834), Harz (Q4186) Bohemian Massif (Q704453) Armorican Massif (Q1980627)
Planned useI will import during april a collection of fossile with related item (publication, location, author, etc…) and a part of fossils (maybe twenty out of four hundred) need to by linked by this property (there are pair of cast and endocast fossils formed by the same process).
Wikidata projectPaleontology, astronomy, geography, geology…

MotivationEdit

Dans le cadre du versement de la première collection de fossiles sur Wikidata à partir des données du Muséum d’Histoire Naturelle de Neuchâtel (Natural history museum (Q3330885)), je suis en train de travailler sur la description des fossiles dans le projet. Cela s’accompagne de plusieurs modifications et de structuration. Pour mener cela à bien, j’ai besoin de cette propriété qui permettrait d’associer des objets dont l’apparition ou la formation est simultanée. J’envisage d’utiliser ça au moins pour des fossiles en empreinte et contrempreinte, mais aussi pour des fossiles issus du même banc stratigraphique. Comme présenté dans la description, on peut envisager facilement de l’utiliser pour des étoiles issues du même cluster de formation, ou bien des massifs issus de la même formation géologique. Merci pour vos éclairages et votre soutien. Lucas Lévêque (talk) 18:23, 12 March 2021 (UTC)

As part of the deposit of the first collection of fossils on Wikidata using data from the Neuchâtel Natural History Museum (Natural history museum (Q3330885)), I am working on the description of the fossils in the project. This is accompanied by several modifications and structuring. To do this successfully, I need this property which would allow the association of objects that appear or form simultaneously. I plan to use this at least for cast and endocast fossils, but also for fossils from the same stratigraphic bed. As presented in the description, we can easily consider using it for stars from the same formation cluster, or mountain ranges from the same geological formation. Thank you for your insight and your support. Lucas Lévêque (talk) 18:23, 12 March 2021 (UTC)

DiscussionEdit

  • comment this just seems hard to define, what exactly means "at the same time"? This may depend on the time scale. On a geological time scale, many things happen "at the same time". Would this simply apply for items where a clear ordering relation cannot be established, eg either it is unknown (lack of current knowledge) or cases where it truly cannot be specified if "A is before B" or "B is before A" since they happen truly simultaneously? Secondly, if your idea is only to link things created by the same process, wouldnt it be easier to create a Q-item of the process and then link to both, eg "generation of solar system" and link HD 186302 (Q59121867) and Sol (Q525) to that process to achieve the same result without making this too complex? --Hannes Röst (talk) 21:41, 12 March 2021 (UTC)
    Hello Hannes Röst, thank you for the comment. Indeed it is not easy to define precisely "at the same time". I think we can get around the question by putting a process constraint, and it is the latter that will give the time scale. I think we can use it for the two cases you give and that an information quality qualifier will indicate when there is a « lack of current knowledge ». Besides, it is good to specify that two objects were formed simultaneously, and in my case by two separate processes that took place strictly at the same time. the indication of the transformation process as a qualifier of the other related object will help clarify the information, in my opinion. Here is the example I am faced with: they are two fossils, fossilized at the same time, by two related but not identical processes (fossilization by external mold (Q105906455) and fossilization by internal mold (Q105906508)). They are inseparable for these fossils but correspond to an unique temporality, the fossilization took place absolutely at the same time, we cannot say that one process precedes the other. However, these two fossils are associated in the database that I am work with, they are the counterpart of the other with a reverse process but without a cause and effect relationship. Hence my proposal for a simultaneity property for at least this kind of item. (Sorry for my translation maybe approximate.) Lucas Lévêque (talk) 14:42, 13 March 2021 (UTC)
    I'd rather use the other time properties to find these programmatically in a SPARQL-query than trying to match everything that has formed at the same time. Ainali (talk)
    Ainali For some item with lots of Properties and high quality of description, I think it’s possible (like sun’s twins). But for 2 fossils, formed by a similar process at the same time how did you link these two part ? Lucas Lévêque (talk) 09:41, 15 March 2021 (UTC)
    Well obviously we can't query well if the data is missing. But the solution is not adding more properties, but to add the data that is missing for the properties we have already. Ainali (talk) 19:38, 15 March 2021 (UTC)
    Well, if we can’t put data because we haven’t the property, how did we do ? Lucas Lévêque (talk) 15:33, 17 March 2021 (UTC)
    We do have start time (P580), end time (P582), temporal range start (P523) and temporal range end (P524) so there are plenty of properties to both store values in and query for already. This would only be redundant to what these can tell us. Ainali (talk) 10:22, 20 March 2021 (UTC)
  •   Support, an important property for processes.--Arbnos (talk) 23:13, 15 March 2021 (UTC)
  •   Leaning oppose Too generalist: too many items may be concerned for a property that will not be generic and excess can occur to combine a bit of everything. —Eihel (talk) 11:36, 22 March 2021 (UTC)
  •   Oppose Hmm, but the property proposed name is actually a query. Query: Show me fossils (or a set of them based on criteria) that were formed at the same time. You would then get SPARQL query results. So it seems having the right data in the right date/time properties seems like the real need here. However, I have no idea if we already have the right properties you might be looking for to fill with data, in order to ask those kinds of queries. I'd move that discussion and add a new topic section for discussion of that here: https://www.wikidata.org/wiki/Wikidata:WikiProject_Geology --Thadguidry (talk) 20:06, 13 May 2021 (UTC)

Suggested data fieldsEdit

MotivationEdit

Tabular-data-type properties link to the tabular-data from Commons. But it does not provide any documentation on how those data are structured. Something better documented and standardized would be much more powerful. As a first step, we could use Wikidata property names in the field names, and mention those fields on Wikidata. As there is really no good place to properly document data on Commons, doing it on the related Wikidata content seems like the way to go.

user:Zolo user:Jheald user:Moebeus user:Stevenliuyi   Notified participants of WikiProject Tabular data, 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) Luis.ramos.pst.ag 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) Andrew Eells (User:AndrewEells ; talk page) 15:35, 7 April 2021 (UTC) RShigapov 9:48, 8 April 2021 (UTC)   Notified participants of WikiProject OntologyZolo (talk) 16:29, 14 March 2021 (UTC)

DiscussionEdit

  •   Support Interesting approach, yes this is something that has been missing. Would a qualifier like series ordinal (P1545) work for a preferred ordering, also? Other qualifiers might also be needed, for example units? ArthurPSmith (talk) 17:53, 15 March 2021 (UTC)
@ArthurPSmith: P1545 would probably work ith this property, though it may be simpler to just sort the data directly on Commons. As for unit, it is a trick one: given that unit is part of the datavalue, not a quallifier, this property would not help. I don't really know how they should be documented on tabular data. Perhaps with a field called unit of measurement (Q47574) in the Commons file ? There is still plenty to be sorted out with tabular data, but it would be best be done on Wikidata talk:WikiProject Tabular data. --Zolo (talk) 21:34, 15 March 2021 (UTC)
@Tinker Bell: not quite sure. It is not about metadata that are technically allowed by a a certain format, it is about how the data themselves are structured. --Zolo (talk) 13:21, 21 March 2021 (UTC)
  •   Support and we really need a uniform way to name the fields in the tables for this property to be useful. --Stevenliuyi (talk) 03:29, 27 April 2021 (UTC)

Wikidata:Property proposal/attributed to

death rateEdit

   Under discussion
Descriptionthe total number of persons dead per 1,000 population per year
Representsmortality rate (Q58702)
Data typeQuantity
Domaindemographics of country or region (Q23983664)
Allowed valuesper capita
Example 1demographics of Norway (Q1996448) → 7.5 in qualifier for this property (P8379) point in time (P585) 2020
Example 2demographics of Bhutan (Q2359819) → 6.265 qualifier for this property (P8379) point in time (P585) 2019 [19]]
Example 3demographics of Russia (Q4224) → 14.5 qualifier for this property (P8379) point in time (P585) 2020 [[20]]
Example 4demographics of the United States (Q1965974) → 8.888 qualifier for this property (P8379) point in time (P585) 2919 [[21]]
Example 5demographics of Togo (Q2983227) → 8.234 qualifier for this property (P8379) point in time (P585) 2019 [[22]]
Example 6demographics of France (Q1172523) → 9.1 qualifier for this property (P8379) point in time (P585) 2017 [[23]]
Sourceall national statistics bureaus, Q863995
Planned useTo be used in lists, infoboxes and subchapter Demographic in countra articles
Number of IDs in source400
Expected completenessalways incomplete (Q21873886)
Robot and gadget jobsTo be used in lists, infoboxes and subchapter Demographic in countra articles
See alsobirth rate (P8763) case fatality rate (P3457)
Proposed byPmt (talk) 18:35, 27 April 2021 (UTC)


Motivering/begrunnelseEdit

(Legg inn motivering/begrunnelse for forslaget til denne egenskapen her.) Will give a statical quantity comparable between different populations. Pmt (talk) 19:33, 18 March 2021 (UTC)

NOTE ! For this property a qualifier point in time (P585) should be used.

DiscussionEdit

  •   Comment isn't there a problem with "," and "." in the samples for France and Togo? The year should probably be given as well (mandatory "point in time" qualifier). --- Jura 09:26, 19 March 2021 (UTC)
  •   Support, an important property for demographics.--Arbnos (talk) 00:12, 20 March 2021 (UTC)
  • Please put in actual examples that make sense. A death rate is not something that's constant for a country and thus likely in need of qualifers. Property examples then suggest how the property should actually be used. The current examples say nothing about COVID-19. Are you wanting to store the COVID-19 death rate or the eneral death rate? ChristianKl❫ 11:53, 27 April 2021 (UTC)

@ChristianKl: I have removed the reference to the WikiProject COVID-19 as this could be misunderstood.

instances are former instances ofEdit

MotivationEdit

We have a lot of items with names "former X" and no machine-readable way of linking "former X" to "X" in a way that encodes the "former" aspect. Some may argue that we shouldn't have "former X" items instead we should just use the "end time" property as a qualifier on "instance of". Maybe they are right, but the fact is we already have all these "former X" items, so either we provide a way of linking "former X" with "X" (this proposed property), or we get rid of them all. And I doubt the later is going to happen, it is just too much work, which means we should do the former. Mr248 (talk) 07:38, 20 March 2021 (UTC)

DiscussionEdit

presentation template / output template / value templateEdit

   Under discussion
Descriptiontemplate for displaying an item as a value in a Wikimedia project
Data typeItem
Allowed valuesWikimedia template (Q11266439)
Example 1Buenos Aires Stock Exchange (Q891560)Template:Buenos Aires Stock Exchange (Q6731940)
Example 2Order of the Republic (Q4335955)Q14153695
Example 3United States of America (Q30) → Template:USA (Q5612638)
Example 4prosaist (Q12144794)Template:Prosaist (Q15278141)
See also
Distinct-values constraintyes

MotivationEdit

We currently have only one property for specifying that a template is associated with some item: topic's main template (P1424). According to the documentation, it should only be used for infoboxes and navigation templates, and it would be good to leave it that way (or maybe they should even be separated). But there is also a fundamentally different type of template. These are templates used to visually represent an entity. This can be a ticker template for a stock exchange or some image representation for an award or flag. Moreover, items are likely to have both a value for topic's main template (P1424) and this one. Therefore, I propose to create a new property that allows linking template items that can be used to render the item visually in Wikimedia projects. —putnik 11:23, 20 March 2021 (UTC)

DiscussionEdit

  •   Oppose All of these examples can be modelled using topic's main template (P1424), it does not have to be restricted to infoboxes or navboxes. If you want to specify the role of the template, you have the qualifier object has role (P3831), with Wikimedia infobox template (Q19887878), Wikimedia navigational template (Q11753321), or any other value you want. Howewer, I think this is innecesary: these data are already (or must be) stored on the template items. --Tinker Bell 22:14, 20 March 2021 (UTC)
    I totally agree that we can use the same property with qualifiers for many different purposes. But we can also not use it if it is not convenient. For example, instead of all properties with images, you could use only image (P18) with qualifiers, and this is also a possible approach. But for practical use, it is often more convenient to create multiple properties. So here, I propose to be guided by practical benefits and look back at real use. Perhaps someday all templates will have more specific values of instance of (P31) (I personally support and do a lot for this), and qualifiers will be filled in in the properties. But now the situation is very far from this, and if we rely only on qualifiers, we will not be able to effectively use these templates. And worse, once the property is filled with new template elements, it will also become less usable for infoboxes and navigation templates. —putnik 09:51, 25 March 2021 (UTC)
  •   Oppose per Tinker Bell. --Hannes Röst (talk) 14:17, 30 April 2021 (UTC)

url textEdit

   Under discussion
Description(qualifier) for "official website" (P856) statement when WMF settings prevent the URL from being used. Use "unknown" as main value
Data typeString
Example 1(theoretical sample)
Wikidata Sandbox (Q4115189) official website (P856) unknown / url text www.example.com
Example 2LyricWiki (Q1198063) official website (P856) unknown / url text www.lyricwiki.org
Example 3Wookieepedia (Q934052) official website (P856) unknown / url text starwars.wikicities.com

MotivationEdit

Settings would generally be the spam blacklist. This way users may retrieve it or not (Add your motivation for this property here.) --- Jura 11:49, 25 March 2021 (UTC)

DiscussionEdit

  Comment I see the need, but isn't there an existing qualifier we could use for this? stated as (P1932) maybe? ArthurPSmith (talk) 18:07, 25 March 2021 (UTC)
  • Maybe that could do, but would it be understood? --- Jura 10:05, 26 March 2021 (UTC)
  Comment Besides stated as (P1932) another way to look at this through "internet eyes" that might work, namespace (P2307), could be reused in a pinch here without breaking anything, since it's just String. Domains are indeed Namespaces https://en.wikipedia.org/wiki/Namespace --Thadguidry (talk) 19:54, 13 May 2021 (UTC)
  • I don't get that explanation. In general, properties (as any other entity on Wikidata) shouldn't be repurposed, so I don't see how we could use P2307. If you want to do an alternate proposal with that could include the above, I don't mind looking into it. --- Jura 20:13, 13 May 2021 (UTC)

number of stitchesEdit

   Under discussion
Descriptionnumber of stitches of a sewing machine
Data typeQuantity
DomainP31/P279* of sewing machine model (Q106153893)
Example 1Q106238217 → 8
Example 2Husqvarna 6460 (Q106020030) → 30
Example 3Husqvarna Combina 2 3230 (Q106153856) → 2
Planned useadd to sewing machine items

MotivationEdit

This is an important property of a sewing machine. It varies wildly between machines, some can do 1 some 8 and some hundreds of different stiches. --So9q (talk) 09:36, 28 March 2021 (UTC)

DiscussionEdit

  •   Support, an important property for the area.--Arbnos (talk) 13:25, 13 April 2021 (UTC)
  •   Question @So9q: What evidence or documentation can you show that this is a defined and important value? I simply know nothing about this. Also, are you suggesting that this is a definite characteristic of every sewing machine? Blue Rasberry (talk) 18:38, 13 May 2021 (UTC)
@Bluerasberry:I don't really have any. It is my own opinion. If you look at sales ads for sewing machines it's one of multiple things that are advertised. Some customers want a lot of stitches but most just use straight and zigzag. In the old days the sewing machines could just do a straight stitch. These days they have computers built in and can do up to about 9 mm wide stiches with letters and what not.--So9q (talk) 21:22, 13 May 2021 (UTC)
@So9q: Is it correct to say that the primary source of this data would either be ads or the operation manual for the sewing machine? If so, I am unsure what to think of that as it seems more difficult than typical to verify. I suppose there should be a database of sewing machines somewhere and that Wikidata could be it. Blue Rasberry (talk) 22:38, 13 May 2021 (UTC)

specific partEdit

   Under discussion
Descriptionqualifier to indicate a specific part of the object-value of a statement that the statement applies to
Representspart (Q15989253)
Data typeItem
Example 1Ripon Cathedral (Q638466) historic county (P7959) Yorkshire (Q163) → specific part = West Riding of Yorkshire (Q1934075)
Example 2Teversal Manor (Q15979549) located in the administrative territorial entity (P131) Ashfield (Q600996) → specific part = unparished part of Ashfield (Q105909200)
Example 3Holyhead (OSD 317) (Q106156311) derivative work (P4969) (O.S. Old Series sheet 78) -> specific part = northwest (Q5491373)
Planned useChange the existing qualifiers used for unparished areas (40,000) and for ridings of Yorkshire (45,000) to use the new property
See alsoapplies to part (P518), depicted part (P5961), object has role (P3831)

SynonymsEdit

  • specifically
  • applies to part (of object-value)

Relation to other propertiesEdit

MotivationEdit

This property is intended to be analogous to applies to part (P518), but specifying a part of the object-value of a statement, rather than a part of the subject.

Use of the property is likely to be limited to specific particular kinds of situation, because in general if a statement applies to a specific part of its object, the normal tendency will be to create a item for that specific part of the object-value, and then make that more specific item the object of the statement. But in a few cases, as in the examples above, that is not appropriate or not desirable, and so this property would be useful, for instance:

  • ridings of Yorkshire. The values for historic county (P7959) are defined to be the counties that existed before Local Government Act 1888 (Q6664051). However the three ridings of Yorkshire and the Isle of Wight (Q9679) are often thought of as traditional counties in their own right, as indeed they were after 1888. For informational value, and also to dissuade people from giving them as main values of P7959, it is useful to specify them in a qualifier. location (P276) has been used so far, but this property would be a better fit.
  • unparished areas. See recent discussion on Project Chat. Use of located in the administrative territorial entity (P131) to point to a partial area defined by the absence of an administrative structure is questionable, and produces undesirable repetition for downstream interpreters of the data. statement is subject of (P805) has been used in the qualifier role, but is not really right. The qualifier now proposed would be a much better solution.
  • parts of derivative works. The derivative work as a whole is an appropriate value for derivative work (P4969). But it is useful to be able to specify which part of the derivative work it was that was based on the underlying work -- for example Holyhead (OSD 317) (Q106156311) was the basis specifically for the [File:OS old series 1 63360 78nw.jpg north-west quarter sheet] of O.S. Old Series sheet 78.
  • in the other direction, on based on (P144) statements it may be useful to be able to indicate which part of an earlier work a later work drew on.

A limited number of further use cases may also exist, that may currently be being handled by applies to part (P518). When this is the case it can be very confusing, as it can become unclear whether applies to part (P518) is referring to a part of the subject of the statement, or a part of its object. By creating this new property, specifically for parts of statement objects, that unclarity would be dispelled. P518 would then only ever refer to part of the subject of the statement, and this property would only ever refer to part of the statement's object.

DiscussionEdit

  • Proposed. Jheald (talk) 14:14, 30 March 2021 (UTC)
User:Zolo
Jane023 (talk) 08:50, 30 May 2013 (UTC)
User:Vincent Steenberg
User:Kippelboy
User:Shonagon
Marsupium (talk) 13:46, 18 October 2013 (UTC)
GautierPoupeau (talk) 16:55, 9 January 2014 (UTC)
Multichill (talk) 19:13, 8 July 2014 (UTC)
Susannaanas (talk) 11:32, 12 August 2014 (UTC) I want to synchronize the handling of maps with this initiative
Mushroom (talk) 00:10, 24 August 2014 (UTC)
Jheald (talk) 17:09, 9 September 2014 (UTC)
Spinster (talk) 15:16, 12 September 2014 (UTC)
PKM (talk) 21:16, 8 October 2014 (UTC)
Vladimir Alexiev (talk) 17:12, 7 January 2015‎ (UTC)
Sic19 (talk) 21:12, 19 February 2016 (UTC)
Wittylama (talk) 13:13, 22 February 2017 (UTC)
Armineaghayan (talk) 08:40, 10 March 2017 (UTC)
Musedata102 (talk) 20:27, 26 November 2019 (UTC) Hannolans (talk) 18:36, 16 April 2017 (UTC)
User:Martingggg
Zeroth (talk) 02:21, 4 June 2018 (UTC)
User:7samurais
User:mrtngrsbch
User:Buccalon
Infopetal (talk) 17:54, 9 August 2019 (UTC)
S.ann.adams (talk) 21:05, 13 December 2019 (UTC)
Karinanw (talk) 16:38, 24 March 2020‎ (UTC)
Ahc84 (talk) 17:38, 26 August 2020 (UTC)
User:BeatrixBelibaste
Valeriummaximum
Bitofdust (talk) 22:52, 26 March 2021 (UTC)
  Notified participants of WikiProject Visual arts given its potential use on paintings and drawings etc. -- Jheald (talk) 14:28, 30 March 2021 (UTC)
@Multichill: There are other reasons for this proposal than just the unparished areas -- being able to specify a specific part of the object-value is a generally useful thing.
But in respect of eg Teversal Manor (Q15979549), here are some thoughts.
  • For most places in England, other than administrative areas, one would expect located in the administrative territorial entity (P131) = <some civil parish>. When that is not the case, it is useful to have the information directly on the item to make clear that it's not just that nobody has refined the P131 down to civil parish level, it is that there is no civil parish.
  • It's useful to use a qualifier for that role, rather than an independent statement, so that if a civil parish did get created for Teversal (Q7707125) (which can happen), then at least in respect of Teversal Manor (Q15979549) the information would all be in the one statement.
  • Yes, in theory one could write queries just as well to check the chain Teversal Manor (Q15979549) : location (P276) -> Teversal (Q7707125) : location (P276) -> unparished part of Ashfield (Q105909200). But in practice it's more accident-prone. It relies on two different statements in two different places both to be right, despite whatever independent editing might have been done to one or the other.
  • Finally, it feels odd to me to treat the "unparished parts" like a real geographical area, because for a number of authorities that 'unparished part' is not a single contiguous area, but rather a collection of several areas, each one a different 'hole' in the parish map. It seems odd to me to potentially have a collection of areas as the value for a property like location (P276), rather than a single specific compact area.
Jheald (talk) 20:45, 30 March 2021 (UTC)
  •   Comment Could you give some more examples of the ambiguity you see in (some) uses of applies to part (P518) as a qualifier? I'm not sure I understand what you mean yet. JesseW (talk) 00:04, 6 April 2021 (UTC)
  •   Comment I saw a case recently where this might apply. The form was ⟨historical letter⟩ ⟨published in⟩ ⟨edition of a book⟩. It could have been ⟨historical letter⟩ ⟨published in⟩ ⟨edition of a book⟩ / ⟨specific part⟩ "Appendix 2". But that would require a string value instead of an item value. Pelagic (talk) 11:16, 18 April 2021 (UTC)
One way can try to represent this (see current Q77607750#P1365) is to write County of the City of Glasgow (Q77607750) replaces (P1365) Lanarkshire (Q530296) with qualifier applies to part (P518) = <somevalue>.
But a machine finding such a statement doesn't really know how to interpret it. Does the statement mean that part of the County of the City of Glasgow replaced all of the county of Lanarkshire? Or that part of the County of the City of Glasgow replaced part of the county of Lanarkshire? Or (?correctly) that all of the County of the City of Glasgow replaced part of the county of Lanarkshire?
(also: how would one represent that middle statement, if were the case that part of the County of the City of Glasgow replaced part of the county of Renfrewshire?)
This is why it makes sense to have two clearly distinct separate properties: one to indicate part of the subject of the statement; and a different one, if one wants to indicate part of the object of the statement.
That is what this present proposal aims to establish. Jheald (talk) 17:56, 20 April 2021 (UTC)

Thank you, that clarifies it a lot. But I think the underlying problem in the examples you give is that you don't have a value to assign applies to part (P518) to. If you had an item for the part of Lanarkshire that was moved, you could assign that as the value of the applies to part (P518) qualifier an it would be clear, without the need for this proposed property. For now, I {oppose}, but I'm glad to change my mind. Could you give an example where there is a value for applies to part (P518) but it is still ambiguous and requires this proposed property? JesseW (talk) 18:39, 20 April 2021 (UTC)

@JesseW: You can kind-of see that in the Holyhead (OSD 317) (Q106156311) example above. Does "northwest" refer to the part of the northwest of the drawing, or the northwest of the printed map? The answer is in fact the northwest of the printed map, in which the whole of drawing 317 was incorporated. (Each single map sheet combined information from multiple drawings, each of smaller areas within it). Jheald (talk) 20:08, 20 April 2021 (UTC)
OK, thanks for pointing that out (I missed it earlier). I've removed my oppose -- I'm still not sure about this, but at least I understand it now. JesseW (talk) 13:32, 21 April 2021 (UTC)