Open main menu

Wikidata β

Wikidata:Properties for deletion

This is the page for requesting the deletion of a property (for items, with IDs beginning with "Q", please use requests for deletions). To nominate a property for deletion, complete the following steps:

  • Place the {{Property for deletion}} template on the property talk page.
  • Open the discussion on this page under the "Requests" section below.
  • Notify the user who originally proposed the property and the property creator for it on their respective talk pages.
  • Validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is, leave a message in Village pump of the project.

Requests may be closed after 7 days, but may be extended if consensus is not reached. If 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.



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


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 (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 worksEdit

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 [3] holding information about 203,000 different language versions [4]. Those 11,000 items holding information about multiple languages [5] 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 C933103 Sight Contamination

  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)

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

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)
@Jura1: You still advertise P364 here by so-called "keeping 3 properties", so-called "it's better to create dummy items for your special cases instead of system-provided no value", so-called "good for films", and so-called "partially deprecated"... I would rather simply ask you again: why you're still keeping it? User friendly in which signal system world? NTSC? PAL? SECAM? Or some of DVRs? Of NVRs? --Liuxinyu970226 (talk) 15:35, 22 September 2017 (UTC)

Moving forward and alternative proposalEdit

@Jura1, Matěj Suchánek, Snipre, Liuxinyu970226, EncycloPetey, Fnielsen: Consensus was reached to merge original language of work (P364) and language of work or name (P407) and decision was made that original language of work (P364) will be deleted. Many subsequent discussions were held. However, some objections were raised without providing any concrete arguments ("movies need to language properties"), in some other discussions problems were brought up which will not be new with merging but already exist now, e.g. how to deal with translations that have intermediary translations. The only unresolved problem is how to deal with items containing data about both work and edition. Based on that I would like to propose the following procedure for merging:

  • move P364 statement to P407 if no P407 statement is on the item
  • delete P364 statement if it is equal to the P407 statement
  • if a book item has P364 and P407 statements but their values differ, check manually if the items contains data about both work and edition and if necessary create new items to follow the guidelines on Wikidata:WikiProject Books.

The last step does not have to be considered for movies since no movie item has conflicting P364 and P407 values [6]. Before merging starts, it will be announced on WD:Status updates/Next and after merging, help will be provided to Wikipedia and sister projects to adapt their templates. --Pasleim (talk) 20:34, 26 September 2017 (UTC)

