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.







for permissions

for deletions


for deletion

for comment

and imports


a query



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


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)
  • Symbol keep vote.svg Keep Given that there are probably many queries where it makes sense to look at this property and it increases the speed of those queries, I'm okay with keeping the property. ChristianKl (talk) 09:29, 5 June 2017 (UTC)
  • Symbol delete vote.svg Delete, little need. MechQuester (talk) 19:53, 16 June 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)
Symbol support vote.svg Support per Andy − Pintoch (talk) 15:22, 15 September 2017 (UTC)

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

Relation with language (P2439)[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)
@Pasleim: Your proposition will create multiple opposing statements in the same item: what happens if one item about an edition has one statement original language of work (P364) and one statement language of work or name (P407) ? With your scenario, you will just create 2 statements for language of work or name (P407) and one will be wrong. You can't separate the conversion and the deletion process
  1. announce the migration in WD:Status updates/Next
  2. launch the migration with the following analysis:
    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 in the item
    • delete it otherwise
No need of fixing templates to perform that action. Templates can be fixed later without any lost if the correct work/edition model was used in WD. If someone created the edition item without the work item, no template fixing will solve the data lost because you will need to create the work item first. So the problem is not template fixing but incorrect data modeling in WD. Snipre (talk) 20:13, 28 May 2017 (UTC)
@Matěj Suchánek, Pasleim, ValterVB: Do you think we can proceed now for property merge ? Snipre (talk) 20:13, 28 May 2017 (UTC)
Your approach looks good to me, I think we are mostly ready. Matěj Suchánek (talk) 07:48, 2 June 2017 (UTC)
I added "(DEPRECATED)" mark to original language of work (P364) just now. --Liuxinyu970226 (talk) 04:39, 13 June 2017 (UTC)
  • It seems the situation on books is a thoroughly confused and no basic statistics on it's status are available. See Wikidata talk:WikiProject Books. Before doing an merges, one should ensure an action plan is available to clean this up. Otherwise the merger just confuses the situation further. It appears that the scheme suggested at Wikidata:WikiProject Books can't be implemented in practice and a new approach may be needed, possibly with enhanced Wikibase features for relevant Wikidata items.
    --- Jura 10:50, 8 July 2017 (UTC)
  • For books, the problem may be that many items for editions don't have an item for the work. For all values with "original language of work" (P364) such items would need to be created.
    --- Jura 14:49, 9 July 2017 (UTC)
    Jura convinced me that the situation around books should get more attention. I found many cases of items containing data about both work and the edition. (Well, they mostly seem to represent editions, eg. they have translator (P655) but they also contain data about the original work, eg. original language of work (P364) or instance of (P31). Perhaps a bot could help here.)
    Nevertheless, the property should be marked as deprecated, so that we have additional means of preventing arbitrary new usages. Matěj Suchánek (talk) 11:30, 10 July 2017 (UTC)
    I'm fine with doing this for books (as it's already done), but if we mark it as such for any item, people may start introducing incorrect data for other items. For books, I think a plan should be worked out how to split these items if people are actually interested in using the model proposed at its WikiProject. An alternative solution may be to develop a property datatype that could more easily hold information for various ISBN.
    --- Jura 05:44, 13 July 2017 (UTC)
> various ISBN
ISBN doesn't exist in 300BCE.
This would take far more time than current properties with multiple items and not necessary better than current 629+747+language 05:21, 24 July 2017 (UTC)
  • So how do we handle collected translations, where there is an original language, but NOT an original work? In particular it is common for translators to publish the surviving plays of Pautus as a collection, or the surviving fragments of Cratinus, but these items never had an original "work" to come from. The modern translation(s) are collected as a volume that is a translation, but not of any particular work. --EncycloPetey (talk) 00:23, 23 July 2017 (UTC)
Use properties that don't assume any works: language (P2439) 04:01, 24 July 2017 (UTC)
  • It looks like we still lack a status and a clear plan for books. This is really problematic as it has a negative impact on other fields.
    --- Jura 07:12, 23 July 2017 (UTC)
    From my own experience, the biggest problems I run into involve dealing with translations of works, and dealing with collected works. Most of the decisions and properties have been made assuming (incorrectly) that (a) there will always be an "original work" from which a translation/edition will come, (b) that translations never have intermediary translations. They also fail to account for (c) editions of translations (a book that is a translation or contains translations, which book is then printed in editions), and (d) collections of works, which may exist in editions, and whose components are themselves translations and/or editions. --EncycloPetey (talk) 20:12, 23 July 2017 (UTC)
that's why several users voted to keep only most generic property (language (P2439))
a, b - remove 364 (and possibly 407)
c - not relevant here, use edition or translation of (P629) and edition(s) (P747)
d - use P629 and P747 and P2439 in any possible combination.
@EncycloPetey: any single example when many items with P629 and P747 and P2439 not able to represent information? d1g (talk) 04:21, 24 July 2017 (UTC)
I think the biggest challenge we face here is the casual dismissal of issues without meaningful discussion. D1gggg, I have to say I don't have much confidence in your suggestions, because it's clear from other edits that you don't know much about library data or the Wikidata properties you're using. You've added entirely the wrong property on more than one occasion, have altered project pages without consensus, and fail to sign your posts frequently. This shows unfamiliarity with the system. So, I will need to hear from more people with greater experience. Your responses above also show that you either do not understand the issues involved, or have not thought about the consequences. How will the data represent the "original language" in a situation like "c", which you claim is "not relevant here"? If we have editions of translations of works, that whatever system is retrieving the data to get the original language, it will have to know somehow to climb more than one step back to get that data. --EncycloPetey (talk) 14:17, 24 July 2017 (UTC)
@EncycloPetey: The proposed system isn't a problem for translated editions:
1) "there will always be an "original work" from which a translation/edition will come". The model used for book is FRBR which is quite widely used. If we decide to use this system, we have to create the corresponding structure so if for one item about a translation we don't have to create one item which will be the work one. But for that we have start the migration in order to avoid people to continue to use the wrong model.
2) The current system with 2 language properties doens't help you to model the case you mentioned:
  • A is a transaltion edition in French of B
  • B is a transaltion edition in German of C
  • C is the first edition in the original language English
