Open main menu

Wikidata:Properties for deletion

Properties for deletion
This is the page for requesting the deletion of a property (for items, with IDs beginning with "Q", please use requests for deletions). To nominate a property for deletion, complete the following steps:
  • Place the {{Property for deletion}} template on the property talk page.
  • Open the discussion on this page under the "Requests" section below.
  • Notify the user who originally proposed the property and the property creator for it on their respective talk pages.
  • Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is, leave a message in Village pump of the project.

Requests may be closed after 7 days, but may be extended if consensus is not reached. If an extended discussion becomes stale and has been left unclosed, a request for closure can be made at the administrators' noticeboard. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Properties for deletion may be used:

  1. To merge a property to another, or request to deprecate a property in favor of another.
  2. To change the data type of a property currently being used.
  3. Rarely, to delete a property with no replacement (e.g. it refers to an external website that is closed and/or not suitable for Wikidata).

Properties for deletion should not be used:

  1. To change the scope or purpose of a property; these should be discussed at the talk page of the property, project chat, or requests for comment.
  2. To request of undeletion of a property. To challenge a recently closed properties for deletion, you may use administrators' noticeboard; otherwise, you may repropose the property.

Add a new request


On this page, old requests are archived. An overview of all archives can be found at this page's archive index. The current archive is located at Properties/1.



Please add a new request at the bottom of this section, using {{subst:Rfd|1=PAGENAME|2=REASON FOR DELETION}}.

first flight (P606)/time of spacecraft launch (P619)/time of spacecraft landing (P620)/time of spacecraft orbit decay (P621)/spacecraft docking/undocking date (P622)Edit

first flight (P606): (delete | history | links | entity usage | logs | discussion) time of spacecraft launch (P619): (delete | history | links | entity usage | logs | discussion) time of spacecraft landing (P620): (delete | history | links | entity usage | logs | discussion) time of spacecraft orbit decay (P621): (delete | history | links | entity usage | logs | discussion) spacecraft docking/undocking date (P622): (delete | history | links | entity usage | logs | discussion)

Overly specific time properties. Use instead, with qualifier point in time (P585):

--Swpb (talk) 18:19, 22 March 2017 (UTC)

  Oppose. Specific properties are more user-friendly for new users than generic properties with qualifiers. New users may easily discover specific properties and put useful data in them. They are much less likely to work out how to use P793 with qualifiers. And it is easier for other wikis to work out to consume a specific property than to consume a generic property filtered by qualifiers. If we were to go down this path, should we not to be consistent also delete date of birth (P569) and place of birth (P19) since they too can also be replaced by P793 with qualifiers? Also, even for experienced users, specific property is easier than generic property+qualifier because it is less typing/clicking to enter. And it is easier for people writing SPARQL queries, since the syntax for querying on qualifiers is more advanced than just querying for specific properties so this would make the SPARQL learning curve steeper (and it is pretty steep already, in my opinion). SJK (talk) 08:46, 24 March 2017 (UTC)
@SJK: I have some doubt about the affirmation "New users may easily discover specific properties and put useful data in them". When you have more than 3000 properties it is difficult to say that a new user can easily find the right property especially when the numbering is not based on any logic. The most problem we have is from the people in WP who want to add one value in an infobox. Most of the time they access WD via the link between the article and the corresponding item. Then they add a new statement and they have to find the right property. They can be lucky by entering the correct words or not. If not what happens ? They don't want to extract all subproperties of significant event (P793) using a SPARQL query (most of wikipedians don't know anything about SPARQL) and they don't want to start any search to find the wikiproject responsible of managing the properties structure. So if the wikipedian doesn't find the correct property in the first search he won't continue to look for it and he will abandon. With one property there is a huge probability than the general property is already used in the item and it is easier to copy-paste the existing statements for a new addition. Even if they don't used the correct value for significant event (P793) like using maiden flight instead of first flight or the inverse, they can already add the location or the date and the error can be detected and corrected using the constraint violation reports. Snipre (talk) 15:29, 4 April 2017 (UTC)
start_date, end_date, point_in_time are intuitive qualifiers/properties.
Documentation of P793 could be improved to emphasize relevant qualifiers. d1g (talk) 15:35, 30 April 2017 (UTC)
  Delete per Snipre --Pasleim (talk) 11:44, 15 April 2017 (UTC)
  Keep first flight (P606). This one is well defined and used. This makes it very easy to query and use as well as to enter in the first place. The significant event (P793) method is not a problem, but also doesn't really offer an advantage over having first flight (P606) as a distinct property. Josh Baumgartner (talk) 20:24, 18 April 2017 (UTC)
  Delete P793/P31/P279*/<event in space> is easier to query than 5 distinct properties. It's better to create taxonomies of evens than a property for every event IMO.
Basic queries with P793 are both easy and narrow: significant event (P793) docking and berthing of spacecraft (Q557450) d1g (talk) 15:29, 30 April 2017 (UTC)
  Keep working with separate properties is easier than prop+qualifier. Some another prop+qualifier schemes had moved to separate properties scheme already. So significant event (P793)/point in time (P585) will be deleted too as I think. — Ivan A. Krestinin (talk) 08:01, 20 May 2017 (UTC)
With birth/death events because every person dies... maybe.
It isn't obvious to have 2 properties per every event over events +3 qualifiers.
@Ivan A. Krestinin: almost 2 times less properties-or-events to find with P793.
We also need to create properties, when we don't need to create events in most cases with significant event (P793) d1g (talk) 01:26, 15 June 2017 (UTC)

  Comment I checked the usage of each template. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)

  Keep first flight (P606) and time of spacecraft launch (P619) because they have almost (or over) 5000 uses [1] [2]. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)
  Delete time of spacecraft landing (P620), time of spacecraft orbit decay (P621) and spacecraft docking/undocking date (P622) because they have at most 350 uses [3] [4] [5]. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 23:03, 14 June 2017 (UTC)
This doesn't really make sense - these properties form a coherent group for describing concepts and so we should either have them all, or put them all as "significant event" qualifiers. All spacecraft go up and so all will have a launch date; not all have come down yet so there will be fewer with landing/decay times. It's natural to expect an imbalance between the two groups, much as we have far more people with "born" than "died". Andrew Gray (talk) 11:27, 25 July 2017 (UTC)
  Comment we shouldn't make decisions in any direction based on current usage. Maybe we don't have understanding what exactly is better, but we shouldn't make popularity-driven decisions. d1g (talk) 04:51, 10 August 2017 (UTC)
  •   Keep seems to be a working set of (sub-)properties.
    --- Jura 14:50, 9 July 2017 (UTC)

Refuse to consider until time of day and time zone issues with Wikidata Datetimes are resolved. Jc3s5h (talk) 23:32, 20 July 2017 (UTC)

  Keep All of these properties seem to be useful and working with them is much easier than using qualifiers with significant event (P793). --Sintakso (talk) 22:56, 26 July 2017 (UTC)
