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

Edit

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.


Contents

RequestsEdit

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)
  •   Delete: Why have a bunch of “time of spacecraft [event]” properties when most of the events (launch, landing, docking/undocking) apply to many kinds of vehicles, and the remaining one (orbital decay) applies to all kinds of spaceborne objects. Hawke666 (talk)

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.

Saehrimnir
Leyo
Snipre
Jasper Deng
Dcirovic
Walkerma
Egon Willighagen
Denise Slenter
Daniel Mietchen
Andy Mabbett
Kopiersperre
Emily Temple-Wood
Pablo Busatto (Almondega)
Nothingserious
Antony Williams (EPA)
TomT0m
Wostr
Devon Fyson
User:DePiep
User:DavRosen
Benjaminabel
99of9
Kubaello
Fractaler
Sebotic
Netha
Hugo
Samuel Clark
Tris T7
Leiem
  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 pl.wiki, 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)
  •   Delete We do need better chemical relationship properties, but they need to be extremely clearly defined. --99of9 (talk) 01:06, 10 July 2019 (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)

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)
  • weak keep: all the Guardian articles fulfil a need. Probably thousands (?) of them have an online ID. So the property could be useful. Nomen ad hoc (talk) 21:51, 5 July 2019 (UTC).

Image Archive, Herder Institute (P6482)Edit

Initial discussionEdit


Second discussion?Edit


incorrect closuresEdit

Repeating previous comment:

  • Given that it's a controversial property, I don't think a participating administrator should be closing this. Number of uses is irrelevant to reason for which this was listed. --- Jura 22:21, 1 June 2019 (UTC)

As Liux.. isn't an admin, there isn't much they can do about it either. --- Jura 22:41, 8 July 2019 (UTC)

3rd discussionEdit

  Keep Unless if Jura1 has a fresh new reason that this property should be deleted, I doubt if there's need to restart any discussions here. --125.38.13.0 07:49, 10 July 2019 (UTC)
  • Liuxinyu970226, this is about the closure(s), I don't understand why you start a 2nd or a 3rd discussion. --- Jura 10:53, 10 July 2019 (UTC)
    @Jura1: When you repeat your reason of deletion, you are just re-starting it, it's true for every humans that edit wikis, anyone, anywhere and anyhow, please do not make so-called "connections" between 125.38.13.0 and me, this IP range has nothing to 5W1H-do and be with me, and just a violation of WD:AGF. --Liuxinyu970226 (talk) 13:21, 10 July 2019 (UTC)
    Sorry, I thought it was you logged out. Anyways, no it's not another deletion discussion as you and the ip seem to think. It's a meta question for administrators. Would you know if the IP is one? --- Jura 15:52, 10 July 2019 (UTC)
@Jneubert, Renamerr, Maqivi, Liridon, Epìdosis:@Renessaince, Urban 3th, ديفيد عادل وهبة خليل 2, Davidpar, Pintoch:@Romaine: Do you all still think that this property should be kept? --Liuxinyu970226 (talk) 22:06, 10 July 2019 (UTC)
  •   Keep, for the reasons given above. Jneubert (talk) 07:24, 11 July 2019 (UTC)
  •   Keep--Liridon (talk) 11:21, 12 July 2019 (UTC)

YouTube Gaming game ID (P5367)Edit

YouTube Gaming game ID (P5367): (delete | history | links | entity usage | logs | discussion)

As it was already announced before, unfortunately, today service YouTube Gaming was definitely closed. More specifically, YouTube has stopped supporting this service and subsequently, all the video game content now can be found only on the page https://www.youtube.com/gaming in the main YouTube app/page. As a result, all links now also redirected on this site, unfortunately I think that we will have to delete the property for obvious reasons since we can no longer do anything here, this is so sad :/ ΛΧΣ21 Vacation9 John F. Lewis (talk) Bene* talk #Reaper (talk) Josve05a (talk) Chris Mason (talk) FunPika Arthena (talk) Wangxuan8331800 (talk) Sjoerd de Bruin (talk) Nicereddy (talk) Syum90 (talk) DrakeCaiman (talk) --George (Talk · Contribs · CentralAuth · Log) Andreasburmeister (talk) Danrok (talk) 18:20, 30 October 2015 (UTC) Macrike (talk) Dispenser (talk) 16:56, 7 July 2017 (UTC) --Zache (talk) 13:34, 12 July 2017 (UTC) Mohammed Adam (T) SharkD  Talk  06:41, 9 November 2017 (UTC) ZebaX2010 (talk) 00:49, 21 November 2017 (UTC) Sight Contamination (talk) Lewis Hulbert (talk) 20:26, 13 December 2017 (UTC) Jean-Fred (talk) 10:48, 28 February 2018 (UTC) Santer (talk) Cloaker416 (talk) 22:18, 12 June 2018 (UTC) Rampagingcarrot (talk) 19:57, 28 June 2018 (UTC) Diggr (talk) 08:07, 3 July 2018 (UTC) Harsh Rathod Poke me! 09:42, 7 July 2018 (UTC) Kirilloparma (talk) 00:30, 5 August 2018 (UTC) Sir Lothar (talk) 10:10, 10 August 2018 (UTC) Cwf97 (talk) 14:33, 22 October 2018 (UTC) Esteban16 (talk) 00:08, 27 October 2018 (UTC) Peterchanws Brasig Le Yota de Mars YotaMoteuchi (talk) 08:09, 22 May 2019 (UTC)   Notified participants of WikiProject Video games. Kirilloparma (talk) 19:06, 30 May 2019 (UTC)