What is the original langauge for A ? German or English ?
That's why the current system is wrong, because it collects data from different items in one item instead of keeping data separetely in the correct items and to use link between items to extract the data you need.
We miss probably a property for items about translated editions which allow to identify which is the edition (in the original lnaguage or not) used as reference for the translation but this problem is not relevant for our present languages problem as the original langague property doesn't help you to solve the problem of intermediary translations.
For the two last points you mentioned there is a need for additional properties but at the end having 2 languages properties don't help you to solve the problem you mention. I think your points should be discuss with the project Wikidata:WikiProject Books but not here in that discussion unless you can show how 2 languages properties can help to solve the problems you mentioned. Snipre (talk) 18:44, 24 July 2017 (UTC)
@Snipre: I don't think you've understood some of the issues I raised:
1) There will NOT always be an "original work". And there is a real problem using translation/edition interchangeably. These two problems create most of the issues I have dealing with translations. Perhaps I need an actual example:
A is the "edition" item for the 4th edition of Swanwick's "Tragedies of Sophocles".
B is the "translation" data item for Swanwick's "Tragedies of Sophocles".
But B is a translation of C, D, E, F, G, H, & J, which are all separate data items for the "works" by Sophocles in the original ancient Greek.
So, is B a "work" because it has multiple editions? Or is it an "edition" because it is a translation of another author's works? And to return to the issue at hand: C, D, E, F, G, H, & J were are all originally written in ancient Greek, but as works they have no language at all. Only specific editions will be written or published in a particular language; even the first edition published or written. And any bot or tool that pulls data from this structure (by the current proposal) would run into difficulties, since, A and B are in English, and if A is an "edition" of B, how will it be indicated that English is not the original language when the data is extracted? We have a three-tiered hierarchy in these situations, but our model assumes that the hierarchy always has only two levels. --EncycloPetey (talk) 19:09, 24 July 2017 (UTC)
@EncycloPetey: What's "translation" data ? I think you are not able to describe your problem. Is it book, an eletronic file, a scroll or different parts of a scroll or even different parts from different scrolls ? Data doesn't mean any thing at that level. Snipre (talk) 19:19, 24 July 2017 (UTC)
@Snipre: You misunderstood. I did not say "translation data", I said "translation data item": A data item for the translation. The translation is a translation/work, and has four editions. Works are never physical objects, only specific editions of works have physical forms. The work itself can appear in any form: printed, electronic text file, audio recording, or performance. So it makes no sense to ask whether the translation is a book, file, scroll, etc. This is the fundamental problem in dealing with books that I keep trying to point out. Our labelling is fuzzy concerning the distinction between works, translation, editions, etc. --EncycloPetey (talk) 14:51, 25 July 2017 (UTC)
@EncycloPetey: So again what is B ? What is C ? Books ? Scroll ?
Then a book can't be a translation of several other books: it can contain translated parts from other books/documents but in that case, if the translated book is composed of several translations coming from different document, it is a new work compared to those documents, because the choice of the translations is a creative choice. I don't see any difficulty to treat your case, what is missing in your case is a link to other documents as inspired by (P941), based on (P144) or after a work by (P1877). A compilation of works is a new work. Snipre (talk) 20:12, 2 August 2017 (UTC)
@Snipre: RE: So again what is B ? What is C ? Books ? Scroll ? I say again: C is a work; it is not an instance of that work, but a work itself. It is not a scroll, nor a book, nor anything physical. To ask whether it is a book or scroll, etc. it to completely fail to understand what a work is. Only the editions of works can be a book, scroll, performance, etc. B is a translation of C, and this is where we run into specifics of the problem. If a translation is treated as an edition, then it must have specific edition data such as a year of publication, but if translations are treated like works, then the translation can exist in multiple editions (as it often does), but in that case it is not a book, scroll, etc. as works have no physical form. This is in fact why translations are troublesome to enter. If I have a translation that exists in different editions as a book, as a chapter, as the right-hand pages of a book, or as an audio file, then the data item for the translation cannot be specified to exist in any particular form. So, again, B is not a book or scroll or anything you could hold or point to; it is a translation. Likewise, C is not a physical object, but is the original work. I am sorry that you cannot understand the difficulty. --EncycloPetey (talk) 20:37, 4 August 2017 (UTC)
@EncycloPetey: The main problem is you don't used usual WD terminology with your "edition data item" or "work data item". We just use work item or edition item. In WD, an item is a collection of data, so when you say "edition data item", this gives something like "a collection of data about data of an edition". If you use your own definitions then don't be surprised to be not understandable.
And finally your problem is you don't do any difference between a book which is a translation of a work and a book which contains a translation of a work. In the second case the book contains more than the translation of the work so it can be considered only as translation of that work but is something different so you need another property to link the book to the different works it contains typically "has part". This solves the problem of antologies or other collections you mentioned in the first time.
Still stays the question of a new edition of a previous translation. In that case just take the FRBR model and consider that the edition definition corresponds to the manifestation definition of the FRBR model and we don't use the expression level of that model.
So example:
A is a work, B is the 1st edition in the original language, C is a translation of the 1st edition
In a logical scheme C is not a translaion of the work, but a translation of an edition in the original language. In your system you should create an additional item D which is the work of the translation and represents this system with:
D is a translation of A, C is a translation of B, B is an edition of A and C is an edition of D. And then you need a aditional property to link C and A. But this latter link is what most of people working with WD want to have.
This creates more complexity for a minimal added value. So in WD, if you have W is a work, X is the 1st edition of W in the original language, Y is a translation of X and Z is a reedition of Y, then X, Y, Z and edition of W and to create the link between X, Y, Z you need new properties like "translated from" (Y translated from X) and "reedition of" (Z is a reedition of Y).
In WD we choose to keep the system simple and to avoid to create to many abstract items like the ones you mentioned (translation defined as work).
So is the WD system clear for you ? Snipre (talk) 23:32, 7 August 2017 (UTC)
@Snipre: I'm sorry that you still don't understand. You're giving examples that have no application for the works I have to deal with. In your example, you say that "B (or X) is the 1st edition in the original language", but there lies one of the problems with the translations of classical literature: there is no 1st edition available anywhere. What we have are dozens of edited editions in the original language that have been reconstructed from medieval or Renaissance manuscripts, where these various editions and manuscripts all differ from each other. Sometimes, a translator will rely on a particular original language edition, but most often they will not. So there is no means of tying most translations to any specific edition printed in the original language. With that link in the chain broken, your entire proposal falls apart at the very first link. So, no the WD system is neither clear nor usable as you have described it, and that is why I have raised the issue of dealing with translations. --EncycloPetey (talk) 00:24, 8 August 2017 (UTC)
@EncycloPetey: I understood your problem: WD community doesn't model the data in order to fit your problem because your translation problem is not relevant for the community objectives. Do you understand that there are different ways to model data and you choose the one which fit the objectives you want to reach ? WD model currently doesn't take care about the sequence of the translations or if a translation was based on two or three originals which were partially recovered. ONCE AGAIN, WD doesn't care about the relations between the different editions or translations. perhaps later we will try to do solve the problem you mentioned and we will create new properties to be able to create that relations.
You don't understand that WD is a top level ontology and not a specialized ontology: we are not describing only books but animals, planets and comics. We want to reach a certain level of details but without having to deal with a heavy model with data relevant only to specialists.
Saying that "the WD system is neither clear nor usable as you have described it" just indicates you don't know the purposes of WD concerning bibliographical data: citation. So we choose an appropriate model for that. If you want to be useful for this community try to understand what are the objectives of WD, which are perhaps not the same like yours. And if you really want to propose a new model which is able to solve the problem you mentioned, don't spent time here: go to Wikidata:WikiProject Books, propose your model there and convince people to use it. Currently I am trying to apply the model described on that page and which was accepted by a relative majority of the WD community, so if you don't like it please go there and try to change it there. You will save your time and the time of other contributors. Snipre (talk) 01:19, 8 August 2017 (UTC)
{@Snipre: No, you didn't understand my problem, and as I pointed out, the model you propose above demonstrates strongly that you do not understand. Claiming that you understood all along, and claiming that I am the one who does not is simply avoiding the discussion by moving the goalposts and does not advance the discussion.
Right now, there is no model for translations at Wikidata:WikiProject Books which is part of the reason I have my problem and am trying to get it addressed and solved. But each time I state the problem, people (such as yourself) first claim there is no problem, then claim that the problem is easily solved, and finally admit that the problem exists and is not easily solved, but then claim instead that it is not important after all. Look back through your own comments above, and this same pattern of response occurs. If you cannot see a solution, that is fine, but please do not simply dismiss the issue on false pretense. --EncycloPetey (talk) 02:28, 8 August 2017 (UTC)

Danish works[edit]

Looks like @Fnielsen: is still focusing on adding original language of work (P364) even duplicate language of work or name (P407) values, I don't know what's wrong within Danish that is not OK to lose original language of work (P364). --Liuxinyu970226 (talk) 23:57, 26 July 2017 (UTC)

How would we describe Digte (Q23009890) (regardless of whether it is a work or a edition (Q3331189)) without both original language of work (P364) and language of work or name (P407)? — Finn Årup Nielsen (fnielsen) (talk) 07:44, 27 July 2017 (UTC)
Should I copy suggestions from Snipre that is archived above? --Liuxinyu970226 (talk) 08:22, 27 July 2017 (UTC)
@Fnielsen: IMHO, I have an idea that describe that thing that without original language of work (P364) but with language of work or name (P407), and perhaps no splitting needed:
1. Allowing loop-back value of edition or translation of (P629) (i.e. adding Digte (Q23009890)edition or translation of (P629)  Digte (Q23009890)) (note that country (P17) is such allowed in sovereign states items), with qualifiers:
a. (may only available after description re-designing, or maybe new datatype needed) start point (P1427)  Danish (Q9035)
b. (ditto, :p) terminus (P559)  English (Q1860)
c. Wikidata usage instructions (P2559)  This work item cannot be splitted, as it has English contents that are in conjunction with original Danish contents, and per the will of author those contents are just included in one work
2. language of work or name (P407)  Danish (Q9035) PRIORITY: Preferred rank
3. language of work or name (P407)  English (Q1860) PRIORITY: Normal rank

I wish you to understand this alternate. --Liuxinyu970226 (talk) 02:04, 28 July 2017 (UTC)

We need to make sure that we don't loose any information. Until a clear plan is available, the best approach is to continue as of now, as said: no large scale changes should be made before.
--- Jura 07:08, 28 July 2017 (UTC)
@Snipre: It still needs your suggestion to resolve problems here. --Liuxinyu970226 (talk) 14:17, 4 August 2017 (UTC)
I added to Digte (Q23009890) all works it compromises by using has part (P527). This allows now to exactly determine which parts of the collection have original language Danish and which parts are translations from English. --Pasleim (talk) 23:06, 4 August 2017 (UTC)
@Liuxinyu970226: Pasleim solved partially the problem: the final step is to delete the original language statements which just means nothing in that case. The English versions of the poem were translated from Danish or from Jutlandic dialect but not from Danish AND Jutlandic dialect. I am quite confident to think that in reality the original version of the poems is in Jutlandic dialect which were translated in Danish. But the current data structure doesn't provide any corretc information about the relation and just add confusion because we mix data: we mix data about the book with data about the poems. Each time you go further into the details you have to create item and not adding more and more informations in the general items. Just take the example of a village: you don't add data about the village in the country item where the village is located in. If the original language is different for each poem, the current statment current statement Original language = Danish/Jutlandic dialect is wrong because it is imprecise. That's why you shouldn't not mix data: the book is in English/Danish/Jutlandic dialect, that's a fact. Then for the original language we have to create an new item for the document which was used as original text or at least to provide the correct process: the poems author wrote them in one language and then translated them in another language, so be accurate and provide the correct sequence. And if you don't know the correct sequence don't write wrong information. Snipre (talk) 00:32, 8 August 2017 (UTC)
@Snipre: That approach only works when there is only one document which was used as original text, and when we know exactly which document that is. For translations of whole books written in the modern era, that is usually possible, but it is not possible for most older texts where all the available source texts were used, or where the "original" is either not identified or never existed in written form. Even for a well known work like Shakespeare's Romeo and Juliet, there is no single source text used for modern editions or translations. All modern English editions of the play are amalgamations of several early texts, and translators seldom identify which edition(s) they worked from. --EncycloPetey (talk) 01:13, 8 August 2017 (UTC)
@EncycloPetey: "That approach only works...when we know exactly which document that is." If you don't know exactly, don't write unsourced information. If an Italian translation of an older Greek document is not known has being translated from the original Greek document in Greek, don't write that the original version form of the Italian translation is Greek, because the translation was perhaps done from Latin. WD doesn't deal with some hypothetical possibilities but with facts. So if you don't know what was the original version used for a transaltion, don't add wrong information. Snipre (talk) 01:42, 8 August 2017 (UTC)
@Jura1: Unfortunately, we still have some editors making major changes to many entries, such as User:Pasleim. --EncycloPetey (talk) 23:42, 6 August 2017 (UTC)
@EncycloPetey: I'm cleaning up items which mix work with edition/translation. You can not abuse this discussion here to stop the whole Wikidata:WikiProject Books. --Pasleim (talk) 00:03, 7 August 2017 (UTC)
@Pasleim: The resolution of the problems of edition / translation are part of the ongoing discussion. No resolution has been adopted by consensus in the discussion. --EncycloPetey (talk) 00:07, 7 August 2017 (UTC)
The topic of this discussion is not if work items should be separated from edition/translation or how to discriminate an edition from a translation but how to merge original language of work (P364) into language of work or name (P407). As pointed out above by User:Matěj Suchánek, the problem are items constaining data both about work and edition/translation. A way has to be found how to separate these items. My constructive answer to this problem was to separate them manually... --Pasleim (talk) 01:22, 7 August 2017 (UTC)
The topic of discussion is the removal / merger of a property associated with books. Refusing to discuss points pertaining to that discussion and removal / merger is not helpful. --EncycloPetey (talk) 02:58, 7 August 2017 (UTC)
The topic of this discussion is the application of the model proposed on that page, so if you want to discuss again the model itself go there. Snipre (talk) 01:29, 8 August 2017 (UTC)
No model is identified for translations at the location you have indicated, only models for "editions" that are used as sources. Wikisource data housed here for translations does not fall into that category, yet we are trying to house a wealth of translation data here. One cannot apply a model that does not exist. --EncycloPetey (talk) 02:32, 8 August 2017 (UTC)
Have you seen Help:Sources#Books? Matěj Suchánek (talk) 08:56, 8 August 2017 (UTC)
@Matěj Suchánek: Yes, but it does not provide the help needed for the large category of items in which I usually work, nor does it provide a useful example for translations or editions of translations. --EncycloPetey (talk) 02:06, 9 August 2017 (UTC)
@EncycloPetey: Note that your undo actions are happened twice or three times, please do not violate 3RR, thx. --Liuxinyu970226 (talk) 03:45, 9 August 2017 (UTC)
@Liuxinyu970226: Please note that WD has no 3RR policy. In fact, several MW projects have no such rule. You are thinking of Wikipedia. --EncycloPetey (talk) 14:05, 9 August 2017 (UTC)
@EncycloPetey: So you can legally do a lot of edit war (Q764327) because you just want to keep one property? --Liuxinyu970226 (talk) 02:23, 10 August 2017 (UTC)
@Liuxinyu970226: Making comments ascribing invented motives and goals to other people will not solve anything, and can damage the community. Please do not make such comments. What property do you think I want to keep? It seems you haven't read any of the above discussion, have you? The issue at hand is that, for some kinds of "books" and especially for their translations, we have no clearly defined model to work from, and so are trying to determine how best to proceed. Discussion above has indicated that no large-scale action be taken yet, because we're still deciding what action to take. Despite the ongoing discussion, and stated desire to hold off on enacting change, some editors are going ahead and making large-scale changes on their own without waiting for the discussion to conclude. But I am instead waiting to enact changes, and am trying to get this discussion to resolve some of the long-standing issues tied into this property. If you read all of the other discussion I've posted here, then that is what you'll find is going on. --EncycloPetey (talk) 03:18, 10 August 2017 (UTC)

What property do you think I want to keep?

original language of work (P364)

It seems you haven't read any of the above discussion, have you?

I read the entire PFD page carefully, that's the reason that I assume that you're edit-waring, as your edit comments like "consensus was to merge but NOT make changes yet" no longer make sense for me to still AGF

Discussion above has indicated that no large-scale action be taken yet, because we're still deciding what action to take.

There's already consensus to drop P364 even for that Danish user, your "aganist" is too late.

If you read all of the other discussion I've posted here, then that is what you'll find is going on.

By watching out the Special:CentralAuth/EncycloPetey, the 2 wikis that you are mostly editing are English Wiktionary and Wikisource, so can we concentrate on what's wrong within both English projects if one day we unfortunatelly deleted original language of work (P364), instead of discussing some random "large-scale changes" which you even did? --Liuxinyu970226 (talk) 03:39, 10 August 2017 (UTC)
@Liuxinyu970226: We are getting way off topic, so I'll be brief: You're wrong on almost every point or assumption you state above, including which projects I've edited mostly. (I've edited heavily on wikispecies, for example, but that project doesn't seem to appear in the data when I follow the link.) So, instead of trying to pick apart other editors, let's stick to discussing the issue at hand, please? --EncycloPetey (talk) 03:50, 10 August 2017 (UTC)

Let me clarify some things concerning "Digte 1906" Digte (Q23009890) as there seems to be some misunderstandings. I really like that particular book as a test bed for Wikidata modeling as this collection of poems is quite complex to model in any database: Some poems were originally written in Danish and first appeared in a novel and as such appear in the Digte 1906. Two poems where written in the Danish dialect "Jutlandic" they were first published in a novel that was part of a triology, the three parts of the triology were collected to one novel which was termed "Kongens Fald" (in Wikidata, we have a work item The Fall of the King (Q1758876) and some edition items no label (Q27655001) Kongens Fald, 1901 edition (Q34605018) and a edition with translation Kungens fall, 1906 (Q34607398)). This work contains body text in Danish, two poems in German, a bit of Latin text (if I recall correctly) as well as the two Jutlandic dialect poems. The two dialect poems are also published in the "Digte 1906" (perhaps with slight variation). The two dialect poems were put to music by Carl Nielsen and published in "Strofiske Sange Strofische Gesänge", a publication that contained the text in both Danish (including Jutlandic) and German (I believe a scanned copy is available somewhere on the Internet, but I cannot find it). Other poems in "Digte 1906" are translations from English to Danish. It is the three Whitman poems that Johannes V. Jensen translated. What further complicates matter is that "Digte 1906" which was actually called "Digte" was later extended a bit, then later extended yet again, extended and edited. The latest version was quite different for the 1906 version. Whether these new publications are new works or just new editions I really haven't come to any decision about. Through the 1900s the Digte 1906 gained a status of a classic so that the original "Digte 1906" where published as a new edition without the additions from the earlier versions! I do not think that "Digte 1906" has been translated in its entirety, but some individual poems exist in various translations. Sorry for this long and complicated explanation, but I invite interested Wikidata modellers to consider the works of Johannes V. Jensen, because the bibliography is so complicated, e.g., newspaper articles were turned into a poem and published in "Digte 1906", body text in a novel was turned (typoset) into a poem, etc. — Finn Årup Nielsen (fnielsen) (talk) 10:15, 8 August 2017 (UTC)

Thanks for this clarifications. My proposal how to deal with this case:
  • Digte (Q23009890) only contains texts in Danish and Jutlandig. So those should be the only values of language of work or name (P407). No other language statements or qualifiers should be added.
  • Since Digte 1906 is a collection of works, use has part (P527) to link to all poems resp. translated poems it contains.
  • Create for each translated poem an own item as well as for each original poem. On the item about the translated poem use language of work or name (P407) to indicate the language of the translation; on the item about the orignal poem use language of work or name (P407) to indicate the original language. The translated poem can be linked with the original poem with edition or translation of (P629).
  • published in (P1433) is used to show in which works a poem was published. This property can have many values. No distinction is made between the work in which the poem was first published and subsequent works.
  • If a poem was put to music, create an own item for the song and use based on (P144) to link the song with the poem.
  • If a work gets slightly extended, one has to decide if it's just a new edition or if it's a new work. No hard rule is applicable here. For a new edition, use edition or translation of (P629) to link to the original version. If you decide it is a new work, you can use instead based on (P144). --Pasleim (talk) 14:14, 8 August 2017 (UTC)
But what should be done if a translated poem has multiple editions? I'm seeking clarification regarding you point above:
Are we going to use edition or translation of (P629) on the translation and then edition or translation of (P629) again on the edition of the translation, so that we have an "edition or translation of an edition or translation"? And for each item in such a situation, what should be used for instance of (P31)? Current practice in this regard leaves much to be desired. And with regard to the issue of "original language", it means that we end up with a situation in which the "original" language is not one tier above the edition, but two steps back. And I have situations analogous to Digte in which I fear we would have three steps. How will those who are making use of the data going to know the "original" language when the information may be one, two, or three data items away instead of a consistent number? Without a specific property to identify the original language, what can we do to clarify that information for users of WD? --EncycloPetey (talk) 03:28, 10 August 2017 (UTC)
@EncycloPetey: Your comments here gave me those panoramas: We must discuss Park Geun-hye (Q138048) in conjunction with Kim Jong-un (Q56226) when talking about his policy (Q1156854) (really?), we must discuss John Cena (Q44437) in conjunction with Roman Reigns (Q275971) (2nd really?), we must discuss your heart in conjunction with automated external defibrillator (Q787407) (biggest REALLY?) mass edits can be happened in any conditions, and are those hurting you and you must "undo, revert, restore..."? e.g. Zhuyifei1999 made a large scale of recommendations to tool maintainers of our new Wikimedia Toolforge (Q36500248), so in your logic those recommendations must also be reverted? Anything is already big-rock-defined here. No more harassments to my Echo notifications, thx. --Liuxinyu970226 (talk) 15:05, 14 August 2017 (UTC)
@Liuxinyu970226: I do not understand how your examples or discussion pertains to the topic being discussed. Your response does not address or solve any issue under consideration, and only distracts from the core problem. I ask again to the community: How will those who are making use of the data know the "original" language when the information is not on the data item, and that information may be one, two, or three data items away (instead of a consistent number), and has no property or qualifier to identify the original language? Without a specific marker to identify the original language, what can we do to clarify that information for users of WD? --EncycloPetey (talk) 16:52, 14 August 2017 (UTC)
If you have a chain of 4 works/editions, how would you do it with the current system? We only have properties "language of work", "language of original work" but no property "language of original work of original work" and "language of original work of original work of original work". --Pasleim (talk) 17:54, 14 August 2017 (UTC)

Movies (or possibly Japanese animes)[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 data have to be saved in the more related item. These principles are 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)

If items are made for dubbing, this is the way suggested by WikiProject Movies. Please see the previous discussion on WikiProject Movies about this and the subsequent discussion at Wikidata:Bot_requests#Merge_of_.7B.7Bp.7C407.7D.7D_with_.7B.7Bp.7C364.7D.7D. This does not solve all other language issues for movies.

Further, you might have noticed at Wikidata talk:WikiProject Books, that the project didn't manage to implement the suggested scheme there either. Maybe it's either not suitable for Wikidata or users can't apply it. Maybe an action plan for WikiProject Books is needed before doing any merges on books as well.
--- Jura 10:44, 8 July 2017 (UTC)

Sorry, but I can't still see any problem. This series of edits and this discussion implies to me that there is a consensus regarding items for dubbed edition items. Please explain in detail to me as a non-involved person where you see problem. Matěj Suchánek (talk) 16:06, 9 July 2017 (UTC)
We don't create such items in general. It seems that even the person who first sought help on how to create one isn't actually interested, or, at least, isn't able to create any. I don't have any real explanation for this inability. Maybe you can help us? Is this a specific contribution pattern that should be investigated?
In general, the core of the information on films is held on the main item. This includes the original language and one or several other languages. In general, there can be several dubbings and subtitlings of films in one language, but they still share core elements of the film. Similarly, there is now the possibility to link several items about posters and scripts of the film.
The idea seems to have been to adopt a solution that is proposed for books, but it appears it isn't working there either, so maybe it's better to consider the outcome of this as potentially desirable for textual work, but currently lacking a practical migration plan. If you see one for books, I'd be interested.
--- Jura 17:07, 9 July 2017 (UTC)
We – who? Me either?
the person who first sought help – @Suruena: could you comment?
the core of the information on films is held on the main item – we aren't going to delete it, are we?
there can be several dubbings and subtitlings of films in one language – imagine having all of them stored in a single item...
it isn't working there either – where not?
Finally, do you have an example of item which would suffer from a significant (if any) data loss during the migration? Anyway, it sounds to me that you don't like the whole work-edition distinction, which was, however, approved in 2013. Matěj Suchánek (talk) 17:48, 9 July 2017 (UTC)
I think any item that currently has its original work language determined will suffer. Maybe the migration plan for books can help sort this out, but looking at what Wikidata:WikiProject Books does and how they implemented it, it's just .. maybe you should read what active participants there write about it. In any case, you are actually deleting information, if there is no clear plan where the same information will be held afterwards.
--- Jura 18:03, 9 July 2017 (UTC)
@Jura1: Can you give me a movie example which splitting is not possible? --Liuxinyu970226 (talk) 02:19, 10 July 2017 (UTC)
Looking only at items that use P31=film, there are currently about 200,000 of these with information about 470,000 different language versions. Some maybe up to 60 different ones. Obviously, we could created 270,000 new items, but these wouldn't be easy to maintain nor use by Wikipedia with the current tools. The confusion we currently have for books may spread further.
--- Jura 05:44, 13 July 2017 (UTC)
Could you please give a source for your numbers? So far I was assuming there are 189,000 movies with language information [2] holding information about 203,000 different language versions [3]. Those 11,000 items holding information about multiple languages [4] are typical movies produced in multiple languages e.g. Monty Python and the Holy Grail (Q25043). However, those do not suffer from the migration. --Pasleim (talk) 06:35, 13 July 2017 (UTC)
I may found an example that not suitable for splitting: Detective Conan (Q185143) (

Konggaru Starry K. Zerabat Erne Mogilevich Santer AldNonUcallinme? Thibaut120094 Shikeishu

Pictogram voting comment.svg Notified participants of WikiProject Anime and Manga for more help on it)

To the best of my knowledge, most of non-Japanese articles that linked by this item, are describing both Japanese and their dub works (*not only describing dubs in their own language, but also other lingua franca), so is it fairy to split it to 60 items? While it's technically possible, there will mostly have opposite voice from at least ja, ko and zhwiki as P407 value would be polluted. --Liuxinyu970226 (talk) 22:57, 14 July 2017 (UTC)
The statements on Q185143#P674 have up to four voice actor (P725) qualifier. How can you tell if that are voice actors of the original work or of a dubbing? How do you plan to add publisher, publishing date, original network, website and translator of the dubbings? With qualifiers some of the data could be stored. But qualifiers on qualifiers do not exist so you will never be able to add all information if you don't split the item. A Wikipedia article describing both the original and the dub work can stay on the current item. --Pasleim (talk) 20:15, 17 July 2017 (UTC)
Hello, Spanish Wikipedia user here. I'm not sure about the politics on different Wikipedias, I think the only thing I know is that in the English Wikipedia you use to translate the main article name to it's translation, in the case of Japanese animes and mangas (Blue Exorcist, The Qwaser of Stigmata, Attack on Titan, Future Diary, ...) but anything else. Talking about Wikipedia in Spanish, I'm truly not concerned about everything, because, for example, we keep the original Japanese titles on manga and anime articles, and in character names too, but there are cases in which, for some reason, the original name is replaced by a translated one (who the heck is Elsa Scarlet?), and that is defended by many users, some of them also participants of WikiProject Anime and Manga. I don't know if there will be a poll for using original names, but if so I'll be so happy, I've succeeded deleting that article for my memory, but every time I see things like Elsa Scarlet I got a mindblow and my body gets possessed. Ok, enough jokes, coming back to reality, there's also a lot of politics on Spanish Wikipedia concerning translations and original titles, for example, we use to keep the original name in its foreign language in movies, but for some reason we translate the title of books, so it's very confusing. --Erne Mogilevich (talk) 19:40, 20 July 2017 (UTC)

Pictogram voting comment.svg Comment Still I don't see serious difference between movies and books. We possibly need widget to create "prepare 30 editions please" and to fill "voice actor" "translator" details. This difficulty isn't unique to movies, but for popular books too (or anything somehow global). d1g (talk) 01:20, 23 July 2017 (UTC) Pictogram voting comment.svg Comment In contrast to this, films and books without separation in 30 item would be cluttered with qualifiers:

  • "applies to country"
  • "applies to language"
Which is way worse than to use separate items with direct statements. d1g (talk) 01:22, 23 July 2017 (UTC)
  • The current solution for films works, includes information about 500,000 language versions and can accommodate additional elements (as illustrated with dubbings, film posters etc.). Unfortunately, we still don't have a plan for books (see section above). We should probably just close the section about movies and, if ever a solution is found for books, rename the property to limit it to films.
    --- Jura 07:12, 23 July 2017 (UTC)
Symbol oppose vote.svg Oppose, see what Snipe said carefully " 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".
Language of creative works applies to many concepts, far beyond "books and/or movies"
It would be unproductive to create sets of specific properties for every of domain to perform same tasks.
@Jura1: please provide an example how movie would be different from book? Why separate items would be wrong for movies? This question was raised several times, please address it. d1g (talk) 04:08, 24 July 2017 (UTC)
The current solution for films works, but the one for books doesn't.
Maybe you can provide a set of working samples for books. This was raised several times, but we haven't seen any actual work, plan or status.
You mention elsewhere that we should follow some other website that would only have one for films, but they actually have three and they explicitly don't try to use their scheme. I don't quite see how the current approach doesn't allow you to map the properties to these three. If there are specific queries you have problems with, try Wikidata:Request a query.
--- Jura 07:08, 28 July 2017 (UTC)
  1. The current solution for films works
    under which signal system? NTSC (Q185796)? PAL (Q105973)? SECAM (Q223765)? Digital video recorder (Q865042)? Network Video Recorder (Q426040)? ...
  2. but we haven't seen any actual work, plan or status.
    Huh? There's no entity books in your neighborhood?
  3. but they actually have three and they explicitly don't try to use their scheme
    This could be intractable as I expanded this section to include ACG stuffs, but then your answer of "How can you tell if that are voice actors of the original work or of a dubbing?" from Pasleim is still missing, which could give me this daydream: the Marvel has actors from Cameroon from Tonga from Saint Helena... and they use Catalan use Faronese use Pitkern use Guarani... so they (the Marvel staffs) can re-use actors for all dubs of Captain America (Q190679) in all languages even some have ≤10,000 native users.

--Liuxinyu970226 (talk) 12:35, 28 July 2017 (UTC)

Also @Jura1: if you keep vote is having the reason of n/a (silent film) (Q21686005), then my answer is that I suggest to merge this item to language without language code (Q22283016) (ISO 639-3 mis). --Liuxinyu970226 (talk) 00:29, 8 August 2017 (UTC)

Specific movie example[edit]

How about considering A Fistful of Dollars (Q76479) as an example? The cast spoke Italian, German, and English, but the movie was filmed entirely without sound. The sound was dubbed on later. The movie was released in Italy first (in Italian), then in Germany, Spain, and other European countries, but did not have a US release until several years later. The US delay resulted from copyright issues because the Italian film was an adaptation of the Japanese samurai film Yojimbo (Q20475). So, what was the "original language" here? Do we need to have separate data items for every different language dub? Or how do we indicate that the movie exists in multiple language dubs? And do any of the languages get precedence or priority over others? --EncycloPetey (talk) 17:06, 14 August 2017 (UTC)

Every different language dub can get its own item, see Wikidata talk:WikiProject Movies/Archive 1#Dubbings. A list of properties you can use with dubbings you find on Wikidata:WikiProject Movies/Properties#Synchronisation. --Pasleim (talk) 17:51, 14 August 2017 (UTC)
  • Tricky question, still I think the current set of properties works generally fine for films. Maybe we could replace "work" with "film" in the label, once written works are sorted out. This would avoid creating additional properties, just to match some "schema".
    --- Jura 17:56, 14 August 2017 (UTC)
This still leaves the question of whether the main data item will have a language value. In this example, should the item for the work have no language at all, since every version of the movie was a dub? And if it has no language, then how do we mark the data item to keep editors from adding specific languages to the work instead of the data items for the individual dubs? --EncycloPetey (talk) 00:09, 15 August 2017 (UTC)
For Le Bal (Q1637024), I came to the conclusion that an item with "no dialogue" might be the most suitable one. Maybe a similar one could be made for Q76479.
--- Jura 06:41, 15 August 2017 (UTC)
...except that every released copy has dialogue. The problem is more general than just the one movie, since it is not always possible to pick out an "original" or "first" release of a film or publication. Even then, the "first" edition of any work is an edition and will be on a separate data item from the work itself. So, should we omit language properties from every work? and put them only on the editions / dubs? --EncycloPetey (talk) 13:44, 15 August 2017 (UTC)
I don't think you can use the same item as on Q1637024, but it should be possible make an item that describes it. As you mention, not all are straigthforward, but with the current two properties, I think we should be able to describe films. This without creating additional ones, just follow How is the situation for books evolving?
--- Jura 07:37, 17 August 2017 (UTC)
@Jura1: The two language properties uses for movies are and So is your suggestion to turn language of work or name (P407) into subtitleLanguage or what do you mean by "just follow"? --Pasleim (talk) 08:39, 17 August 2017 (UTC)
@Jura1: Please either elaborate what you meant with "just follow" or cross your statement out. --Pasleim (talk) 21:21, 25 August 2017 (UTC)
@EncycloPetey: Instead of omitting the language property for A Fistful of Dollars (Q76479), I would use the special value novalue since it's also an information that the movie was filmed without sound. --Pasleim (talk) 08:39, 17 August 2017 (UTC)

What about P2439?[edit]

If we go with P407, what should we do about P2439?

IMO one property for "language" should be enough.

Both P364 and P407 have millions of claims, it would more easier to move data to P2439 (with 3000 items - easy to check).

What should we do? d1g (talk) 01:07, 23 July 2017 (UTC)

See above (closed thread). Matěj Suchánek (talk) 07:01, 24 July 2017 (UTC)
P407 is unmatched with
  1. - domain Series
  2. - Used on these types CommunicateAction CreativeWork Event WriteAction
P2439 is the only options for properties above d1g (talk) 08:25, 24 July 2017 (UTC)
@D1gggg: You are just wrong: 1) we first have to solve the original problem with P407 and P364 so no need to speak about P2439. 2) then we can speak about P2439. Can you just once consider the number of use of P407 and P364 with the one P2439 ? Can you just think about the number of edit to do to transfer everything from P407 and P364 to P2439 ? Somebody who is smart can easily understand that replacing P364 by P407 (and changing the label of P407 with language) and then replacing P2439 by P407 will save a lot of modifications ? If you still don't understand, just calculate the number of modifications and find the one with the minimal amount of modifications. Snipre (talk) 19:07, 24 July 2017 (UTC)
@Snipre: I agree on 1, but 2: "replacing P2439 by P407" - what if we just keep P2439 for (creative works) and (events)?
I never argued for amount of minimal edits, but how things would be in final state.
At least part of discussion from 2014 argued to use "just language", so it should be P2439, not P407 "language of work".
Should we rename P407 to "language"? - I missed this part of discussion. d1g (talk) 20:26, 24 July 2017 (UTC)
It was proposed there. And please indicate where it is indicated that we need a different language for work and for event. Snipre (talk) 20:38, 24 July 2017 (UTC)
I agree with what is said in #Recipient; @Snipre: no, we don't need separate properties "for work and for event", but one property, like what does. d1g (talk) 20:45, 24 July 2017 (UTC)
I think they have three.
--- Jura 07:08, 28 July 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)
✓ Done Replaced by object has role (P3831) 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)
object has role (P3831) 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) ?
✓ Done Replaced by object has role (P3831) 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
sourcing circumstances (P1480) 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


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 [5]
  2. Usage of this property as a qualifier of main subject (P921) should be replaced by another value of main subject (P921)[6]
  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 :
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): 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:
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)
  • Symbol delete vote.svg Delete Too hard to translate in some asian languages. --Liuxinyu970226 (talk) 13:28, 27 May 2017 (UTC)
  • Without understanding all of the technicalities above, I thought of using this property to better reflect the parameter "founded" in some infoboxes. "inception (P571):1647" is not much of information actually. Was it then founded as a populated place, a village, a city with certain status or whatever? A single entity can be founded several times in that aspect. A city can be burned and founded again! I agree, that this is very difficult to turn into descent language, but I think it at least makes sense semantically. -- 16:14, 7 August 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)
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)