@Sintakso: in SPARQL difference is in 1 triple, 1 is less than 2, but I wouldn't call it "much".
Can you show example how one property is far better than event?
What happens when one needs to specify a qualifier for this property?
But it takes more time to maintain individual property (create, translate in every language)
Date-related properties aren't specific to space.
3(4 with location) qualifiers are free from "...location of ..." "...time of..." restrictions and much faster to enter data by humans. You only need to know 4 properties, not 5-10-300-1000. There is nothing to "discover" because so few options to make mistakes between. d1g (talk) 04:51, 10 August 2017 (UTC)
@D1gggg: I didn't mean just the use of the properties in SPARQL queries. I believe that the users are much more likely to find a distinct property than they are to notice the existence significant event (P793), read it's documentation and remember that they can use it for inserting date of landing, docking etc. Distinct properties are easy to search, so the users don't even have to know/remember the property exists and they can still find it easily. The use of significant event (P793) wouldn't probably spare any time at all, because it would still be needed to translate labels of the items used with it and to check constraint violations regularly (so that users wouldn't be using eg. docking (Q22988075) instead of docking and berthing of spacecraft (Q557450)). The only change I would support would be to delete spacecraft docking/undocking date (P622) and replace it with two properties for docking and undocking. --Sintakso (talk) 06:52, 10 August 2017 (UTC)
@Sintakso: because it would still be needed to translate labels of the items used with it
Only for events never described in Wikipedia as separate article (something rare).
E.g.: burial (Q331055) baptism (Q35856).
We don't have specific properties to both of them, we will spend time on property creation.
300-1000 distinct events aren't stretched at all.
Furthermore, when we use Q1764062, Q331055 and Q35856 in 793 users could read Wikipedia articles if they never heard about such event. d1g (talk) 20:32, 10 August 2017 (UTC)
@Sintakso: we are using this approach in award received (P166)
Point in time is not something we need to know every time, but additional information.
E.g. "was it ever sequenced?" "how many times burial ceremony happened?"
Where and when should be qualifiers d1g (talk) 20:42, 10 August 2017 (UTC)
@D1gggg: I agree that the significant event (P793) + qualifiers approach might be more useful for rare events. However, I believe that in case of common events the time spent with the property creation is outweighted by the user-friendliness of distinct properties. Also, I don't see any point in deleting properties which are already in use and replacing them with significant event (P793) as it doesn't seem to have any major advantages. --Sintakso (talk) 10:06, 11 August 2017 (UTC)
  Delete Not user-friendly for new users at all, because you must know these property before adding them, and don't forget to check if they exist! There are too many dates properties. This method (creating new properties) is very painstaking: if you want to add and event that doesn't have its own property, you must ask for a property creation, wait weeks... "Good" events have their own properties, "bad" have not... And why do we a have a "date of (event)" property and not others? For example, a "first flight" might be described not only by a date, but by the airport(s), the crew (pilot(s) and so on), important people who attended... Are we going to split each event into multiple properties? Please, have a look at YF-16 (Q17372279). El Caro (talk) 15:06, 20 August 2017 (UTC)
  Delete per El Caro's arguments --Hsarrazin (talk) 08:13, 25 August 2017 (UTC)
  Delete. Consistency is important. Storing data so many different ways makes it difficult to use. --Yair rand (talk) 23:40, 11 September 2017 (UTC)
  •   Keep. They are used by several Wikipedias using the {{#Property:P622}} etc syntax. Deleting these properties will break those infoboxes and there is no easy replacement solution in the proposed migration scheme that doesn't involve bespoke, locally hosted Lua scripts to let the infoboxes find the relevant significant event (P793) + point in time (P585) dates. Until parser functions become sufficiently advanced that these can be migrated by changing wikitext alone, we'll need to keep these properties. Deryck Chan (talk) 15:53, 24 September 2017 (UTC)
  •   Keep As Joshbaumgartner. Keep first flight (P606) and delete the rest. /ℇsquilo 14:02, 30 October 2018 (UTC)
This is a drive of complex problems, and at the moment I don't think keep all or delete all are good either. If there's some spikes that prevents us to safety use P793, as well as other properties, then those are just bugs, we should actually fix em.
And @Deryck Chan: isn't {{#Property:}} somewhat deprecated now? What's the technical block on migrating usages to be {{#statements:}} (at least, as you're a Cantonese user, what's problem on Cantonese Wikipedia (Q1190962))?

--Liuxinyu970226 (talk) 12:41, 27 October 2017 (UTC)

@Liuxinyu970226: I looked at the property talk pages and checked the templates that used these properties. it:Template:Infobox missione spaziale is an example that uses the {{#Property:}} syntax (through Template:Wikidata (Q8478926)) to fetch this property. I'm not aware of any use of these properties on yue.wp. So my suggested plan of action is (0) mark these properties as deprecated (1) copy these statements into the proposed new statement structure (2) modify all the relevant templates to transfer all uses of these properties in other Wikimedia sites to the new statement structure (3) finally delete the property. Deryck Chan (talk) 11:22, 31 October 2017 (UTC)
I've recently learned that it's not possible to select statements based on qualifier values using {{#statements:}}. Module:Wikidata (Q12069631) and Q25936424 don't currently have that functionality either. So I think we should keep these properties until that becomes possible. Deryck Chan (talk) 14:47, 7 December 2017 (UTC)
Some versions of Q25936424 can read out statements based on qualifiers, e.g. the version on frwiki. Moreover, spacecraft docking/undocking date (P622) also requires qualifiers. Infoboxes need to select statements based on qualifier values to properly display the data of spacecraft docking/undocking date (P622). --Pasleim (talk) 06:43, 8 December 2017 (UTC)
  •   Keep I vote to keep. There is no such thing as "too much specific". We have "subproperty" property for a reason. --Ogoorcs (talk) 01:56, 8 September 2018 (UTC)
  •   Keep I'm Okay with SJK Olivier LPB (talk) 10:53, 30 January 2019 (UTC)
  •   Keep I vote to keep. There is no such thing as "too much specific". This is easier to use by new users. Deror avi (talk) 08:22, 3 February 2019 (UTC)
  •   Keep Because of its wide used and related with common concepts. We shouldn't abuse of P793 and reserve it for unusual/open points in time that are difficult to foresee as property. Amadalvarez (talk) 10:58, 26 March 2019 (UTC)
  •   Delete because we can replace them with other properties--DiMon2711 12:36, 27 April 2019 (UTC)

analog or derivative of (P5000)Edit

analog or derivative of (P5000): (delete | history | links | entity usage | logs | discussion)

Property represents analog (Q50824047) which is ambiguous and inaccurate and so it's incorrect from a chemistry perspective. It mixes different concepts of functional analog, structural analog, derivative and molecular similarity and some others; concepts that are neither synonymous nor similar, concepts that shouldn't be equated with each other. Problem of chemical classification is one of the most important and most challenging in WD's chemistry scope, but Wikiproject Chemistry hasn't been notified about this proposal and I found this property by accident. Fortunately, there is only one use of this property.

This property should be deleted as it's incorrect and importing data from the indicated sources can lead to addition of a huge collection of chaotic and inaccurate data. Discussion about chemical classification should be continued in Wikiproject Chemistry and such bypass solutions should not be created.

Jasper Deng
Egon Willighagen
Denise Slenter
Daniel Mietchen
Andy Mabbett
Emily Temple-Wood
Pablo Busatto (Almondega)
Antony Williams (EPA)
Devon Fyson
Samuel Clark
Tris T7
  Notified participants of WikiProject Chemistry, pinging participants of the property proposal discussion: @Andrew Su, YULdigitalpreservation, Okkn, ديفيد_عادل_وهبة_خليل_2, Andrawaag, Gstupp:. —Wostr (talk) 13:21, 23 September 2018 (UTC)

  •   Keep I see it is useful and has no problem.The description can be improved David (talk) 14:03, 23 September 2018 (UTC)
    • Could you explain how this property is useful? Wostr (talk) 14:42, 23 September 2018 (UTC)
    • I have to ping you, David, as I would like to know the answer or some argument for keeping this property. Especially in the light of my comment of September 24 (below, the long one beginning with I'm not sure), in which I pointed out major problems with the sources that were to be used to populate this property. Wostr (talk) 20:34, 12 November 2018 (UTC)
  • I understand your concern. Do you have any plans to create more specific properties replacing this property? Or should we force this property to be used with a qualifier of object has role (P3831) (functional analog (Q25205085), structural analog (Q485014), Substrate analog (Q7632163), or Transition state analog (Q17087414))? Actually, the term "analog" is used ambiguously in molecular biology and in medicine, such as nucleic acid analogue (Q15057699) and Insulin analog (Q742283). Also, I'd like to hear what is the chemically correct relationships between 2-chlorodiazepam (Q15408412) and diazepam (Q210402), or between fexofenadine hydrochloride (Q27255526) and fexofenadine (Q415122). Regards, --Okkn (talk) 09:10, 24 September 2018 (UTC)
    • I'm not sure that properties are needed here at all. We had in Wikiproject Chemistry some initial discussions about chemical classification (e.g. here), but these discussions are not finished, as we in WP Chemistry have a lot to do before this (e.g. determining what we already have in WD and cleaning up after mass bot imports). From my POV the basic chemical classification should be based on classes of chemical compounds using instance of/subclass of (e.g. diazepam has a benzodiazepine, chloroaromatic classes; these classes are subclasses of more general classes etc.; this way diazepam and 2-chlorodiazepam are a member of the same classes). But this is my POV that has not been accepted (as any other) to be used in WD; and that's not the only option that can be present in WD. With the analogs, derivatives and so on there are IMHO too many problems: one can say that 2-chlorodiazepam is an analogue of diazepam, but there are really no clear and objective boundaries – methanol is an analog of methane? one can say that; diazepam is a structural analog of methane? some may argue that this is also true, really, I had that kind of discussions in, because we have 'derivatives' and 'similar compounds' parameteres in infoboxes...
      The problem here is also that we would have several thousands of statements imported to WD and that's it. Many users like to import data to WD, but no one likes to curate that data, no one is checking whether imported data is correct or not. And in this case it would certainly be incorrect: just look what is the purpose of 'analogs & derivatives' in MeSH: It is used when the specific chemical heading is not available and no appropriate group heading exists i.e. it is used where there is no chemical class to be used for classification, so this is a kind of a substitute property, a replacement for something that is missing right now. ChEBI 'functional parent' have more sense (A has_functional_parent B if and only if given any a, a instantiates A , has molecular graph ag and a obo: has_part some functional group fg, then there is some b such that b instantiates B, has molecular graph bg and has functional group fg’ such that bg is the result of a graph transformation process on ag resulting in the conversion of fg into fg'.), but I don't think that such relationships are needed in WD, at least not right now.
      My point is that: classification should be thoroughly discussed first and there should not be mass imports before that, because there are always people who wants to import something (no matter if this is correct or not), but there are no volunteers for cleaning this up. Wostr (talk) 14:06, 24 September 2018 (UTC)
  • I understand that a property like this makes interesting browsing, but I think it can be done differently. I agree with the point that analog and derivative are not so well defined, but my worries stems particularly from the fact that it is unbound and will lead to many links between chemical structures. I'm slightly in favor of removing. --Egon Willighagen (talk) 16:45, 25 September 2018 (UTC)
  •   Delete or at least rename based on a more specific relation. We already discussed the problem in WikiProject Chemistry and only relations based on a clear definition have to be used. Snipre (talk) 23:18, 7 October 2018 (UTC)

demonym (P1549)Edit

demonym (P1549): (delete | history | links | entity usage | logs | discussion)

I think this property could be replaced with one that links to senses (e.g. sense 1 of Kenyan (L35249)); this would be especially useful for words with lots of conjugations. I have not created a new property proposal because it would be more appropriate to have the discussion in one place.

I've already created 161 English noun lexemes which would be able to replace current uses; it would also be necessary to create equivalent items for adjectives, as well as to create the relevant senses for the noun and adjective lexemes (I've only added a sense to L35249 so far). —Jc86035 (talk) 10:33, 4 November 2018 (UTC)

Notified 94 contributors to the property and its talk page: User:Nikki User:Abián User:Jura1 User:VIGNERON User:Tubezlob User:Jheald User:Lockal User:Infovarius User:Putnik User:Laddo User:Kalogeropoulos User:Innocent bystander User:Event User:Jakec User:Vinhtantran User:MaGa User:Labant User:K175 User:Autom User:Robin van der Vliet User:Matěj Suchánek User:Janezdrilc User:Ctschiebout User:Kevin Scannell User:Maria zaos User:Horcrux User:Soued031 User:Metsavend User:Obaid Raza User:İncelemeelemani User:Pinky sl User:Andreasmperu User:Рөстәм Нурыев User:Pmt User:Gustavo Rubén User:Oriciu User:Mr. Ibrahem User:زكريا User:ToJack User:Renessaince User:Arnaugir User:MisterSynergy User:AmaryllisGardener User:Beta16 User:Mahir256 User:Спасимир User:Asierog User:Avatar6 User:Wylve User:Şêr Jc86035 (talk) 10:39, 4 November 2018 (UTC) User:Krupolskiy Anonim User:YMS User:ಶಿವಕುಮಾರ್ ನಾಯಕ್ User:Hibm98 User:GAllegre User:Epìdosis User:Jklamo User:David1010 User:SR5 User:Máté User:Ślimaczek User:HakanIST User:FocalPoint User:Allen4names User:Mbch331 User:Zygimantus User:Fnielsen User:Peppepz User:Geraki User:Supaplex User:Thierry Caro User:NMaia User:Loischantada User:ANDROBETA User:Marklar2007 User:Kikos User:Raid5 User:Doostdar User:Palapa User:Octahedron80 User:Милан Јелисавчић User:Frokor User:Rippitippi User:Conny User:Qllach User:Miguillen User:יונה בנדלאק User:Liuxinyu970226 User:桂鷺淵 User:Bjankuloski06 User:Thomas11 User:Ayack User:Чаховіч Уладзіслаў User:Александр Сигачёв Jc86035 (talk) 10:41, 4 November 2018 (UTC)

I would like to note that the property is used as label for country of citizenship (P27) at huwiki. If the property is deleted, the current data needs to be imported into the newly accepted structure, and huwiki needs to be notified to create a workaround to the new structure if possible. Ideally, the new structure should make it possible. – Máté (talk) 12:10, 4 November 2018 (UTC)

This is also the case for WD powered templates at svwiki, frwiki and probably many more. /Autom (talk) 13:13, 4 November 2018 (UTC)
@Máté, Autom: Where is it used on huwiki/svwiki/frwiki? Those are not listed in the box on the talk page, perhaps the script which looks for property usage can be improved. @Jc86035: Please notify the projects using this property too. - Nikki (talk) 14:52, 4 November 2018 (UTC)
@Nikki: hu:Sablon:Személy infobox of the top of my head. – Máté (talk) 14:58, 4 November 2018 (UTC)
@Nikki: On svwp, it is used by the module Wikidata2, which in invoked by a lot of templates (like Faktamall biografi WD in biografies). I know frwiki had a similar system a year ago (it's possible it has change since then). /Autom (talk) 18:25, 4 November 2018 (UTC)
@Autom: Do you have any specific place where this spcific property is used on svwiki? I see many potential problems with this property in the Swedish language, so at least I have never tried to use or even edit it. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 17:03, 19 April 2019 (UTC)
@Sextvå.tvånoll.ettsjunoll.sjufyra: It is used to display nationality in Faktamall biografi WD (via Wikidata2). In the article Bill Gates, the template does not return "USA" but "Amerikan", which is the value of demonym (P1549) [common gender (Q1305037), singular (Q110786)] of United States of America (Q30) (the country of citizenship (P27) of Bill Gates (Q5284)). /Autom (talk) 14:11, 20 April 2019 (UTC)
  •   Delete but probably wait some weeks/months until Lexemes are more stable. Cdlt, VIGNERON (talk) 12:17, 4 November 2018 (UTC)
  • I agree that we should eventually replace the existing property with lexemes, but we shouldn't delete this until people are able to switch to using lexemes. We still need to decide how we want to link things together. - Nikki (talk) 14:52, 4 November 2018 (UTC)
  •   Delete The property demonym of (P6271) has been created. This one can now be deleted (first declare obsolete, move content, then delete).--Micru (talk) 17:30, 19 December 2018 (UTC)
  •   Comment If this property is being used in an infobox or by a Lua module, it will need to be retained and to go on having its values added to and extended, at least and until such time as inverse property values become obtainable via Lua - as at present they are not. Jheald (talk) 18:09, 19 December 2018 (UTC)
  •   On hold. I agree with Jheald that we need a place -> demonym property to keep infoboxes working. We should keep this property until we have a new Item -> Lexeme "demonym" property, migrate all existing uses and infoboxes, then delete P1549. Deryck Chan (talk) 15:52, 11 January 2019 (UTC)
  •   Delete Very barely used, and replacement is even available for these not more than 100 usages. --Liuxinyu970226 (talk) 12:44, 16 March 2019 (UTC)
  •   On hold. Until infoboxes (as happens in cawiki) can be transformed after have access via LUA module. Thanks, Amadalvarez (talk) 12:47, 26 March 2019 (UTC)
  •   Comment. As noted, 1) there is no wikibase client for lexemes, 2) there is no Lua function available for backlinks or API queries, pending of phab:T185313 that it seems silently declined for a year now. There is not any path from a wiki page like w:fr:Paris to reach parisien (L26359). If these blockers are solved, there are still some concerns. How to deal with parisien (L26359) or parisienne (L25620)? How to obtain the demonym for a given language and a lexical category? At the end, it will be one more, or several, arbitrary access and it is expensive in Lua time usage that has limitations in infoboxes powered by Wikidata. --Vriullop (talk) 07:52, 27 March 2019 (UTC)

GINCO ID (P3905)Edit

GINCO ID (P3905): (delete | history | links | entity usage | logs | discussion)

This property is covered by Thésaurus de la désignation des objets mobiliers ID (P4979) and Thésaurus de la désignation des œuvres architecturales et des espaces aménagés ID (P4980) and I think it is better to have those seperate. —Lymantria (talk) 13:19, 19 November 2018 (UTC)

@Zolo, Shonagon, VIGNERON, Pigsonthewing, Gzen92, ChristianKl: Pinging those involved in the discussion on the property proposal of GINCO ID (P3905). Lymantria (talk) 12:06, 10 December 2018 (UTC)

  • @Lymantria: could we have some more in-depth explanations? I think it's better to have one property for one database on one website. Just because this database has subparts means we need to have differents property (see. IMDb ID (P345) for an other example of a database with subparts). Plus, if we would use Thésaurus de la désignation des objets mobiliers ID (P4979) and Thésaurus de la désignation des œuvres architecturales et des espaces aménagés ID (P4980), then some fixing seems to be needed (I fixed the formatter URL (P1630) already). Also @Ayack: who did the proposal for P4979 and P4980 (who were accepted with only 2 votes each). Cheers, VIGNERON (talk) 12:49, 10 December 2018 (UTC)
    • The main reason I think that it is better to have two seperate properties, is that for instance balcony (Q170552) has an entry in both and now yields a constraint violation for GINCO ID (P3905). Lymantria (talk) 13:11, 10 December 2018 (UTC)
      • Oh, good point, thanks Lymantria. Is there a lot of case like that? by design, there should be few so they could easily be dealt with exceptions on the constraint (like I did Special:Diff/809146141), but if there is a lot (more than 10% of the total?) then indeed we should maybe have separate properties. @Ayack: signaled me that there is indeed a problem with the identifiers for P4979 and P4980 (what I thought was a fix caused some problems…), does someone has more informations (or even better specifications) on how this database(s) works? Cdlt, VIGNERON (talk) 15:06, 10 December 2018 (UTC)
        • I have not really investigated if there are many of those cases, but I assume less than 10%. Still, the property now combines two thesauruses, which I think is not wise. Lymantria (talk) 17:34, 10 December 2018 (UTC)
  •   Comment based on the explanations given, I'd delete either the above or the two other ones. --- Jura 06:14, 20 December 2018 (UTC)

translation (P5972)Edit

translation (P5972): (delete | history | links | entity usage | logs | discussion)

@Tubezlob, Denny, Micru, Infovarius, Runner1928, Duesentrieb: @Sintakso, Jura1, Deryck Chan, Mfilot, TomT0m, ArthurPSmith:@Njardarlogar, Liamjamesperritt, fnielsen, Jc86035, Rua:

translation (P5972) requires every sense to be linked to every other sense with the same meaning. It scales very badly and it's difficult to maintain. Using item for this sense (P5137) is better because every sense needs only a link to the Q-item that represents its meaning.

The two objections to this approach are:

  • it will create items whose meanings are only slightly different because some senses differ only in nuances;
  • it will create items for verbs, adverbs, prepositions and adjectives.

IMO, the latter is not a problem because we already have adjectives (Orwellian (Q2156379)) and verbs (google (Q1156923). As regards prepositions, they are very few.

Previous similar discussions:

--Malore (talk) 05:04, 14 December 2018 (UTC)

  • Before we can limit its scope, the community still needs to decide whether adding thousands of Senses to the Main namespace is a good idea. I believe it is an important direction to move towards, but there is yet to be any consensus on the issue. Liamjamesperritt (talk) 21:16, 15 December 2018 (UTC)
  •   Weak oppose. I agree with Jura and Denny here. Translations aren't necessarily symmetric so linking to an item doesn't automatically solve all our problems. I see this as the centralized equivalent of the translation table on Wiktionary. Storing these in the Sense entry may make it unwieldy in Wikidata view, but seems to be what Wiktionary requires. Deryck Chan (talk) 10:31, 14 December 2018 (UTC)
    It’s not necessarily an easy task, but the fact that translations differs just a little bit is also an opportunity to describe the relationship between them by statements. author  TomT0m / talk page 10:37, 14 December 2018 (UTC)
    @Deryck Chan: To me it seems unnecessary to think of this in terms of translation. I think sense entities (i.e. items in the existing main namespace or in a dedicated sense namespace) can handle this perfectly if we leave minimal room for ambiguity. That is, if two languages have slightly different concepts for the colour blue, we create two separate sense entities for these two concepts and mark one as a subset of the other, or both as overlapping - whichever is correct.
    An important property of this implementation is that it is up to the user that queries for translations what counts as a "translation": should the translated word be a virtually exact match (i.e. uses the same sense entity), could the word have a broader or narrower meaning, and could it have an overlapping meaning? --Njardarlogar (talk) 11:53, 14 December 2018 (UTC)
    @Jura1, Denny, Deryck Chan: The current description says word in another language that corresponds exactly to this meaning of the lexeme. "corresponds exactly" suggests that the property is symmetrical.--Malore (talk) 17:48, 14 December 2018 (UTC)
    Change to   Neutral. It seems that this property is (badly) trying to solve a different problem as what I expect it to solve. Maybe we need to wait till Wiktionary can transclude Lexemes and then figure this out. Deryck Chan (talk) 22:41, 14 December 2018 (UTC)
  • My view is - I think we need translation (P5972) for now, but it should be reserved for cases that can't obviously be handled by item for this sense (P5137), and we should be actively figuring out how to migrate all uses of the first property to the second in some manner... ArthurPSmith (talk) 13:52, 14 December 2018 (UTC)
  •   Oppose I think in current shape of lexemes we need it, but use it only where item for this sense (P5137) does not work. KaMan (talk) 16:07, 16 December 2018 (UTC)
  • I (also) think that we should use item for this sense (P5137), but fall back on translation (P5972). — Finn Årup Nielsen (fnielsen) (talk) 00:40, 31 January 2019 (UTC)
  •   Oppose per KaMan. ChristianKl❫ 16:13, 12 February 2019 (UTC)
  •   temporary keep until we have a sane system to query Lexemes locally. --Liuxinyu970226 (talk) 12:46, 16 March 2019 (UTC)

The Guardian article ID (P6085)Edit

The Guardian article ID (P6085): (delete | history | links | entity usage | logs | discussion)

Per ChristianKl and Dominic's comments at Wikidata:Property proposal/New York Times short URL, it might be better to either have a single property for unique short URLs, or to not have any special properties for short URLs at all. The property has, regardless, not seen any adoption aside from the three example values that I used in the property proposal form, so deleting it would not currently result in any significant loss of data. —Jc86035 (talk) 13:19, 7 January 2019 (UTC)

Notifying the other property proposal participants: Germartin1, Visite fortuitement prolongée, ArthurPSmith, MartinPoulter, eru, Pigsonthewing, Thierry Caro. Jc86035 (talk) 13:22, 7 January 2019 (UTC)

No strong feelings on this. ArthurPSmith (talk) 15:18, 8 January 2019 (UTC)
(Note: I created both property proposals. I forgot to mention this.) Jc86035 (talk) 17:22, 8 January 2019 (UTC)

female form of label (P2521)Edit

female form of label (P2521): (delete | history | links | entity usage | logs | discussion)

Given that we now have Lexemes, there's no good reason to store this information in the item namespace ChristianKl❫ 12:59, 14 January 2019 (UTC)

  •   Oppose Until an alternative is proposed (which should be a requirement when proposing a deletion). As far as I know, this property is currently being used at least in the French Wikipedia, so it would be a good idea to start with understanding the rational of the property creation. Going in that direction, maybe @Jura1: could elaborate on that in order to move forward. Andreasm háblame / just talk to me 13:58, 15 January 2019 (UTC)
  Delete The frwiki usage should be modified, they should query Lexemes. --2409:8902:9301:B6A9:5CB3:E6FD:4195:E1F7 04:48, 16 January 2019 (UTC)
  •   Oppose Eventually maybe but there's no replacement now. Data access to lexemes is not possible yet. The same applies to demonym (P1549). Matěj Suchánek (talk) 08:41, 16 January 2019 (UTC)
  •   Delete but   On hold until the access to Lexemes is ready. Cheers, VIGNERON (talk) 11:59, 21 January 2019 (UTC)
  • {{o}} for now per Andreasmperu and Matěj Suchánek. (vote withdrawn given alternatives below) --Marsupium (talk) 01:58, 22 January 2019 (UTC), 10:47, 25 March 2019 (UTC)
  • There is also male form of label (P3321). Somehow lexeme contributors haven't found a way yet to link them in a structured way. --- Jura 13:00, 26 January 2019 (UTC)
  •   On hold until we migrate all the data to Lexemes and transfer existing external uses to Lexemes, then   Support deprecation. Deryck Chan (talk) 19:38, 26 January 2019 (UTC)
  •   Keep Used extensively also in Catalan Wikipedia for infoboxes deppending on sex or gender (P21). I.e. Nicole Kidman is an actress, not an actor, and this is basic for languages with gender flexion. Previously, you need to have access to Lexemes and move all data. --Vriullop (talk) 08:03, 29 January 2019 (UTC)
  •   note @ChristianKl: I've mentioned this discussion in phab:T212843 as an urgent case of making Lexeme data accessible by other WMF wikis. Please head over there to discuss how Lexeme access should be implemented. Deryck Chan (talk) 14:05, 1 February 2019 (UTC)
  •   Keep Until now I saw no technical support on querying Lexemes, and even one day available, this property should also be used elsewhere if one wiki can't support it due to Parsoid problems. -- 02:12, 2 February 2019 (UTC)
  •   Keep this is a very useful and important property for my native Polish and I don't think there is a good alternative in place at the moment Powerek38 (talk) 21:28, 24 February 2019 (UTC)
  •   On hold until all data is migrated to lexemes and actually used on all Wikipedias. Robin van der Vliet (talk) (contribs) 14:00, 2 March 2019 (UTC)
  •   Keep I agree with the comments above about the lack of availability regarding lexemas. Besides, this a useful property for Galician language, as it let us distinguish between sexes in the infoboxes.Maria zaos (talk) 16:07, 6 March 2019 (UTC)
  •   Keep; It's often used in --Estevoaei (talk) 21:53, 24 March 2019 (UTC)
  •   Keep The property is being used in a large number of articles, it can not be eliminated until the templates that use it are modified. Bye, --Elisardojm (talk) 23:00, 24 March 2019 (UTC)
  •   Delete
    (1) This property needlessly inscribes a specific gender model into the (relatively upper) ontology, which
    (a) raises point-of-view concerns and
    (b) introduces an imbalance (e.g., in terms of modeling permissions) between concepts’ genders (values of properties) as items and labels’ genders as implicit in this and other properties, allowing editors to create and use new gender items (e.g., non-binary (Q48270)), but not the label forms associated with such genders.
    (2) To the extent that gender (‘real-world’ gender, not grammatical gender; sexus, not genus, in somewhat dated-seeming linguistic terms) is, or should be, linguistically marked, the imbalance in occurrences of the properties female form of label (P2521) and male form of label (P3321), respectively, suggests that the conceptualization of these properties or the structures built around them (e.g., infobox-generating code on Wikipedias) at best only leads to a reinforcement of questionable views of male gender being the default, female gender being an aberration in supposed need of explicit mention (and other genders supposedly being a phenomenon below the bar of notability or acceptability). Such views not being universally accepted raises doubts as to whether the current property model behooves a universal ontology.
    Conclusion: This property (along with male form of label (P3321)) should be deleted and could, while a lexeme-based solution is not yet within reach, be replaced by a new property “gendered form of label” (or perhaps, more generally, “qualified label”), using qualifiers referring to gender items (rather than property-implicit senses of gender). See below for what this might look like this when used for actor (Q33999) as an example.
    However, note external use.
    BlaueBlüte (talk) 05:56, 11 March 2019 (UTC)
  •   Keep This property is largely used in cawiki infoboxex. Until lexemes were well upload and access to lexemes being available from LUA module, it can not be delete. It's curious to observe that the hardest positions in favor to delete it comes from people with a short number of editions. Amadalvarez (talk) 09:39, 25 March 2019 (UTC)
  •   Keep Same. --Davidpar (talk) 20:51, 25 March 2019 (UTC)
  •   Wait for Lexemes to mature, then   Delete. NMaia (talk) 04:58, 31 March 2019 (UTC)
  •   Keep This is an excellent solution which is understood by all and has been put to good use. It works, allowing infoboxes to be flexible and relevant. --FocalPoint (talk) 09:29, 26 April 2019 (UTC)
  •   Keep for now used in several wikipedias. Long term, who knows. Not there yet. With regard to "gendered form of label"-proposal ...feel everyone free to propose that one. Only after getting created that property and copying the data from P2521&P3321 to that new one... propose the deletion of these two. IMHO I don't see much improvement in lumping together "male", "female" and "non-binary" labels in every language the same property. And, after all, if lexemes are gonna be the long-term solution Wikidata probably doesn't need another temporal "patch". strakhov (talk) 18:11, 5 May 2019 (UTC)
  •   Keep : the human gender identity binary division is another problem. Here we just need to say how we deignate a grammatical gender (which is language specific and does not necessarily match the male/female genetic classification even if it also has exceptions in many species, unrelated to the human gender identity which is a sociologic problem). We still need to refer to groups that in some languages may be considered distinct, but not in others (notably for activities or nobility titles). At least these languages (not all) create a binary division and it is common. Note that this also applies to biological species : they may have a single unified gender (masculine or feminine or neutral) independantly of the fact individuals are male or female (e.g. in French : "une fouine" is feminine for both males and females, and "un serpent" is masculine for both males and females; other species have dictinct names, "une truie" if the female domestic pork, "un cochon" or "un porc" is the male domestic pork, but sometimes "porc" is used for any male or female individual ; most domestic animals have gender-based names, and the biological gender is also an important classification useful in agriculture because it is selective for the production).
    You may argue that "masculine"/"feminine" would go to the classification of lexems (instead of items) but this will only apply to the grammatical form of names (which is independant of the group classification of items which need to refer to social gender groups, or to biological genders for species). The grammatical genders of lexems will still very frequently not match the social or biological genders of classes of items, for which we need appropriate properties to create distinct classes of items, even their translated item label is identical in some language but not all; each item in Wikidata will refer to lexems only by language-specific pairing, there will be no 1-to-1 relation between items and lexems and in fact almost very item in Wikidata for classes will have multiple associated lexems with different grammatical properties. And even some instance items, like human individuals, will have multiple lexems to refer to them in the same specific language, including contextual grammatical forms (like genitives or abbreviated names, or different usage names: official, formal, civil, artist names, nicknames, surnames given by others, or names changed/augmented during their life becaue of mariages or given honor or change of nationality or residence, or variants used specifically only in specific regions or situations...). To make things even more complex, the grammatical gender may change depending if this is a different plural form (e.g. in French: "un amour" is grammatically masculine in singular independantly of the person gender, "des amours" is grammatically feminine in plural also independantly of the gender of persons even if they are only boys/men!)
    I say keep "masculine and feminine" (grammatically and socially for persons) as classes in Wikidata, but at least create another property or classes for male/female biological gender distinctions. And of course add separately the grammatical gender distinctions and forms in lexems. Verdy p (talk) 15:30, 14 May 2019 (UTC)
  1.   Keep: useful. Nomen ad hoc (talk) 14:40, 21 May 2019 (UTC).

Proposed replacementsEdit

“gendered form of label”Edit

This example (using item actor (Q33999)) would equally serve as an illustration of a possible “qualified label” property, which would comprise “gendered form of label” as a special case based on the qualifiers used.

gendered form of label
  actriu (Catalan)   edit
sex or gender (P21) female (Q6581072)
transgender female (Q1052281)
editors can easily assign existing forms of the label to genders not considered by the original editor
▼ 0 reference
+ add reference
  actor (Catalan)   edit
sex or gender (P21) male (Q6581097)
transgender male (Q2449503)
▼ 0 reference
+ add reference
  actor/actriu (Catalan) editors can easily add new forms corresponding to new gender items   edit
sex or gender (P21) non-binary (Q48270)
▼ 0 reference
+ add reference
  actrx (Catalan)(or whatever Catalan speakers may come up with)   edit
sex or gender (P21) non-binary (Q48270)
▼ 0 reference
+ add reference
  Schauspieler*in (German)   edit
sex or gender (P21) non-binary (Q48270)
mode of derivation (P5886) Gendersternchen (Q62023201) external users (e.g., Wikipedias) could query for …
▼ 0 reference
+ add reference
  SchauspielerIn (German)   edit
sex or gender (P21) non-binary (Q48270)
mode of derivation (P5886) a different (perhaps new) property might be in order here Binnen-I (Q863893) … specific forms of neologisms based on editor preferences
▼ 0 reference
+ add reference
  Schauspielerin (German)   edit
sex or gender (P21) female (Q6581072)
transgender female (Q1052281)
▼ 0 reference
+ add reference
  … (…)   edit
sex or gender (P21)
▼ 0 reference
+ add reference
+ add value
@Andreasmperu, Matěj Suchánek, Marsupium, Vriullop, Powerek38:@Maria zaos, Jura1, Amire80, Nikerabbit, GerardM: do you all agree with the replacement here? Or you will still vote keep, regardless of it? --Liuxinyu970226 (talk) 11:49, 23 March 2019 (UTC)
This proposal is interesting but I think this isn't suitable venue for discussing it. Wikidata:Project chat or Wikidata:Property proposal will definitely have greater attention. Matěj Suchánek (talk) 21:41, 24 March 2019 (UTC)
Until this proposal (or another accepted alternative) were not totally deployed, the P2521 must be kept. Amadalvarez (talk) 09:39, 25 March 2019 (UTC)
@Amadalvarez: male form of label (P3321) too? --Liuxinyu970226 (talk) 23:16, 26 March 2019 (UTC)
@Liuxinyu970226: NO. We're not using P3321 in cawiki infoboxes. Thanks,Amadalvarez (talk) 05:15, 27 March 2019 (UTC)
@Liuxinyu970226:I agree with Amadalvarez, so   Keep P2125.--Maria zaos (talk) 20:29, 31 March 2019 (UTC)

External useEdit

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

male form of label (P3321)Edit

male form of label (P3321): (delete | history | links | entity usage | logs | discussion)

Per #Property:P2521 above, given that we now have Lexemes, we should also drop this property to just say "male form", but no other infos. --Liuxinyu970226 (talk) 15:06, 14 January 2019 (UTC)

  •   Keep This is an excellent solution which is understood by all and has been put to good use. It works, allowing infoboxes to be flexible and relevant. --FocalPoint (talk) 09:30, 26 April 2019 (UTC)
  •   Keep I think it can be useful. DGtal (talk) 10:14, 13 May 2019 (UTC)

media legend (P2096)Edit

media legend (P2096): (delete | history | links | entity usage | logs | discussion)

This data should be moved to Commons since it supports Structured Data. Example: Douglas Adams (Q42)image (P18)commons:File:Douglas_adams_portrait_cropped.jpgU+1F360 (talk) 05:47, 6 February 2019 (UTC)

  On hold This is similar to #P2521. It needs to wait until it's possible to fetch the data from Commons due its use in infoboxes. Matěj Suchánek (talk) 08:26, 6 February 2019 (UTC)
  Keep. You're too early. Come back here when you have a good alternative. Let's just close this one for now and don't leave it open for months. Multichill (talk) 12:41, 16 February 2019 (UTC)
Damage report: Last (2nd) paragraph in Talk:Q2709#English description, – 22:27, 23 February 2019 (UTC)
  Keep for now, at least; with no prejudice to renomination when circumstances change as Matěj explains. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:08, 4 March 2019 (UTC)
  Keep Depending on the context in which an image is shown it makes sense to have different media legends. ChristianKl❫ 14:21, 8 March 2019 (UTC)
  On hold let's make sure this information is migrated to Commons first, then   Delete. NMaia (talk) 05:02, 31 March 2019 (UTC)
  Keep. It's used by infoboxes on many Wikipedias. If we want to deprecate this, the following needs to happen:
  1. Make it feasible for Lua to transclude image captions on Commons.
  2. Copy all existing uses of this property to the caption fields in Commons.
  3. Migrate en:Module:Wikidata and all descendent modules from P2096 to Commons caption fields.
  4. Then remove all uses of this property and deprecate it.
Deryck Chan (talk) 13:44, 7 April 2019 (UTC)
  On hold As many others said, I support deletion, but we do first many other things after remove the property. --Tinker Bell 05:39, 15 April 2019 (UTC)
This file is used in many different topics, but not all of the should use the same label.
Strongly   Keep The same file can be used for many different purpose in different situation. The description on Commons cannot fullfill all those purposes. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 20:14, 19 April 2019 (UTC)

Microsoft Store album ID (P4603)Edit

Microsoft Store album ID (P4603): (delete | history | links | entity usage | logs | discussion)

The store has been closed. —★ → Airon 90 15:57, 12 February 2019 (UTC)

  Delete looks like it never really got used anyway. Multichill (talk) 12:33, 16 February 2019 (UTC)
  Delete Not sure this is useful if this was closed Misc (talk) 22:41, 17 February 2019 (UTC)
  Delete Per above. Esteban16 (talk) 17:42, 26 February 2019 (UTC)
  Keep While the website is no longer functional, there are thousands of IDs which can still be obtained due to having been saved in the Internet Archive. It may be beneficial to keep this data in Wikidata, although there may not be much of a use case at the moment. Jc86035 (talk) 08:51, 1 March 2019 (UTC)
  Keep per Jc86035. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:53, 4 March 2019 (UTC)
  •   Delete 3 actual uses as of today. --- Jura 21:13, 16 March 2019 (UTC)
  •   Delete; unused so far, it won't be useful in the future. --abián 14:52, 25 March 2019 (UTC)
  •   Delete. Too few uses to justify keeping a historical identifier. Deryck Chan (talk) 13:38, 7 April 2019 (UTC)
  •   Delete not used and website closed. --Rschen7754 18:22, 13 April 2019 (UTC)
  Keep It can still be used ny internet archive. Trade (talk) 16:04, 6 May 2019 (UTC)
  Delete Not used and never be completed. Snipre (talk) 23:54, 9 May 2019 (UTC)

Microsoft Store artist ID (P4497)Edit

Microsoft Store artist ID (P4497): (delete | history | links | entity usage | logs | discussion)

The store has been closed. —★ → Airon 90 15:58, 12 February 2019 (UTC)

  Delete looks like it never really got used anyway. Multichill (talk) 12:34, 16 February 2019 (UTC)
  Delete not useful if closed Misc (talk) 22:42, 17 February 2019 (UTC)
  Delete Per above, and it was barely used. Esteban16 (talk) 17:40, 26 February 2019 (UTC)
  Keep While the website is no longer functional, there are thousands of IDs which can still be obtained due to having been saved in the Internet Archive. It may be beneficial to keep this data in Wikidata, although there may not be much of a use case at the moment. Jc86035 (talk) 08:51, 1 March 2019 (UTC)
  Keep per Jc86035. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:56, 4 March 2019 (UTC)
  •   Delete 9 uses as of today, 16 months after creation. --- Jura 21:11, 16 March 2019 (UTC)
  •   Delete; unused so far, it won't be useful in the future. --abián 14:53, 25 March 2019 (UTC)
  •   Delete. Too few uses to justify keeping a historical identifier. Deryck Chan (talk) 22:02, 6 April 2019 (UTC)
  •   Delete not used and website closed. --Rschen7754 18:22, 13 April 2019 (UTC)
  •   Delete; unused so far, it won't be useful in the future. Snipre (talk) 23:56, 9 May 2019 (UTC)

Image Archive, Herder Institute (P6482)Edit

Image Archive, Herder Institute (P6482): (delete | history | links | entity usage | logs | discussion)

I think something went wrong here, value is identical with subject --- Jura 19:37, 15 February 2019 (UTC)

@Jura1: please ping the participants in the property proposal: @ديفيد عادل وهبة خليل 2, Jneubert, YULdigitalpreservation, Urban 3th: Jura1 proposes Property:P6482 for deletion. − Pintoch (talk) 08:30, 16 February 2019 (UTC)
Seems to work as intended. John III Sobieski (Q53454) has Image Archive, Herder Institute (P6482) with contents "Q53454" on it. This links to which resolves to . So what do you think went wrong here? It's nice they adopted our identifiers. Multichill (talk) 12:39, 16 February 2019 (UTC)
Value is identical with subject! Yes, thats intended. The database contains image sources of places, objects, events, persons, organizations, etc. If a Wikidata identifier is found for an entity (for example, Q53454 - John III Şoboski), it is stored in its associated record. Property "P6482" works like a beacon and determines the corresponding image sources in the database. The link refers to the image sources associated with John III Şoboski. Urban 3th (talk) 07:13, 18 February 2019 (UTC)
  Keep as per Urban 3th. It's uncommon but somehow really nice to see QIDs in use as persistent identifiers for web access in an external database. Jneubert (talk) 08:58, 18 February 2019 (UTC)
  Delete and create a third-party formatter URL for Wikidata identifier (Q43649390). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:06, 4 March 2019 (UTC)
  Keep - it will not be identical in case of merge to another item. Also, User:Pigsonthewing does not explain how to store the information that for a given item in WD there is an ID in Herder. The formatter cannot tell that. 02:00, 14 April 2019 (UTC)
The formatter [sic] does not need to do so; that's what http response headers are for. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 14 April 2019 (UTC)
User:Pigsonthewing, in which Wikidata property would the "http response headers" be stored, so that the information about existence of an ID in Herder is available in Wikidata? 19:26, 14 April 2019 (UTC)
  Delete Per, in which WMF policy, such http response headers can be disclosed on a wiki page? Disclosure of them are always violating wmf:Privacy Policy. --Liuxinyu970226 (talk) 10:34, 29 April 2019 (UTC)

Boobpedia article (P6270)Edit

Boobpedia article (P6270): (delete | history | links | entity usage | logs | discussion)

Recently proposed on the project chat under Suitability of property "Boobpedia article", now archived (pinging StarryGrandma, ChristianKl, Ghouston, Micru, Lazypub, The Honorable, Mahir256, Robin van der Vliet, Valentina.Anitnelav, Gerwoman). StarryGrandma already put it much better than I could, especially in their second comment, and site administrator Th. Hon. also said they would support a deletion request, so I’ll keep my comment brief – IMHO this is some seriously creepy shit that I really don’t want to see on Wikidata. (And no, ChristianKl, this has nothing to do with me being conservatively minded.) —Galaktos (talk) 15:56, 18 February 2019 (UTC)

  •   Delete see the previous discussion for my reasoning. ChristianKl❫ 15:59, 18 February 2019 (UTC)
  •   Keep - to repeat my original comment "I don't think Boobpedia should be used to prove notability. But I find it no worse of a site than many of the others we have available." Lazypub (talk) 00:10, 19 February 2019 (UTC)
  •   Delete - I'm an admin on the site, so obviously I'm not "conservatively minded." Boobpedia is a user-edited wiki with articles of wildly varying reliability, mostly about living people. Having an official property for it gives a false impression about the quality and accuracy of the site. Th. Hon. 02:30, 19 February 2019 (UTC)
    • But how is that any different than, as example, musicbrainz (which is considered authority control), discogs, or imdb? Lazypub (talk)
      • Musicbrainz appears to be professional spam, this GUID is obviously not better than discogs or allmusic. OTOH your examples don't mention "boobs", some celebs might not welcome this name for a property, same idea as some stuff listed in the Project:Living people policy, e.g., weight, and cup size (as plain English version of boob) is worse than weight, here: mass. I'll have a screaming fit if somebody puts "was 32B, now 34D" in an enwiki article where I could add the references. Hopefully 34D isn't good enough for boobpedia, but I digress. 19:26, 19 February 2019 (UTC)
  •   Keep This property is just a property like any other. Qualifying this property like "creepy shit" is definitely not an objective criteria that we can use to evaluate our properties. If the scope is considered too broad, it can be narrowed by restricting its uses to professions where this property would be applicable.--Micru (talk) 06:09, 19 February 2019 (UTC)
  •   Delete per StarryGrandma -- Jneubert (talk) 09:12, 19 February 2019 (UTC)
  •   Delete - Valentina.Anitnelav (talk) 10:08, 19 February 2019 (UTC)
  •   Delete - --Gerwoman (talk) 17:58, 22 February 2019 (UTC)
  •   Delete I don't think we need property for all user-generated wikis.--Jklamo (talk) 12:31, 24 February 2019 (UTC)
  •   Keep If we got rid of the user-generated wikis, we could very easily delete half our properties. Trade (talk) 16:28, 25 February 2019 (UTC)
Not to mention the fact that we are a user-generated wiki. Should other sites discount what we do here? Lazypub (talk)
User-generated wikis aren't considered acceptable sources on enwiki. Th. Hon. 00:41, 27 February 2019 (UTC)
That's for sources on non-structured sites. We aren't sourcing the information, we are simply listing the identifiers. Lazypub (talk)
  •   Keep As said before, qualifying this property like "creepy shit" is definitely not an objective criteria that we can use to evaluate our properties, and we do have a large number of other IDs using user generated content. Topics like pornography often deal with "machismo" and objectification of people, which is bad. But I do not think these topics should be swept under the rug. How to deal with it? Baloubet du Rouet (talk) 04:08, 28 February 2019 (UTC)
    • I'm not sure if you read the discussion, but this is not about pornography (there are other identifiers in this area that are ok) and Boobpedia is not dedicated to porn ("Boobpedia is a free and user-edited encyclopedia of women with big boobs"). Accordingly there might be an article for any women with cup C and above and this id is used on people who have nothing to do with pornography, like Lara Logan (Q133653), Aretha Franklin (Q125121) and a lot more. While it might be normal to refer to women as "boobs" in the pornographic area this kind of objectification is degrading towards others and should not be made "official" by dedicating an own id to it. - Valentina.Anitnelav (talk) 11:29, 1 March 2019 (UTC)
  •   Delete I take a very liberal line to allowing IDs from "adult" sites, but this one presents non-trivial BLP issues (not to mention safe-space issues, when people start creating entries there for Wikimedians), and we get very little benefit from using it. Colleagues voting "keep" should consider how they would feel if someone created an entry there for their mother/ sister/ daughter/ life-partner. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:04, 4 March 2019 (UTC)
  •   Delete I don't want to lend any support to this dubious site. We have a responsibility to consider BLP and #MeToo issues; this clearly fails both. --Tagishsimon (talk) 22:30, 6 March 2019 (UTC)
  •   Delete   Facepalm Gamaliel (talk) 19:44, 7 March 2019 (UTC)
  •   Keep. This is an ID like any other we store. Thierry Caro (talk) 14:42, 11 March 2019 (UTC)
  •   Delete per Jklamo, Multichill (talk) 16:31, 11 March 2019 (UTC)
  •   Delete Very problematic, per above. --Rschen7754 01:43, 16 March 2019 (UTC)
  • As a user who's creating pages about erotic/pornographic models, including female, I can't remember a situation when Boobpedia was helpful for me. There are some catalogues of similar reliability which not mentionned in properties here, such as,,, and there are not wiki-powered. However I'm voting   Neutral, it's not an inferior-quality source. I'm still adding this to Statements 'cause I'm not much care. --Wolverène (talk) 15:45, 28 March 2019 (UTC)
  •   Keep Wikidata is a meta-database. We're defeating this purpose by deleting this property. I'm pinging some voters of the initial property proposal as well: PMG, Cwf97, Marberal, Daft fiction. --Deansfa (talk) 01:26, 5 April 2019 (UTC)
  •   Keep PMG (talk) 07:26, 5 April 2019 (UTC) In my opinion there is no difference between this property and other ID property to user generated content. It also fits to Wikidata:List of properties/pornography.
  •   Keep Marberal (talk) 14:38, 5 April 2019 (UTC) What Boobpedia brings to the table is a whole lot of information detailing physical characteristics of people, which is within the scope of the Wikidata project. I think that by counting on that information, Wikidata improves and increases the amount of information stored in it. As for the main critics, I'll address the main four in here: ¿Boobpedia is user-edited? As of right now that can also be said of other property IDs. ¿Boobpedia is disrespectful? The data it brings to the table is comprised of numbers/classes detailing physical characteristics such as height, weight, eye color and many others, and the references to that data, and thus doesn't contravene the policies detailed in the resolution about the biographies of living persons. ¿Boobpedia objectifies those people by providing such a detailed amount of physical data? Wikidata is a user-edited knowledge base, which by design objectifies everything to represent it as properties in a huge graph. For example, every person's data is represented as an object instanced from the class "human", with several added physical properties such as height, color or mass. ¿Boobpedia only compiles information about "women with big boobs"? As many other databases its scoped, which means that it only compiles information regarding its area of interest. The same can also be said about many other properties that we use, such as Musicbrainz which compiles data only about music.  – The preceding unsigned comment was added by Marberal (talk • contribs) at 14:38, 5 April 2019‎ (UTC).
    • There seem to be some misunderstandings:
      1. I could not find any concern that Boobpedia compiles only information about "women with big boobs" in the discussion above (could you point me to it?): There was a concern that Boobpedia's scope is too broad - as it makes no difference between women in the erotic/pornographic business and others.
      2. In this context "objectification" does not refer to collecting information about a person within a certain model. It is a concept referring to a certain way of representing another person (e.g. as just a means to a certain goal (in the sexual domain: sexual arousal, erotic desires) or reduction to body/appearance (unrelated to their skills and accomplishments and without considering the subject's dignity) - if you want to delve deeper into this topic you may have a look at the entry in the Stanford Encyclopedia of Philosophy [6]).
      3. Given point 2, the disrespectfulness (towards women outside the pornographic/erotic business), the tendency to violate their dignity and thus the violation of goals expressed in Wikidata:Living_people should become a bit clearer. It is not respectful towards Aretha Franklin or Lara Logan to reduce them to their "boobs" and it is not respectful to speculate (contrary to your impression it seems to me that this information is rather scarcely sourced) about their size of breasts/body measurements and represent this as an issue of general concern. - Valentina.Anitnelav (talk) 09:47, 7 April 2019 (UTC)
  • I'd like to point out that per some of the reasoning in the Keep votes, stalker-y and doxing sites like Encyclopedia Dramatica (Q159540), Porn Wikileaks (Q7230195), and Kiwi Farms would be acceptable sites for properties, as "just a property like any other." As I suggested upthread, perhaps limiting website properties to sites Wikipedia would consider acceptable sources is in order? Th. Hon. 01:53, 14 April 2019 (UTC)
      1. While I see why it would be shocking to have a identifier on those web sites, I can also see value to someone studying the harassement targetting some persons (or quantifying it somehow). --Misc (talk) 08:23, 9 May 2019 (UTC)
  •   Delete low quality, BLP problems, etc. --99of9 (talk) 14:05, 20 April 2019 (UTC)
  •   Keep Like the property for Bilibili ID (see archive), copyright problems aren't what Wikidata users concern. --Liuxinyu970226 (talk) 10:30, 29 April 2019 (UTC)
    Additional   Comment @99of9: For BLP concerns, we may consider adding property that may violate privacy (Q44601380) to this property, hence we warned users to no longer abuse using it. --Liuxinyu970226 (talk) 23:29, 9 May 2019 (UTC)
    I don't think you are supposed to use property that may violate privacy (Q44601380) on identifiers. And what is it about about abuse you are talking about? --Trade (talk) 21:08, 10 May 2019 (UTC)
    @Trade: I boldly added it, can't I? --Liuxinyu970226 (talk) 01:23, 14 May 2019 (UTC)
    Adding property that may violate privacy (Q44601380) doesn't say that people should be careful about adding data. It says that data should be only added when it "be considered widespread public knowledge or openly supplied by the individual themselves". I'm doubting that's true for most of the people that currently have the tag. ChristianKl❫ 11:53, 15 May 2019 (UTC)
  •   Delete, for the people who say "creepiness" is not a valid deletion criterion, I am at a loss. Wikidata ought to be a safe space. Most of these people did not ask for, and likely do not want, a web site focusing on their breast measurements and bra size. The creepiness factor is one of the most important criteria—Wikidata should have no part in providing a venue for unwanted, sexualized attention being given to women just because they are females in the public eye. Dominic (talk) 00:51, 24 May 2019 (UTC)

LGDB game ID (P5116)Edit

LGDB game ID (P5116): (delete | history | links | entity usage | logs | discussion)

Linux Game Database have been dead for quite some time. I think it's fair to say, they are not coming back. —Trade (talk) 00:05, 22 February 2019 (UTC)

Yeah, I always kept the hope :-( Too bad I did not create a Mix’n’match beforehand − it’s a bit of pain to do it via Internet Archive.
Regarding the property − I think current practice is to change the formatter URL to go to the Internet Archive.
Jean-Fred (talk) 13:59, 22 February 2019 (UTC)
I tagged the 4 LGDB properties with Wikidata property for a discontinued website (Q60457486) and added a preferred formatter URL (P1630). Jean-Fred (talk) 14:16, 22 February 2019 (UTC)
Looks like the Internet Archive did a fairly good job:
Jean-Fred (talk) 14:25, 22 February 2019 (UTC)
  •   Keep And - as a meta issue - please can we stop having deletion discussions for identifiers which are no longer issued, but still exist in archives? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:55, 4 March 2019 (UTC)
  •   Keep I 10000% agree with Pigsonthewing said, plus we should refrain from PFDing for properties that "met copyright problems". --Liuxinyu970226 (talk) 10:32, 29 April 2019 (UTC)

Twitter user ID number (P6552)Edit

Twitter user ID number (P6552): (delete | history | links | entity usage | logs | discussion)

Redundant with Twitter username (P2002) and creation seems to be inconsistent with the discussion (see use on Q2013 by creator) --- Jura 11:12, 3 March 2019 (UTC)

In what way is it inconsistent? NMaia (talk) 02:09, 4 March 2019 (UTC)
Proposal discussion is at: Wikidata:Property proposal/Twitter user ID. Creation by User:Pintoch seems perfectly correct. The sole objection was from Jura1, who wrote only "Oppose adding both" with no rationale; and did not give an answer when asked why. There were four supporters, in addition to the proposer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 4 March 2019 (UTC)
  • Keep, but use only as a qualifier to P2002 (or perhaps vice versa). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 4 March 2019 (UTC)
  •   Keep. Not a valid rationale in my view. NMaia (talk) 22:36, 4 March 2019 (UTC)
  •   Keep; the username itself is still useful information. Trivialist (talk) 00:56, 5 March 2019 (UTC)
  •   Comment @NMaia: It seems that the actual "we" are confusing many pro/con lists of both properties, can we please restructure both as one section, to discuss both P2002 and P6552? --Liuxinyu970226 (talk) 14:36, 5 March 2019 (UTC)
  •   Keep Useful because a Twitter user may rename their account, but having a log of the name used has value. Also there is a known pattern where users will archive their accounts by renaming their account and then creating a new account with the original username. Having both the username and user id numbers allows us to track this. William Graham (talk) 19:27, 26 April 2019 (UTC)

National Library of Ireland authority ID (P1946)Edit

National Library of Ireland authority ID (P1946): (delete | history | links | entity usage | logs | discussion)

Identifier not used by National Library of Ireland, linked indentifiers are works, not authors. See Property talk:P1946. —Jklamo (talk) 16:38, 4 March 2019 (UTC)

  •   Delete based on the discussion on the property talk page it looks like this has never worked and is simply not a valid id. ArthurPSmith (talk) 18:15, 4 March 2019 (UTC)
  • There are currently 16,501 uses of this property. Is the proposal to simply discard that data? Can nothing be salvaged? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 4 March 2019 (UTC)
    • I don't know how much can be salvaged, but this also discusses the problem. When the Property example on the property page is incorrect, there is a serious problem. Circeus (talk) 18:49, 4 March 2019 (UTC)
    • @Pigsonthewing:, as far as I can tell from the talk page, this property's existence in VIAF has a) no connection whatsoever with the website data and b) is really just a mirror of the LCC data anyway. Circeus (talk) 12:32, 17 March 2019 (UTC)
  •   Delete The very example on the property page is incorrect, and since almost all records are being added based on VIAF records which seem to reflect no actual ID in use at the Library, this is essentially unsalvageable. Circeus (talk) 12:32, 17 March 2019 (UTC)
  • I don't have a vote either way, though I'm edging toward keep. I originally proposed this based on the data that the library was feeding to VIAF. It is still feeding that data and they are still digitizing their indices (according to their website). I think it stands to reason that if a library is actively creating identifiers and giving this data to VIAF that the numbers have meaning and likely use in the future, even if they don't link to anything today. Hazmat2 (talk) 23:17, 23 May 2019 (UTC)
    @hazmat2: Have you looked at the talk page for the property? Here's what someone who actually asked the NLI wtf was going on got for an answer: "The VTLS files [prob. referring to VTLS (Q7907618) software and not any standard] where added to VIAF as a test in 2014 and they had not been able to do any further things with them afterwards. The bibliographical records currently linked do share the same VTLS ID, but are totally independent from the authority record. No correlation whatsoever. The authority record linked in VIAF is correct, but it is not actually a record created by the NLI, it is a downloaded record from the Library of Congress authorities server. So basically a copy of the data with a new number in their own VTLS system."
    They will never "have meaning" and they are not actively either "creating identifiers" nor "giving this data to VIAF", because they're not adding anything further from the original data dump, which was never their data to begin with, but a mirror of LCC authorities. Circeus (talk) 23:37, 23 May 2019 (UTC)
    • Nope. I wasn't actively following this on the talk page. All I knew was that there had been new VTLS numbers on VIAF since two years ago. Probably just evidence of linking on VIAF side then which I took as NLI linking them. If that's the case then I vote delete as well. Hazmat2 (talk) 00:23, 24 May 2019 (UTC)

business division (P199)Edit

business division (P199): (delete | history | links | entity usage | logs | discussion)

Merge to subsidiary (P355). To the extent there is any difference at all in the use of these two properties, it is subtle and inconsistent. They certainly don't offer a clear distinction in legal statuses, which vary from country to country anyway. —Swpb (talk) 14:55, 6 March 2019 (UTC)

Kopiersperre Jklamo ArthurPSmith S.K. Givegivetake fnielsen rjlabs ChristianKl Vladimir Alexiev User:Pintoch Parikan User:Cardinha00 User:zuphilip MB-one User:Simonmarch User:Jneubert Mathieudu68 User:Kippelboy User:Datawiki30 User:PKM User:RollTide882071 Kristbaum Andber08

  Notified participants of WikiProject Companies


LilyPond notation (P5482): (delete | history | links | entity usage | logs | discussion)

Procedural request; the datatype should be changed to "musical notation". Jc86035 (talk) 10:36, 17 March 2019 (UTC)

  Support   Comment The new datatype is currently limited to 400 characters, whereas strings could be of any length. As of today, the longest occurrence is only 125 characters, but for the sake of discussion, I added a 760 character value at Il était un petit navire (Q2607622). LaddΩ chat ;) 15:02, 17 March 2019 (UTC)
@Laddo: I was aware when floating the existence of a musical notation datatype that the limit for all string-based properties was 400 characters. Did this limit get larger some time ago for regular strings? If so, then the datatype should promptly be adjusted to use the new upper limit. Mahir256 (talk) 18:43, 17 March 2019 (UTC)
@Mahir256: Dunno what the maximum number of character is, but Wikidata usage instructions (P2559) has one entry with 514 chars (
PREFIX wd: <>
SELECT ?item ?itemLabel ?valueLabel (strlen(?valueLabel) as ?nbChar)
	?item wdt:P2559 ?value .
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en,en"  }    
order by desc (?nbChar)
Try it! ), and I had no issue creating a string of 1000 chars here. LaddΩ chat ;) 20:43, 17 March 2019 (UTC)
@Lucas Werkmeister (WMDE), Lydia Pintscher (WMDE): can you clarify the maximum character limit for properties based on strings? If in fact it is higher than 400, can this new datatype be extended to use that character limit? Mahir256 (talk) 20:46, 17 March 2019 (UTC)
@Mahir256: the limit for external identifiers, strings and URLs was recently raised to 1500 characters (T154660). No comment from me on whether that should apply to musical notation too. --Lucas Werkmeister (WMDE) (talk) 11:20, 18 March 2019 (UTC)
I'm open to increasing it if we are confident we can deal with the licensing issues that potentially arise with longer musical pieces. --Lydia Pintscher (WMDE) (talk) 16:18, 18 March 2019 (UTC)


@Laddo: I've filed a Phabricator task for increasing the length limit of the datatype. Jc86035 (talk) 11:28, 20 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Laddo, Mahir256: Since the length limit has been increased, I think it would now be appropriate to replace the property. Jc86035 (talk) 16:29, 15 April 2019 (UTC)


LinkedIn personal profile URL - DEPRECATED: Use P6634 (P2035): (delete | history | links | entity usage | logs | discussion)

This has been superseded by LinkedIn personal profile ID (P6634) (see consensus at Wikidata:Property proposal/LinkedIn personal profile_ID, and earlier discussions linked from there), and I have marked it as deprecated. I have now copied over existing values, excluding a few which were malformed, or otherwise not working. A few more have been moved to LinkedIn company ID (P4264), where they correctly belong. I have placed notices of this breaking change on the talk pages of all versions of Template:LinkedIn URL (Q29508942). We need to decide how much time to allow sister projects to catch up before we delete the property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:11, 29 March 2019 (UTC)


P6779 (P6779): (delete | history | links | entity usage | logs | discussion)

Request by the creator of the Property: Terms of use can not be respected on WD: CC BY-NC 4.0. The creation of a new property is also possible. Regards. --Eihel (talk) 15:09, 25 May 2019 (UTC)