Internet Archive gives me an Your browser isn't supported :(error so i don't really think that's an option. Are there any other video game properties or video game databases that you think we should finish or create before they inevitable close down? --Trade (talk) 21:27, 30 May 2019 (UTC)
I can confirm you, that at the moment we have only two video game streaming platforms, it's Twitch and also now closed YouTube Gaming. For all other platforms that exist, most of whom are not diffused, there is no identifier property, so there’s no need to worry about that. To create, I think, we still have for a moment Mixer (games) as other video game streaming platform, but it's not really diffused as Twitch, so I don't know. Kirilloparma (talk) 00:28, 31 May 2019 (UTC)
I was thinking about gaming databases as a whole, not just streaming websites. Personally i'm concerned about Steam Greenlight (Q61905393) (Melody's Escape (Q60197903) - Melody's Escape). I've had trouble making a property proposal due to the nature of the URL. --Trade (talk) 01:40, 1 June 2019 (UTC)
  •   Delete. Looks like this has already been deprecated so we can safely delete the property. Deryck Chan (talk) 17:39, 16 July 2019 (UTC)

Property:P5660Edit

Diffusion ENS ID (P5660): (delete | history | links | entity usage | logs | discussion)

The related site has been closed and the content was moved to Savoirs ENS ID (P5664) (see for instance, in the case of Michel Serres (Q364456), [6] and [7]). —Nomen ad hoc (talk) 15:46, 4 June 2019 (UTC)

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Marianne Casamance
Le Passant
Natou844
  Notified participants of WikiProject France. Nomen ad hoc (talk) 21:27, 4 June 2019 (UTC).

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 meSimon Cobb Alessandro Marchetti sky Juliansteinb Maria zaos Josephguillaume Cavernia


  Notified participants of WikiProject Wikidata for research. Nomen ad hoc (talk) 06:58, 15 June 2019 (UTC).

lithography (P2157)Edit

lithography (P2157): (delete | history | links | entity usage | logs | discussion)

This property seems over-specialized. I had been using statements like Exynos 9820 (Q28859206) fabrication method (P2079) 8nm (Q25991737) and they seem adequate. The statements would be easy to convert. @MisterSanderson, Ruud Koot, Tobias1984: Ghouston (talk) 10:05, 26 June 2019 (UTC) —Ghouston (talk) 10:05, 26 June 2019 (UTC)

Aside from the point that there are numerous manufacturing techniques that apply to more things than semiconductors, and we don't really want properties for them all, it seems that these semiconductor techniques can be described more accurately. E.g., according to [8] there are processes like "8nm FinFET LPP (Low Power Plus)" and "7nm EUV (Extreme Ultra Violet)". The source for the Exynos 9820 says it uses 8nm FinFET LPP. If it was desired to group the semiconductor lithography processes together, that can be done by creating a subclass of manufacturing process (Q1408288). (that would probably be photolithography (Q622938), judging by its enwiki article). Ghouston (talk) 00:26, 27 June 2019 (UTC)

Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Ilya
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Pintoch
Daniel Mietchen
Jsamwrites
Tinker Bell
FabC
Jasc PL
putnik
Dhx1
Tris T7
Peb Aryan
lore.mazza004
Rc1959
Premeditated
  Notified participants of WikiProject Informatics

  • I would vote   Delete, but not without discussing its usage in templates. Over-simplifying Wikidata by removing properties in favour of qualifiers is not the best solution for those uses. Let discuss at the Spanish Wikipedia, and depending the consensus, this property should be deleted or kept. --Amitie 10g (talk) 23:32, 7 July 2019 (UTC)
  • Template use is a good question, I can see a link to ca:Plantilla:Infotaula equipament informàtic on the talk page, and it's visible on ca:Intel 8085, for example. My suggested alternative would be using a different property, not a qualifier, but it would have a wider range of possible values: any manufacturing process. Ghouston (talk) 07:56, 8 July 2019 (UTC)

