Page semi-protected from being moved
Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
(Redirected from Wikidata:PFD)
Jump to: navigation, search

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 the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Add a new request


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

Edit


Project
chat

Administrators'
noticeboard

Development
team

Translators'
noticeboard

Requests
for permissions

Interwiki
conflicts

Requests
for deletions

Property
proposal

Properties
for deletion

Requests
for comment

Partnerships
and imports

Request
a query

Bot
requests


Requests[edit]

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


doubles record (P555) and singles record (P564)[edit]

doubles record (P555): (delete | history | links | entity usage | logs | discussion) singles record (P564): (delete | history | links | entity usage | logs | discussion)

Can be replaced by number of wins (P1355) and losses (P1356) with qualifiers. Even if it is not replaced, it should replaced by four properties with number datatype.--GZWDer (talk) 16:28, 2 February 2016 (UTC)

  • Delete per the nominator--these should be replaced since a wins/losses combined property is non-granular semantic information (indicated by the expected dash). --Izno (talk) 13:59, 8 March 2016 (UTC)
  • Delete. Thierry Caro (talk) 08:56, 12 March 2016 (UTC)
  • Symbol keep vote.svg Keep for now. Four properties make more sense, but this property should be kept until then. Qualifiers are not an appropriate substitute for sub-properties, though. --Srittau (talk) 02:45, 25 March 2016 (UTC)
    "but this property should be kept until then" - We have the replacement properties and just need to do the replacement. Voting keep based on the fact it's being used is not a valid reason for keeping. Lastly, sub-properties are a bad thing. --Izno (talk) 12:14, 28 March 2016 (UTC)
    What are those properties? I only see number of wins (P1355) and losses (P1356), we are still lacking "games won in singles/doubles", "games lost in singles/doubles". --Srittau (talk) 19:12, 28 March 2016 (UTC)
    @Srittau: something generic like wins of (P642) "singles tennis match" (which would be P31 type of tennis match (Q1967745) and P279 tennis match P279 competition or similar). --Izno (talk) 16:20, 26 April 2016 (UTC)
    @Izno: In your proposal, how should we then call-up the replacer for "win-loss balance in singles" in infoboxes (currently called-up as {{#property:P564}})? I have no clue as to how the code would look like that I would have to write in a tennis player's infobox. Vinkje83 (talk) 10:37, 5 July 2016 (UTC)
  • Symbol delete vote.svg Delete number of wins (P1355) and losses (P1356) can be used but we need a good qualifier to make the distinction between single/double/mixed matches. --Pasleim (talk) 10:05, 6 April 2016 (UTC)
    of (P642)? --Edgars2007 (talk) 10:31, 6 April 2016 (UTC)
  • Symbol keep vote.svg Keep These two properties are actively used on quite some languages, in tennis-infoboxes. Deletion will make it a lot more difficult to maintain the value of these items (that is changing basically every week for active players), as well as replacing those properties in the infoboxes. For tennis, this is just the way statistics are registered, and this is the only way this makes sense for tennis. For other sports, these properties should not be used. Maybe the name of the properties (or their explanation) should be changed to clarify that they are tennis only? Edoderoo (talk) 21:37, 2 July 2016 (UTC)
  • Symbol keep vote.svg Keep The concept of 'win/loss balance' is a natural phenomenon in tennis. A concept like 'number of matches won' in itself has no meaning there (neither has 'number of matches lost'). It's only the two numbers together that make sense. The inclusion of singles record (P564) and doubles record (P555) in tennis players' infoboxes is finally coming into use (more than just occasionally), and their wikidata values are actually getting updated by the international community. Replacing them by four new properties (two would not work, obviously) would cause more complicated code to include them in the infoboxes, and that will most probably arouse new objections against wikidata. Vinkje83 (talk) 23:31, 2 July 2016 (UTC)
  • Symbol delete vote.svg Delete. Also, with number of wins (P1355) and losses (P1356) with qualifiers we can make some interesting queries. I can do the data conversion task here (I was anyway planning to update data from websites) and notify Wikipedias etc. @Edoderoo, Vinkje83: fyi, I created a simple Lua module to be used in tennis infoboxes. It maywill require some clean-up, but that is a different story. --Edgars2007 (talk) 19:37, 27 August 2016 (UTC)
    • @Edoderoo, Vinkje83: extra-ping, as I forgot to sign. --Edgars2007 (talk) 19:37, 27 August 2016 (UTC)
      • Unfortunately LUA is not (yet) accepted on some wiki's, like nl-wiki. Use of WikiData-data is actually not fully accepted yet, though "we" try to push it through in some areas where it makes most sense, like these two highly changing properties (updated weekly, in theory). But in theory LUA would indeed take away some of the issues, but for the moment I would prefer to keep these two properties, as without them some wiki's will simply loose the data completely right now. Edoderoo (talk) 19:43, 27 August 2016 (UTC)
        • Client decisions not to use Lua (really??) shouldn't affect our decisions. That's just, frankly, dumb. While they're welcome to their opinion, they're also welcome to the consequences of that opinion, and one of them is that they may not have access to the same power as other wikis do. --Izno (talk) 19:49, 27 August 2016 (UTC)
          • And we wouldn't delete number of wins (P1355) and losses (P1356), when converting data. At least, I was planning to do that. Once I would convert everything (keeping also old props), then is the work with Wikipedias. We can also have some logic in module - if there isn't the "new" properties, load the "old" ones. Yes, we would have extra work in maintaining data for some while, but with help of SPARQL queries that is pretty easily doable with python. --Edgars2007 (talk) 20:31, 27 August 2016 (UTC)
            • There is no official vote or something that lua shouldn't be used on nlwiki. Edoderoo is probably talking about nl:Module:Cycling race and the relevant discussion. It's not weird that a part of the community doesn't like pushing of "outsiders". Sjoerd de Bruin (talk) 12:10, 6 September 2016 (UTC)
  • Symbol keep vote.svg Keep Both properties are used in 40+ projects.--Jklamo (talk) 00:43, 23 January 2017 (UTC)

Skull and crossbones.svg Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is leave a message in Village pump of those projects! Please link to annoncment in ruwiki, lvwiki, itwiki, arwiki. Eran (talk) 12:23, 9 September 2016 (UTC)

  • Symbol delete vote.svg Delete per above as splittable into two propereties. Pppery (talk) 02:50, 3 February 2017 (UTC)
  • Why has this discussion stayed open for over a year? Pppery (talk) 02:49, 3 February 2017 (UTC)
  • Symbol keep vote.svg Keep Per Vinkje83 and Edoderoo, these properties are widely used in tennis infoboxes in this combination (win/loss).--Wolbo (talk) 01:31, 22 February 2017 (UTC)
  • Symbol keep vote.svg Keep used in many Wikipedia templates, can't be removed. Stryn (talk) 11:59, 19 March 2017 (UTC)
  • Symbol delete vote.svg Delete--Chris XC3000 (talk) 11:43, 27 March 2017 (UTC)
  • Symbol keep vote.svg Keep (for now) because I can't see (nobody's demonstrated it here) how the properties would be replaced. Matěj Suchánek (talk) 14:34, 20 May 2017 (UTC)

comment (DEPRECATED) (P2315)[edit]


Property:P546[edit]

docking port (P546): (delete | history | links | entity usage | logs | discussion)

Use via (P2825). GZWDer (talk) 17:13, 3 August 2016 (UTC)

Symbol keep vote.svg Keep "docking port" is more equivalent to the particular gate at a terminal that an aircraft uses, and I don't think you would ever assign that using 'via'. If there's another analogous property then I wouldn't object to merging, but I don't see these two as being anywhere close to equivalent. ArthurPSmith (talk) 14:39, 4 August 2016 (UTC)
Ok, I agree significant event (P793) is a good choice here. Fine with deleting P546 in that case. ArthurPSmith (talk) 18:41, 4 August 2016 (UTC)
Symbol delete vote.svg Delete but I prefer not to use via (P2825) but instead significant event (P793). A spaceflight has many key events, and it's excessive to create for each possible event a new property. On Q591584#P793 I demonstrated a while ago how this could work. Soyuz TMA-9 (Q591584) had two docking ports. With the current approach you don't know which port was served first and during which time they were served. Because there are a handful more properties describing key events of the spaceflight, it's in addition hard to extract a timeline of the flight. With significant event (P793) we gain a better overview and can model the whole journey. --Pasleim (talk) 15:58, 4 August 2016 (UTC)
Symbol delete vote.svg Delete per Pasleim for the use of significant event (P793). Snipre (talk) 16:21, 4 August 2016 (UTC)
Symbol keep vote.svg Keep per my comment on #Property:P446surueña 11:11, 17 August 2016 (UTC)
Symbol delete vote.svg Delete per Pasleim. --Jklamo (talk) 23:39, 8 September 2016 (UTC)
Symbol keep vote.svg Keep, via (P2825) and significant event (P793) are too generic for effective usage. — Ivan A. Krestinin (talk) 20:31, 24 October 2016 (UTC)
Symbol keep vote.svg Keep seems to be in use.
--- Jura 19:11, 15 January 2017 (UTC)

Property:P2837[edit]

Wikidata month number (P2837): (delete | history | links | entity usage | logs | discussion)

No clear usage; can be replaced with series ordinal (P1545) GZWDer (talk) 17:47, 3 August 2016 (UTC)

Wrong datatype, should be integer, not quantity.
--- Jura 20:01, 3 August 2016 (UTC)
Symbol delete vote.svg Delete - no idea what Jura's referring to; it looks like series ordinal (P1545) is already being used on the months where they are described as subclasses so the data is there. I really don't think it is helpful to have a property like this that is entirely wikidata-internal and applies to only 12 items, there have to be other ways to do it. I would question the creation process on this one. ArthurPSmith (talk) 14:45, 4 August 2016 (UTC)
RE: "applies to only 12 items". You are aware such properties as Swedish county code (P507) never can have very widespread usage! -- Innocent bystander (talk) 15:24, 4 August 2016 (UTC)
@Jura1: during the property proposal, you mentioned that this property could be used by a (non-existent) script by me. As I don't plan to use this property, are there any other application where it is needed? --Pasleim (talk) 16:06, 4 August 2016 (UTC)
The property talk page links to a series of queries .. it works, but it would work better once integer datatype is available. Once it's available, I think we should convert it.
--- Jura 16:14, 4 August 2016 (UTC)
Why can't you use the series ordinal (P1545) qualifier on subclass of (P279) for the month instead of having a separate property? ArthurPSmith (talk) 18:44, 4 August 2016 (UTC)
Probably I'm just too weak with SPARQL or too slow to get it done in 30". Maybe you manage to re-write the query on Wikidata:WikiProject Q5/lists/people who died on their birthday.
--- Jura 11:54, 17 August 2016 (UTC)
@jura1: I rewrote that query such that it doesn't need P:P2837 --Pasleim (talk) 16:30, 12 September 2016 (UTC)
Thanks. I like the way you did the sections. BTW, it times out for me. Will we get integer-datatype anytime soon?
--- Jura 17:32, 12 September 2016 (UTC)
The ticket for the integer datatype is phab:T112247. It doesn't seem we will get it soon. --Pasleim (talk) 18:27, 12 September 2016 (UTC)
Symbol delete vote.svg Delete I don't see any further use cases of this property which couldn't be solved with series ordinal (P1545). --Pasleim (talk) 11:52, 12 October 2016 (UTC)
The change brought the query closer to time-out limit. I restored the use of this property. This should be converted to integer datatype once available.
--- Jura 19:11, 15 January 2017 (UTC)

number of awards (P2422)[edit]

number of awards (P2422): (delete | history | links | entity usage | logs | discussion)

Seems to be wholly redundant to quantity (P1114). Currently has no more than seven (7) uses. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:42, 13 September 2016 (UTC)

Symbol oppose vote.svg Oppose It is different from quantity (P1114). There could be a quantity X of a particular medal that have been produced which corresponds to quantity (P1114), while only a quantity Y has been awarded, which corresponds to number of awards (P2422). Also, number of awards (P2422) is also used for "number of inductees", so if there is a deletion, some would need to be merged to "quantity" as stated above by Pigsonthewing (talkcontribslogs), but the inductees numbers would need to be merged to "membership" property, although it's not as a good as keeping number of awards (P2422). Thanks, Amqui (talk) 16:42, 19 September 2016 (UTC)
In the unlikely event that we know that a specified number of medals have been made but only some have been awarded, use, say, quantity (P1114) with an "applies to part" = "unissued award" qualifier. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:36, 26 September 2016 (UTC)
  • Pictogram voting comment.svg Comment the current English label is ambiguous in the first place, and more akin to "quantity awarded", as by its current label it could be interpreted to the number of awards a person has, eg. number of Grammies won. I tend to favour deletion and stop the propagation of "specialist" labels that can suitably covered by something like "quantity". The more specialist labels makes things more difficult for contributors to have to know or guess, and means that when we come to infoboxes people just get it wrong. Our purpose is to help get it right and easier for infoboxes!  — billinghurst sDrewth 06:53, 5 November 2016 (UTC)

NSW Flora ID (P3130)[edit]

Pictogram voting info.svg Info The initial discussion started at Wikidata:Bot_requests#NSW Flora IDs.

@Pigsonthewing, YULdigitalpreservation, ChristianKl: At the moment this property works only for species (formatter: href=/cgi-bin/NSWfl.pl?page=nswfl&lvl=sp&name=), but the website has

too. This is simmilar to GRIN URL (P1421) or AlgaeBase URL (P1348). So the datatype of this property should be changed to URL. --Succu (talk) 08:13, 2 September 2016 (UTC)

The problem with Url's is that it makes the data easy to break if they switch away from the php formatted links. ChristianKl (talk) 18:26, 26 September 2016 (UTC)
Not really. See GRIN urls changed. It's also easy to apply URL constraints. --Succu (talk) 18:38, 26 September 2016 (UTC)
  • Oppose deletion until the alternative solutions (plural) I put to Succu on the bot requests page have been properly discussed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:31, 26 September 2016 (UTC)
    Mind to repeat them? --Succu (talk) 18:38, 26 September 2016 (UTC)
    There's a link to the discussion in the first line of this section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:42, 26 September 2016 (UTC)
    Obviously it matters to you... (colons too) --Succu (talk) 18:49, 26 September 2016 (UTC)

Abbe98
Achim Raschka (talk)
Brya (talk)
Dan Koehl (talk)
Daniel Mietchen (talk)
Delusion23 (talk)
Faendalimas
FelixReimann (talk)
Infovarius (talk)
Joel Sachs
Josve05a (talk)
Klortho (talk)
Lymantria (talk)
Michael Goodyear
MPF
PhiLiP
Andy Mabbett (talk)
Prot D
pvmoutside
Rod Page
Soulkeeper (talk)
Tinm
Tommy Kronkvist (talk)
TomT0m
Pictogram voting comment.svg Notified participants of WikiProject Taxonomy --Succu (talk) 21:52, 29 September 2016 (UTC)

I am not a big fan of URL's in Wikidata (unwieldy), and actually I would be in favour of switching GRIN from URL to external identifier (should be quite doable). Having said that, this particular case is a very poor candidate for an external identifier, as it apparently would lead to "in&name=Avicennia~marina+subsp.~australasica" as a external identifier, which is just as unwieldy as a full URL. - Brya (talk) 10:49, 30 September 2016 (UTC)
Brya: Could you express your concerns about datatype URL a little bit more please? --Succu (talk) 19:19, 30 September 2016 (UTC)
My unease consists of two points: 1) if one checks an item the URL's are in a place where one does not expect them (GRIN is in a different block from GBIF, ITIS and other such databases). 2) readability of a URL is very poor (too long). - Brya (talk) 19:28, 30 September 2016 (UTC)
Thanks. So both of your concerns are about the handling by the Wikidata UI I think. The migration to external ID resulting into the rendering it in a separated section has a lot of pro and cons but was leaving the datatype URL behind. I'd like to see them united. I'm not sure how this could be done, but I'am sure that declaring fragments of an URL as an external ID is the wrong way. --Succu (talk) 20:19, 30 September 2016 (UTC)
There are adjacent solutions:
  • P:P2772, P:P2773, P:P2774, P:P2775, P:P2776, P:P2777, but I would not propagate that for taxon items like this one.
  • P:P2549 having indeed a combination of two parts in the ID. I don't see much objection in using something similar here for the identifier, hence having "lvl=fm&name=Acanthaceae" as the identifier, which indeed is the identifying part.
Therefore Symbol oppose vote.svg Oppose to deletion and change into URL-datatype. Lymantria (talk) 07:22, 3 October 2016 (UTC)
A part of an Uniform Resource Locator (Q42253) like lvl=in&name=Avicennia~marina+subsp.~australasica is not an identifier (Q853614). An Uniform Resource Identifier (Q61694) like URL is. --Succu (talk) 18:39, 3 October 2016 (UTC)
A part of a Uniform Resource Locator (Q42253) may not be an identifier (Q853614), an identifier (Q853614) may become part of a Uniform Resource Locator (Q42253). Lymantria (talk) 19:40, 4 October 2016 (UTC)
Lymantria: Please, could you provide more details? I do not understand what your point is. --Succu (talk) 19:45, 4 October 2016 (UTC)
My point is that I disagree with you that lvl=in&name=Avicennia~marina+subsp.~australasica cannot be considered an identifier. The actual fact that the identifier is made part of a URL is hardly an argument. Lymantria (talk) 19:49, 4 October 2016 (UTC)
So a part of an ID makes it an ID of its own? --Succu (talk) 20:02, 4 October 2016 (UTC)
Nope. And that is neither what I said, nor what I meant. But the ID has become part of the URL. Do you suggest that the part does not identify the database entry uniquely? Lymantria (talk) 20:14, 4 October 2016 (UTC)
Yes: A part of an Uniform Resource Identifier (Q61694) is not an ID. A part of International Standard Book Number (Q33057) like 0 is not an ID. --Succu (talk) 20:47, 4 October 2016 (UTC)
You seem to state that you want to delete Property:P3035 and Property:P3097? That would take a new deletion request. But what you say about the general case, would mean that ID's with a formatter URL cannot be ID's, because the URL is already an ID. I fail to understand that. Lymantria (talk) 05:33, 5 October 2016 (UTC)
Of course not. formatter URL (P1630) is a shortcut for an external id e.g. for an internal database table id (unique key (Q934729)). Saying 0-9538134-4-5 could be identified by International Standard Book Number (Q33057)=0 alone makes no sense to me. A Compound key (Q5156838) should not treated this way. --Succu (talk) 22:29, 5 October 2016 (UTC)
But then, the actual problem is that - just like International Standard Book Number (Q33057) - its identifier consists of two parts, one describing "lvl" (somewhat similar to "level"), and one pointing to the actual taxon. There is even a third, "page=nswfl" pointing to the database. The mere fact that the UI does not allow multiple part entries for ID's does IMHO not disqualify these to be identifiers, combined into a single identifier.
Would we switch to URL, then there is the interesting fact that there is no reason to not insert a shortcut like lvl=in&name=Avicennia, which interestingly is functioning, but in fact gets close to your mentioning about 0-9538134-4-5 identified by International Standard Book Number (Q33057)=0. I would not be in favour of that kind of use. Lymantria (talk) 14:12, 6 October 2016 (UTC)
Looks like that Italian Senate of the Republic ID (P2549) was later misused ([5]). --Succu (talk) 19:51, 4 October 2016 (UTC)

Yahoo! Japan Talent Database ID (P3284)[edit]

Yahoo! Japan Talent Database ID (P3284): (delete | history | links | entity usage | logs | discussion)

Service end dead link --Rain night (talk) 04:38, 13 December 2016 (UTC)

  • Pictogram voting comment.svg Comment if the links aren't working any more, you can set the formatter URL to "deprecated rank".
    --- Jura 14:14, 13 December 2016 (UTC)
  • Symbol delete vote.svg Delete as per nomination. Having an identifier that points into a database that is no longer available is of questionable value. 50.53.1.33 22:19, 9 February 2017 (UTC)
  • Symbol keep vote.svg Keep We don't need an external site for an identifier to be useful. We should not be discarding such data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:50, 26 February 2017 (UTC)
  • Symbol keep vote.svg Keep via Pigsonthewing. ChristianKl (talk) 17:52, 23 May 2017 (UTC)

ISO 639-6 code (P221)[edit]

ISO 639-6 code (P221): (delete | history | links | entity usage | logs | discussion)

The ISO 639-6:2009 standard was withdrawn in 2014, and it never caught up. Its use here in WD is testimonial with just a few entries. It is not available online, and it is unlikely that the codes are imported unless there is some special interest. Ping: @GerardM, Visite fortuitement prolongée, Infovarius, Pamputt, Kolja21:--Micru (talk) 13:49, 13 December 2016 (UTC)

  • Pictogram voting comment.svg Comment see w:ISO 639-6.
    --- Jura 14:19, 13 December 2016 (UTC)
  • Symbol delete vote.svg Delete Not used, deprecated, better avoid to import useless data. Snipre (talk) 17:13, 13 December 2016 (UTC)
  • Pictogram voting comment.svg Comment I do not object to deleting, or keeping. However, I would like to understand why the standard was withdrawn - the ISO language codes are certainly useful for a lot of what we do here, is there a plan to replace it with something else? ArthurPSmith (talk) 19:00, 13 December 2016 (UTC)
    • @ArthurPSmith: Its current status is "withdrawn, no replacement", but of course ISO 639-3 and others remain operational. I haven't found the official reasons behind the withdrawal, however on this paper they shed some light on the inconvenience of using language codes for language classification and the lack of consensus on the topic, as language are fuzzy living entities and it is quite hard to find boundaries, even more so for variants. On this email on the ietf-languages mailing list hint towards a lack of usefulness, plus that the agency that was designated as registration authority ceased its operation.--Micru (talk) 08:22, 14 December 2016 (UTC)
  • Symbol keep vote.svg Keep While I have doubts about how useful or verifiable the data is, several Wikipedias include this in their infoboxes and some are even using the data from this property. - Nikki (talk) 17:13, 27 December 2016 (UTC)
  • I'd rather Symbol keep vote.svg Keep: how to store the 639-6 code without this property? Cdlt, VIGNERON (talk) 11:20, 11 January 2017 (UTC)
  • Symbol delete vote.svg Delete The only non-WMF resource of ISO 639-6, GeoLang, is even no longer providing the list, and only says "No Results Found", for the existing usage of codes, we should announce all the local communities, to run a bot script to remove em from Template:Infobox language (Q7217946). --Liuxinyu970226 (talk) 04:16, 16 January 2017 (UTC)
  • Symbol delete vote.svg Delete as per nomination. With the specification withdrawn and the data no longer available this seems to be of little usefulness. There are several other ISO 639 identifiers that can be used in lieu of this one. 50.53.1.33 22:16, 9 February 2017 (UTC)
  • Symbol keep vote.svg Keep Given that Wikipedia import the data into their infoboxes. We should delete data that get's used in infoboxes without good reason. ChristianKl (talk) 11:18, 11 February 2017 (UTC)
    @ChristianKl: deletion of parameters from infoboxes can just be a bot work, iirc. --Liuxinyu970226 (talk) 11:10, 2 March 2017 (UTC)
  • @Liuxinyu970226: Whether the individual Wikipedias want to delete the paramater from their infobox is an editorial decision on their side and not something that a Wikidata approved bot can decide.
  • Symbol keep vote.svg Keep as in use. Yes a bot could delete the parameters from the infoboxes, but then that would result in the data currently present in the article disappearing - if we want Wikipedias to use Wikidata as a source for infobox information it is very important that we don't delete the information they are using without their consensus. Separately I don't see why Wikidata has to restrict itself to currently used identifiers, surely our mission includes representing the world as it was rather than just as it is (otherwise why have entries for entities like German Democratic Republic (Q16957) or properties like end time (P582) instead of deleting the no-longer valid data). Thryduulf (talk) 09:27, 12 April 2017 (UTC)
  • Pictogram voting question.svg Question according to Wikipedia this has been withdrawn, but was it replaced with anything? If a newer, better standard exists then we should replace this identifier with the newer version, and Wikipedia infoboxes should follow suit. Laurdecl talk 06:08, 15 May 2017 (UTC)

station code (P296)[edit]

station code (P296): (delete | history | links | entity usage | logs | discussion)

Zero instances. There are much more specified properties holding station codes.--Marfi (talk) 09:09, 20 December 2016 (UTC)

Symbol keep vote.svg Keep Are you looking at the same property? It's been used 4500+ times. It was proposed for deletion 3 years ago and decided not to - see discussion here. Yes there are more specific properties that should be used if they apply, but this one is suitable for generic use with a qualifier indicating what system the code is for, I seem no reason to delete. ArthurPSmith (talk) 13:32, 22 December 2016 (UTC)
Symbol keep vote.svg Keep It is good to keep a record of it. Plus usage is alot. MechQuester (talk) 03:59, 31 January 2017 (UTC)
Symbol delete vote.svg Delete 5536 missed qualifiers. So currently we have 5536 unknown codes. Separate properties will bring structure to this data hell. — Ivan A. Krestinin (talk) 19:05, 2 March 2017 (UTC)
I'm torn. The fact that MTR station code (P1377) and China railway TMIS station code (P1378) etc exist means that this is somewhat redundant if we insist on having the mandatory qualifier. On the other hand, if we remove the mandatory qualifier constraint, this property can be used more liberally with various transport systems. Other properties of the station item can be used to tell us which transport system it's in. On balance I vote deprecate and Symbol delete vote.svg Delete. Deryck Chan (talk) 18:10, 10 March 2017 (UTC)
I'll be willing to change to keep if we relax the \w+ format requirement so that the Japanese and Norwegian uses of this property - which are the vast majority of uses not already covered by more specific properties - cease to be constraint violations. Deryck Chan (talk) 15:24, 22 March 2017 (UTC)
Prefer Symbol keep vote.svg Keep, unless if someone can tell me which property should be used for Japanese no label (Q11660285). --Liuxinyu970226 (talk) 12:33, 11 March 2017 (UTC)
Symbol keep vote.svg Keep In most case, the code system can easily be guessed by using connecting line (P81) or operator (P137). Deleting this property at this time is inappropriate, I think. --Okkn (talk) 19:51, 13 March 2017 (UTC)
  • Symbol keep vote.svg Keep unless and until all uses are migrated to more specific properties. Thryduulf (talk) 09:28, 12 April 2017 (UTC)
    Same, but there should finally be some decision on whether this should be done, or the more specific properties migrated to this one. --Nenntmichruhigip (talk) 13:32, 18 April 2017 (UTC)

Property:P3417[edit]

Quora-United Nations Headquarters.png

Quora topic ID (P3417): (delete | history | links | entity usage | logs | discussion)

Is this datatype correct? Shouldn't it be string?
--- Jura 12:30, 24 December 2016 (UTC)

  • I don't understand what's the value of knowing what tag is used for a certain topic on a closed, private and proprietary website, especially one which works actively against public dissemination of knowledge and even archival: https://konklone.com/post/quora-keeps-the-worlds-knowledge-for-itself Nemo 13:03, 24 December 2016 (UTC)
  • A ridiculous nomination, and a very pointy one just after this. Speedy keep. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:21, 24 December 2016 (UTC)
  • The property uses IDs for an external source, so the data type is valid IMHO. Keep --Magnus Manske (talk) 13:25, 24 December 2016 (UTC)
  • When the external-id datatype was introduced, we had long discussions about which properties should have external-id datatype. Consensus was somehow that an external-id should uniquely identify a concept, that's why certain string-properties weren't converted to external-id, e.g. Twitter hashtag (P2572). For me Quora topic ID (P3417) is pretty similar to Twitter hashtag (P2572) as it was introduced to group together posts and ease searching. They don't identify concepts but group together ideas like Exams and Career Advice, Tips and Hacks, Concrete and Cement. Therefore I Symbol support vote.svg Support to move this property from external-id to string datatype. --Pasleim (talk) 10:59, 26 December 2016 (UTC)
  • The data type is according to my opinion correct. Keep. Wesalius (talk) 19:45, 26 December 2016 (UTC)
  • For me it isn't clear: this proposal is for delete the property, or for delete this property and recreate it with a different data type? --ValterVB (talk) 18:02, 27 December 2016 (UTC)
    • It's to delete it and recreate it with string datatype. We can only do the opposite change without deleting. For the full deletion of the property, a second section would need to be started.
      --- Jura 18:36, 27 December 2016 (UTC)
      • That is not correct. We can convert both ways, since the two datatypes use the same internal representation. Daniel Kinzler (WMDE) (talk) 20:05, 20 January 2017 (UTC)
  • Symbol support vote.svg Support conversion to string datatype. In addition the problem that came up on Project Chat which prompted me to start this thread, there seems to be also a stability issue with these strings. As the explanations we get to the contrary are comments like "ridicule" and acts conver up instead of explain possible issues that come up, these links seem highly problematic.
    --- Jura 15:01, 31 December 2016 (UTC)
    • Yet again, I need to remind you that adding "support" to your own proposal is double !voting. Your nomination was described as "ridiculous", which is not "ridicule". No evidence of a "cover up" has been shown. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:26, 31 December 2016 (UTC)
  • Symbol keep vote.svg Keep Since string and external-id have the same structure this should not be "delete"; so the real question is whether a conversion is merited. If I am understanding the original external-id conversion arguments, I believe this should be external-id over string. The differentiating factor seems to be whether the value has peer review (Q215028) as a unique controlled vocabulary (Q1469824). Virtually all identifiers are used for grouping (e.g., all of authority control (Q36524) and subject indexing (Q1167863)). Though Twitter hashtag (P2572) is certainly used for grouping it is not a peer reviewed controlled vocabulary (so it is very easy to come up with different hash tags that essentially cover the same concept). This is why I see it differently than this one. 50.53.1.33 22:07, 9 February 2017 (UTC)
  • I prefer it to be external id. ChristianKl (talk) 11:24, 11 February 2017 (UTC)
  • Symbol keep vote.svg Keep with external ID. If someone finds it useful, and it's not causing any direct harm to our project, then by all means let it be. Icebob99 (talk) 15:50, 5 March 2017 (UTC)
  • Symbol keep vote.svg Keep; no opinion about datatype or references. d1g (talk) 15:41, 30 April 2017 (UTC)
  • Symbol delete vote.svg Support migration, unfortunately keep such claims under external-id could sometimes make problems that may or not about "language variants"-related markers (e.g. -{}-), cf. mw:Parsoid/Language_conversion/Preprocessor_fixups/20170501/sister-other#wikidatawiki. --Liuxinyu970226 (talk) 15:28, 18 May 2017 (UTC)
  • It's time this benighted proposal was closed. We have 161K uses of the property, and growing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 23 May 2017 (UTC)

race time (P2781)[edit]

race time (P2781): (delete | history | links | entity usage | logs | discussion)


no label (P907)[edit]

no label (P907): (delete | history | links | entity usage | logs)


language of work or name (P407) and original language of work (P364)[edit]


Relation with language (P2439)[edit]

Meanwhile, we have got a new property language (P2439). Its usage is marginal compared to these two properties, that's why I haven't mentioned it in the conclusion. But I think we have a good opportunity to make another decision about this one. Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)