As before, this proposal doesn't deal with the problem of books that are/contain translations for which no "original" work item can exist. G. M. Cookson's Four Plays of Aeschylus Four Plays of Aeschylus (Q26710829) is not a work, it is a translation (which Wikidata combines with edition). But no original "work" item of those four plays ever existed. So we have no possibility of indicating derivation.
Also as before, no provision exists for parallel texts, where both an edition of a work and a translation of a work are included in the same volume.
This doesn't look so much like an alternative proposal as merely a restatement of the same proposal with more specific details. --EncycloPetey (talk) 22:04, 26 September 2017 (UTC)
This propsal does deal with these problems. It states that such items will be checked manually and edited according to the guidelines on Wikidata:WikiProject Books. In previous proposals this manual part was missing and it was suggested to do everyting programmatically. --Pasleim (talk) 22:30, 26 September 2017 (UTC)
Fine for me. Just a last question: what's about the label of language of work or name (P407) ? No need of solving that question now but I think that changing "language of a work or name" to "language" will simplify the problem. Snipre (talk) 22:50, 26 September 2017 (UTC)
@Pasleim: No, this proposal doesn't deal with those problems, and your last claim is not what the proposal says. The "new" proposal only makes provision for creating new items to follow the guidelines on Wikidata:WikiProject Books. It does not deal with existing items. Further, WikiProject Books does not currently have guidelines in place to deal with either of the situations I have described. Hand-waving and passing the buck are not solutions. I see no concrete solution that has yet been proposed for cases such as those I have raised, nor for similar situations. --EncycloPetey (talk) 00:00, 27 September 2017 (UTC)
@EncycloPetey: Wikidata:WikiProject Books provides principle and not a solution for every special case. Instead of claiming that nobody is giving the solution you need please try to show by applying the principle of work/edition that this system is not able to answer the cases you raised.
And I already provided some solutions for at least the first of your case: a compilation of original texts or translated texts is de facto a work. Four Plays of Aeschylus (Q26710829) is an edition and an additional item for work has to be created even if only one edition of this book exists. The item defined as work of Four Plays of Aeschylus (Q26710829) is a work composed of 4 other works and the characteristic allowing to consider the compilation of the 4 texts as work is the choice of selecting the 4 texts and to create a new text composed of 4 others.
Then for the second case, I don't see a problem: as you mentioned, wikidata considers translation and edition in the same manner. So in your case what prevent you to define the item containing an original text and its translation as an edition/translation with two languages, the original language and the translation language ? It would be a problem if WD was considering edition and translation as different types of documents (but even in that case we could create a new class) but this not the case.
The only problem we have to solve is to be able to link the different translations/editions by additional properties in order to provide more informations in case of translations about what was the original text (not the work but the edition) used as source for the translation. Snipre (talk) 01:01, 27 September 2017 (UTC)
I'm sorry, but what? You are not using the standard terminology, I assume, because what you are saying makes no sense. Specifically, you are not using "work" in any sense that I understand it to mean. How can a "work" that consists of translations, consist of other works? Translations are never works; they are editions by Wikidata standards. So you are effectively stating that a work can consist of editions, which makes no logical sense.
With regard to the second situation, we are considering the original text and the translation to be co-equal, which cannot ever be the case. The original text has an author (and possibly an editor), but the translation has a translator. One of the languages is that of the original text, while the other language is that of the translation text. We are talking about throwing all that information together without any means for the user to disentangle it.
One point in all this is that we should be treating editions and translations as separate types of documents, and many of the difficulties of dealing with translations derive from our failure to distinguish between them. But that is another discussion.
But back to the original issue in the first case: If a translator publishes a single translation on its own, that's clearly a translation/edition by our current standards. You are suggesting that if a translator publishes two translations together which were not originally published together in the combination in the original language, then it's a work. And if a translator publishes three translations together, it's also a work, unless those three form a trilogy in the original language and we have a data item for that, in which case it's a translation/edition. And I suppose then that if a poem or short story collection is translated in full, then the translated volume is an edition that consists of edition/translations. But if the translator plays editor and includes only three-quarters of the original stories, then the volume is now a work that consists of works, or perhaps edition/translations? Would this same logic apply to translations of parts of works? Because that is incredibly common. All the Japanese translations of Tom Brown's School Days (each done independently) omit huge sections of text and whole chapters. Nearly all English translations of Euclid's Elements of Geometry omit several of the original 13 books, and some include all "15" with apocrypha. The Christian Bible does not have regular contents in its various translations, since there are differing views of what constitutes canon, apocrypha, pseudepigrapha, etc. Does each translation that includes a differing set of books constitute a different "work" then? The logic of your reasoning escapes me. --EncycloPetey (talk) 02:42, 27 September 2017 (UTC)
@EncycloPetey: Just be constructive once because until now you just critize everything without proposing something:
First what is your work definition ? Because I provide an explanation about why I consider an book composed of existing texts or translations is a work: the selection of texts is a work. What is your problem with that definition ? When somebody says "I want to publish the best texts of an author", if sombody cuts a original text, he is performing a creation. Even if the choice is based on obvious criteria. It seems you have a very limited vision of what is creation, so please just give your definition of work first.
Then about case, you lose nothing as you always have the the work item to identify the original data and to infer then the corresponding case:
* work item:
** language: X
** author: XX
* edition item:
** language: X, Y
** author: XX
** translator: ZZ
What kind of information is lost ? And by the way, what is your solution to model this case in WD ? Snipre (talk) 02:16, 1 October 2017 (UTC)
If selecting texts is a creation, and the result is a work, then why isn't translation also a creation, resulting in a work? Your definition doesn't explain that. --EncycloPetey (talk) 02:36, 1 October 2017 (UTC)
@EncycloPetey: Translations could be considered as work, this is a choice we can do, the question is to know if we need to add more complexy and for which gain. I just created a first list of cases and I can describe quite complex cases for translated texts without need of work definition for translations. So if we don't need to have work for translation, no need to add it. We are creating a model and the purpose of a model is not the reach the perfection but to be useful for the application we want to use.
And by the way you didn't provide any definition from your side. Do you want to be constructive or do you want to stay at the objections level ? Snipre (talk) 13:24, 1 October 2017 (UTC)
edition or translation of (P629): somevalue, qualifier language of work or name (P407)? And I don't understand this: P364 has been "language of original work". But you also state: ... for which no "original" work item can exist. So usage of P364 looks wrong, doesn't it? Matěj Suchánek (talk) 07:30, 27 September 2017 (UTC)
No original work in that form exists, but there is a translation because the components have original works from which they are translated. That is, the four plays were originally in ancient Greek, and the translations are in English, or French, or whatever, but there is not a "work" that consists of those four plays published in the original language used as the translation source, rather the individual plays are works that were all translated. So the original language was Greek, but the published language is English, and by all standards presented in the proposal, we would simply mark the translations as "English" with no indication whatsoever that they were ever written in any language but English, and with no indication whatsoever that they are translations rther than works originating in English. That is positively misleading the users. --EncycloPetey (talk) 12:58, 27 September 2017 (UTC)
On Four Plays of Aeschylus (Q26710829) you state that it is an English [7] work [8] having multiple parts [9]. On the parts items you state that these are English translations [10]. You also provide for each translation a link to the original work item [11]. On the original work items you state that these are works [12] in Ancient Greek [13]. Now we will use P407 instead of P364 in the last linked edit. What is here misleading the users? --Pasleim (talk) 13:55, 27 September 2017 (UTC)
Your links do not support what you claim. Where did I say that Four Plays of Aeschylus (Q26710829) was a "work"? If you feel we must do this incrementally, with diffs and details going over every word, then let's start there. Where did I say it was a "work"? --EncycloPetey (talk) 01:15, 28 September 2017 (UTC)
In September 2016 when you added that instance of (P31)=book (Q571), book (Q571) was a direct subclass of work (Q386724). Today, book (Q571) is a subclass of intellectual work (Q15621286) which is subclass of work (Q386724). Since subclass of (P279) is a transitive property, stating that Four Plays of Aeschylus is a instance of a book, it is implicitly also an instance of a work. --Pasleim (talk) 05:45, 28 September 2017 (UTC)
But, since this data item is for the copy at Wikisource, is that a correct value to use for "instance"? I used "book" because I could not find a more suitable value to use, but surely a particular copy cannot be a "work". (Please stay with me, and don't get sidetracked.) --EncycloPetey (talk) 13:54, 28 September 2017 (UTC)
I'm not an expert on Wikisource and there are would be project pages with more knowledgeable users on Wikisource linking. But the question is whether s:en:Four Plays of Aeschylus (Cookson) describes the work by Cookson or a particular copy of the work. If it describes the work the item is fine, if it describes a particular copy we need two items. One item for the work, i.e. the compilation of the four translations, and one item for the copy. --Pasleim (talk) 21:25, 28 September 2017 (UTC)
No, there are no project pages with more information, and that's part of the problem. This issue has never been worked through to its logical conclusion, nor has it ever been written up. Please don't waver on this discussion now.
But as for the four English translations by Cookson: aren't they also "works" that will have multiple editions? Couldn't Cookson's translation of The Suppliants appear in more than one published edition? And so, in addition to having two data items for Cookson's book Four Plays (one for the book as a "work", and one for the edition housed at Wikisource), wouldn't we also have to have two data items for each of the four translations of plays included in the volume (one for the translation as a "work", and one for the specific edition of that translation that was published)? --EncycloPetey (talk) 02:20, 29 September 2017 (UTC)
A translation is a translation and not a work. This does not exclude that a translation can not appear in more than one edition. Each edition gets its own item.
Imagine I told you a translations are also works, would it change something on how we should delete P364? --Pasleim (talk) 09:13, 29 September 2017 (UTC)
You're getting sidetracked here; please stay with me. Each publication of a work housed at Wikisource necessitates that each publication has a different data item. We are treating editions and translations as the same thing, yes? And Cookson's translation of Prometheus Unbound is a translation, yes, but there are multiple editions of that translation because it has been published by different editors in different volumes. We can't re-use the same data item every time the Cookson translation appears in another volume, so the translation must have multiple editions. We therefore must have a master data item indicating the information about the translation as a "work", and then data items for each edition of the translation. --EncycloPetey (talk) 15:53, 30 September 2017 (UTC)
I almost agree with you, I just don't call the translation a "work" but maybe it would be easier if I do so. If a translation gets published by different editors then we need indeed an item for the translation and items for each edition. --Pasleim (talk) 18:26, 30 September 2017 (UTC)
I agree that the terminology is inadequate for describing this situation. But continuing: What happens then when a translation has two (or more) different textual revisions, each of which has been published in more than one location? We have this issue with Browning's translation of Prometheus Bound and Shelley's translation of Cyclops' for example. As far as I can tell, we would have a data item for the original play, one for the translation as a "work", one data item for each "revision" of that translation as a "work", and one data item for each "edition" of each revision of that translation. --EncycloPetey (talk) 19:31, 30 September 2017 (UTC)
Yes that is the idea. Sounds fairly complicated but it is the only way to give proper attribution to each editor and to show each publication date and place. And if Wikisource hosts multiple edition of a work/translation/revision there are even software restrictions which forces us to follow this data model. --Pasleim (talk) 20:03, 30 September 2017 (UTC)
Complicated, but we're not quite done yet, though we can soon move on to the next step in the discussion. Before we go there, I must also point out that many translators translate using a specific edition of the original text, such as the Dindorf edition of a Greek text. So we can have an edition of a revision of a translation of an edition of a Greek publication of a work. The actual Wikisource edition must then have six data items in place, all of which are suitably interlinked. And someone seeking the original language would have to blindly navigate through six layers of data items to find what that original language was of the translated work. --EncycloPetey (talk) 20:44, 30 September 2017 (UTC)
It is not a blind navigation. We have edition or translation of (P629) to link to the next upper layer and instance of (P31) to tell the type of the layer. --Pasleim (talk) 00:48, 1 October 2017 (UTC)
It is blind. In the situation we've constructed, there are six layers of "edition/translation of" to sift through, but in the end, a person would have to follow a link into "has part/part of" and follow it back to find the original language, since the "work" in question would be marked as "English" for its language, since the book as a whole was not composed originally in Greek. A user would have to poke around every possible link or "edition/translation of" and "has part" or "part of" and might find the original language somewhere within a maze of interconnected data items. If they stopped too soon, or didn't know ahead of time which direction to follow for the links, they would mistakenly end up with the wrong language. --EncycloPetey (talk) 01:11, 1 October 2017 (UTC)
Well if we go from a particular edition up to the work, there should never be more than one edition or translation of (P629) claim and if an item uses "has part/part of" it is possible that multiple original languages exist. If you have usability concerns, you should consider that seen over all books cases like Four Plays of Aeschylus (Q26710829) are rather rare. Moreover, the target audience of Wikidata are not users visiting but Wikipedia/Wikisource which include data from Wikidata and external pages retrieving data through the API or query service. For those, the current situation means that they have to poke around every possible statement and might find the original language somewhere within a maze of unstructured data. The original language can be found sometimes as qualifier on language of work or name (P407), sometimes as qualifier on original language of work (P364), sometimes as qualifier on edition or translation of (P629), sometimes as an own statement, or sometimes one has to follow the edition or translation of (P629) link. On the original work item, sometimes original language of work (P364) is used, sometimes language of work or name (P407), sometimes both. If there is a translation of a translation of a work, P364 is anyway illdefined. If we could do the migration, we could write a function for the Lua module on Wikipedia to retrieve the original language and external pages could add a while-loop to their code and we would finally have a distinct data structure that works in all situations. --Pasleim (talk) 02:39, 1 October 2017 (UTC)
@Pasleim, EncycloPetey: I created a lis of cases here and I was trying to model the cases acording to the work/edition principle. I didn't find big issue until now, but we have to provide a more detailed example for some cases. The main problem is never the language but work definition so I think all the discussion above is out of the box concerning the issue of merging 2 properties about languages. I proposed to EncycloPetey to provide a defined case where the merge of the mentioned properties is a real problem. For the general discussion about the work/edition model, better discuss about that in the talk page of Wikibooks project.
@EncycloPetey: I propose you to generate some cases based on what you mentioned like I did in my cases list and then we can discuss based on a generic case (and not on a real case where you are the only one knowing the details) the solution.
@Pasleim: You mentioned that translations should have work items. If I agree in the absolute vision of a perfect classification, I ask you: where do you find an advantage of this more complex system compared to the one where translations are considered as edition ? The best will be to model the cases from my list with the addition of work for translations and see what are the results. Snipre (talk) 13:42, 1 October 2017 (UTC)
@Snipre: I commented on the talk page of your list as the answer is irrelevant for the migration discussion here. --Pasleim (talk) 14:08, 1 October 2017 (UTC)
@Pasleim: RE: "seen over all books cases like Four Plays of Aeschylus (Q26710829) are rather rare". Actually they aren't. If you like I can show you how almost any translated book becomes just as complicated. For example, The Time Machine (Q627333) by H. G. Wells (Q42511) has no single authoritative edition to be the standard. Rather, there is the serialized version of the novel, and at least two book formats for the novel with significantly differing text and even different chapter numbers. That's just the major English editions. When one of these gets translated, we have to identify whcih English edition was the one translated, because it's not always one particular translation. The choice of edition affects the number of chapters, and this is hugely important for Wikisource, where editors like to be able to place the translated text side-by-side with the "original". To do this requires a data item for each chapter, both in the original language and in the translation, which means there must be data items for each chapter as part of the "work" and data items for each chapter of the "edition" and data items for each chapter of the "translation". And if the translation has gone through multiple editions (it usually has), then we end up with the same morass of data items that we had for the Greek plays.
Whether you consider Oliver Twist by Charles Dickens or L'Homme qui rit by Victor Hugo, you get the same complexity of hundreds of interconnected data items. Most of these works were serialized to begin with, later collecting them together as a novel, and sometimes then published over multiple volumes or parts even before the process of translation, and then having differing numbers of volumes in the translation. --EncycloPetey (talk) 15:30, 1 October 2017 (UTC)
There is no consensus on the notability of Wikisource chapters on Wikidata.
Whether we need a hundred items to model all editions and translation of Oliver Twist does not depend at all on whether we have one, two or three language properties. --Pasleim (talk) 15:59, 1 October 2017 (UTC)
You've lost that train of thought we built up. What happens on the French, German, etc. editions of translations when we have so many data items and so many links to manage? How would an average user find the original language of a work in such a situation, when presented with a labyrinthine set of data items? Notability is unsettled, but that includes also those volumes where the book consists entirely of individual works by separate authors, which do seem to be accepted now. And chapters of translated books will exist on multiple WS projects, albeit in different languages. For those that will have translations on other WS, the balance is likely to tip in favor of inclusion. --EncycloPetey (talk) 01:37, 3 October 2017 (UTC)
@EncycloPetey: And simply, can you please explain that what's your qualifier usage of original language of work (P364)? That so-called usage is simply confused to me, and even the talk page of that property also disencourage it. --Liuxinyu970226 (talk) 10:59, 3 October 2017 (UTC)
I don't understand your question. I can't tell whether you meant to politely ask a question (which I do not understand) or meant to be insulting (I can't tell if that was intentional). --EncycloPetey (talk) 13:55, 3 October 2017 (UTC)
@EncycloPetey: Well
  1. In Antigonae (Q24790761), what means the qualifier "original language of work (P364)  Ancient Greek (Q35497)" within language of work or name (P407)  German (Q188)?
  2. In those 4 items Choephori (Q22972166), Agamemnon (Q22810156), Eumenides (Q23012889) and The Persians (Q23308144), what means the qualifier "original language of work (P364)  Ancient Greek (Q35497)" within language of work or name (P407)  English (Q1860)?

--Liuxinyu970226 (talk) 06:58, 4 October 2017 (UTC)

That is a work-around to indicate the language of the source text from which the translation was made. We currently have no standard to identify the source text (or edition), nor the means to identify the language of the text from which a translation was made. This is a significant point, as a translation is not made from a "work" but from a specific text or texts, and neither is a translation always made from the "original" but may be done from a translation. We have no preferred means to indicate any of this information. --EncycloPetey (talk) 12:17, 4 October 2017 (UTC)
And even once we have a method for indicating source text and source language (for the immediate source, not the ultimate one), there are challenges. I was a translation of Euripides that was made from Dindorf's edition. However, I have no access to a copy of Dindorf's edition, so I have insufficient information to create the various data items that would be needed, such as which volumes contain which plays. Further, Dindorf's edition of the plays would have its language marked as both German and ancient Greek, since the play text is in English, but all prefatory materials and internal notes are in German. Having such a work as the source of the English translation leaves the question open of whether the English copy was translated from a Greek text or from a German text. Wikidata currently has no way at all to indicate which was the source language. --EncycloPetey (talk) 13:22, 4 October 2017 (UTC)
Thank you for going ahead with this. I suggest including this to Tech News as well because templates can break when the property gets deleted.
Note that when you include subclasses of film (Q11424) to the query after the third point, it does return some results. Not many, though. Matěj Suchánek (talk) 07:30, 27 September 2017 (UTC)
We can include it to Tech News but I promise that I will fix the templates listed on Property talk:P364. Thus, there should be no broken templates. --Pasleim (talk) 21:25, 28 September 2017 (UTC)
Just   Delete as quickly as possible, all of those "keep" comments are daydream, and are illegal that try to defend their edit wars. --Liuxinyu970226 (talk) 05:28, 1 October 2017 (UTC)
  •   Comment I don't think much progress seems to have been made for movies. If we proceed with the suggested merger, this would just lead to make it indeterminable. There were some suggestions that we should follow for these, but as schema has three different ones for languages, I don't think this is would be any progress from the stable solution we have now for movies. Going forward, I'd keep excluding films from the merger.
    As for books, I think it would be good to formulate a clear plan so users are able to determine what a language statement would mean on such items without loading dozens of items and attempting to check these for completeness. I can understand that some approach might seems theoretically desirable and work well in a single editor environment, but this doesn't necessarily help users with Wikidata problems.
    --- Jura 06:40, 1 October 2017 (UTC)
What kind of progress do you expect ? The principle is given: use of model based on FRBR system which is the only system which allows you to add data like voices or the publication date of each dubbed version. Until now you never provided any explanation how I can add the names of the voices like the ones available in this section of WP:fr and in this section of WP:es for The Hunt for Red October (Q507994). So your system is not applicable but this is our responsability to find a solution ? Perhaps it is time to wake up the Project Movies to define an action plan: the merge of the 2 languages properties is not a problem, this is a situation which reveals the problem.
So I propose you a very simple deal: let us working on the book cases and from your side start to work on the movie cases. And please provide me an example how I can add the dubbed voices for the case of The Hunt for Red October (Q507994): I hope you won't consider this as a theoretical problem. Snipre (talk) 21:40, 1 October 2017 (UTC)
@Jura1: Per above, the de facto most big problem with your P364 is how to handle actors of dubs, please just answer it, otherwise my delete vote is still okay. --Liuxinyu970226 (talk) 23:23, 4 October 2017 (UTC)
  Comment Snipre: Thanks for giving me credit for the Wikiproject Movies structure, but it's mostly undeserved even though I made efforts that it was spelled out, properly applied and even key indicator defined. As you notice, it's fairly clean, complete and even noise can be removed without much problem. It might be too ambitious, but I'd expect a similar working approach for books. The existing movie structure should work for your The Hunt for Red October (Q507994) sample without problems. Once done, we can then work together to make sure it appears in the Spanish infobox (French wont work, as I don't think they use Wikidata for films). Alternatively, if available, you could do one for Catalan (Catalan Wikipedia also uses Wikidata in film infoboxes). If you have problems with the properties for movies, please ask at the WikiProject. Please help us keep away purely disruptive or non-contributing efforts.
--- Jura 09:38, 8 October 2017 (UTC)
Although you claim that the WikiProject Movies structure is fairly clean and complete, some major information are missing. For example, why are two or even three language properties necesseary to describe a movie? --Pasleim (talk) 17:07, 9 October 2017 (UTC)
Some people favoring merging advocated following which has three different scheme's for movies. Personally, I don't. We should we do with a property "subtitle language"?
--- Jura 08:38, 11 November 2017 (UTC)
@Jura1: So we agree that the current data structure described in Wikiproject Movies is the reference. So according to this data structure, the original movie requires only one language property and all dubbed movies have to be described in a different item using again one unique language property. There is no need of having 2 or more language properties in the same item so changing P364 by P407 will have no impact on items which follows the data structure described in the Wikiproject. Only the items which are not using the data structure required by the Wikiproject can be impacted but that's not our problem, that's the problem of the Wikiproject Movies which allows different data structures or didn't plan until now any data curation.
So do we agree that
1) there is no need of 2 different language properties (based on the data structure of Wikiproject Movies) ?
2) we can deprecate P364 starting now (after changing the data structure of Wikiproject Movies) ?
3) we have to define a strategy to convert P364 by P407:
All other cases are not following the data structure of Wikiproject and have to be curated. Snipre (talk) 11:50, 20 October 2017 (UTC)
@Jura1: Please answer the above questions by Snipre and me. If you don't do so, I will soon start with the conversion outlined above, we still have to respect that a majority of users voted for merging P364 with P407. --Pasleim (talk) 08:29, 10 November 2017 (UTC)
Also the question that about NTSC/PAL/SECAM issue that I asked more than 3 times here. --Liuxinyu970226 (talk) 12:49, 10 November 2017 (UTC)
Pasleim: I don't really see how Snipre's proposal will help him achieve what he planned to do (sort out the books part, add the dubbed versions of "Red October") and why instead WikiProject movies gets told it's their responsibility to fix it for him. I don't think this is particularly respectful from participants in the discussion who don't actually contribute to Wikidata otherwise in the field. If we continue this way, it might just end up as an endless soap. Accordingly, I have asked this discussion to be closed as stale. Obviously, I could try to help you sort out the books part, but this doesn't need a deletion discussion nor is a deletion discussion a suitable forum There does seem to be consensus that books need help, but unfortunately it's not clear how this should be done. Merely voting isn't going to build a plan. Given the countless participants of the books projects, it's unclear why people of other projects should do that. Pasleim, I do appreciate your efforts to get some sense into this, but we probably both focus on more important things. Maybe Matěj Suchánek wants to address the SECAM question, I avoid doing that as he asked me not to do in another context.
--- Jura 08:38, 11 November 2017 (UTC)
I'm not going to address any made up terms like "SECAM". The result of initial discussion, which I closed in May, is clear: to merge two properties. Since this cannot be done by software (like with items), we need to migrate one to another. I gave users opportunity to share what issues we need to know about before the migration but now I see I shouldn't have.
So yes, this discussion is stale and can be closed. The community had already decided anyway. Matěj Suchánek (talk) 15:37, 11 November 2017 (UTC)
The problem is that it failed to develop an implementation plan. So we are just where we were 6 months ago. Despite a general idea, it's not something that can be acted upon. Maybe we should try to develop better support for WikiProject Books going forward. Users seems to be confused by conflicting approaches and chat in forums.
--- Jura 16:09, 11 November 2017 (UTC)