Property:P4828Edit

JORFSearch person ID (P4828): (delete | history | links | entity usage | logs | discussion)

Per Topic:V2ux3hpbf5ofitqw: isn't a real ID. No further need of a such property. Nomen ad hoc (talk) 14:44, 5 July 2019 (UTC). —Nomen ad hoc (talk) 14:44, 5 July 2019 (UTC)

VIGNERON
Mathieudu68
Ayack
Aga
Ash Crow
Tubezlob
PAC2
Thierry Caro
Pymouss
Pintoch
Alphos
Nomen ad hoc
GAllegre
Jean-Frédéric
Manu1400
Thibdx
Marianne Casamance
Le Passant
Natou844
  Notified participants of WikiProject France. Nomen ad hoc (talk) 14:44, 5 July 2019 (UTC).

  Delete per request. Nomen ad hoc (talk) 21:46, 5 July 2019 (UTC).
  DeletePintoch (talk) 08:33, 6 July 2019 (UTC)
  Delete --Deansfa (talk) 15:15, 6 July 2019 (UTC)
  Delete Jean-Fred (talk) 16:50, 6 July 2019 (UTC)
  Delete --DannyS712 (talk) 14:56, 9 July 2019 (UTC)

Property:P6978Edit

middle family name (P6978): (delete | history | links | entity usage | logs | discussion)