Recipient[edit]

Which property will stay? I'm leaning to keeping language of work or name (P407) since it's used more often and its labels make its scope wider. Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)

The labelling of the new property has to simplified: the current one is just creating confusion if the contributor want to specify the language of something which is not a work or a name, or something the contributor can't assimilate to a work or a name. Whats should he do ? Looking for another property ? Proposing the creation of a new property ? The best to simplify the future unique property with "language" only. The best is to delete original language, with the following rules
if in one item the property "original language" is used:
  • convert it into "language of work or name" if no existing statement using "language of work or name" is found
  • delete it otherwise
Snipre (talk) 20:04, 13 May 2017 (UTC)

Migration[edit]

Given that both properties have some external usage, how should the migration proceed? Should we create a timetable? (Announcing in WD:Status updates/Next is essential.) Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)

  1. announce the migration in WD:Status updates/Next
  2. copy over all values of "original language" to "language of work or name" but don't yet delete the "original language" statements
  3. fix all templates
  4. remove all "original language" statements and delete property
I can help with all steps including fixing the templates on other projects --Pasleim (talk) 20:44, 16 May 2017 (UTC)
Agree with this steps. Just to avoid error: we keep Property:P364 and delete Property:P407, correct? --ValterVB (talk) 16:50, 17 May 2017 (UTC)
@ValterVB: Nope, the opposite (discussed in the section above). Matěj Suchánek (talk) 14:40, 20 May 2017 (UTC)

