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

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

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

What property do you think I want to keep?

original language of work (P364)

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

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

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

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

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

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

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

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

Movies (or possibly Japanese animes)Edit

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

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

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

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

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

Konggaru Starry K. Zerabat Erne Mogilevich Santer AldNonUcallinme? Thibaut120094 Shikeishu 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 no label (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

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 [5]. 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 [6] work [7] having multiple parts [8]. On the parts items you state that these are English translations [9]. You also provide for each translation a link to the original work item [10]. On the original work items you state that these are works [11] in Ancient Greek [12]. 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)
  Support only reasonable solution --Pasleim (talk) 18:16, 27 March 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)
  Oppose even after months no reason is provided why the language of a movie should be described in a different way than for examples songs, websites or books --Pasleim (talk) 18:16, 27 March 2018 (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)

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 [13] [14]. 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 [15] [16] [17]. 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 no label (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 no label (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)
Then this property should have subject item of this property (P1629) which value? If there's no criteria way that to be documented then @amadalvarez: I suggest you to change your keep to delete because the Dutch translation means "number of railway tracks" which probably has way to mean "of a railway line", the Hungarian usage (currently only one usage) should be checked either @tgr, tacsipacsi:. -- 23:25, 1 March 2018 (UTC)
Let my ask, what's the alternative property when we delete this one ?. I just say that, before delete, we all together must agree with a non ambigous definition and then, or create a new one property or redefine this one and clear all content that doesn't match with the new definition. My concern is that some people think that deletion must solve the problem (it remind me a President that wanted to chop all forest to avoid the forest fires). I'm not defending present situation, I just want to avoid repeat the problem when someone else try to create a property to "track lines" or "point to get the train" or "platform that can be show at display station" or... or.... Thanks, Amadalvarez (talk) 12:45, 2 March 2018 (UTC)
  • Delete The current property is ambiguous within and between languages and inconsistently used to the point where it is not even possible to say what the correct value for any station more complicated than a single track adjacent to a single platform with a single signalling berth, let alone whether any particular value matches that. The diagram illustrates just some of the problems, not showing bay platforms for example. One aspect of the problem is that there are no standard, unambiguous terms for most of the different types of platform and almost no sources specify how the platforms are being counted. It is not even standard between stations in the UK - Bristol Temple Meads uses the red numbering system, Birmingham New Street uses the blue system, Stratford isn't even consistent within itself (3/3A, 4A/4B and 11/11A are all different layouts). The way forward is to hammer out what exactly we want to count and then figure out how to describe that, then figure out how to represent that in Wikidata, then figure out how to translate the data into that format. The current property is not useful for any of that. Thryduulf (talk) 20:35, 3 May 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)

@Ju gatsu mikka, Ebe123, Airon90, MGChecker: What do you think about this? You have edited Pokemon species items. --Okkn (talk) 10:08, 16 April 2018 (UTC)

I agree P1685 is too specific, however I agree with user:Okkn that a specific property for Pokédex number has major benefits for data integrity. How would you like to specify similar constraints with P642? --MGChecker (talk) 19:40, 17 April 2018 (UTC)
  Good bye as Pokedexes can also be different between series (don't surprise, PM anime also have characters that ruled different dexes), I can't see a neutral way to create a lot of properties in order to sync something that ≤1000 usages. --Liuxinyu970226 (talk) 13:21, 25 April 2018 (UTC)



download link (P4945)Edit

download link (P4945): (delete | history | links | entity usage | logs | discussion)

Created not trough property proposal process--Edgars2007 (talk) 11:35, 14 March 2018 (UTC)

  • I'm not sure deletion is the right response here, as it maybe useful to have this. Although I believe there were previous discussions for similar properties that had a number of reason to oppose having download URL's as part of our data. But I'm more concerned that one of our property creators, MichaelSchoenitzer appears not to be aware of Wikidata:Property creators. How did that happen? ArthurPSmith (talk) 15:19, 14 March 2018 (UTC)
    • I got the right at at time when there rules haven't existed yet. I knew Property Proposal and used this process but didn't thought it's a "no exceptions"-rule. (The site also does not sound like that.) I proposed splitting the property streaming media URL (P963) and no one disagreed. When someone renamed the old property I paniced because so we now have a few thousand wrong statements in Wikidata. I'm sorry I broke rules I didn't knew, I won't do again but I still think that we should clean this up quickly but that's on other people to decide now. -- MichaelSchoenitzer (talk) 21:49, 14 March 2018 (UTC)
  • @MichaelSchoenitzer: The argument that another property is being abused to support this is a good one for creating it. However, there is quite a bit of history here - here are previous discussions along these lines where the proposal was rejected or at least not yet approved: Wikidata:Property proposal/download link, Wikidata:Property proposal/external image URL (which links to older proposal discussions in the "see also" section). @NMaia, Pintoch, Mahir256, ChristianKl: @Pigsonthewing, ديفيد عادل وهبة خليل 2, Strakhov, Pasleim, Jura1: what do you think on this now? ArthurPSmith (talk) 14:24, 15 March 2018 (UTC)
  •   Delete agree with nominator.
    --- Jura 09:26, 19 April 2018 (UTC)
    •   Comment Somehow I missed that we actually had a proposal for this at Wikidata:Property proposal/download link (see comment below by Jasc PL) and the conclusion of that was not to create this.
      --- Jura 06:55, 8 May 2018 (UTC)
  •   Keep, or delete - if a property proposal process is the absolute rule for us; move this discuss to Wikidata:Property proposal/download link, then recreate download link (P4945) (I hope) with this exact name. There are several important arguments for having this property. BTW, I see that computing items needs are much insufficient represent in the WD. --Jasc PL (talk) 14:55, 20 April 2018 (UTC)

Ruud Koot
Daniel Mietchen
Giovanni Alfredo Garciliano Diaz
Jasc PL
  Notified participants of WikiProject Informatics I would like to be able to use a property like download link (P4945) on open source software items to list the download URL of particular software versions (sourced from the official website, source control systems of Linux distribution package repositories, etc). In many cases, the qualifier checksum (P4092) could and should be included, sourced from either official website and/or Linux distribution package repositories. file format (P2701) should also be a mandatory qualifier. What I am not clear on, is what is the difference between download link (P4945) and full work available at (P953)? Could the scope of full work available at (P953) simply be expanded to include software source distributions, binaries, etc? If so, how would one determine which URL is for a source tarball, and which is a binary package? How would one handle software which has multiple binary packages (either for different CPU architectures or different Linux distribution packaging systems)? Dhx1 (talk) 14:15, 20 April 2018 (UTC)

Full   Support for Dhx1 arguments. --Jasc PL (talk) 14:55, 20 April 2018 (UTC)


number probable (P1675): (delete | history | links | entity usage | logs | discussion)

Unused qualifier --- Jura 13:49, 1 April 2018 (UTC)

  Speedy delete Created by error. --Liuxinyu970226 (talk) 06:11, 5 April 2018 (UTC)
  •   Weak oppose. The property creation proposal was clear about the purpose of this property. @Blue Rasberry, Filceolaire, Emw: Can you let us know whether you still intend to start using this property? Deryck Chan (talk) 09:17, 19 April 2018 (UTC)
  •   Comment I don't think it was created by error either. It's just not used. I came across it when checking completeness of constraints on properties.
    --- Jura 09:21, 19 April 2018 (UTC)

Projeto Excelências ID (P2731)Edit

Projeto Excelências ID (P2731): (delete | history | links | entity usage | logs | discussion)

The current notice over at says the site (and consequently its database) has been shut down due to a lack of funding.--NMaia (talk) 11:56, 10 April 2018 (UTC)

  Keep The formatter URL no longer working as a result of the site’s closure does not mean it is no longer useful; there are discussions about DMOZ ID (P998) around the time DMOZ shut down and we still have that property today. Mahir256 (talk) 14:33, 10 April 2018 (UTC)
  Comment I deprecated the formatter url, but it seems that this property hasn't really been put to use   Delete
--- Jura 19:30, 10 April 2018 (UTC)
Should we really delete a property because so far it hasn't been used much? Because the simple answer here would be to simply use it more. The point here is moot however since the database is down and we don't know the IDs anymore. NMaia (talk) 22:56, 21 April 2018 (UTC)
@NMaia: I think the situation would be different if there were 500 uses. Compare with Wikidata:Properties_for_deletion#Supermodels.nl_ID_(P3330) below.
--- Jura 10:40, 4 May 2018 (UTC)
  Delete In this case, and unlike dmoz, as a backup site even doesn't exist, delete it won't make anything broken. --Liuxinyu970226 (talk) 10:34, 23 April 2018 (UTC)


  • Closure seems to be premature. Besides the creator hardly anyone has commented.
    --- Jura 21:20, 6 May 2018 (UTC)
    @Jura1: Feel free to recreate another request. --Liuxinyu970226 (talk) 14:10, 7 May 2018 (UTC)


Rosetta Code ID (P5047): (delete | history | links | entity usage | logs | discussion)

  • Per Liuxinyu970226 above.
    --- Jura 06:46, 8 May 2018 (UTC)
    • I believe nobody commented on this nomination because none of the links was provided to back up the deletion. Jura, Could you provide a link to the discussion where it was decided that wiki links should be string-datatype. Alexei Kopylov (talk) 20:49, 8 May 2018 (UTC)
  •   Neutral I need to ping users who edited it: @Micru, Renamerr, Милан Јелисавчић, Arnaugir, Thierry Caro:, and users that joined that property proposal: @ديفيد عادل وهبة خليل 2, ArthurPSmith, Pigsonthewing: to hear if they still against deletion or not. --Liuxinyu970226 (talk) 12:32, 9 May 2018 (UTC)
  •   Keep Seems fine as external id - see Dijkstra's algorithm (Q8548) for example, 3 out of 4 identifiers are similar-looking strings, this doesn't look out of place at all there. ArthurPSmith (talk) 13:24, 9 May 2018 (UTC)
  • @Jura1: On the previous discussion you said "I think the datatype question needs to be resolved first.", can you please explain what is the "datatype question"? You also said: "you really shouldn't be trying to assess consensus and closing the discussion all in the same post", here I disagree because although you also belong to the group of property creators you seem to ignore the situation that to do what you propose takes too much energy and effort that might not be available. It definitely can be done in special circumstances (I have done it myself in the past) but definitely not for all property proposals, and also not for property proposals that had low participation as this one. Do you agree with that? --Micru (talk) 10:14, 20 May 2018 (UTC)

units used for this property (DEPRECATED) (P2237)Edit ID (P3330)Edit ID (P3330): (delete | history | links | entity usage | logs | discussion)

The website has been down for more than one year.--Thierry Caro (talk) 19:00, 20 April 2018 (UTC)

  •   Delete The site has been inactive for over a year, I actually checked this once in a while. Currently it just adds noise and helps no-one. DGtal (talk) 06:00, 22 April 2018 (UTC)
  •   Comment the property seems to have a reasonable number of uses (500). Was it useful when it existed?
    --- Jura 06:04, 22 April 2018 (UTC)
    • I don't know. DGtal (talk) 22:18, 26 April 2018 (UTC)
  • Keep Just update or remove the formatter URL. The IDs are still useful data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:37, 30 April 2018 (UTC)
    • What use to they have? They give you no information except a number of a dead URL. What can you do with that? DGtal (talk) 06:24, 2 May 2018 (UTC)

FIPS 5-2 (code for US states) (P883)Edit

FIPS 5-2 (code for US states) (P883): (delete | history | links | entity usage | logs | discussion)

This property has been split into two new properties - FIPS string code for US states (P5086) and FIPS numeric code for US states (P5087), and all US states have been updated. See new properties discussion. You can use this query to see that all values match.--Yurik (talk) 21:19, 22 April 2018 (UTC)

cc: @Aude, Danrok, Docu, Jura1, Mahir256, Pintoch:

  Delete note that kawiki claims to be using it, so probably has a template that needs fixing. ArthurPSmith (talk) 12:56, 23 April 2018 (UTC)
  DeletePintoch (talk) 17:38, 23 April 2018 (UTC)

USGS-ANSS event page (P5089)Edit

USGS-ANSS event page (P5089): (delete | history | links | entity usage | logs | discussion)

Seems to be a duplicate of USGS earthquake ID (P3196)--NMaia (talk) 14:34, 23 April 2018 (UTC)

  DeletePintoch (talk) 17:37, 23 April 2018 (UTC)
  Comment @NMaia: can you give examples? 1906 San Francisco earthquake (Q211386) doesn't have a USGS earthquake ID (P3196) and the structure looks different in the ones I've seen. ArthurPSmith (talk) 19:45, 23 April 2018 (UTC)
They seemed similar enough for me to suspect it, but I don't have definitive evidence they're the same. NMaia (talk) 20:28, 23 April 2018 (UTC)
Identifiers on the USGS website consist of a network identifier and a network assigned code. The network identifier is often two characters long (as currently enforced by USGS earthquake ID (P3196)) but also longer network ids like "official" (as in 1906 San Francisco earthquake (Q211386)) are possible, see [18]. --Pasleim (talk) 21:00, 23 April 2018 (UTC)

@DarTar, Thryduulf, Andrawaag, Daniel Mietchen, YULdigitalpreservation, ChristianKl: from the first proposal discussion and @ديفيد عادل وهبة خليل 2, YULdigitalpreservation, Gerwoman: from the second (minus those who have already commented above). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:04, 2 May 2018 (UTC)

MyDramaList name ID (P3862)Edit

MyDramaList name ID (P3862): (delete | history | links | entity usage | logs | discussion)

This appears to be spam, the site is blacklisted on enWP for spamming. It has no obvious use other than promoting a site that is not usable as a source.--JzG (talk) 18:19, 1 May 2018 (UTC)

  Keep - "usable as a source" is not a requirement for a property on Wikidata. @CherryPie94: from the original proposal discussion. Neither they, nor I, are spammers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:00, 2 May 2018 (UTC)
  Keep Banned on English Wikipedia doesn't mean banned on other WMF sites, even in the case that that is listed on global spam blacklist. The English Wikipedia eventually doesn't allow using [[d:QXXX]], but what happened? Its only result is that many new and brave Wikidata users no longer trust English Wikipedia. --Liuxinyu970226 (talk) 07:34, 6 May 2018 (UTC)

island of location (P5130)Edit

island of location (P5130): (delete | history | links | entity usage | logs | discussion)

This property was proposed at Wikidata:Property proposal/landmass, where it went rather unnoticed, with only two !votes before it was created. It subsequently changed from 'landmass' to 'island of location' (I'm not sure why), and around 8,000 values were subsequently moved over to this from located on terrain feature (P706), location (P276) and part of (P361) (which is when I noticed it, as some of the changes appeared on my watchlist).

From my perspective, there's not a sufficient difference from located on terrain feature (P706) to justify having this property, and it adds unnecessary complications to templates that concatenate the various location strings together (templates like commons:Template:Wikidata location already do located on terrain feature (P706)+location (P276)+located in the administrative territorial entity (P131)+country (P17)+continent (P30) to come up with a useful location string). Discussing this at Property talk:P5130, the main rationale seems to be "uses of located on terrain feature (P706) are a mess", which is a justification for cleaning up uses of that property, not creating a new one. So I think this needs further discussion/thinking through, before it has more widespread usage, or deletion - hence why I'm raising it here. Thanks. Mike Peel (talk) 00:22, 9 May 2018 (UTC)

Ping @Thierry Caro, ArthurPSmith, Fralambert, Pintoch, Esquilo, Jura1: as people that contributed to the property proposal and commented on the property's talk page. Mike Peel (talk) 00:25, 9 May 2018 (UTC)
  Comment What I think it is if we could merge continent (P30) and island of location (P5130). They have mostly the same definition, except that island of location (P5130) use a smaller unit. --Fralambert (talk) 00:32, 9 May 2018 (UTC)
  Comment. I'd rather delete located on terrain feature (P706), which matches with no simple concept in human daily life. Which island a thing is on is understandable. Which terrain feature it belongs to, well, I am not that sure. So let's move what should be back to location (P276) and have the new specific properties populated. The older one was created a long time ago when we were OK with having unclear declarations under catch-all umbrellas. It is now a source of constraint violations and uncompleteness. Thierry Caro (talk) 00:48, 9 May 2018 (UTC)
  Comment I Always saw located on terrain feature (P706) as quite a simple concept as well as convenient. What exactly makes you see it as anything else? Can you point to examples of those "constraint violations" you talk about?--Hjart (talk) 21:25, 10 May 2018 (UTC)
  Delete located on terrain feature (P706) is a more general property that can be used regardless if the object stand on an island, a peninsula, a hill, a mountain, a plain or whatever. The datamodel used on Wikidata today is unconsidered and uncoordinated. There are too many properties thoughtlessly created. Fewer and more general properties and better use of qualifires is the only way out of this swamp. /ℇsquilo 12:15, 9 May 2018 (UTC)
  Keep I'm also not sure why it changed from "landmass" to "island of location", I assume this was to distinguish from continent (P30). However, I believe those are really quite different concepts - a "continent" generally includes many islands in addition to the main land area (for example Long Island, Vancouver Island, etc. are surely all part of North America), and several "continents" may be located on one landmass (Europe and Asia most notably). I think this is definitely a useful property to have; it's sort of a complement to watershed (P4614) for example. ArthurPSmith (talk) 13:20, 9 May 2018 (UTC)
@ArthurPSmith: 'Watershed' is quite different, as you wouldn't normally include that in a string describing the location of somewhere (it's more likely to be a separate line in an infobox). Agree that this and 'continent' are different things, though. In a string of "Located on <X>, location, located in administrative area, country", I'm worried that we'll have to check a huge number of X's, which will vary between topics, rather than just a single one as we currently do - and that makes things unnecessarily complex. Thanks. Mike Peel (talk) 13:39, 9 May 2018 (UTC)
Mike Peel I'm not sure why you think every type of located on terrain feature (P706) would always be useful in a location string, but this new property has been declared as a subproperty of (P1647) of located on terrain feature (P706), so perhaps your code should first just programmatically look up all subproperties of located on terrain feature (P706) and use those? ArthurPSmith (talk) 13:44, 9 May 2018 (UTC)
@ArthurPSmith: I'm not sure Lua can even do that? Thanks. Mike Peel (talk) 13:50, 9 May 2018 (UTC)

  Delete One can not have different properties for an item of same forekomst av (P31) depending on the location is on an island or not. This will end up having Properties like located on a mountain, a peninsula, desert, sump and so on. Pmt (diskusjon) 14:59, 9 May 2018 (UTC)

  Neutral I think generally, use of located on terrain feature (P706) should be expressive enough. The property may be useful in some cases, but I do not support imposing on using it. – Susanna Ånäs (Susannaanas) (talk) 04:33, 15 May 2018 (UTC)

  Delete located on terrain feature (P706) did work well for most instances I have seen. I always thought of it's target as quite simply a "geographic area" and as such could be almost any area, land or sea, forest, island, settled area etc. I suspect Thierry simply misunderstood it.

  Keep. It is a very basic thing to know which landmass something is situated on. It is probably the most important location property we should have, together with located in the administrative territorial entity (P131). Thierry Caro (talk) 20:39, 20 May 2018 (UTC)

But at least I am very happy to know that there now is ONE subproperty of located on terrain feature (P706) and hoping that other subproperties will come soon. Breg Pmt (talk) 23:54, 20 May 2018 (UTC)

There are already other subproperties to located on terrain feature (P706). These are continent (P30), mountain range (P4552), watershed (P4614), geomorphological unit (P4688). They are very useful. Thierry Caro (talk) 00:00, 21 May 2018 (UTC)
And further will be needed... Untill those propeties equal and to the same Level as island of location (P5130) are settled I propose that island of location (P5130) are deleted, and a clear structure of how man made geographical objects location should be described by properties in air, land, sea and space. Breg Pmt (talk) 00:56, 21 May 2018 (UTC)