Pictogram voting comment.svg 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)

Symbol keep vote.svg Keep first flight (P606) and time of spacecraft launch (P619) because they have almost (or over) 5000 uses [7] [8]. 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)
Symbol delete vote.svg 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 [9] [10] [11]. 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)
Pictogram voting comment.svg 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)
  • Symbol keep vote.svg 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)

Symbol keep vote.svg 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.
< Honeycrisp (Q3140024) View with Reasonator View with SQID > start time (P580) View with SQID < ... >
location (P276) View with SQID < ... >
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)
Symbol delete vote.svg 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)
Symbol delete vote.svg Delete per El Caro's arguments --Hsarrazin (talk) 08:13, 25 August 2017 (UTC)
Symbol delete vote.svg Delete. Consistency is important. Storing data so many different ways makes it difficult to use. --Yair rand (talk) 23:40, 11 September 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) Imzadi1979 (talkcontribslogs) Jakec (talkcontribslogs) Legobot (talkcontribslogs) Liuxinyu970226 (talkcontribslogs) Ljthefro (talkcontribslogs) Puclik1 (talkcontribslogs) Rschen7754 (talkcontribslogs) (administrator) Scott5114 (talkcontribslogs) SounderBruce (talkcontribslogs) TCN7JM (talkcontribslogs) naveenpf (talkcontribslogs) Labant (talkcontribslogs) Gz260 (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) Imzadi1979 (talkcontribslogs) Jakec (talkcontribslogs) Legobot (talkcontribslogs) Liuxinyu970226 (talkcontribslogs) Ljthefro (talkcontribslogs) Puclik1 (talkcontribslogs) Rschen7754 (talkcontribslogs) (administrator) Scott5114 (talkcontribslogs) SounderBruce (talkcontribslogs) TCN7JM (talkcontribslogs) naveenpf (talkcontribslogs) Labant (talkcontribslogs) Gz260 (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)
Symbol keep vote.svg Keep, subtle differences, even though people do not use it properly. MechQuester (talk) 19:55, 16 June 2017 (UTC)
Symbol delete vote.svg Delete I think it would be helpful to have P276 qualifier in P559 - we have to use direction qualifier anyway. P609 is specific but adds no new information over P559 and P276. And we need to qualify P609 anyway using same qualifiers. d1g (talk) 05:47, 10 August 2017 (UTC) ID (P3269)[edit] ID (P3269): (delete | history | links | entity usage | logs | discussion) was created as a spin-off of RKDartists ID (P650). The ID (P3269) and RKDartists ID (P650) id's are exactly the same. This turned out to be a temporary project. The website at 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, at least until the same information from that archived page is actually also available elsewhere. The 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 I therefore suggest to keep the property and change the formatter URL to*/$1
Examples for checking that indeed had more information:
Pictogram voting comment.svg Comment The '' URL at Internet Archive gives better results than the '' 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 pages. Spinster 💬 17:17, 15 April 2017 (UTC)
  • keep per Spinster (but do not delete values for pages not archived by; other arhcives may exist). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:48, 12 May 2017 (UTC)
  • Pictogram voting comment.svg Comment We have archive URL (P1065) for linking to archived pages. If the outcome is to keep the property, I think adding qualifiers for known archived pages would be better than changing the formatter URL. - Nikki (talk) 17:37, 9 August 2017 (UTC)


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)
I also have to say Symbol keep vote.svg Keep:
  • I don't think it's clear what is intended to happen if we were to decide on "delete". Some people are talking about how to store the data (whether to keep this property or use different ones), other people are talking about whether to keep the existing data for this property, and I wouldn't be surprised if someone started talking about whether we want to store this data at all.
  • Unless we decide we do not want to store this data at all, the data will need checking at some point. If we delete what we have and start again, it will need checking as it's re-added, therefore I don't think deleting it is very productive. We should focus instead on finding ways to verify what we have and what people will add in the future.
  • It shouldn't be that hard to check the labels, identify which ones need fixing and then ping speakers of those languages.
  • As for the data, I'm only familiar with Germany and the UK (which happen to account for over half of the uses of this property). Information about German stations is available as open data and the National Rail site has maps of UK stations so the data for those two shouldn't be difficult to verify (although maybe a bit tedious if it can't be automated). Other countries may have similar resources available.
  • I think you are probably overestimating the scale of the problem. I would expect the majority of stations to be small and straightforward stations which produce the same number whether you're counting the right thing or not (e.g. single track plus single platform or two tracks plus two side platforms). In the UK, smaller stations with islands are likely to accidentally produce the right number too. In Germany, it's normal to talk about tracks rather than platforms, so those are also likely to be correct.
- Nikki (talk) 09:23, 7 June 2017 (UTC)
@Nikki: So how do we actually fix those error values? Do you have a line map on it? --Liuxinyu970226 (talk) 05:27, 19 June 2017 (UTC)
@Liuxinyu970226: Sorry, I got halfway through replying before being distracted by other things. I would propose the following:
  1. Wait for this discussion to be closed (if the decision is to delete it, there's no point trying to fix it).
  2. Check and fix the labels and descriptions on the property. This could be done by creating a new section on the property talk page and pinging speakers of those languages. If there are any which can't be verified after a period of time, remove those until someone who speaks the language can check/fix them.
  3. Check the existing statements with references to make sure those are correct (there aren't many, from what I remember).
  4. Find sources we can use to check the rest of the statements. I already mentioned knowing of sources for the UK and Germany. Italy is the next biggest one.
  5. Check the statements against the sources and add references to the ones which have been verified. How we check the data depends on the sources, some can be automated, others will have to be done by hand.
  6. Decide what to do with the statements which can't be verified.
  7. Not really 7th, it can be done at any point: Discuss somewhere else (on Wikidata:WikiProject Railways?) other ways of counting and how we should model those.
Since my last comment, I've checked most of the UK ones. Over 1500 are correct and about 100 need further investigation for a variety of reasons (not all of them are wrong). I'm not sure how to add the references though, I think it might need a bot. - Nikki (talk) 10:03, 10 July 2017 (UTC)
@Nikki: For China, #4 could be very hard to define because of my comments below. --Liuxinyu970226 (talk) 13:36, 10 July 2017 (UTC)
@Nikki: Note that even stations in London can also have confusing values on platform e.g. London Waterloo station (Q795691)
  1. cs:Waterloo (železniční stanice) - Nástupišť (hran): 20 (+4 neužívaná)
  2. cy:Gorsaf Waterloo Llundain - Nifer o blatfformau: 19
  3. da:Waterloo Station - Perronspor: 19
  4. en:London Waterloo station - Number of platforms: 24 (22 in use) (you say that 22 is "correct")
  5. fi:Waterloon rautatieasema - Raiteisto: 24 laituriraidetta
  6. fr:Gare de Londres Waterloo - Voies: 19
  7. he:תחנת ווטרלו - רציפים בשימוש: 22
  8. hu:London Waterloo pályaudvar - Vágányok száma: 22
  9. ja:ウォータールー駅 - ホーム数: 20
  10. ka:ვატერლოო (მეტროსადგური) - პლატფორმების რაოდ.: 8
  11. nl:Station London Waterloo - Perrons: 20
  12. no:Waterloo stasjon - Plattform(er): 19
  13. pl:Waterloo Station - Liczba peronów: 19
  14. pt:Estação Waterloo - Plataforma: 20
  15. ru:Лондон-Ватерлоо (станция) - Количество платформ: 24
  16. simple:Waterloo station - Number of platforms: 20
  17. sk:Waterloo (železničná stanica) - Počet nástupíšť: 19
  18. sv:Waterloo Station - Antal spår: 20 (+4 oanvända)
  19. tr:Waterloo İstasyonu - Platformlar: 24
  20. uk:Ватерлоо (вокзал) - Кількість платформ: 19
  21. zh:滑鐵盧車站 - 站台數: 24(22個使用中)

--Liuxinyu970226 (talk) 23:30, 14 July 2017 (UTC)

@Liuxinyu970226: Some cases are more complicated and will need qualifiers. I didn't say that 22 is the right number, it's one of the ones which needs more investigation. It seems that 19 and 24 are correct for the total number (at different times), 19, 20 and 22 are correct for the number in use (at different times) and the sitelink for kawiki was on the wrong item. - Nikki (talk) 10:41, 15 July 2017 (UTC)
@Nikki: Unfortunatelly your solutions haven't explain what to do for Spanish solution (Q1342434), that's my key concern. In Spanish solution (Q1342434) stations, the "physical" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different. So. e.g. which should be the "correct" value of Changhua Station (Q5071979)? 5? But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of "5" is unavailable. 3? that's number of tracks, and one of "3" is available for two lines. 4? So articles in all 3 languages are saying wrong values. --Liuxinyu970226 (talk) 08:35, 31 July 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)
@Srittau: I'd personally prefer to have separate properties for the seven or so ways to count platforms, but the problem remains that this property is not defined correctly in all languages and the data is inconsistent. If the property is to be kept, the data should ideally be reviewed (or wiped and re-imported) for each rail system where the property is in use. Jc86035 (talk) 09:46, 24 May 2017 (UTC)
@Srittau, Jc86035: anyway, the de facto usage of this property on stations of China is also confusing due to local usage of Template:Infobox China station (Q14446899) where:
|月台数目=(車站側式月臺的數目,此參數可選)//physically numbers of Q2735706+Q2725290, but document says only Q2735706
|侧式站台=(車站島式月臺的數目,此參數可選)//numbers of Q2735706, but document says Q2725290, and even in case of Q2735706 this is also including Q877472-like cases
|岛式站台=(車站月臺面的數目,此參數可選)//numbers of Q2725290, but document says "platform faces", and even in case of Q2725290 this is also including Q877472-like cases
|站台面=(車站月台的數目,此參數可選)//numbers of "platform faces" (where's the item of this concept?), but document says Q2735706+Q2725290

--Liuxinyu970226 (talk) 01:31, 30 June 2017 (UTC)

Also, this property should NOT be used at stations of Singapore and Malaysia (at least until the fully solutions of platform-related property usage is documented) because of the significant huge number of Spanish solution (Q1342434) usage. --Liuxinyu970226 (talk) 01:41, 30 June 2017 (UTC)

Multichill (talk) Thryduulf (talk) 21:38, 2 November 2013 (UTC) -revi (talkcontribslogs)-- 01:13, 3 November 2013 (UTC) (was Hym411) User:JarrahTree (talk) 06:32, 3 November 2013 (UTC) A.Bernhard (talk) 08:28, 9 November 2013 (UTC) Micru (talk) 12:36, 9 November 2013 (UTC) Steenth (talk) YLSS (talk) 13:59, 25 November 2013 (UTC) Konggaru (talk) 12:31, 14 December 2013 (UTC) Elmarbu (talk) 21:48, 17 December 2013 (UTC) Nitrolinken (talk) 16:30, 14 February 2014 (UTC) George23820 Talk‎ 17:39, 17 August 2014 (UTC) Daniele.Brundu (talk) 21:34, 30 August 2015 (UTC) Dannebrog Spy (talk) 16:13, 9 December 2015 (UTC) Knoxhale 18:39, 26 June 2016 (UTC) happy5214 22:48, 8 July 2016 (UTC) Jklamo (talk) 07:32, 15 August 2016 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits DarTar (talk) 16:36, 5 September 2016 (UTC) Pizza1016 (talk | contribs) 01:33, 10 November 2016 (UTC) Sascha GPD (talk) 23:00, 1 February 2017 (UTC) Liuxinyu970226 (talk) 09:09, 2 February 2017 (UTC) A1AA1A (talk) 18:17, 21 May 2017 (UTC) Mauricio V. Genta (talk) 13:56, 9 June 2017 (UTC) Sam Wilson 10:26, 18 June 2017 (UTC) Danielt998 (talk) 05:01, 28 August 2017 (UTC) Pictogram voting comment.svg Notified participants of WikiProject Railways --Liuxinyu970226 (talk) 10:11, 4 July 2017 (UTC)

  • Delete or deprecate. It's not defined which of the many ways of counting platforms this is intended to represent, nor which of these ways any current use is using. This means we can't correct the data as we don't even know what is correct, and even if we do decide on a definition there will be no way of verifying whether uses are correct to it without manually looking at plans of the given station - which has no benefit over entering data afresh. Thryduulf (talk) 21:15, 7 July 2017 (UTC)
  • Pictogram voting comment.svg Comment seems trivial, but each time I looked into this, it left me puzzled. Maybe criterion used (P1013) as qualifier is needed to state how one counts.
    --- Jura 10:23, 8 July 2017 (UTC)
  • Symbol keep vote.svg Keep Surely there is a confusion between number of platform tracks and number of platforms (even translations of criterion used (P1013) are inconsistent), but in my opinion the solution is to create new number of platforms property and clarify existing data. Both concepts are widely used in transport-related infoboxes in various languages.--Jklamo (talk) 14:49, 12 July 2017 (UTC)
    @Jklamo: Translations confusion can be minor issues, but sometimes it can be border than this problem, see e.g. Beijing West Railway Station (Q523887):
I added number of platform tracks (P1103)  South America (Q18) (the value of "站台面") in the last year before something wrong, where @Jc86035: said:
Symbol oppose vote.svg Oppose Per above, this property is already existing, you might want to request another property for the number of physical platforms. --Liuxinyu970226 (talk) 09:01, 2 February 2017 (UTC)
@Liuxinyu970226, Pasleim: Updated the proposal to be for number of platform faces; Property talk:P1103 should be updated because it still refers to "number of platforms".did not realize data was taken from en-gb labels Jc86035 (talk) 08:14, 4 February 2017 (UTC) Jc86035 (talk) 14:54, 2 February 2017 (UTC)
So I changed to Symbol support vote.svg Support, thx for patches of properties. --Liuxinyu970226 (talk) 13:30, 3 February 2017 (UTC)
@Jc86035: However, I'm afraid that I already typed the values of "站台面" as P1103 value, so am I wrong now? Should I use "站台数目" instead now? --Liuxinyu970226 (talk) 13:51, 3 February 2017 (UTC)
@Liuxinyu970226: I think so, yes. Jc86035 (talk) 08:17, 4 February 2017 (UTC)
Then I changed the value to 10 which means "站台数目", however when I saw other languages:
  1. de:Peking Westbahnhof - Bahnsteiggleise: 18 Bahnsteige
  2. en:Beijing West Railway Station - Platforms: 10
  3. es:Estación de Pekín Oeste - Plataformas: 10
  4. hu:Peking Nyugati pályaudvar - Vágányok száma: 10
  5. ja:北京西駅 - ホーム: 10面20線 島式ホーム2面4線(地下鉄)
  6. pl:Pekin Zachodni - Liczba peronów: 10, Liczba krawędzi peronowych: 18
  7. sv:Pekings västra järnvägsstation - Antal spår: 20, Nivåer: 4
  8. zh:北京西站 - 股道数目: 20, 站台数目: 10个, - 侧式站台: 2个, - 岛式站台: 8个, - 站台面: 18个
(note that huwiki 10 is because of my value changing) But if following the newest meaning of P1103 (number of tracks served by a platform at a railway station) it really should be 18 psst. should be 22 as 18 (for CR(H?)) (should not be 20 because 2 tracks of this station are headshunt (Q784358)) + 4 (for Beijing Subway). --Liuxinyu970226 (talk) 02:36, 14 July 2017 (UTC)
Symbol delete vote.svg Delete, per Liuxinyu970226, platform counting styles can always be different between countries, so this property can't reflect all countries. -- 09:00, 29 August 2017 (UTC)


geo datum (P796): (delete | history | links | entity usage | logs | discussion)

Use relative to (P2210). GZWDer (talk) 16:21, 25 June 2017 (UTC)

no label (Q29043286) shouldn't use "geo datum", but P2210 "reference point".
Most users don't know what Geo datum is.
Most users only need one datum in their life World Geodetic System (Q215848). d1g (talk) 12:19, 30 July 2017 (UTC)
Geodatums should be where they make sense the most (e.g. geopoint properties, geoshape properties). d1g (talk) 12:21, 30 July 2017 (UTC)

no label (P3688)[edit]

BVMC place id (P4098)[edit]

BVMC place id (P4098): (delete | history | links | entity usage | logs | discussion)

All the values for this property are simply GeoNames ID (P1566).

The original proposer has already been contacted about this. Personally, I would like Wikidata to support auto-derivative properties at its technical level; however, as this feature is still not available, editors have been avoiding this kind of (duplicate) properties until now. --abián 21:17, 22 July 2017 (UTC)

Symbol delete vote.svg Delete duplication. - yona b (talk) 05:04, 23 July 2017 (UTC)
Symbol keep vote.svg Keep we need custom formatter URL.
We don't have another property or alternative way to get custom URL for specific items from Geonames
1000 values are harmless, even if duplicates d1g (talk) 06:58, 23 July 2017 (UTC)
Symbol delete vote.svg Delete we have third-party formatter URL (P3303) for 3rd party formatters.--GZWDer (talk) 14:28, 24 July 2017 (UTC)
Symbol delete vote.svg Delete per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:49, 25 July 2017 (UTC)
Pictogram voting comment.svg Comment The problem with third-party formatter URL (P3303) is that most of the time the third party does not use all the identifiers available in the first database and we have no way to know this before we actually click on the link and discover this very one is not covered. With this in mind, I've come to believe that third-party formatter URL (P3303) in its current form is a bad thing, and that we should have a standalone property every time the formatter URL varies, even when most of the IDs it points to are shared. Thierry Caro (talk) 00:59, 7 August 2017 (UTC)
Symbol keep vote.svg Keep per this comment. - Nikki (talk) 17:30, 9 August 2017 (UTC)
Symbol keep vote.svg Keep I'd say keep for now. I agree with Thierry Caro third-party formatter URL (P3303) is not a solution.
This thing worries me, for example, with Directory of Open Access Journals (Q1227538), as the "identifier" there is the ISSN (P236): example. A way of storing this data (that journal being indexed there) is using catalog (P972)->Directory of Open Access Journals (Q1227538) (see Anuario de Estudios Medievales (Q15751449)).
But "catalog (P972)->invalid ID (Q-BVMC place "catalog" item)" would be kind of a reach, so P972's scope would need somehow to be expanded.. And after we wouldn't even have a "click-able link" here.
Anyway, if we are gonna have these properties, a specific constraint like «if P4098 exists, then its value has to be equal to P1566's»... would be nice. Strakhov (talk) 17:56, 9 August 2017 (UTC)
I don't think it can be done with normal constraints right now, but it would be easy to do with a complex constraint, using something like this query. - Nikki (talk) 10:21, 25 August 2017 (UTC)
Symbol keep vote.svg Keep per Thierry Caro too, @GZWDer: the property that you suggested, third-party formatter URL (P3303), should be the actual property for deletion as its value can be confusing. --Liuxinyu970226 (talk) 01:12, 28 August 2017 (UTC)

Note that, in this case, the issue exposed by Thierry Caro doesn't apply. The BVMC lets you use any identifier available in Geonames (example, example) and retrieves the information on the fly. However, all your comments are being very enriching, thank you! --abián 18:27, 2 September 2017 (UTC)


mandatory qualifier (P1646): (delete | history | links | entity usage | logs | discussion)

Not used in documentation and succeeded by property constraint (P2302). GZWDer (talk) 17:01, 23 July 2017 (UTC)

Symbol delete vote.svg Delete Per Property talk:P1646#Convert to new scheme and delete. Matěj Suchánek (talk) 10:16, 29 July 2017 (UTC)
Symbol delete vote.svg Delete in order to maintain only one property (property constraint (P2302)) for all constraint-related questions.
P1646 can be derived from P2302. d1g (talk) 12:34, 30 July 2017 (UTC)
Migrate and then Symbol delete vote.svg Delete. --Yair rand (talk) 23:36, 11 September 2017 (UTC)
Migrate and then Symbol delete vote.svg Delete. --Marsupium (talk) 12:53, 15 September 2017 (UTC)


Wikimedia username (P4174): (delete | history | links | entity usage | logs | discussion)

Lack of consensus for creation at Wikidata:Property proposal/Wikimedia user name. --- Jura 03:18, 25 August 2017 (UTC)

  • Symbol delete vote.svg Delete "note that you may be blocked from editing WMF sites, if you add this property to an item about somebody else than yourself". -- Innocent bystander (talk) 06:58, 25 August 2017 (UTC)
  • Symbol delete vote.svg Delete - created while several unresolved Symbol oppose vote oversat.svg Strong oppose - real problem with --Hsarrazin (talk) 08:07, 25 August 2017 (UTC)
    • There were no "unresolved" opposes; the opposition based on WMF privacy policy was addressed and refuted: the data was already held using website account on (P553); the new property makes it easier to monitor such use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:04, 26 August 2017 (UTC)
  • Symbol keep vote.svg Keep Otherwise items like Shi Zhao (Q9147313) will be nonsense. --Liuxinyu970226 (talk) 13:33, 25 August 2017 (UTC)
    Also ping supporters @Thierry Caro, NMaia, Tubezlob, Mahir256, VIGNERON:@Mr. Ibrahem, Sadads, OwenBlacker: --Liuxinyu970226 (talk) 13:39, 25 August 2017 (UTC)
  • Symbol keep vote.svg Keep. But delete the warning message. There is no reason to have for Wikimedia a special policy that we don't have for Facebook or Instagram. Thierry Caro (talk) 13:41, 25 August 2017 (UTC)
  • Symbol neutral vote.svg Neutral this property shouldn't have been created until a consensus had been reached on how to use it but now that is has been created, I see no real reason to delete it. PS: I have no illusion, the property is not really the issue here, with or without this property, the exact same data can, were and will be stored (prior to this property creation there was already a hundred of wikimedia user name store in various ways). Cdlt, VIGNERON (talk) 13:44, 25 August 2017 (UTC)
  • Symbol keep vote.svg Keep per my arguments made in the creation conversation — not least that the information is already held; at least this way it can be monitored more sensibly. — OwenBlacker (talk) 13:56, 25 August 2017 (UTC)
  • Symbol keep vote.svg Keep. Arguments of Thierry Caro are right: there is no difference between a Wikimedia username and an other username in an other website (for example Twitter, where a lot of people also use a pseudonym). Tubezlob (🙋) 15:18, 25 August 2017 (UTC)
    • Are you saying that you wont be respecting WMF policies even in fields where it's applicable?
      --- Jura 15:34, 25 August 2017 (UTC)
    • oh yes, there is an enormous difference - on Facebook, you have to use your real name (per FB rules) ; there is NO privacy of FB, per FB rules - on wikimedia, there is an official Privacy policy !! - it is totally different --Hsarrazin (talk) 22:50, 25 August 2017 (UTC)
      • I challenged you in the property proposal to cite any part of WMF policy which means we can't have this property. You failed to do so. You cannot do so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:39, 26 August 2017 (UTC)
  • Symbol delete vote.svg Delete: I'm really worried about the privacy part. If people keep adding sexual orientation (P91) and ethnic group (P172) without source, who says they will do it for this one? Our policies and tools are not good enough for something like this. Attempts to get better policies were useless so far. Sjoerd de Bruin (talk) 17:12, 25 August 2017 (UTC)
  • Symbol delete vote.svg Delete useless with current "usage instructions". Encouraging users to create items about themselves is not a good idea.--Jklamo (talk) 21:05, 25 August 2017 (UTC)
  • Symbol keep vote.svg Keep without this property, the data just gets stored in website account on (P553)/website username (P554). For privacy concerns, this doesn't make any difference. --Pasleim (talk) 21:15, 25 August 2017 (UTC)
    • After this is deleted, I don't think it should be stored with that property. Already now, some seem to have used that other property as a way to circumvent as creation of this property was refused due to privacy concerns before.
      --- Jura 10:52, 26 August 2017 (UTC)
      @Jura1: I guess the Template:Connected contributor (Q7646869) template should use this property? So let's withdraw so-called "privacy" problems. --Liuxinyu970226 (talk) 02:52, 28 August 2017 (UTC)
  • Symbol keep vote.svg Keep As every properties, this one is intended for public and referenced information. If it used differently, we have a policy for the disclosure of non-public personal information (with oversighters to remove such data and administrators to ban transgressors). As noticed by VIGNERON, this property allows to store Wikimedia usernames in a single place, making possible to monitor and detect bad usage much more easily than the actual situation. I also agree with Tubezlob: Wikimedia usernames don't differ from Twitter username (P2002) or Instagram username (P2003), and I see no one stating that they were created to doxx Twitter and Instagram users... -- Envlh (talk) 21:33, 25 August 2017 (UTC)
  • Symbol keep vote.svg Keep per many of the above. Furthermore, this property passed a property proposal in the last few days. PfD should not be used to circumvent that process; the claim of "lack of consensus " is false. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:43, 26 August 2017 (UTC)
    • Well, that "it passed a property proposal" is a strongly disputed claim here. -- Innocent bystander (talk) 10:42, 26 August 2017 (UTC)
      • That it passed a property proposal is an undisputable truth. The claims that it should not have done so are far from "strong", and have no merit. They're made by the original objectors, who aren't happy at being in the losing minority - but the proposal was closed by a neutral admin. Even if the admin was at fault, then the avenue for remedy would be the Admin Noticeboard (or Project Chat), not PfD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:36, 26 August 2017 (UTC)
  • Symbol keep vote.svg Keep - the arguments on the property proposal page against this were unconvincing, as the concerns could be solved with policy and simple queries to keep things in check. We should not be outright deleting a property because it might be a problem, when the utility is clearly demonstrated. -- Fuzheado (talk) 13:48, 26 August 2017 (UTC)
    • @Fuzheado: could you demonstrate such a simple query that would "keep things in check"?
      --- Jura 14:12, 26 August 2017 (UTC)
  • wrt to this thing being the same as twitter or facebook or instagram, it is an undisputable truth in those social networks users can protect their accounts with a lock, not allowing common people to scrutinize their actions, pictures or vapid fantasies. In Wikimedia projects all your contributions are open, with the exact time you saved them, every topic, every comment in every discussion. We even offer tools to stalk user's edits. And it's not possible to hide any of that under a little tiny lock. It's not even possible to delete your account here. It's not exactly the same. Strakhov (talk) 23:38, 26 August 2017 (UTC)
    • thanks Strakhov, this is exactly the problem : this makes too easy scrutinizing edits of a user, by persons who, without this property, would not be able to link the username to the real-life identity… only voluntary disclosure by concerned users should be allowed to avoid risks for contributors in their private and/or professional life --Hsarrazin (talk) 17:14, 28 August 2017 (UTC)
  • Symbol keep vote.svg keep as any personal identifier it makes no sense to allow home page, but prohibit social media accounts (incl this). Personal web pages are not replacement to other accounts (e.g. youtube cannot replace homepage and vice versa).
We could improve any description in order to follow any policy - it is strange to remove property. d1g (talk) 04:20, 27 August 2017 (UTC)
Pictogram voting comment.svg Comment many lawbreaking things could be entered in Help:Description - should we remove them?.. Please don't make this slippery slope argument every time. This is not specific to properties or even specific property. d1g (talk) 04:37, 27 August 2017 (UTC)
  • Symbol delete vote.svg Delete until issues on "only the account owner is able to..." are resolved. We are not in a hurry, since people willing to disclose their Wikimedia alias already discovered how to store this data circumventing previous refusal and, after all, there are not so many legitimate uses. Strakhov (talk) 11:12, 27 August 2017 (UTC)
  • By the way, our labour here is about constructing a collaborative database, not losing or winning proposals. Strakhov (talk) 11:19, 27 August 2017 (UTC)
  • Pictogram voting comment.svg Comment First, I'd like to see a comment from WMF's legal staff or quotation of privacy policy that states that this property should not exist. Second, this property had actually existed as website account on (P553)/website username (P554) before this one was created, so in my opinion there didn't have to be any discussion about its existence. Matěj Suchánek (talk) 16:47, 27 August 2017 (UTC)
    @Jalexander-WMF: Would you be able to have an official viewpoint from WMF from the appropriate staff member? Thanks.  — billinghurst sDrewth 03:59, 28 August 2017 (UTC)
    Also @Mdennis (WMF): the leader of m:Support and Safety. --Liuxinyu970226 (talk) 09:59, 28 August 2017 (UTC)
    Maggie and I have talked (and consulted with legal) and while we don't believe it is a violation of the Privacy Policy (and so wouldn't try to block it etc) we do note that it does have the potential of being used for harassment or outing (in violation of the Terms of Use) if done without the blessing of the user involved and/or when it isn't pubic knowledge. There are lots of users who are very public with the fact that they are the same person who an article is about (hence the existence of well used talk page templates or user boxes) but it can also be a problematic thing if they're trying to preserve their privacy online like many of us try to do. Jalexander-WMF (talk) 22:47, 29 August 2017 (UTC)
  • Symbol keep vote.svg Keep: I'm for keeping it, but to use it only when a profile page on any Wikimedia project already discloses this information. This profile page should then be added as reference URL. -- Maxlath (talk) 15:06, 28 August 2017 (UTC)
  • Symbol keep vote.svg Keep if a bot can actively revert all changes involving this property by non-autoconfirmed users (on the assumption that all autoconfirmed users are aware of and adhere to the WMF's privacy policy). Mahir256 (talk) 16:15, 28 August 2017 (UTC)
  • Symbol keep vote.svg Keep property similar to properties for other social network. Same policy should be applied. Pamputt (talk) 16:30, 28 August 2017 (UTC)
  • Symbol keep vote.svg Keep We have properties for user accounts on other sites that are less relevant than Wikimedia.--Micru (talk) 17:47, 28 August 2017 (UTC)
  • Symbol keep vote.svg Keep per @Thierry Caro, @Pasleim and @Envlh. --Waldir (talk) 08:19, 29 August 2017 (UTC)
  • Symbol keep vote.svg Keep Wikidata has many properties for things that count as sensitive personal data: birth date, gender, sexual orientation, union membership and online account are examples. A breach of privacy comes when people use these inappropriately, adding speculative or inappropriately obtained data. The fact that Wikidata can represent such data is not the fault. Hence it is a fallacy to argue against the existence of the property on grounds of possible misuse. None of the arguments for removal seem solid. MartinPoulter (talk) 14:07, 29 August 2017 (UTC)
  • Symbol keep vote.svg Keep. Valid identifier with unique values. Deryck Chan (talk) 21:11, 18 September 2017 (UTC)

Foursquare username (P4205)[edit]

Foursquare username (P4205): (delete | history | links | entity usage | logs | discussion)

Hi. I did not pay attention when I proposed this property but it seems it is a duplicated property of Foursquare venue ID (P1968).--Pamputt (talk) 05:16, 8 September 2017 (UTC)

Symbol delete vote.svg Delete sorry from me too, I'm a bit new to property creation and didn't check this one well enough. --99of9 (talk) 09:12, 8 September 2017 (UTC)
A little Symbol keep vote.svg Keep, shouldn't this for personal detail like ? --Liuxinyu970226 (talk) 23:34, 8 September 2017 (UTC)
Ah! Indeed, it could be used from user. Pamputt (talk) 11:50, 10 September 2017 (UTC)
@Pamputt: Well, my comment above in theory shouldn't be a reason to withdraw this pfd, since I still don't see how an example could be happened, really the 4sq staffs should consider a better way to search *public* user details. --Liuxinyu970226 (talk) 05:50, 18 September 2017 (UTC)