Closure of stale threadEdit

As this hasn't really gotten ahead, I think we should leave it to the relevant WikiProjects to address possible needs for improvement.
--- Jura 08:38, 11 November 2017 (UTC)

  Oppose The roadmap is only stucked by you, so peoples are discussing how you could be softhearted. --Liuxinyu970226 (talk) 09:16, 12 November 2017 (UTC)
PS: Let's simply count the votes above:
  1. Arguments to keep (6, 30%): Arbnos, Jklamo, Finn Årup Nielsen (fnielsen), ValterVB, Jura, and EncycloPetey;
  2. Arguments to delete (13, 65%): Pasleim, Kareyac, ArthurPSmith, Tubezlob,, Thierry Caro, Fralambert, billinghurst, Strakhov, Liuxinyu970226 (don't surprise, I already decided to migrate), Snipre, Queryzo, d1g
  3. Arguments neutral or no idea (1, 5%): Eran

Maybe it's worth to encourage those 30% to change their brain on P364. --Liuxinyu970226 (talk) 11:51, 12 November 2017 (UTC)

  • Actually, we were trying to figure out a plan, not bean count. As nothing useful came up, we can close the discussion and leave it to the projects to sort out.
    --- Jura 13:10, 22 November 2017 (UTC)

FINAL VOTE: Suggested closure reasonsEdit

1. Close as "No consensus to do actual delete/Consensus to keep"

  Oppose Such "consensus to keep" overwritten are violating the MediaWiki Code of Conduct (Q45161493), and if Jura1's opinion is this, it can even be subject to one reason that I request fireing their Administrator right. --Liuxinyu970226 (talk) 04:36, 30 December 2017 (UTC)
What the hell are you talking about Liuxinyu970226? Multichill (talk) 20:35, 5 February 2018 (UTC)

2. Close as "Consensus to remove all usages like P794 below, then delete"

  Neutral Will ask @Deryck Chan: separately and privately for the possibility of this opinion. --Liuxinyu970226 (talk) 04:38, 30 December 2017 (UTC)
@Liuxinyu970226: The P794 experience showed that this is possible, as long as people agree on what use cases migrate where. Deryck Chan (talk) 11:38, 24 January 2018 (UTC)

3. Close as "remove all except films' usages"

  Support --Liuxinyu970226 (talk) 14:34, 20 December 2017 (UTC)
  Support --Pasleim (talk) 13:41, 21 December 2017 (UTC)
  Support and P794 has to be relabelled as movie original language to avoid any other use of this property. Snipre (talk) 21:30, 28 December 2017 (UTC)
  Support and change label per Snipre ArthurPSmith (talk) 21:52, 5 February 2018 (UTC)

4. Discussion

Since when did we resolve matters by voting, rather than reaching consensus through discussion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:32, 5 February 2018 (UTC)

Since this request has been open for a year. It is not uncommon to have a vote if some discussion gets stale. Also, the arguments of the discussion are being repeated in the vote (suggested closure reasons). Sjoerd de Bruin (talk) 13:48, 6 February 2018 (UTC)
@Pigsonthewing: I must point that the discussion related to P364 is opened for a whole year, A WHOLE YEAR, how can a consensus not be happened within a whole year? --Liuxinyu970226 (talk) 04:34, 7 February 2018 (UTC)

no label (P794)Edit

  • It's really unfortunate how this was handled. This was deleted before a correct replacement was found. Now we have many statements moved to qualifiers people agree that they are wrong: Property_talk:P1480#de_facto,_interim,_acting . The correct approach would be move them back and delete later if possible.
    --- Jura 15:01, 19 December 2017 (UTC)
That's just a complete mischaracterization of a very deliberative process. Replacements were found for all use cases, 99% of the time with no controversy at all. In the tiny subset where there was disagreement, no one said that the qualifiers being used were wrong, only that another qualifier might be better (which can still be addressed), and no one but you expressed the thought that the old, generic qualifier would be better, even temporarily. So no, this property was absolutely not "deleted before a correct replacement was found", and it was deleted after extremely thorough discussion and solid consensus. Swpb (talk) 13:56, 20 December 2017 (UTC)
I don't recall anyone supporting the solution of using sourcing circumstances (P1480) at Property_talk:P1480#de_facto,_interim,_acting. Unfortunately I didn't check last month if the contributor had fixed all uses after some were actually moved to a suitable qualifiers. Given this negligent approach, I'm not really confident that the reminder of the changes have been done correctly.
--- Jura 14:48, 20 December 2017 (UTC)
If you want to query uses of sourcing circumstances (P1480) and make sure they're all to your approval, go ahead. Or talk to @Deryck Chan: directly and tell him how "negligent" you think he is, and then see if he's interested in helping you. Whining and being dishonest about a very decisive closure you don't happen to like is accomplishing nothing but making yourself undesirable to interact with. Swpb (talk) 18:09, 20 December 2017 (UTC)

Undeletion of Property:P794Edit

It appears that many qualifiers have been replaced with in incorrect sourcing circumstances (P1480) and still need to be corrected/reverted. Subsequent discussions for a better solution haven't be productive.
--- Jura 10:29, 7 January 2018 (UTC)

  Oppose If there's clear replacement then use that replacement, no more harrasement, otherwise I just will make a fire request aganist your administrator right. --Liuxinyu970226 (talk) 15:04, 7 January 2018 (UTC)
Anyway, if you would love to open a ≥1km high discussion thread, please do so on WD:RFC rather than here, thank you for regarding. --Liuxinyu970226 (talk) 15:18, 7 January 2018 (UTC)
item itemLabel property propertyLabel value valueLabel asObject asObjectLabel
Frank-Walter Steinmeier (Q76658) Frank-Walter Steinmeier P39 position held Q29576752 chairman of the Social Democratic Party Q4676846 acting
Pietro Badoglio (Q200085) Pietro Badoglio P39 position held Q28798091 minister of Italian Africa of the Kingdom of Italy Q4676846 acting
Charles Dupuy (Q356032) Charles Dupuy P39 position held Q191954 President of the French Republic Q4676846 acting
Ferruccio Parri (Q471315) Ferruccio Parri P39 position held Q28798091 minister of Italian Africa of the Kingdom of Italy Q4676846 acting
Ferruccio Parri (Q471315) Ferruccio Parri P39 position held Q39415052 minister of Treasury of the Kingdom of Italy Q4676846 acting
Antonio Starabba, Marquess of Rudinì (Q605268) Antonio Starabba, Marquess of Rudinì P39 position held Q26305375 minister of Justice of the Kingdom of Italy Q4676846 acting
Igor Radojičić (Q609400) Igor Radojičić P39 position held Q6594693 President of Republika Srpska Q4676846 acting
Wendy Chamberlin (Q2559277) Wendy Chamberlin P39 position held Q27832358 United Nations High Commissioner for Refugees Q4676846 acting
Giuseppe de Nava (Q3770441) Giuseppe de Nava P39 position held Q27136108 minister of Maritime and Railway Transports of the Kingdom of Italy Q4676846 acting
Willem Frederik van Reede (Q14519538) Willem Frederik van Reede P39 position held Q251747 President of the Senate of the Netherlands Q4676846 acting
Felice Merlo (Q25938587) Felice Merlo P39 position held Q25938572 minister for Ecclesiastical Affairs and Justice of the Kingdom of Sardinia Q4676846 acting
Félix Pachano (Q26741229) Félix Pachano P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Adolfo de Cucco (Q26761712) Adolfo de Cucco P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Adolfo Vieyra Latorre (Q26761714) Adolfo Vieyra Latorre P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Johannes Rau (Q2551) Johannes Rau P39 position held Q29576752 chairman of the Social Democratic Party Q4676846 acting
Franz Amrehn (Q96399) Franz Amrehn P39 position held Q641159 Governing Mayor of Berlin Q4676846 acting
Alcide De Gasperi (Q153832) Alcide De Gasperi P39 position held Q28798093 minister of Italian Africa Q4676846 acting
Alcide De Gasperi (Q153832) Alcide De Gasperi P39 position held Q28798091 minister of Italian Africa of the Kingdom of Italy Q4676846 acting
Camillo Benso, Count of Cavour (Q166092) Camillo Benso, Count of Cavour P39 position held Q26877864 minister of the Navy of the Kingdom of Italy Q4676846 acting
Camillo Benso, Count of Cavour (Q166092) Camillo Benso, Count of Cavour P39 position held Q25936389 minister of Interior of the Kingdom of Sardinia Q4676846 acting
Camillo Benso, Count of Cavour (Q166092) Camillo Benso, Count of Cavour P39 position held Q26844985 minister of War of the Kingdom of Italy Q4676846 acting
Camillo Benso, Count of Cavour (Q166092) Camillo Benso, Count of Cavour P39 position held Q26084477 minister of Finance of the Kingdom of Sardinia Q4676846 acting
Camillo Benso, Count of Cavour (Q166092) Camillo Benso, Count of Cavour P39 position held Q26084496 minister of War of the Kingdom of Sardinia Q4676846 acting
Camillo Benso, Count of Cavour (Q166092) Camillo Benso, Count of Cavour P39 position held Q26084477 minister of Finance of the Kingdom of Sardinia Q4676846 acting
Jim Wallace, Baron Wallace of Tankerness (Q333807) Jim Wallace, Baron Wallace of Tankerness P39 position held Q1362216 First Minister of Scotland Q4676846 acting
Jim Wallace, Baron Wallace of Tankerness (Q333807) Jim Wallace, Baron Wallace of Tankerness P39 position held Q1362216 First Minister of Scotland Q4676846 acting
Giovanni Lanza (Q674128) Giovanni Lanza P39 position held Q26084477 minister of Finance of the Kingdom of Sardinia Q4676846 acting
Giovanni Lanza (Q674128) Giovanni Lanza P39 position held Q26084477 minister of Finance of the Kingdom of Sardinia Q4676846 acting
Giovanni Lanza (Q674128) Giovanni Lanza P39 position held Q26084477 minister of Finance of the Kingdom of Sardinia Q4676846 acting
Cesare Alfieri di Sostegno (Q1054500) Cesare Alfieri di Sostegno P39 position held Q26085299 minister of Agriculture and Trade of the Kingdom of Sardinia Q4676846 acting
Bernardino Grimaldi (Q3638716) Bernardino Grimaldi P39 position held Q26457103 minister of Treasury of the Kingdom of Italy Q4676846 acting
Francesco Tedesco (Q3750727) Francesco Tedesco P39 position held Q26457103 minister of Treasury of the Kingdom of Italy Q4676846 acting
Li Zongren (Q20297) Li Zongren P39 position held Q887003 President of the Republic of China Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q28798091 minister of Italian Africa of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q26277644 minister of Public Works of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q33205128 minister of Corporations of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q26277644 minister of Public Works of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q26877864 minister of the Navy of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q28798091 minister of Italian Africa of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q26844985 minister of War of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q33205128 minister of Corporations of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q28798091 minister of Italian Africa of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q26248695 minister of Foreign Affairs of the Kingdom of Italy Q4676846 acting
Benito Mussolini (Q23559) Benito Mussolini P39 position held Q26911615 minister of Air Force of the Kingdom of Italy Q4676846 acting
Giovanni Giolitti (Q297190) Giovanni Giolitti P39 position held Q26277644 minister of Public Works of the Kingdom of Italy Q4676846 acting
Giovanni Giolitti (Q297190) Giovanni Giolitti P39 position held Q26305375 minister of Justice of the Kingdom of Italy Q4676846 acting
Giovanni Giolitti (Q297190) Giovanni Giolitti P39 position held Q26877864 minister of the Navy of the Kingdom of Italy Q4676846 acting
Antonio Salandra (Q354715) Antonio Salandra P39 position held Q26877864 minister of the Navy of the Kingdom of Italy Q4676846 acting
Luigi Facta (Q431330) Luigi Facta P39 position held Q27131271 minister of Reconstruction of the Lands Liberated From the Enemy Q4676846 acting
Frédéric François-Marsal (Q459212) Frédéric François-Marsal P39 position held Q191954 President of the French Republic Q4676846 acting
Enrico Morin (Q3725932) Enrico Morin P39 position held Q26248695 minister of Foreign Affairs of the Kingdom of Italy Q4676846 acting
Enrico Morin (Q3725932) Enrico Morin P39 position held Q26877864 minister of the Navy of the Kingdom of Italy Q4676846 acting
Giovanni Cuomo (Q3767072) Giovanni Cuomo P39 position held Q33206661 minister of Popular Culture of the Kingdom of Italy Q4676846 acting
Simonetta Pozzoli (Q24260682) Simonetta Pozzoli P39 position held Q30185 mayor Q4676846 acting
Walter Scheel (Q2571) Walter Scheel P39 position held Q4970706 Federal Chancellor of Germany Q4676846 acting
Alain Poher (Q12950) Alain Poher P39 position held Q191954 President of the French Republic Q4676846 acting
Alain Poher (Q12950) Alain Poher P39 position held Q191954 President of the French Republic Q4676846 acting
André Blattmann (Q120004) André Blattmann P39 position held Q25212272 Chief of the Armed Forces Q4676846 acting
Agostino Magliani (Q139839) Agostino Magliani P39 position held Q26457103 minister of Treasury of the Kingdom of Italy Q4676846 acting
Agostino Magliani (Q139839) Agostino Magliani P39 position held Q26457103 minister of Treasury of the Kingdom of Italy Q4676846 acting
Francesco Saverio Nitti (Q367132) Francesco Saverio Nitti P39 position held Q26248695 minister of Foreign Affairs of the Kingdom of Italy Q4676846 acting
Urbano Rattazzi (Q449387) Urbano Rattazzi P39 position held Q26456736 minister of Finance of the Kingdom of Italy Q4676846 acting
Bill Skate (Q719336) Bill Skate P39 position held Q1073440 Governor-General of Papua New Guinea Q4676846 acting
Carlo Bon Compagni di Mombello (Q1054496) Carlo Bon Compagni di Mombello P39 position held Q26083910 minister of Public Education of the Kingdom of Sardinia Q4676846 acting
Federico Pescetto (Q1400532) Federico Pescetto P39 position held Q26248695 minister of Foreign Affairs of the Kingdom of Italy Q4676846 acting
Federico Seismit-Doda (Q1400564) Federico Seismit-Doda P39 position held Q26457103 minister of Treasury of the Kingdom of Italy Q4676846 acting
Agustín B. Gambier (Q16527578) Agustín B. Gambier P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Andries Hudde (Q20857991) Andries Hudde P39 position held Q1162163 director Q4676846 acting
Eufemio Alcayaga (Q26761707) Eufemio Alcayaga P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Juan Alsina (Q26761713) Juan Alsina P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Samuel Saraví Hardy (Q26761784) Samuel Saraví Hardy P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Alfredo Sarquisse (Q26761815) Alfredo Sarquisse P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Jorge Falcone (Q26761816) Jorge Falcone P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Jorge Falcone (Q26761816) Jorge Falcone P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Ivanoe Bonomi (Q313717) Ivanoe Bonomi P39 position held Q27136108 minister of Maritime and Railway Transports of the Kingdom of Italy Q4676846 acting
Ivanoe Bonomi (Q313717) Ivanoe Bonomi P39 position held Q26248695 minister of Foreign Affairs of the Kingdom of Italy Q4676846 acting
Ivanoe Bonomi (Q313717) Ivanoe Bonomi P39 position held Q28798091 minister of Italian Africa of the Kingdom of Italy Q4676846 acting
Ivanoe Bonomi (Q313717) Ivanoe Bonomi P39 position held Q26248695 minister of Foreign Affairs of the Kingdom of Italy Q4676846 acting
Bettino Ricasoli (Q519900) Bettino Ricasoli P39 position held Q26305375 minister of Justice of the Kingdom of Italy Q4676846 acting
Ubaldino Peruzzi (Q1079356) Ubaldino Peruzzi P39 position held Q26456736 minister of Finance of the Kingdom of Italy Q4676846 acting
Ferdinando Acton (Q1406068) Ferdinando Acton P39 position held Q26844985 minister of War of the Kingdom of Italy Q4676846 acting
Filippo Cordova (Q3071888) Filippo Cordova P39 position held Q26305375 minister of Justice of the Kingdom of Italy Q4676846 acting
Pietro De Rossi di Santarosa (Q3388107) Pietro De Rossi di Santarosa P39 position held Q26085299 minister of Agriculture and Trade of the Kingdom of Sardinia Q4676846 acting
Guido Jung (Q3779346) Guido Jung P39 position held Q37981911 minister of Trade and Currencies of the Kingdom of Italy Q4676846 acting
Roberto Hurtado (Q26741581) Roberto Hurtado P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Alfredo Paz (Q26761708) Alfredo Paz P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Luis Doyhenard (Q26761710) Luis Doyhenard P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Juan Carlos Parodi (Q26761823) Juan Carlos Parodi P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Andrew G. McCabe (Q27734885) Andrew G. McCabe P39 position held Q1057168 Director of the Federal Bureau of Investigation Q4676846 acting
Matteo Renzi (Q47563) Matteo Renzi P39 position held Q27991508 Minister of Economic Development Q4676846 acting
Matteo Renzi (Q47563) Matteo Renzi P39 position held Q6092845 Italian Minister of Transports and Infrastructures Q4676846 acting
Roberto Etchepareborda (Q2159496) Roberto Etchepareborda P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
José de Carvajal y Hué (Q6294279) José de Carvajal y Hué P39 position held Q21192262 Minister of Governance Q4895105 interim
Adrián Fernández Casco (Q21694115) Adrián Fernández Casco P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Guillermo Cranwell (Q1230972) Guillermo Cranwell P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Manuel Obarrio (Q5993921) Manuel Obarrio P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Manuel Obarrio (Q5993921) Manuel Obarrio P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Saturnino García Anido (Q21694111) Saturnino García Anido P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Eduardo Bergalli (Q21694126) Eduardo Bergalli P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Rudolf Anthes (Q2172342) Rudolf Anthes P39 position held Q22132694 museum director Q4895105 interim
Juan José Montes de Oca (Q21694009) Juan José Montes de Oca P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Enrique Palacio (Q21694098) Enrique Palacio P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Virgilio Tedín Uriburu (Q21694113) Virgilio Tedín Uriburu P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Tomás José Caballero (Q6148525) Tomás José Caballero P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Martín Biedma (Q21694034) Martín Biedma P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Eduardo Crespi (Q5559260) Eduardo Crespi P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Alfonso Ferrero La Marmora (Q471272) Alfonso Ferrero La Marmora P39 position held Q25936261 minister of Foreign Affairs of the Kingdom of Sardinia Q4676846 acting
Benito Lynch (Q817347) Benito Lynch P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Carlos Monsalve (Q17995988) Carlos Monsalve P39 position held Q26741444 Mayor of La Plata Q4676846 acting
Albert Bessemans (Q18612682) Albert Bessemans P39 position held Q27016924 Q27016924 Q4676846 acting
Juan Debenedetti (Q21693712) Q21693712 P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim
Leopoldo Frenkel (Q21693724) Q21693724 P39 position held Q21693213 Mayor of Buenos Aires Q4895105 interim

Cleanup discussionEdit

Could you give a few examples of the incorrect sourcing circumstances (P1480) you see? ChristianKl❫ 23:48, 7 January 2018 (UTC)
@ChristianKl: please see above. There is a query for them on the talk page of sourcing circumstances (P1480). The contributor who converted them almost immediately realized his error and, as I saw them doing some correctly, I assumed initially that everything had been fixed. Unfortunately, this hasn't moved since and it would be bad practice if we would let them linger there a further couple of months, until an acceptable alternative was determined.
--- Jura 16:19, 8 January 2018 (UTC)
@Deryck Chan: How do you think about them? --Liuxinyu970226 (talk) 04:44, 10 January 2018 (UTC)
Thanks for pinging me. Let's continue the discussion at Wikidata:Requests for comment/Close-out of statements formerly using P794. Deryck Chan (talk) 17:10, 11 January 2018 (UTC)
Whatever change may be decided in 6 months, we still need to clean up this part. As you did the bulk edits, it's expected that you'd clean it up. If you can't do it or don't have the time to do it, please say so.
--- Jura 17:25, 11 January 2018 (UTC)
I'm of the opinion that we're better off parking these statements with a sub-optimal qualifier than to return them to P794. I disagree with your description that I "realized his error", but I accept that you and a few other editors disagree with me and some other participants of the discussion above who desired to move those qualifiers to sourcing circumstances (P1480), and offered to move the qualifiers again when a better choice of P than both P794 and P1480 is agreed upon. Deryck Chan (talk) 12:38, 22 January 2018 (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)

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

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

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

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

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

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

@Liuxinyu970226: I looked at the property talk pages and checked the templates that used these properties. it:Template:Infobox missione spaziale is an example that uses the {{#Property:}} syntax (through Template:Wikidata (Q8478926)) to fetch this property. I'm not aware of any use of these properties on yue.wp. So my suggested plan of action is (0) mark these properties as deprecated (1) copy these statements into the proposed new statement structure (2) modify all the relevant templates to transfer all uses of these properties in other Wikimedia sites to the new statement structure (3) finally delete the property. Deryck Chan (talk) 11:22, 31 October 2017 (UTC)
I've recently learned that it's not possible to select statements based on qualifier values using {{#statements:}}. Module:Wikidata (Q12069631) and Module:Wikidata2 (Q25936424) don't currently have that functionality either. So I think we should keep these properties until that becomes possible. Deryck Chan (talk) 14:47, 7 December 2017 (UTC)
Some versions of Module:Wikidata2 (Q25936424) can read out statements based on qualifiers, e.g. the version on frwiki. Moreover, spacecraft docking/undocking date (P622) also requires qualifiers. Infoboxes need to select statements based on qualifier values to properly display the data of spacecraft docking/undocking date (P622). --Pasleim (talk) 06:43, 8 December 2017 (UTC)


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)

  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   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 TRA 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)
  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)   instead. This discriminates specified parts (parts for which we have actual items, West Wing (Q1932621)     for the white house for example) from unspecified ones (the whitehouse has wings). author  TomT0m / talk page 11:17, 20 May 2017 (UTC)
  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) Maxim75 (talk) 06:04, 22 September 2017 (UTC) NCFriend (talk) 12:29, 2 August 2017 (UTC)   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)
  •   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)
  •   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:
  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   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)
  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)
  • I was canvased by Liuxinyu970226 to change my opinion to delete. The current label of the property is "number of platform tracks" with description "number of tracks served by a platform at a railway station". What's difficult about this? Take the number of tracks going through a train station (for example 8 for Haarlem railway station (Q800863)) and deduct the tracks that don't have a platform (track 2 and 7 for Haarlem) and you get the result (6 for Haarlem). So in some countries and languages people didn't stick to this definition. Go mass remove the property there, but don't destroy the work for the people who did do it properly. Multichill (talk) 09:11, 23 September 2017 (UTC)