Movies[edit]

Some users had questions about films and their dubbed versions. Will the FRBR system apply to them? Matěj Suchánek (talk) 14:48, 13 May 2017 (UTC)

This discussion is related to a more global concept than the FRBR system: data duplication have to be avoided and saved in the more related item. This principle is important for bots, queries and automatic data extraction like the one for infoboxes in order to have general rules allowing codes reusability. We shouldn't not have a special way to store data for book and another for movies. WD is one database and we have to have general rules independent of the topics. Snipre (talk) 19:53, 13 May 2017 (UTC)
  • I demonstrated the FRBR system for movies on Via col vento (Q29478369) and Via col vento (Q29478260). Till now, no member of the WikiProject Movie could show me how to express the data I added to this items without the FRBR system. I understand this as a silent agreement to the FRBR system. --Pasleim (talk) 20:44, 16 May 2017 (UTC)

as (P794)[edit]

as (P794): (delete | history | links | entity usage | logs | discussion)

Incredibly vague property described only as a "generic qualifier". Most instances should be replaced with the better-defined subject has role (P2868).--Swpb (talk) 18:23, 10 February 2017 (UTC)

  • Symbol delete vote.svg Delete and split to different properties.--GZWDer (talk) 07:06, 13 February 2017 (UTC)
  • For {{Statement|QXXX|PYYY|QZZZ}}:
  1. If we want to specify X, use subject has role (P2868).
  2. If we want to specify Y, use <new property "specifically">. (previously we use P31 but I think P31 is still vague)
  3. If we want to specify Z, use <new property>. (position held (P39) Governor of X as (P794) acting governor (Q4676866))
  4. If we want to qualify the whole statement (de facto (Q712144)), use <new property>.
  5. If we want to indicate that X, Y or Z is "being" W for some kind of purpose (as (P794) Chinese Taipei (Q216923), author pseudonyms), use <new property, item version of stated as (P1932)>. (Is one property enough? Or is it still vague so that we need three properties?)