Premature creation as even the property creator can't explain how it's meant to be used. Besides, I get the impression they didn't bother reading the discussion, but merely run some script. --- Jura 08:58, 6 July 2019 (UTC)

  •   Keep We do not require property creators to resolve all points of discussion before creating a property - I'm grateful the creator finally got around to assessing this one and taking care of it. There's clearly a need for this property, and plenty of examples of how it would be used. ArthurPSmith (talk) 14:25, 6 July 2019 (UTC)
  •   Comment Unfortunately, ArthurPSmith changed the proposal after everybody else commented on it and we have no way to sort things out as we do usual. Let's recall the process: someone proposed a property, people support or oppose it, maybe comment to help improve it, then a property creator assesses the consensus and creates it. Nothing of that has been followed here. The property creator didn't even bother reading it. Let's start this correctly from zero and then decide it. --- Jura 14:34, 6 July 2019 (UTC)
    • @Jura1: first your description of the situation is really incorrect. It does not seems premature (a lot of property are created more quickly, with less people participating and/or less favourable balance of pro vs. cons), please assume good faith of Pintoch, ArthurPSmith didn't change the proposal, he just changed the label and description in English from "Second family name in Scandinavian names" to "middle family name", this doesn't seem a very big change and we can still put back the previous label, no need to delete the property. Then, this is the pot calling the kettle black: you did the same thing (and even worse as datatype can't be change unlike the label, and more people disagreed with your creation) with precedes word-initial (P6712). Cheers, VIGNERON (talk) 21:26, 6 July 2019 (UTC)
      • This is to discuss the deletion request. Don't sidetrack the discussion about the nominator: not good VIGNERON. Don't lend people assumptions: not good VIGNERON. --- Jura 22:29, 6 July 2019 (UTC)
  • Template:Weak keep. Whoa this one is complicated. @1Veertje: Can you explain whether these middle family names are, in legal documents, given names or family names? And is the difference between middle family name (P6978) and second family name in Spanish name (P1950) that middle family name (P6978) is used before the main family name, while second family name in Spanish name (P1950) is used after the main family name? Deryck Chan (talk) 17:38, 16 July 2019 (UTC)
they're a given name. It's not automatically the mother's maiden name: sometimes it's the family name of the godparent or a (local) notable person. Like middle names they are often abbreviated to just the letter. When the full name is written out they are before the family name. 1Veertje (talk) 17:50, 16 July 2019 (UTC)

Property:P5482Edit


Property:P185Edit

doctoral student (P185): (delete | history | links | entity usage | logs | discussion)

Generally too many. Inverse should be sufficient --- Jura 17:59, 12 July 2019 (UTC)


Ping Danrok, Zolo. Nomen ad hoc (talk) 07:26, 14 July 2019 (UTC).

Also @Dim Grits, Hannolans, İncelemeelemani, Emptyfear, AttoRenato:@Lupin~frwiki, Mormegil, Rooiratel, Dumbassman: Those who recently edited this property. --Liuxinyu970226 (talk) 11:47, 15 July 2019 (UTC)
Also @Cgolds: who opened a related discussion on French Bistro, and who just suggested only keeping student (P802). Nomen ad hoc (talk) 06:46, 17 July 2019 (UTC).
  •   Keep. Infoboxes about professors often include a short list of prominent doctoral students. The inverse may be sufficient to generate a list of all students who have their own Wikidata items, but this property allows further curation of who are the most important students using ranks. @Lupin~frwiki: "PhD candidate" and "doctoral student" have different boundaries (other kinds of doctorate are not included) and different universities use different names, so I wouldn't advise rescoping the property.
Ok, I understand. So you would use this property for medicine doctorate for instance, I understand. Then "doctoral candidate" could then be much more convenient than "doctoral student". Do you agree? --Lupin~frwiki (talk) 14:22, 17 July 2019 (UTC)
Probably not physician (Q39631), but likely to include other kinds of doctorates conferred after academic study: Doctor of Education (Q837184), Doctor of Engineering (Q17119067), Doctor of Laws (Q959320) and the University of Oxford which call their doctors of philosophy "DPhil" rather than "PhD". Deryck Chan (talk) 15:32, 19 July 2019 (UTC)

@Dim Grits: I think doctoral student (P185), doctoral advisor (P184) serve a different purpose from student (P802), student of (P1066). These two SPARQL queries [9][10] show editors have found uses in over 1000 biographical items where distinguishing between doctoral student-teacher relationships and other student-teacher relationships has been helpful. Deryck Chan (talk) 17:33, 16 July 2019 (UTC)

  •   Comment A big problem imho that also concerns student (P802) has been to establish an inverse property constraint. The property would be totally valid as a way to store the main students or Phd candidates of a teacher. Currently most of the student of (P1066)/doctoral advisor (P184) relationships that I have filled during the past years have been also reversed (either by bot or by well-meaning users attempting to "correct" an apparent error) making the student (P802)/doctoral student (P185) information meaningless. I would agree to keep this property along with student (P802) if the constraint is entirely lifted. Alexander Doria (talk) 18:40, 16 July 2019 (UTC)
    @Alexander Doria: I tend to agree that student of (P1066) and student (P802) should be inverse properties. Importance can be marked using rank, rather than removing unimportant (but truthful) entries. Deryck Chan (talk) 15:32, 19 July 2019 (UTC)
    Agree too. Only mentioning "notable" students is IMHO too arbitrary... especially if "notability" isn't properly defined. Nomen ad hoc (talk) 15:38, 19 July 2019 (UTC).
Consistency can be assured but some work is needed. We can get the same information without this property. Use this kind of property to distinguish some items of the set does not seem a good idea since the choice of each item can be discussed and different in every country, field, etc. This selection should be let to each wikipedia page imho. --Lupin~frwiki (talk) 14:22, 17 July 2019 (UTC)

Property:P6886Edit

writing language (P6886): (delete | history | links | entity usage | logs | discussion)

This property duplicates languages spoken, written or signed (P1412). —EncycloPetey (talk) 14:19, 21 July 2019 (UTC)

  •   Keep The property is well-delimited (only the language used in written work) and there's a clear rational for its inception (languages spoken, written or signed (P1412) is not appropriate for Wikisource). Alexander Doria (talk) 18:09, 21 July 2019 (UTC)
    It is not well-delimited. What limits it? If an author publishes an edition of a work by another author, with added commentary in a different language, then is the language of the original work considered or just the language of the commentary? This is a very real situation, as editors of Classical works often publish edited editions of Classical works in the original language, along with a translation and notes. So, if an author publishes an Ancient Greek edition of Menander, with an English translation, and footnotes in French, German, Greek, and English, then which language(s) has the author written in?
    Why is "languages spoken, written, or signed" not appropriate for Wikisource? Don't speeches and orations count towards "language written"? Wikisource hosts many transcribed speeches and lectures. Wikisource also hosts audio recordings of works, which are not written. And do works recorded secondhand by another individual count as written by the original author or speaker, or is this a language written by the secondhand writer only? This matters for authors like Jesus and Socrates, who have no known works written by the authors themselves. Do we count personal correspondence to family and colleagues (which can be hosted on Wikisource), or only published works, and what if the correspondence is later published? And once we see how broad "writing language" is in this light, then how is it any different from "languages spoken, written, or signed"?
    Clearly this is a property of individual works written by the author. Each work has a language (or languages) it which it was written, and some works (such as musical works) are written in no language at all. If we are to use this property, it should be justified by a work written in that language, which shows that it is a property of the work written, and not the author who wrote it. --EncycloPetey (talk) 20:28, 21 July 2019 (UTC)