The original English label is "number of platforms". The label was then changed without notifying translators to update the other labels. If this property is kept, we have to delete all statements added after the English redefinition and stick to the original proposal --Pasleim (talk) 10:05, 23 September 2017 (UTC)
Indeed, and @Multichill: even we can only consider tracks and ignore any kinds of "physical" platforms, please be aware that most stations in rural areas of Southeast Asian countries don't have any possible "platforms", on the other hand, a random abandoned station is likely having no tracks anymore? So in both cases are you sure 0 is suitable? NO! Stations without physical platforms are still stations (at least still providing board and alight services), and stations with no tracks are still stations! --Liuxinyu970226 (talk) 04:22, 22 October 2017 (UTC)
If you don't know how to use it, don't use it instead of trying to get it deleted. Multichill (talk) 16:34, 22 October 2017 (UTC)
  Keep --Ogoorcs (talk) 20:11, 19 October 2017 (UTC)
  •   Keep. We can always argue about the definition of "a platform" or "a platform track" and there will be borderline cases whatever criterion we go with. Use qualifier criterion used (P1013) or sources if fine distinctions need to be made. Deryck Chan (talk) 17:01, 8 November 2017 (UTC)
The problem is that there's no qualifier for the existing data, so we don't know how to interpret it. ChristianKl❫ 13:14, 23 December 2017 (UTC)
The vast majority of railway stations around the world have one track per platform. The definition of a "platform" also varies from station to station (e.g. most island platforms count as 2 platforms but there are exceptions), so we ought to allow some ambiguity in the way we record them on Wikidata. Wikimedia projects generally collect verifiable information from other sources and disambiguate as required, not impose our ontology onto the world's railway stations and force disambiguation upon information sourced from external sources. Deryck Chan (talk) 11:19, 13 February 2018 (UTC)

  Delete Given that the existing data can't be trusted to have a consistent meaning because of the name change. It's unfortunate but I don't think there's a way to transfer the existing data over in a way that won't leave a lot of errors. ChristianKl❫ 13:14, 23 December 2017 (UTC)

  Comment I applause the « has part / number » scheme, but the right property is has parts of the class (P2670)  . author  TomT0m / talk page 12:38, 22 January 2018 (UTC)
  •   Keep, describe with precision and correct errors. I support reasons describes by @Multichill:. There are a lots of properties with very poor use and meaning description in their talk pages. Usually, the english name is the only "clue" to understand what had in mind the creator when done; in addition, a bad translation (interpretation) of labels opens a missunderstanding that must be correct. However, the destruction of the present situation without write down a new precise "use of property handbook" of the new solution will (re)produce -in some time- a similar problem. Regarding solution « has part / has part of the type + number », I disagree because this generic properties increase the difficulty for "getting users" of WD, via query, via API or via WP module to build an infobox, for instance. Is easier to have an specific data for an specific concept, and leave these solutions for marginal situations not foreseen in the data model. Now, I'm working in create a "WD full powered infobox for stations" and the data collection for this area of knowledge is not the best we have. So, keep clear another conceptual inconsistences are prioritari to me than destroy the few content we have now. Thanks.Amadalvarez (talk) 06:20, 17 February 2018 (UTC)