Totally we need four (or six) new property to indicate this. --GZWDer (talk) 07:30, 13 February 2017 (UTC)
@Swpb: I'm collecting the current usage of the property. It is much more complex than I have thought. I will post it here once I have done the work.--GZWDer (talk) 18:27, 13 February 2017 (UTC)
For author pseudonyms, WikiProject Books is recommending using named as (P1810), which might work for other cases where the value in question is actually a name. On the P1810 talk page I have suggested using P1810 as a qualifier to show the preferred name for something in an external database that we have an ID for -- see for example Jan Vermeer van Haarlem the Elder (Q3159680) for how different databases prefer to name the same artist. Jheald (talk) 17:53, 13 February 2017 (UTC)
  • I am not sure how the following couple of current uses would fit the cases above
Bedfordshire (Q23143) Vision of Britain unit ID (P3615) 10173048 as (P794) administrative county (Q2560047)
Does subject has role (P2868) work for this case? Or do we risk simply transferring all the ambiguity of as (P794) and dumping it on subject has role (P2868), if we stretch and stretch the uses of that property ? Jheald (talk) 16:02, 13 February 2017 (UTC)
For your Glasgow example, I'd use of (P642) and maybe add a valid in period (P1264). For your Bedfordshire examples, I'd use criterion used (P1013) or applies to part (P518), or even turn it around and use Vision of Britain unit ID (P3615) as the qualifier:
--Swpb (talk) 17:46, 13 February 2017 (UTC)
@Swpb: I think the latter would be very counter-intuitive for anyone trying to write searches. For a property that's almost always used as an external ID to not be present as an ID, but as a qualifier on something else, would (I suspect) almost always be missed. criterion used (P1013) is an interesting idea, but I think it's value should usually be a question not an answer. As for applies to part (P518) I get a bad feeling every time I see it used for something which is not a physical part, or at least a subdivision (of events in time). Applied to a county I would expect P518 to have the value of a geographical area. Perhaps we need a property "applies to facet", or "applies to aspect". Jheald (talk) 17:56, 13 February 2017 (UTC)
@Jheald: Valid point about the latter. As for criterion used (P1013), I've never seen it as limited to geographic or temporal use, and I don't think it would need to be altered to serve this purpose, but I wouldn't oppose a property like you suggest. --Swpb (talk) 18:08, 13 February 2017 (UTC)
Sorry, I meant to write 518 instead of 1013. (I think you did too). Hope I wasn't too confusing! I've gone back and changed it. Jheald (talk) 18:14, 13 February 2017 (UTC)
That makes more sense. I can see that case for 518; I still think 1013 would be a valid alternative. --Swpb (talk) 18:31, 13 February 2017 (UTC)

