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)

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)

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

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)

e-mail address (P968)Edit

e-mail address (P968): (delete | history | links | entity usage | logs | discussion)

Change data type to string. According to this RFC, this property can't be used correctly in it.voy as they want to show the email with a link to mailto: URI and you can't do [mailto:EMAILADDRESS EMAILADDRESS] right now. —Micru (talk) 18:37, 26 December 2018 (UTC)

  Oppose - We shouldn't change the datatype here because 1 re-user (it.voy) can't handle the default output. In this case it.voy should adapt their module:wikidata so it does render the output they want. For some projects other properties may be hard to handle because of their current datatype if they use the data as outputted by default. If the data output doesn't suit you, you need to make a script/module (or ask for help with a script/module) so it renders the way you want. Mbch331 (talk) 14:39, 27 December 2018 (UTC)
  •   Comment the it.voy usage aside, I think it's just plainly redundant. Using a string with the formatter URL mailto:$1 seems a much more logical choice. phone number (P1329) does it that way already. Lewis Hulbert (talk) 19:30, 4 January 2019 (UTC)
    • Fully agreed. NMaia (talk) 01:43, 17 March 2019 (UTC)
  •   Oppose - The property is used in many wikis. To change this means a comparatively high effort. It is very simple to remove mailto: from the string. --RolandUnger (talk) 08:54, 6 January 2019 (UTC)
  •   Support I support changing the datatype, but we should likely first create a new one, copy over the values and then slowly deprecate the old one.
It will be easier to enter data when the user doesn't have to write mailto: in front of every email address and making it easier to enter data is valuable. ChristianKl❫ 10:11, 6 January 2019 (UTC)
  •   Oppose - It is not a big deal to make [mailto:email email]. I don't know which tool are you retrieving the email from Wikidata, in my following example, I use Módule:WikidataIB:
{{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}}mailto:mam@mam.org.br
{{#invoke:String|replace|source={{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}}|pattern=mailto:|replace=}} → mam@mam.org.br
So,
[{{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}} {{#invoke:String|replace|source={{#invoke:WikidataIB|getValue|fetchwikidata=ALL|noicon=yes|onlysourced=yes|P968|qid=Q1581634}}|pattern=mailto:|replace=}}]mam@mam.org.br
And you can use some subst's as well. Sorry for the long coding. Ederporto (talk) 16:12, 6 January 2019 (UTC)
@Ederporto: I'm so sorry, but this format can't work if a wiki has wiki with script conversion (Q36509592) support, in that case, your example will wrongly shown as "man-{@}-man.org.br", where @ is enclosed by "-{}-". --Liuxinyu970226 (talk) 01:38, 12 January 2019 (UTC)
@Liuxinyu970226: Wouldn't {{#invoke:String|replace|source=man-{@}-man.org.br|pattern=-{@}-|replace=@}} solve it? Ederporto (talk) 14:52, 12 January 2019 (UTC)
  •   Weak oppose. If it's not broken, don't fix it. Deal with complications downstream. Deryck Chan (talk) 14:03, 1 February 2019 (UTC)
  •   Keep Rationale is flawed, as explained above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:09, 4 March 2019 (UTC)
  •   Keep The reason seems typed too simply, and haven't considered all other cases well. --Liuxinyu970226 (talk) 12:47, 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)
  •   Oppose for now per Andreasmperu and Matěj Suchánek. --Marsupium (talk) 01:58, 22 January 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. --218.68.229.42 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)
  •   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)

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

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)

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, –84.46.53.3 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)

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)

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)

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 Șoboski (Q53454) has Image Archive, Herder Institute (P6482) with contents "Q53454" on it. This links to https://www.herder-institut.de/bildkatalog/wikidata/Q53454 which resolves to https://www.herder-institut.de/bildkatalog/index/index?tree%5BPersonen%5D=5196 . 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 https://www.herder-institut.de/bildkatalog/wikidata/Q53454 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)

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

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)

Twitter username (P2002)Edit

Twitter username (P2002): (delete | history | links | entity usage | logs | discussion)

Superseded by the Twitter user ID number (P6552), which is more stable. NMaia (talk) 03:18, 2 March 2019 (UTC)

  • Is there a way to link full Twitter profiles from this new property, rather than such short profiles? —MisterSynergy (talk) 07:22, 2 March 2019 (UTC)
  •   Keep even where the underlying ID remains consistent it can be very useful to know what different usernames people have actively used (e.g. in the UK, many politicians change their twitter name during election campaigns).
  •   Keep This is independent and useful information, though it may not strictly qualify as an external id any more (user names can be reused right?). On linking via wikidata-externalid-url - that's not really within the scope of the app which was designed for just simple string re-writing; however I could look into it if this property is deleted and there's a strong demand for this. ArthurPSmith (talk) 14:48, 4 March 2019 (UTC)
    • That would be really useful, I think. There's a ticket for it here. NMaia (talk) 22:28, 4 March 2019 (UTC)
  •   Keep There nothing to be gained from deletion of this property, which is widely used both on and outside Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:49, 4 March 2019 (UTC)
  •   Keep Why not re-purpose it to function as a qualifier to Twitter user ID number (P6552), when that is more widely adopted? There is some value (at least in theory) in keeping historical usernames i would imagine. Moebeus (talk) 15:02, 5 March 2019 (UTC)
A qualifier property already exists for that, website username (P554). Ghouston (talk) 22:31, 13 March 2019 (UTC)

Property:P6552Edit

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)

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)

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


  Notified participants of WikiProject Companies

Property:P5482Edit

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: <http://www.wikidata.org/entity/>
SELECT ?item ?itemLabel ?valueLabel (strlen(?valueLabel) as ?nbChar)
WHERE
{
	?item wdt:P2559 ?value .
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en,en"  }    
}
order by desc (?nbChar)
LIMIT 3
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)