Pokédex number (P1112) + Pokémon browser number (P1685)Edit

Pokédex number (P1112): (delete | history | links | entity usage | logs | discussion) Pokémon browser number (P1685): (delete | history | links | entity usage | logs | discussion)

It's too specific and get's used to justify other very specific property proposals. Existing data should be moved to catalog code (P528).--ChristianKl (talk) 19:36, 4 November 2017 (UTC) @Legoktm, Jakob:

  • I initially wanted to answer with {{vote_keep}} because I think wikidata should also provide space for very specific types of data. I like the approach you have with catalog code (P528) though. Lets find something similar for Stardate 😀 --Shisma (talk) 20:04, 4 November 2017 (UTC)
  •   Comment additional properties like this should not be created but this looks like a special exception. Pokémon seem to get sorted by this value in different lists. Before proposing a deletion we should come up with more detailed alternatives and examples. catalog code (P528) alone is not enough, how about the existing qualifiers? -- JakobVoss (talk) 08:22, 10 November 2017 (UTC)

Relations Ontology ID (P3590)Edit

Relations Ontology ID (P3590): (delete | history | links | entity usage | logs | discussion)

Duplicating equivalent property (P1628) as shown in this query:

SELECT ?property ?propertyLabel ?id ?equivalentProperty {
  ?property wdt:P3590 ?id .
    ?property wdt:P1628 ?equivalentProperty
    FILTER (STRSTARTS(STR(?equivalentProperty),""))
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en,en"  }    

Try it!

--JakobVoss (talk) 07:33, 8 November 2017 (UTC)

  •   Comment @Gstupp: what do you think, as property proposer? It does seem to me like this is a bit redundant. ArthurPSmith (talk) 19:07, 8 November 2017 (UTC)
  • My thought is that basically all external ID properties (for classes or properties) are potentially duplicates since you can add them as equivalent classes or equivalent properties respectively. They're functionally equivalent, for use in making SPARQL queries. One could add equivalent class statements to everything in Wikidata and make all external ID properties redundant. The only difference is that with the external ID, the format is consistent, whereas with the equivalent property purl, you can have multiple URI strings matching the same concept, which makes SPARQL queries inconsistent. For this reason I think the external ID property should stay. I'm not sure what makes this one special. I added the equivalent property statements while I was waiting for the RO property to be approved. Gstupp (talk) 21:43, 8 November 2017 (UTC)


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

Merge into language of work or name (P407) and rename P407 to "language".
P407 was originally called "language". Later, P407 was renamed to "language of work" and at the same time the proposal for language (P2439) was started to also have a language property for names and terms. Meanwhile, however, P407 is no longer used only for works, but also for names (~35,000 uses) and terms (~70,000 uses). With this perspective, the property language (P2439) (~2100 uses) is obsolete and an unncesseary complication. --Pasleim (talk) 15:15, 9 December 2017 (UTC)

  •   Comment There isn't much benefit in combining language of works with languages of names. language (P2439) was meant to cover this and uses of Property:P407 could be moved there. The main problem with P2439 is its label. It tends to be used for anything and the way the language is associated with an item is even less clear (I think Pasleim did quite a lot of cleaning up these days). We haven't even sorted this out for books yet ..
    --- Jura 15:24, 9 December 2017 (UTC)
  •   Delete This is just redundant and not-well-defined. If we need a new language property (do we?), let's make a new proposal with arguments pro and against. Matěj Suchánek (talk) 16:33, 9 December 2017 (UTC)
  •   Delete Unlike original language of work (P364) which is still controversial based on films, this property even doesn't have any criteria. --Liuxinyu970226 (talk) 10:41, 10 December 2017 (UTC)
  •   Delete But only if it is merged with language of work or name (P407) and if language of work or name (P407) is relabelled "language". Snipre (talk) 21:39, 12 December 2017 (UTC)
  •   Delete per Snipre. ChristianKl❫ 13:05, 23 December 2017 (UTC)
  •   Delete Will be more clear this way. --Fralambert (talk) 15:55, 23 December 2017 (UTC)
  •   Keep. Q5401 this proprerty Q2624777.--Arbnos (talk) 13:49, 6 January 2018 (UTC)
  •   Keep per Arbnos/Matěj Suchánek. Use this for names going forward.
    --- Jura 10:21, 7 January 2018 (UTC)
    • @Jura1: Attention please: Matěj Suchánek is voted delete above, so one of your "per" is invalid, would you please pick another user's comment, or just drop that "field value"? --Liuxinyu970226 (talk) 05:05, 10 January 2018 (UTC)
    •   Comment think about it, I'm sure you will figure it out.
      --- Jura 10:30, 10 January 2018 (UTC)
  •   Delete a confusing property. -- 23:14, 7 January 2018 (UTC)
  •   Delete confusing property - and rename language of work or name (P407) --Hsarrazin (talk) 09:40, 10 January 2018 (UTC)
  •   Delete. I don't get what all those language properties are trying to do. Thierry Caro (talk) 06:45, 23 January 2018 (UTC)
  •   Delete. Consensus can change and it seems that language (P2439) can now be merged back into language of work or name (P407), now that we have language used (P2936) to take care of the subset of cases where some consider it useful to have a more niche property. Deryck Chan (talk) 11:21, 24 January 2018 (UTC)
  •   Delete "per Jura". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:21, 15 February 2018 (UTC)

Riigikogu ID (P4287)Edit

Riigikogu ID (P4287): (delete | history | links | entity usage | logs | discussion)

This ID apparently doesn't have other use than being an ID for temporary web page for each of current 101 parliament members. This ID is not intended to be permanent. Each ID will be defunct (web page gone) as soon as person is no longer a parliament member. Currently 127 persons have this ID, so for 26 of them the ID is defunct or was defunct already at the time when added here, e.g. Q312894 or Q2621730. So storing these IDs here doesn't seem useful.--2001:7D0:88DD:F880:4C62:3A48:E43D:9237 13:41, 25 December 2017 (UTC)

  Keep Although it does seem that the Riigikogu website no longer shows the member's profile page when they're no longer a member (and thus we might want to change the formatter URL (P1630)), these IDs can still be used to access information on what the member did whilst in office, e.g. their speeches (Q312894, Q2621730), or questions (Q312894, Q2621730). If a member leaves office, and then returns, they also appear to retain their earlier ID. --Oravrattas (talk) 13:46, 26 December 2017 (UTC)
I don't have special expertise here, but if the formatter URL can be changed to save this, that sounds like the best option. --99of9 (talk) 00:10, 27 December 2017 (UTC)
  Keep per Oravrattas. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:23, 28 December 2017 (UTC)
  Question @Oravrattas: Can you fix the URL format string so that the IDs of former members of parliament will also lead to a valid link on the website? Deryck Chan (talk) 10:31, 23 January 2018 (UTC)
@Deryck Chan: sure, though it's not obvious to me which we should use. Is the idea simply that this should be any valid URL for people? Linking directly to, say, the person's speeches, might make it seem like that's what this property is about, rather than something more general. --Oravrattas (talk) 11:33, 25 January 2018 (UTC)
  •   Delete. I've looked at the links that Oravrattas gave me and figured that while the identifier is stable, there doesn't seem to be a single formatter URL that works well for all current and former parliamentarians. Given that these IDs are actually longer than the member's names (I wonder if they're just hashes of the member's name) I'm becoming convinced that this ID isn't particularly useful for Wikidata. Deryck Chan (talk) 11:00, 20 February 2018 (UTC)
    • Neither string length nor lack of a formatter URL is a good reason to delete a valid identifier property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:30, 20 February 2018 (UTC)

name shares origin with (P3484)Edit

name shares origin with (P3484): (delete | history | links | entity usage | logs | discussion)

Ash Crow
Harmonia Amanda
Чаховіч Уладзіслаў
Place Clichy
Jon Harald Søby
Sight Contamination
  Notified participants of WikiProject Names

This property was created on the sly, without notifying the Wikidata:WikiProject Names or any of its members, and is inconsistant with the ontology defined by the project (see Wikidata:WikiProject Names/Help).

Furthermore, more than one year after its creation, it has only one use, for the items Decker (Q2674262), Dicker (Q21502285) and Dikkers (Q28133204).--Ash Crow (talk) 19:48, 26 January 2018 (UTC)

Ping @Swpb: as original proposer and @GZWDer: as creator of the property. -Ash Crow (talk) 19:51, 26 January 2018 (UTC)
  Delete there was an existing ontology, used massively, combining said to be the same as (P460) with qualifier criterion used (P1013) and the reason. One year later, this property still has no uses, and everyone working on names kept the existing system. --Harmonia Amanda (talk) 20:00, 26 January 2018 (UTC)
@Ash Crow: Delete if you want, but I object vehemently to this being called "on the sly". I am not a property creator. I proposed a property where properties are proposed; it got consensus there and was created. I didn't even know at the time that there was a WikiProject to inform...and if informing WikiProjects is a policy, it's not one I've seen before - if it's unwritten but you expect people to follow it, write it down!! If it is written down, I apologize, but it isn't exactly obvious to find: it's certainly nowhere to be seen on Wikidata:List of policies and guidelines, or Wikidata:Property proposal, or Wikidata:Property proposal/Header, or Wikidata:WikiProjects... and while you're writing down guidance, please grab AGF from your more mature sister project. Swpb (talk) 20:29, 26 January 2018 (UTC)
  Delete do you really call consensus the 1 (one) positive vote you got, after 9 days ? without any notificztion to the project that has been working on names for years, now ? - not easy to find ? even if you don't know about the project, the general use is to ask on Project Chat about what to use, or if there are already existing properties, before proposing the creation of a new property, which generally results in someone pointing to the appropriate project. You did not ask about anything, made a proposal, got the creation with 1 vote, without bothering whether other people could be concerned… and this property is clearly NOT USED, except on the very specific item you used as example. This is not collaborative work... and this property, as it is, is useless and unused. --Hsarrazin (talk) 20:34, 26 January 2018 (UTC)
Again, I didn't make the property, and I didn't decide what level of consensus was needed! Take that up with User:GZWDer. (But yes, a decision with no opposing voices is a consensus, by definition, even if a provisional one – another thing your sister projects settled a long time ago.) But again, more about this mysterious "general use". Where the hell is any of this written down? If someone with a decade on Wikipedia can't see what's expected, how on earth is a total new person supposed to figure your project out?? I thought hostility to new users was bad on Wikipedia, but this project takes the cake. Not only are your procedures all of the form "we don't say so, but everyone knows it" - but when someone doesn't know it, the immediate assumption is that they're malicious! (See: "sly") You could not possibly shoot the viability of your project in the foot any harder than by acting like you are. Swpb (talk) 20:47, 26 January 2018 (UTC)
I didn't tell you are a property creator. My problem is more with the actual creator of the property (who created it rather quickly with only one vote) than with your proposal. As for the Wikiprojects, they are mentioned in the FAQ. If you come from another Wikimedia project, the weight given to consensus on wikiprojects can indeed be confusing, but as a very generalist project in multiple language, they provide a very efficient way to notify all people working on a particular topic. As for the part you "object vehemently": English is not my native language, so the expression may have stronger undertone than what I intended (I had to use Linguee to translate it to English) - what I wanted to say that it went under the radar. -Ash Crow (talk) 21:30, 26 January 2018 (UTC)
Appreciated. For future, yes, the word "sly" almost always implies intent to deceive. Swpb (talk) 14:05, 29 January 2018 (UTC)
If someone with a decade on Wikipedia can't see what's expected, how on earth is a total new person supposed to figure your project out??… well, like on any project : Ask the Project chat (whatever it is called on any project), which you did not ! --Hsarrazin (talk) 09:11, 27 January 2018 (UTC)
@Hsarrazin: Swpb (talk) 14:45, 1 February 2018 (UTC) Now you're going in circles: How could anyone know there was a question to be asked in the first place? Nothing I've ever come across would suggest this particular question! In fact, I still have not been shown where this "ask a WikiProject first" rule is written down, because it isn't, anywhere. I dare you to acknowledge that simple fact. Your project's documentation is embarrassingly lacking, and you're doubling down on defending the indefensible. I've pointed to at least four places where this supposedly well-known guidance should appear explicitly; you could apply your combative energy to making sure it does, instead of attacking people for not being mind-readers. That's assuming your goal here is to make a better project, instead of making yourself feel smart while driving valuable contributors away as fast as possible. Swpb (talk) 14:05, 29 January 2018 (UTC)
  •   Delete. Property created without consensus, duplicates the existing common usage without a "good selling point". Tpt (talk) 20:51, 28 January 2018 (UTC)
  •   Comment why was this requested without any intent of using it? @ArthurPSmith:
    --- Jura 12:57, 30 January 2018 (UTC)
    • @Jura1: I didn't request it, I just commented the one time. It sounded like the proposer had a use case for it, but if there's not many places it would help or there's a suitable alternative I don't have a problem with deleting it. This isn't an area I have worked in at all. ArthurPSmith (talk) 16:46, 30 January 2018 (UTC)
  •   Delete Humanization. --Liuxinyu970226 (talk) 04:22, 7 February 2018 (UTC)
  •   Keep. This will probably become superfluous when the Lexeme data-type comes in and we can actually store etymological information property. But in the meantime this property expresses a different logical relation from said to be the same as (P460) - the surnames are different in their current forms but have branched from the same surname. @Liuxinyu970226: What do you mean by humanization? Deryck Chan (talk) 11:10, 13 February 2018 (UTC)
  •   Delete Seems not to be needed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 15 February 2018 (UTC)

eFlora propertiesEdit

We currently have Flora of North America taxon ID (P1727) and Flora of China ID (P1747), each representing subjects at - their formatter URLs are, respectively,


It turns out that these are storing members of the same single set of values, which can mean storing the same value twice where a plant species (or even more commonly, a parent taxon like a genus, or a family, such as Orchidaceae (Q25308) ) occurs in both places.

Unfortunately, that was not declared when the second of those properties was proposed.

Not only that, but the eFloras site has many other floras and checklists (listed on its home page), using the same type of ID. In some cases twenty or more of these use the same value (see example, below), and thus we would need twenty or more properties to link to them all in the same manner:

It is possible - and would be sensible - to combine these as one property, using the formatter URL$1 (example for same taxon: - note that that includes links to all of the individual flora pages shown in the collapsed section above).

We could either create a new property, migrate values from, and then delete, both of the above properties; or migrate values from one to the other and delete the former and rename the target. I am ambivalent as to which solution is best. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 7 February 2018 (UTC)

Achim Raschka (talk)
Brya (talk)
Dan Koehl (talk)
Daniel Mietchen (talk)
Delusion23 (talk)
FelixReimann (talk)
Infovarius (talk)
Joel Sachs
Josve05a (talk)
Klortho (talk)
Lymantria (talk)
Mellis (talk)
Michael Goodyear
Nis Jørgensen
Andy Mabbett (talk)
Prot D
Rod Page
Soulkeeper (talk)
Strobilomyces (talk)
Tommy Kronkvist (talk)
  Notified participants of WikiProject Taxonomy --Succu (talk) 21:57, 7 February 2018 (UTC)

  Keep. Both are pubished as books too. --Succu (talk) 22:01, 7 February 2018 (UTC) BTW: Why should we link to a search result? --Succu (talk) 22:11, 7 February 2018 (UTC)

Because that's the format used by the target website; and because, as shown above, it gives the best results. And just as in many other properties, such as ITIS TSN (P815) and NLM Unique ID (P1055). Oh, and IPNI plant ID (P961), whose formatter URL is$1 and which you enthusiastically supported. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 14 February 2018 (UTC)
Assuming you are responding to my question:
  1. A search by id is not documented at the Flora Search Page, but a search by Latin Name:
  2. The formatter URL used for IPNI is a search by id and results in a single record.
--Succu (talk) 20:38, 14 February 2018 (UTC)
This is not the forum to complain about deficiencies in the documentation on the eFlora website; contact details for such purposes may be found on that site. The formatter URL I gave above is also a a search by id and results in a single record; helpfully that record has links pointing to the 20+ (in my example) other records that eFlora holds for the taxon. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:25, 14 February 2018 (UTC)
ROFL, Mr. Mabbett. --Succu (talk) 22:44, 14 February 2018 (UTC)

  Keep. As per Succu. Dan Koehl (talk) 10:26, 8 February 2018 (UTC)

  Keep. Also agree with Succu. Cheers Scott Thomson (Faendalimas) talk 11:27, 9 February 2018 (UTC)

  Keep: why make it unnecessarily complicated. Also, this approach would make it much more difficult to edit an item. - Brya (talk) 04:17, 10 February 2018 (UTC)

This proposal reduces, rather than increasing, complexity (one property rather than 20+; one value on an item, rather than 20+ identical values). No evidence to support the assertion that it would "make it much more difficult to edit an item" has been offered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:34, 12 February 2018 (UTC)
Also, I found this quote, on the proposal discussion for P1727: "As all the e-flora's use the same number, perhaps they can be handled all together? Not sure how many of them are really interesting (North America, China, Pakistan, Taiwan, any others?)." - Brya 18:19, 16 February 2015 (UTC) . Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:31, 12 February 2018 (UTC)

has dialect (P134)Edit

has dialect (P134): (delete | history | links | entity usage | logs | discussion)

A while ago, Wikidata:Property_proposal/dialect_of was proposed and quite a few editors were supporting the creation under the condition that "has dialect" (has dialect (P134)) is deleted, because "dialect of" should be the correct direction for this relation. The discussion has stalled there so I am proposing P134 for deletion.

Pinging the editors involved: @BrillLyle, Nikki, Giovanni Alfredo Garciliano Diaz, Pigsonthewing, Charles Matthews, Yair rand: @John Cummings, Pasleim, ديفيد عادل وهبة خليل 2, PKM, Hsarrazin, ArthurPSmith: should we delete Property:P134?

Of course, if there is a clear consensus here, "dialect of" should be created first so that the existing information can be migrated. − Pintoch (talk) 10:36, 10 February 2018 (UTC)

  •   Support I agree with the logic, and this also seems in line with common sense about referencing: "A is a dialect of B" is what you'd mostly expect. Charles Matthews (talk) 10:45, 10 February 2018 (UTC)
  •   Support I think so, having has dialect (P134) will be redundant. Also, it's information that should be on the dialects items (through dialect of), not in the main item. --Giovanni Alfredo Garciliano Díaz diskutujo 19:33, 10 February 2018 (UTC)
  •   Delete Visite fortuitement prolongée (talk) 22:36, 10 February 2018 (UTC)
  •   Delete. --Yair rand (talk) 15:54, 11 February 2018 (UTC)
  •   Delete provided "dialect of" is created first and appropriate jobs are run to transfer the data before deletion. - PKM (talk) 19:22, 11 February 2018 (UTC)
  •   Delete has good replacement. --Liuxinyu970226 (talk) 14:33, 12 February 2018 (UTC)
  •   Delete ArthurPSmith (talk) 16:26, 12 February 2018 (UTC)
  •   Delete or   Keep, so long as we only have one property, per my comments at Wikidata:Property proposal/dialect of. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:32, 12 February 2018 (UTC)
  •   Weak oppose. I agree that "[subject] is a dialect of [object]" is the more useful property, but "[subject] has dialect(s) [object]" is useful for infoboxes about languages too. I weakly prefer to have both, but if the consensus is that there can only be one I would rather have the new "is dialect of" property. Deryck Chan (talk) 11:21, 13 February 2018 (UTC)
  •   Delete after creation of "dialect of" and transfer of data --Hsarrazin (talk) 13:36, 13 February 2018 (UTC)
  •   Delete or   Keep per Andy. Mahir256 (talk) 16:46, 14 February 2018 (UTC)


Wolfram Language entity code (P4839): (delete | history | links | entity usage | logs | discussion)

Creation seems to be premature, format was still being discussed.
--- Jura 03:50, 14 February 2018 (UTC)

@Jura Compare with place/Earth (Encyclopædia Britannica Online ID (P1417)), we do not break this down into place and Earth. I think the case is even better for Wolfram Language entity code (P4839) since place/Earth is just a URL snippet while Entity["Country", "Japan"] is the input form as given by the function InputForm. However, while the formatter URL works in the property examples of the property page, it does not work in the item pages such as here. The examples also do not show up well in the property talk page because of the ] bracket and the property is not recognized as an identifier (not sure whether it should be considered as such). -- IvanP (talk) 05:41, 14 February 2018 (UTC)
  • Datatype seems incorrect, in my opinion. These are all things that still need to be sorted out. Not sure if people read much of the proposal. It's not a property for languages as some assumed.
    --- Jura 05:46, 14 February 2018 (UTC)
  • Keep. Clear consensus for creation. Also @Mahir256, ArthurPSmith, Liuxinyu970226, GZWDer: from that discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:17, 14 February 2018 (UTC)
  •   Keep Jura's arguments make no sense to me. The consensus seemed clear other than his comments, which I simply do not follow. ArthurPSmith (talk) 15:41, 14 February 2018 (UTC)
  •   Keep I concur with Jura that we (or more specifically @IvanP:) should cease using the property until format concerns are resolved, but I disagree with deleting the property entirely. We've discussed formats for some properties long after they've been created--heck, some properties are so underused that we could start a discussion for one's format with the most minimal of impacts. Mahir256 (talk) 16:44, 14 February 2018 (UTC)
Maybe change the data type to external-id? -- IvanP (talk) 17:02, 14 February 2018 (UTC)
@IvanP: As far as I'm aware, data types can only be changed by deleting the property and re-creating it with the correct data type. (  Support deleting and recreating as external-id property.) --Yair rand (talk) 22:06, 14 February 2018 (UTC)
  •   Delete and recreate as external-id, since string datatype results many confusing Lint errors in many wikis. --Liuxinyu970226 (talk) 07:49, 15 February 2018 (UTC)
  • Just to clarify: I do think this should eventually be created. The question is just with what format. And yes, I think we should avoid changing around formats once a property is created. I don't think we should oppose the creation of properties merely because the format isn't sorted out yet.
    --- Jura 09:10, 15 February 2018 (UTC)
  •   Keep consensus for creation --Pasleim (talk) 09:16, 15 February 2018 (UTC)