Table of use cases[edit]

This is the list of some of current uses of the property:

to be replaced by X Y Z W represents
existing subject has role (P2868) Vladimir Putin (Q7747) participant of (P1344) 30th G8 summit (Q652832) President of Russia (Q218295) X is a Y of Z, X is a W
existing subject has role (P2868)? John Farmer (Q889628) position held (P39) Governor of New Jersey (Q3112728) acting governor (Q4676866)
Edward Smith (Q215786) significant event (P793) RMS Titanic maiden voyage (Q21027972) sea captain (Q849424)
probably subject has role (P2868) Louis XI of France (Q8058) significant person (P3342) Jean Bouchard (Q3170866) confessor (Q21500210) Z is a W of X, W is a "subclass" of Y
new property "value type"? Israel (Q801) demonym (P1549) Israeli noun (Q1084) Z is a Y of X, Z is a W (W is not a subclass of Y)
Bělá pod Bezdězem (Q1019942) contains settlement (P1383) no label (Q21150650) basic unit of settlement (Q329245)
existing subject has role (P2868)? value type? no label (Q14924305) participant (P710) Jetty Paerl (Q287157) singer (Q177220)
existing subject has role (P2868)? value type? criterion used (P1013)? Thai (Q9217) Wikimedia language code (P424) th primary definition (Q22283033) ?
value type? criterion used (P1013)? lightweight class (Q26211786) mass (P2067) 72.5kg upper bound (Q21067467) Z is W of Y of X
existing has cause (P828) Mauro Fiore (Q926054) residence (P551) United States of America (Q30) emigration (Q187668) Z is a Y of X, because of W
character role (P453) Frozen (Q246283) voice actor (P725) Robert Pine (Q1139435) bishop (Q29182) Z is a Y of X, with role W
The Story of Robin Hood and His Merrie Men (Q961039) cast member (P161) Anthony Eustrel (Q4772462) Archbishop of Canterbury (Q29282)
new property "under the name of" Chinese Taipei at the 2016 Summer Olympics (Q18204509) country (P17) Taiwan (Q865) Chinese Taipei (Q216923) Z, under the name of W, is a Y of X
new property "status of the statement" Nimrod Fortress (Q1404704) country (P17) Israel (Q801) de facto (Q712144) the status of "Z is a Y of X" is W
of (P642) Mary and Carrie Dann (Q6779292) instance of (P31) sibling duo (Q14073567) activist (Q15253558) Z of W is a Y of X
Web Map Tile Service (Q10908558) instance of (P31) technical standard (Q317623) geospatial information (Q350758)
criterion used (P1013) Norway (Q20) inception (P571) 1905-06-07 declaration of independence (Q1464916) Z is a Y of X, under the criterion of W
new property "originally as"? Italian Navy (Q833040) inception (P571) 1861-01-01 Regia Marina (Q855186) Z is a Y of W, X was W
Split into two statements Apollo 12 (Q188433) location of landing (P1158) Pacific Ocean (Q98) significant event (P793)splashdown (Q1642255) Concurrent information without direct logical relation

Discussion[edit]

I also found many other use of this property, some of them are incorrect:

  1. Many uses of this property with value song (Q7366), film (Q11424), etc should be removed by spliting the item to new items [7]
  2. Usage of this property as a qualifier of main subject (P921) should be replaced by another value of main subject (P921)[8]
  3. The property is also uses with Wikidata property example (P1855) meaning "scope of example" (decays to (P816)). This can either be removed or replaced by a new property.

--GZWDer (talk) 19:47, 13 February 2017 (UTC)

Minor point, but I am a little confused when you're talking about "W is a subclass of Y", when Y appears to be a property. Jheald (talk) 20:49, 13 February 2017 (UTC)
This is somewhat another kind of subproperty, where as (P794) is used like type of kinship (P1039) and version type (P548).--GZWDer (talk) 21:06, 13 February 2017 (UTC)
I have made a couple of tweaks to the table diff. I hope these are all right. Jheald (talk) 12:51, 14 February 2017 (UTC)
Here's a query for the most commons classes of X, Z, W, with an example of X : tinyurl.com/zn6rj8z
I haven't gone through the whole list yet, but we should perhaps list all the types of proposed "specifically" replacements, and make sure we're happy with them, eg
2010 Tour de France (Q217287) participant (P710) Adriano Malori (Q375923) "specifically" Lanterne rouge (Q1315624) (70 similar uses)
There's also quite a lot of potential "has role" replacements, where the role would be quite generic eg "antagonist" etc, for the purpose of the character's appearance in the film. But that may be okay. Jheald (talk) 15:40, 14 February 2017 (UTC)
@GZWDer, Jheald: Thanks for that detailed tableǃ I would like to see how many instances of each usage there are, to illuminate the evaluation of the need for new properties. As for specific rows:
Basically, I think there may be a need for a couple of new properties, but I think their description and scope need more fleshing out, and we need to look first to existing properties that may be able to do the job without overly stretching their scope. --Swpb (talk) 16:44, 14 February 2017 (UTC)
Agreed. Clearly "subject has role" and "object has role" are not the same thing, For example if we didn't have child (P40) and type of kinship (P1039) but have as (P794) and relative (P1038)/significant person (P3342), you may represent the relationship of Elizabeth II (Q9682) and Charles, Prince of Wales (Q43274) as Elizabeth II (Q9682)relative (P1038)  Charles, Prince of Wales (Q43274), with qualifier "subject has role" mother (Q7560) or "object has role" son (Q177232) (though we mean the latter if we use type of kinship (P1039)). Currently "subject has role" is represented by either as (P794) or subject has role (P2868), and "object has role" is represented by five different properties (as (P794), subject has role (P2868), type of kinship (P1039), version type (P548) and instance of (P31)), we should clean them up. Maybe subject has role (P2868) itself also needs discussion.--GZWDer (talk) 06:18, 15 February 2017 (UTC)
Here is an updated query for the most common joint combinations of Y and (class of W): tinyurl.com/hdx3axc. For each it gives an example X and corresponding example W. (Thanks due to User:MartinPoulter for clueing me into the use of "named subqueries" through his example here).
Also this alternative ordering of the same query, showing all the classes of W for a particular Y together: tinyurl.com/hn8fey9
Splitting "as" and "has role" into "subject has role" and "object has role" could go a long way towards clarifying most of these. It tends to follow fairly closely whether Y is one-to-many or many-to-one. In turn the uses on "subject has role" and "object has role" could then be examined to see if any uses could or should be further cascaded down to more specific properties. Jheald (talk) 09:54, 15 February 2017 (UTC)
Later we may want to write a new help page indicating the differents between them and how to use them.--GZWDer (talk) 15:02, 15 February 2017 (UTC)
As we're agreed, I've created the proposal. --Swpb (talk) 15:41, 15 February 2017 (UTC)
  • If you believe the data that's contained should be moved depending on circumstance to different more specific properties, first move the data and then come back when the property is empty. As long as it isn't Symbol keep vote.svg Keep. ChristianKl (talk) 07:37, 18 February 2017 (UTC)
  • Symbol keep vote.svg Keep agree with ChristianKl. SJK (talk) 01:15, 12 March 2017 (UTC)
  • Keep in the short term but deprecate. I've updated a few items of the table to show where they should go. Deryck Chan (talk) 15:34, 22 March 2017 (UTC)

type of kinship (P1039)[edit]

type of kinship (P1039): (delete | history | links | entity usage | logs | discussion)

It is inconsistent that relative (P1038) uses this but superproperty significant person (P3342) uses as (P794) as qualifier. Propose to merge both usage to a new property "specifically" "object has role" (with alias "specifically" and " type of kinship"). See also the deletion proposal of as (P794) above. (I don't support using instance of (P31) as it's still vague) Previous discussion at Wikidata:Property_proposal/Archive/20#specifically.--GZWDer (talk) 15:02, 13 February 2017 (UTC)

"Specifically"? Really? No will find it, nor know how to use it. Too ugly for general users. So Symbol keep vote.svg Keep as this named and used property is useful and user friendly. Far better to fix up the relationships of what exists rather than try to recreate what looks like a working wheel.  — billinghurst sDrewth
  • Symbol delete vote.svg Delete, but keep as (P794). I actually want the latter to have an even broader use than what it has now. It is precisely the fact that it catches everything that makes it useful and easy to use. Thierry Caro (talk) 13:27, 14 February 2017 (UTC)
    @Thierry Caro: as (P794) is proposed for split to different properties. You may want to discuss this above.--GZWDer (talk) 15:54, 14 February 2017 (UTC)
  • Prefer "object has role" per discussion above--GZWDer (talk) 13:58, 15 February 2017 (UTC)
  • Symbol keep vote.svg Keep For user friendliness. ChristianKl (talk) 17:47, 16 February 2017 (UTC)
    • For user friendliness you may add aliases. Also type of kinship (P1039) have no indication that the type of kinship is with respect of the relationship to the person item on the page where added, but "object has role" clearly have. Property_talk:P1039 also discussed the ambiguity.--GZWDer (talk) 10:42, 17 February 2017 (UTC)
      "Object has role" is no better and lacks clarity. I doubt that anyone is going to think of some other person as an "object", nor that a relationship of grandparent, or father-in-law as a "role". They are people and have relationships/kinships/...  — billinghurst sDrewth 23:53, 19 February 2017 (UTC)
  • Symbol keep vote.svg Keep User friendly, enough specific, easier queryable.--Jklamo (talk) 21:24, 26 February 2017 (UTC)
  • Symbol keep vote.svg Keep significant person (P3342) is too generic and is not defined enough. — Ivan A. Krestinin (talk) 19:08, 2 March 2017 (UTC)
  • Pictogram voting comment.svg Comment I would like to reduce number of basic properties to memorize: SPARQL/easier data entry, but I also understand comments about "Object has role". d1g (talk) 09:25, 3 March 2017 (UTC)
  • Wait for the outcome of #as (P794), above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:31, 12 May 2017 (UTC)
  • Symbol keep vote.svg Keep Kinship doesn't lead to participation or importance, so significant person (P3342) and as (P794) are not applicable. --Infovarius (talk) 07:54, 19 May 2017 (UTC)

version type (P548)[edit]

version type (P548): (delete | history | links | entity usage | logs | discussion)


designated as terrorist by (P3461)[edit]

designated as terrorist by (P3461): (delete | history | links | entity usage | logs | discussion)


number of elevators (P1301)[edit]

number of elevators (P1301): (delete | history | links | entity usage | logs | discussion)

Should use has part (P527) -> elevator (Q132911), qualified with a quantity. There are currently 851 uses, which is low compared to the potential use.--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:18, 24 February 2017 (UTC)

  • Symbol oppose vote.svg Oppose specific enough, 850+ uses, used by two templates.--Jklamo (talk) 18:40, 24 February 2017 (UTC)
  • Symbol oppose vote.svg Oppose Using a specific property as opposed to a generic property with a qualifier is more user-friendly. It is less clicking/typing, easier for new users to understand, etc. I think qualified generic properties should only be used if no specific property exists, and specific properties should only be deleted if they are useless (and 851 uses proves this isn't useless.) SJK (talk) 00:57, 12 March 2017 (UTC)
  • Symbol delete vote.svg Delete "number of ..." (lifts) belong to units. I see "lits" as units. One property or qualifier is enough to describe "totals". I don't understand why do we enter units, when we can explode property count for every unit. Do we need units or do we need specific properties instead of units? d1g (talk) 15:13, 30 April 2017 (UTC)

IDEAS person ID (P3649)[edit]

IDEAS person ID (P3649): (delete | history | links | entity usage | logs | discussion)

Duplicate of RePEc Short-ID (P2428), just a different URL to the same information.--Bamyers99 (talk) 18:58, 27 February 2017 (UTC)

  • That seems true, so let's Symbol delete vote.svg Delete the new one. ChristianKl (talk) 19:16, 27 February 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Is it? The link in the example for P3649 is:

https://ideas.repec.org/f/pal207.html

For P2428, the URL is:

https://authors.repec.org/pro/psh93

The respective values are f/pal207 and psh93; the formats of which do not match. Another URL for P3649 is https://ideas.repec.org/e/pfr10.html, so the letter prefix is significant. These prefixes are used in |repec_prefix= in en:Template:Infobox economistAndy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 27 February 2017 (UTC)

The examples on the property pages are for different people. Andrei Shleifer (Q502557) vs Alberto Alesina (Q1387534) The prefix is only significant if using the ideas url. The same information, the list of papers, is available from the authors.repec.org url, which doesn't need the prefix. --Bamyers99 (talk) 22:53, 27 February 2017 (UTC)
I can see that they are for diferent people. I referred to the formats not the values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:04, 28 February 2017 (UTC)
I found the url for displaying the IDEAS interface without having to know the e/f prefix: https://ideas.repec.org/cgi-bin/h.cgi?h=psh93 --Bamyers99 (talk) 01:39, 28 February 2017 (UTC)
In that case, Symbol delete vote.svg Delete. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:25, 28 February 2017 (UTC)
After migrating data; that is - there are now over 500 uses. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:49, 6 March 2017 (UTC)
I already copied all enwiki infobox uses to P2428. Evidently Thierry Caro didn't see the deletion notice on the P3649 talk page. --Bamyers99 (talk) 15:13, 6 March 2017 (UTC)
Sorry. I didn't know the deletion was being debated. Feel free to do what's best. Thierry Caro (talk) 15:55, 6 March 2017 (UTC)
IDEAS is a particular site based on RePEc`s data. Since the identifiers are the same, it is bad to keep both in Wikidata, because data entry efforts split up between the two, and it would be cumbersome trying to keep them in sync. RePEc Author links are meant to be permanent (see the note on the bottom of, e.g., https://authors.repec.org/pro/pal207/), whereas IDEAS URLs don't claim that. -- That said, the IDEAS page contains more information (about ranking, download statistics and so on), so there is value in linking to it. Is there something like computed fields in Wikidata, which would allow us to offer only P2428 for input, but to display an additional computed link link to IDEAS? Jneubert (talk) 13:56, 12 May 2017 (UTC)
As of just now, there are 14 items which have P3549 and no P2428, while 1787 items have P2828 and no P3549. Jneubert (talk) 14:14, 12 May 2017 (UTC)

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)

Symbol oppose vote.svg 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)
Symbol delete vote.svg Delete per Snipre --Pasleim (talk) 11:44, 15 April 2017 (UTC)
Symbol keep vote.svg 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)
Symbol delete vote.svg 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)
Symbol keep vote.svg 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)

terminus location (P609)[edit]

terminus location (P609): (delete | history | links | entity usage | logs | discussion)

Merge with terminus (P559). The distinction between these two properties is fuzzy and not worth distinguishing. terminus (P559) supposedly indicates a "feature", meaning a road, station, etc., at the end of a linear feature, whereas terminus location (P609) supposedly indicates the city, town, or other administrative entity at a terminus, but their use overlaps significantly: see Hallandsås Tunnel (Q493063).--Swpb (talk) 16:38, 29 March 2017 (UTC)

Symbol delete vote.svg Strongly agree the deletion reason, I'm just confused with such unnecessary splitting. --Liuxinyu970226 (talk) 12:05, 6 April 2017 (UTC)
Symbol delete vote.svg Delete --Pasleim (talk) 11:43, 15 April 2017 (UTC)
Symbol delete vote.svg Delete, confusing and unnecessary. Jc86035 (talk) 11:51, 18 April 2017 (UTC)

BeneBot* (talkcontribslogs) Detcin (talkcontribslogs) Dough4872 (talkcontribslogs) Happy5214 (talkcontribslogs) Jakec (talkcontribslogs) Legobot (talkcontribslogs) Liuxinyu970226 (talkcontribslogs) Ljthefro (talkcontribslogs) Puclik1 (talkcontribslogs) Rschen7754 (talkcontribslogs) (administrator) Scott5114 (talkcontribslogs) SounderBruce (talkcontribslogs) TCN7JM (talkcontribslogs) naveenpf (talkcontribslogs) Labant (talkcontribslogs)


Pictogram voting comment.svg Notified participants of WikiProject Roads

Symbol keep vote.svg Keep Per Wikidata:Property_proposal/Archive/8#P609. terminus (P559) and terminus location (P609) are bit confusing, but they are used distinctively (both 10,000+ uses). Separate terminus location (P609) property is better solution than located in the administrative territorial entity (P131) qualifier.  – The preceding unsigned comment was added by Joshbaumgartner (talk • contribs).
Symbol keep vote.svg Keep Just because people aren't using it properly doesn't mean it should be deleted. Please see where it is properly used, like California State Route 78 (Q19183). --Rschen7754 01:56, 20 April 2017 (UTC)

BeneBot* (talkcontribslogs) Detcin (talkcontribslogs) Dough4872 (talkcontribslogs) Happy5214 (talkcontribslogs) Jakec (talkcontribslogs) Legobot (talkcontribslogs) Liuxinyu970226 (talkcontribslogs) Ljthefro (talkcontribslogs) Puclik1 (talkcontribslogs) Rschen7754 (talkcontribslogs) (administrator) Scott5114 (talkcontribslogs) SounderBruce (talkcontribslogs) TCN7JM (talkcontribslogs) naveenpf (talkcontribslogs) Labant (talkcontribslogs)


Pictogram voting comment.svg Notified participants of WikiProject Roads since the first one didn't go through. --Rschen7754 01:56, 20 April 2017 (UTC)

Symbol keep vote.svg Keep The distinction between the two properties is made in the infoboxes on Wikipedia also. --Labant (talk) 02:24, 20 April 2017 (UTC)
Symbol keep vote.svg Keep I'll concede that this split model doesn't work particularly well with the given tunnel example. However, it is the best solution for road items, for reasons spelled out in the property proposal linked above. -happy5214 18:34, 25 April 2017 (UTC)

Fotografen.nl ID (P3269)[edit]

Fotografen.nl ID (P3269): (delete | history | links | entity usage | logs | discussion) was created as a spin-off of RKDartists ID (P650). The Fotografen.nl ID (P3269) and RKDartists ID (P650) id's are exactly the same. This turned out to be a temporary project. The website at http://www.fotografen.nl/ just contains a banner to go to RKDartists (where all data is available) and all links are broken. This property is completely redundant now. Multichill (talk) 10:40, 15 April 2017 (UTC)

Symbol keep vote.svg Keep with modified formatter URL for those photographers where the pages were archived at archive.org, at least until the same information from that archived page is actually also available elsewhere. The fotografen.nl had some quite valuable information that was (and still is) not available on the RKDartists website (sample photos by the photographer, a bibliography, sometimes a short written biography and information about memberships and management of copyrights). And it turns out that the Wayback Machine has partly archived fotografen.nl. I therefore suggest to keep the property and change the formatter URL to
https://web-beta.archive.org/web/*/http://fotografen.nl/nl/component/nfm_fotografen/fotograaf/id/$1
Examples for checking that fotografen.nl indeed had more information:
Pictogram voting comment.svg Comment The 'web-beta.archive.org' URL at Internet Archive gives better results than the 'web.archive.org' version.
Pictogram voting comment.svg Comment A quick test seems to show that this only works for some photographers whose oeuvres are managed by the Nederlands Fotomuseum. I'm willing to inventorize their list and remove the values for those statements that don't link to working archive.org pages. Spinster 💬 17:17, 15 April 2017 (UTC)
  • keep per Spinster (but do not delete values for pages not archived by archive.org; other arhcives may exist). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:48, 12 May 2017 (UTC)

no label (P3873)[edit]

no label (P3873): (delete | history | links | entity usage | logs)


taxon author (P405)[edit]

taxon author (P405): (delete | history | links | entity usage | logs | discussion)

taxon author (P405) is rendered redundant by the recent creation of named by (P3938). That said, P405 is widely used, so it may be better to merge the new property into P405, and update its label, description, and constraints.--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:46, 12 May 2017 (UTC)

PS: Abbe98
Achim Raschka (talk)
Brya (talk)
Dan Koehl (talk)
Daniel Mietchen (talk)
Delusion23 (talk)
Faendalimas
FelixReimann (talk)
Infovarius (talk)
Joel Sachs
Josve05a (talk)
Klortho (talk)
Lymantria (talk)
Michael Goodyear
MPF
PhiLiP
Andy Mabbett (talk)
Prot D
pvmoutside
Rod Page
Soulkeeper (talk)
Tinm
Tommy Kronkvist (talk)
TomT0m
Pictogram voting comment.svg Notified participants of WikiProject Taxonomy --Succu (talk) 21:56, 15 May 2017 (UTC)

  • I would prefer that taxonomy would also use the qualifier solution with named by (P3938) but I see no reason to delete this existing property as long as the data isn't moved over. ChristianKl (talk) 10:13, 23 May 2017 (UTC)
    • In nomenclature it's not important which of several authors coined the name. There is no one to one relationship between these two qualifiers. See also ex taxon author (P697). --Succu (talk) 15:34, 23 May 2017 (UTC)

inventory number (P217)[edit]

inventory number (P217): (delete | history | links | entity usage | logs | discussion)

Duplicates catalog code (P528), as can be seen, for example, on Munimenta antiqua: or, observations on antient castles (Q27308080). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:16, 12 May 2017 (UTC)

  • Symbol keep vote.svg Keep no, it's not the same. inventory number (P217) is used with collection (P195) and catalog code (P528) with catalog (P972). Multichill (talk) 20:37, 15 May 2017 (UTC)
  • Symbol keep vote.svg Keep Not the same thing at all. A catalogue code is a specific code signed to an object when it appears in an exhibition. An inventory number is a number assigned by the institution where the object resides. They are two totally different things (and this is what I spent $80k getting into debt to learn... ;-) Missvain (talk) 20:44, 15 May 2017 (UTC)
    • That distinction does not appear to be made on Wikidata. Not least since galaxies and other astronomical bodies, for example, are rarely exhibited, nor kept in institutions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:21, 15 May 2017 (UTC)
      • Sounds like galaxies should not be using inventory numbers then and just catalogs. When it comes to paintings or other movable heritage, however, we need both. Jane023 (talk) 22:01, 15 May 2017 (UTC)
        • AFAICT, they do use "catalogue" (despite not being exhibited). Why do we need both? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:20, 15 May 2017 (UTC)
          • Because a painting can be lent out for an exhibition, whereupon its exhibition catalog number is not the same as its inventory number in the lending institution. They are two disctinct concepts that should not be confused. An inventory number refers to a collection, while a catalog number generally refers to a page in a printed book. Jane023 (talk) 15:56, 16 May 2017 (UTC)
            • The fact that "a painting can be lent out for an exhibition" in no way precludes the combining of these two properties. Nor does the fact that some catalogues exist on dead tree media. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:44, 16 May 2017 (UTC)

There are very few museums that have kept their numbering consistently for longer than two decades, besides some fossilized 19th-century royal collections and other slowly-changing collections. There are many many inventory numbers that have thus never been printed in an official catalog with their inventory numbers at the point in time they had that inventory number. This is generally information only kept at the institution itself. It would be detrimental to the project to remove this needed identifier for collections. As far as merging the identifier with the collection property, I am also against this, as most collections do not have identifiers (private families, small collections, etc). Jane023 (talk) 08:27, 17 May 2017 (UTC)

"It would be detrimental to the project to remove this needed identifier for collections" is simply a rephrasing of "we need both"; not an argument as to why both are needed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:27, 17 May 2017 (UTC)
To track paintings in collections on Wikidata, whenever possible, we like to use inventory numbers of institutions, because we can easily cross-reference these with other publications and online resources. The visual image and measurements are not enough to determine the uniqueness of a painting and other characteristics are needed. The inventory number is just one piece of the puzzle. Catalogs of works in an institution may or may not be published by institutions themselves, but are also an important piece of the puzzle. Art auction data is also important; in that case, a painting may be assigned a lot number and this is often used in art provenance records in combination with the date, place, and name of the auction house, whether or not that specific painting made it into the printed sale catalog (if a sale catalog was even printed at all). At a following auction, the same lot number can be re-used, so to refer to a specific painting in any auction you need the number in combination with the other references. The exact same thing is true for collections, except the accessioning and deaccessioning process happens a lot more slowly. Catalogs, on the other hand, are assembled at the discretion of the author, and sometimes the author is well versed in provenance methodology, and sometimes not. So a catalog might be recorded by number, number + page number, catalog number, footnote number or illustration number in addition to catalog number, etc. So the idea of using an inventory number for a collection is a lot cleaner than using a catalog number, which can be quite messy. Museums produce catalogs regularly for exhibitions, and from time to time they may produce highlight catalogs (which sometimes do and sometimes don't include the inventory numbers). They very rarely produce catalogs on paper of the entire collection. Probably less often than once every 15 years or so. Merging these fields would making tracking much more difficult, in addition to confusing the number assigned to a painting by an institution in its inventory and the number assigned to a painting by the institution in one of its printed catalogs. Jane023 (talk) 12:11, 18 May 2017 (UTC)
  • Symbol keep vote.svg Keep I don't think we have to call everything a catalog whether or not it is a catalog. ChristianKl (talk) 10:17, 23 May 2017 (UTC)

Property:P1103[edit]

number of platform tracks (P1103): (delete | history | links | entity usage | logs | discussion)

This property is used and labelled inconsistently. The meaning of the property was changed a while after it was created, but not all of the labels were updated to reflect that decision so that some labels mean "number of platforms", which can mean several different things depending on the region and language as well as context, and some labels mean "number of platform tracks". As a result, an insubstantial number of values could be or are incorrect, since they describe the number of platforms counted in a different way. Several different replacement properties could be taken from this property proposal discussion (properties were not created). Jc86035 (talk) 12:50, 17 May 2017 (UTC)

As an example, Greenford station (Q800841) has one island platform with a bay platform inset. Quoting Thryduulf: "The outside faces have one platform number each (1 / 3) and are used exclusively by London Underground. The bay platform has a platform on both sides of the train but one number (2), currently the doors only open on the north side of the train (due to rolling stock limitations, not station infrastructure limitations, so future trains may be able to use both sides). It therefore has 1 (island), 2 (island + bay), 3 (platform numbers in use; independently signallable platforms; tracks adjacent to platforms) or 4 (platforms adjacent to tracks) platforms." The British English label was different to the English label for more than a year, so if this property were added for it, it could have had any of the aforementioned values depending on the user interface language of the editor and how they counted platforms. Jc86035 (talk) 12:59, 17 May 2017 (UTC)

Symbol keep vote.svg Keep so fix it, deleting it won't solve the problem. Multichill (talk) 19:58, 17 May 2017 (UTC)
@Multichill: The problem is that because the data is polluted and half the labels are still wrong, we don't really know if the values are correct. I suppose all the values could be gone through (this would have to be done manually for all of them) and the labels redone. Jc86035 (talk) 12:34, 18 May 2017 (UTC)
@Multichill: Would a solution like « delete after data fixing » would do the trick ? A kind of deprecation. This lacks ous current workflow. author  TomT0m / talk page 11:16, 20 May 2017 (UTC)
Symbol delete vote.svg Delete By reading that archived proposal I kindly agree what Pigsonthewing said, in the future we can say a stationhas part (P527)  side platform (Q2735706) with qualifier quantity (P1114)  3, has part (P527)  island platform (Q2725290) with qualifier quantity (P1114)  3, has part (P527)  bay platform (Q877472) with qualifier quantity (P1114)  3, etc. I really don't know where's the example which the total number of platforms can't just be numbers of Q2735706+Q2725290+Q877472+... --Liuxinyu970226 (talk) 04:33, 20 May 2017 (UTC)
@Liuxinyu970226: As Thryduulf stated in the prior discussion: some stations (UK, Taiwan, etc.) have independently signallable A/B platforms on the same face, stations in different parts of the world number platforms differently, and so on. I think several more items/properties might need to be created for those (has part → platform number?), but for most stations has part (P527) should suffice. Jc86035 (talk) 05:13, 20 May 2017 (UTC)
@Liuxinyu970226: use has parts of the class (P2670) View with SQID instead. This discriminates specified parts (parts for which we have actual items, West Wing (Q1932621) View with Reasonator View with SQID for the white house for example) from unspecified ones (the whitehouse has wings). author  TomT0m / talk page 11:17, 20 May 2017 (UTC)
Symbol keep vote.svg Keep, I am not a fan of "use this very generic property with this obscure item/qualifier combo". Useful property. Sebari – aka Srittau (talk) 15:27, 23 May 2017 (UTC)