Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
Jump to navigation Jump to search

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.






a query

for deletions

for comment


for permissions


for deletion

and imports




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 no label (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: no label (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 (no label (P2439))
a, b - remove 364 (and possibly 407)
c - not relevant here, use edition or translation of (P629) and has 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 works[edit]

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

How would we describe Digte (Q23009890) (regardless of whether it is a work or a 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 -Zest ReaperDawn

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

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

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

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

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

Also @Jura1: if you keep vote is having the reason of 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 example[edit]

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

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

What about P2439?[edit]

Moving forward and alternative proposal[edit]

@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 Symbol delete vote.svg 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)
  • Pictogram voting comment.svg 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)
Pictogram voting comment.svg 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 thread[edit]

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)

Symbol oppose vote.svg 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 reasons[edit]

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

Symbol oppose vote.svg 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"

Symbol neutral vote.svg 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)
Symbol support vote.svg Support only reasonable solution --Pasleim (talk) 18:16, 27 March 2018 (UTC)

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

Symbol support vote.svg Support --Liuxinyu970226 (talk) 14:34, 20 December 2017 (UTC)
Symbol support vote.svg Support --Pasleim (talk) 13:41, 21 December 2017 (UTC)
Symbol oppose vote.svg 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)
Symbol support vote.svg 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)
Symbol support vote.svg Support and change label per Snipre ArthurPSmith (talk) 21:52, 5 February 2018 (UTC)
Symbol support vote.svg Support and change label - seems like a consensus solution to me. - PKM (talk) 19:15, 31 July 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)

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

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

Symbol keep vote.svg Keep first flight (P606) and time of spacecraft launch (P619) because they have almost (or over) 5000 uses [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)
Symbol delete vote.svg Delete time of spacecraft landing (P620), time of spacecraft orbit decay (P621) and spacecraft docking/undocking date (P622) because they have at most 350 uses [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)
Pictogram voting comment.svg Comment we shouldn't make decisions in any direction based on current usage. Maybe we don't have understanding what exactly is better, but we shouldn't make popularity-driven decisions. d1g (talk) 04:51, 10 August 2017 (UTC)
  • Symbol keep vote.svg Keep seems to be a working set of (sub-)properties.
    --- Jura 14:50, 9 July 2017 (UTC)

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

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

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

@Liuxinyu970226: I looked at the property talk pages and checked the templates that used these properties. it:Template:Infobox missione spaziale is an example that uses the {{#Property:}} syntax (through Template:Wikidata (Q8478926)) to fetch this property. I'm not aware of any use of these properties on yue.wp. So my suggested plan of action is (0) mark these properties as deprecated (1) copy these statements into the proposed new statement structure (2) modify all the relevant templates to transfer all uses of these properties in other Wikimedia sites to the new statement structure (3) finally delete the property. Deryck Chan (talk) 11:22, 31 October 2017 (UTC)
I've recently learned that it's not possible to select statements based on qualifier values using {{#statements:}}. Module:Wikidata (Q12069631) and 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)

Symbol keep vote.svg Keep I vote to keep. There is no such thing as "too much specific". We have "subproperty" property for a reason. --Ogoorcs (talk) 01:56, 8 September 2018 (UTC)

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)
  • Pictogram voting comment.svg 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)
Symbol delete vote.svg 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)
  • Symbol delete vote.svg Delete agree with nominator.
    --- Jura 09:26, 19 April 2018 (UTC)
    • Pictogram voting comment.svg 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)
  • Symbol keep vote.svg 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
Pictogram voting comment.svg 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 Symbol support vote.svg Support for Dhx1 arguments. --Jasc PL (talk) 14:55, 20 April 2018 (UTC)
  • Symbol delete vote.svg Delete Needs to come through proper property proposal process.--Jklamo (talk) 07:57, 31 May 2018 (UTC)
  • Symbol keep vote.svg Keep --Niridya (talk) 14:47, 16 August 2018 (UTC)
    @Niridya: for what reason? --Liuxinyu970226 (talk) 23:04, 13 September 2018 (UTC)
    @Liuxinyu970226: : sometimes it can be useful. For example to create a link to the download page of a software. --Niridya (talk) 18:01, 14 September 2018 (UTC)
  • Symbol keep vote.svg Keep Germartin1 (talk) 12:56, 12 October 2018 (UTC)


WSJ topic ID (P3183): (delete | history | links | entity usage | logs | discussion)

This external id property is broken and also seems to be unfixable. Was deleted from enwiki on the same rationale Gotitbro (talk) 21:44, 21 May 2018 (UTC)

  • Pictogram voting comment.svg Comment You mean the formatter URL is broken? That doesn't necessarily mean the identifier is invalid. If there's more to this perhaps you can link to relevant documentation/discussion? ArthurPSmith (talk) 14:23, 22 May 2018 (UTC)
  • @ArthurPSmith: WSJ seems to have discontinued the use of topical categories on its website so the formatter URL cannot be fixed at all. This property is deprecated. I have already linked the Engish Wikipedia discussion above. Gotitbro (talk) 11:09, 12 June 2018 (UTC)
  • Symbol delete vote.svg Delete if it was discontinued. Doesn't really seem to be used (~100).
    --- Jura 14:14, 1 June 2018 (UTC)
  • Symbol delete vote.svg Delete Ok, I'll go along with that, seems not much point to keep it now. ArthurPSmith (talk) 15:07, 13 June 2018 (UTC)
  • Symbol keep vote.svg Keep "the formatter URL cannot be fixed at all" Oh, really? I fixed it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 22 June 2018 (UTC)
  • Symbol keep vote.svg Keep I don't see why we should delete a historic (at this point) identifier. Linking to the Wayback machine is a reasonable fix. I expect we will need to do this for many more external ID properties to come in the following years... --Azertus (talk) 19:35, 12 September 2018 (UTC)
  • Pictogram voting comment.svg Comment I don't know if we can mark a property as deprecated so that it doesn't show up in the suggestions anymore? Users wanting to still add IDs could do so by pasting the property ID into the search box. --Azertus (talk) 19:37, 12 September 2018 (UTC)

item for this sense (P5137)[edit]

Soundex (P3878)[edit]

Soundex (P3878): (delete | history | links | entity usage | logs | discussion)

This property can be computed by clear and fast algorithm from other data. It's a very bad practice to store such data in a database.--Ignatus (talk) 10:04, 13 July 2018 (UTC)

Will SPARQL provide a function for this?--GZWDer (talk) 10:53, 14 July 2018 (UTC)
  • That's nothing impossible in providing such an extension function (in the Callimachus project they have keyword:soundex, we can have e.g. wikibase:soundex). I don't know how deep in the database interface levels it can be put, but the developers can be contacted to ask for it if it is needed (that is probable). This is longer to wait for but way more flexible then introducing any property, and, the main thing, duplicating data is evil. Ignatus (talk) 19:31, 14 July 2018 (UTC)
  • Would you do the necessary to implement it and come back to us once it's done?
    --- Jura 07:10, 15 July 2018 (UTC)
  • Symbol keep vote.svg Keep Calculating anything in SPARQL is a phenomenally bad move, to be avoided if at all possible. The whole reason SPARQL can be efficient is that it is based on fast indexed lookup searches. That's not possible with calculated values. Jheald (talk) 23:29, 14 July 2018 (UTC)
  • Symbol keep vote.svg Keep Wikidata isn't a purely relational database and the data doesn't have to be normalized - we have bots that can run simple calculations and keep things synchronized if that's appropriate. In general I'm sympathetic to avoiding duplication of data, but I think in this case it's a useful property to have even if easily calculated. A more valid concern I think would be if the way this is used does not fit in with wikidata internationalization (does the property only work for some languages or its value is ambiguous due to language differences?) but I don't think that's what's being argued here. ArthurPSmith (talk) 13:47, 16 July 2018 (UTC)
  • Symbol keep vote.svg Keep per Jheald and ArthurPSmith − Pintoch (talk) 19:39, 28 October 2018 (UTC)
  • Pictogram voting comment.svg Comment In fact there is an internationalization concern. Soundex is only applicable to the English language. There are other phonetic algorithms optimized for other languages, e. g. Cologne phonetics for German or the French version of Soundex. Shouldn't there be a more general solution then? --Dealerofsalvation (talk) 11:21, 31 October 2018 (UTC)

Nobel prize ID (P3188)[edit]

Nobel prize ID (P3188): (delete | history | links | entity usage | logs | discussion)

Hello. On the base on Pigsonthewing's suggestion, I propose that we delete the generic identifier for Nobel laureates in other to split it into more specific ones. It would help us to classify more precisely our properties with instance of (P31) (Physics under Wikidata property related to physics (Q22981316), literature under Wikidata property related to literature (Q29561722), etc.). It would also be useful for completing easily specific external links templates such as Template:Research links (Q54913733) on French WP.--Nomen ad hoc (talk) 15:38, 31 July 2018 (UTC)

Of course, the deletion would be immediately followed by the creation of the specific properties. Nomen ad hoc (talk) 15:39, 31 July 2018 (UTC).
  • Symbol delete vote.svg Delete. Thierry Caro (talk) 15:48, 31 July 2018 (UTC)
  • Comment Deletion should not "be immediately followed by the creation of the specific properties"; once there is consensus to delete this property, the deletion should be put on hold; the new properties should then be created, and once done, the data be copied (or moved) across. Only then should the current property be deleted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 31 July 2018 (UTC)
  • Symbol keep vote.svg Keep Symbol oppose vote oversat.svg Strong oppose Even with this change the ID's would still consist of at least a "year/name" format, I don't think that's a significant simplification. And I believe it's better to treat the prizes as a whole than split them up for several reasons: (1) the number of ID"s is not large as it is so making this change would drop each of them to at most about 300, (2) there is not that large a distinction among the science fields - chemists have won in physics and in medicine as well as chemistry (and also the peace prize). Maybe there's a legitimate reason to treat the literature and peace prizes differently, but I am strongly opposed to splitting up the science prizes into separate ID's. ArthurPSmith (talk) 17:17, 31 July 2018 (UTC)
    ArthurPSmith: I changed my mind and then agree with you. 3 distinct properties (science - including physics, chemistry and medicine.-, peace, and literature) would suffice. Hence could you please support it? Nomen ad hoc (talk) 08:19, 13 August 2018 (UTC).
  • Symbol keep vote.svg Keep I still see no valid reason for splitting the current property. Cdlt, VIGNERON (talk) 07:23, 14 August 2018 (UTC)
  • Symbol keep vote.svg Keep but clean it up and maybe change formatter URL. We have now a federated search see discussion Property_talk:P3188 ==> that we get all Nobel Prize winners defined see list. My understanding is that has redesigned the web so someone needs to spend some time and find matching pages. I have tried communicate with with no success see T203915 - Salgo60 (talk) 07:30, 7 October 2018 (UTC)
  • Pictogram voting comment.svg Comment I'm wondering to what extent this can really be regarded as an ID. I just tried to get from William Nordhaus (Q562481) to his entry on the Nobel side via Q562481#P3188, and it did not work, since the corresponding formatter URL (P1630) and format as a regular expression (P1793) do not fit with the actual , although they work for the property examples given. --Daniel Mietchen (talk) 00:33, 9 October 2018 (UTC)
  • Pictogram voting comment.svg Comment @Mietchen: I have a dialogue with Nobel data and has done some federated searches T200668 / Listeria lists and my understanding is that they are migrating the old web to a new and miss a timeplan. I have asked to get updated of the status maybe we should have a depreciated status?!?!- Salgo60 (talk) 13:25, 11 October 2018 (UTC)

Wikidata project (DEPRECATED) (P4570)[edit]

B-side (P1432)[edit]

B-side (P1432): (delete | history | links | entity usage | logs | discussion)

Per Wikidata:Project chat#Property constraints – music releases, instance of (P31)single (Q134556) and instance of (P31)song (Q7366) should not be used on the same item. This means that singles should be treated like albums/EPs, which means that they can use tracklist (P658); so the A-side(s) and B-side(s) should be inferred from or indicated on the single's tracklist (possibly with object has role (P3831)), rather than on the items for the songs. (If it should be indicated on the song items, then that could be done with subject has role (P2868) as a qualifier on a statement with part of (P361) and the single's item.) While structural necessity isn't a strict requirement for the existence of a property, singles have been released with multiple A-sides and with different B-sides for different releases, which would be hard/impossible to represent using just B-side (P1432) on the item for the mutual A-side.

If there is a consensus to delete, the property should be deprecated and then deleted after there are no uses left. This would require the creation of about 344 items (the number of uses), since most singles currently have one item for both the single and the A-side. An example with separated items for single and song is Eastside (Q55975144)/Eastside (Q55977453) (I created both and I'm not aware of any other examples). —Jc86035 (talk) 12:30, 8 August 2018 (UTC)

Symbol delete vote.svg Delete: If we keep items for songs and singles separate (which I support) it makes little sense to use B-side (P1432). To use qualifiers to identify A- and B-sides is a good idea. -Valentina.Anitnelav (talk) 08:02, 9 August 2018 (UTC)
Symbol delete vote.svg Delete Better to use qualifiers on tracklist (P658) --ValterVB (talk) 08:44, 9 August 2018 (UTC)
An example of a version of a single with an A-side and a B-side is Make You Feel My Love / Painting Pictures (Q56085807). Jc86035 (talk) 06:34, 15 August 2018 (UTC)
Symbol keep vote.svg KeepB-sides charted separately from their respective A-sides before 1969. See The Beatles' #1 singles for one obvious example of this. - Bossanoven (talk) 11:49, 19 August 2018 (UTC)
@Bossanoven: I think that's irrelevant. This deletion nomination is about how B-sides are shown to relate to their A-sides, and the property's deletion would not negatively affect chart data.
If the single charted (as opposed to the songs) then the chart data can go on the single's item, and if the songs charted separately (as they do now on most charts) then the chart data can go on the songs' items. Usually charts are consistent about this, as far as I'm aware; so other than the issue of singles almost always being conflated with songs in the current data structure (i.e. there being only one item for both the song and the single), there shouldn't be any major problems with this. Jc86035 (talk) 16:59, 21 August 2018 (UTC)
@Jc86035: Wouldn't it remove confusion in the reader's mind to see that a famous A-side charted separately from its famous B-side, and to see this through the B-side property? - Bossanoven (talk) 17:48, 21 August 2018 (UTC)
@Bossanoven: Is Wikidata even meant to be read? I guess its primary purpose is to be a database. If the data exists in the tracklist stored on the single's item then it doesn't necessarily need to be added anywhere else.
Regardless, since it seems very common to state the track number as a series ordinal (P1545) qualifier in a part of (P361) statement, I extended this when I was editing items like Let's Spend the Night Together (Q1389086)/Ruby Tuesday (Q1953769) by adding qualifiers like subject has role (P2868)A-side (Q55997636) (and subject has role (P2868)B-side (Q13432985), although those two songs are each other's A-sides on their single and thus could not have used B-side (P1432) anyway). I think this additional qualifier is sufficient to indicate that a single has more than one track.
Why (and how) would you indicate chart positions through the B-side property? I don't think it would be feasible or technically possible, given the limitations of qualifiers, although maybe I'm taking you too literally. In any case, if the property's purpose is cosmetic rather than functional then it doesn't really need to exist. Jc86035 (talk) 18:09, 21 August 2018 (UTC)
Good discussion, to keep it separated is a good idea! However Wikipedia often mixes song and single, see Hey Jude (Q607742). So is the Wikipedia article going to linked to the song or single. I would suggest to connect to the song, as they are the more important entity. Germartin1 (talk) 15:18, 3 September 2018 (UTC)
@Germartin1: Yes, the sitelinks would remain with the song, unless an article is explicitly about all songs on a single for whatever reason. (I've done this for the items that I've worked on, such as Ocean (Q55064464)/Ocean (Q56070900)/Ocean (Q56070899) and Popular Song (Q7229734)/Popular Song (Q56085662)/Popular Song (Q56085664)/Popular Song (Q56085678).) This approach is also the most logical where a song has multiple single releases (e.g. Yesterday (Q202698)). Jc86035 (talk) 11:48, 18 September 2018 (UTC)

Sweet kate
Sight Contamination
Pictogram voting comment.svg Notified participants of WikiProject Music. (If no one else comments I think it would be appropriate to close this as delete; Bossanoven is now indefinitely blocked for unrelated reasons.) Jc86035 (talk) 10:44, 4 November 2018 (UTC)

located at street address (P969)[edit]

located at street address (P969): (delete | history | links | entity usage | logs | discussion)

Per Liuxinyu970226, this property should have the monolingual-text datatype because there are places which are bilingual and/or use multiple writing systems, such as Hong Kong (zh/en), Macau (zh/pt), Morocco (ar/ber/fr), most of Xinjiang (zh/ug), parts of Switzerland (de/fr/it/rm), and most of India (en/hi/bn/te/...). If deleted the property would need automatic conversion to a new property with that datatype with the language set based on the writing system of the text and the local language of the located in the administrative territorial entity (P131) or country (P17). —Jc86035 (talk) 16:35, 15 August 2018 (UTC)

I haven't notified any of the many projects which use this property, partly because I'm not sure exactly how I'm supposed to do it. Notifying all talk page contributors of this discussion. Ahoerstemeier, Bcoh, Danrok, Esquilo, Fnielsen, Fralambert, Giftzwerg 88, GZWDer, Ivan A. Krestinin, Jeremyb, Jhertel, Jura1, Kolja21, Laddo, Michiel1972, Napoleon.tan, Pasleim, SPQRobin, Syced, VicVal, Zolo. Jc86035 (talk) 16:50, 15 August 2018 (UTC)

Notifying all contributors to the property in the last two years. Alfonso Márquez, Avatar6, ChristianKl, Edoderoo, Geertivp, Herzi Pinki, İncelemeelemani, J budissin, JakobVoss, JMagalhães, Kareyac, Laura Marianne, Maitsavend, Mormegil, NMaia, Nvrandow, Obaid Raza, Oriciu, Otets, Pyro z, Red Winged Duck, Renamerr, Romaine, Ryanag, Sannita, Sigwald, Sjoerddebruin, Soued031, Susannaanas, Venkisrimba, Zeroth, Zyksnowy, Спасимир, আফতাবুজ্জামান. Jc86035 (talk) 16:53, 15 August 2018 (UTC)

I also need these users who joined former two RFD discussions for this property to join here: @VIGNERON, -revi, Jianhui67, Amqui, Pigsonthewing:@Billinghurst, Rana24news, Jsamwrites, Pustekuchen2014, ArthurPSmith:@Oursana, Srittau, Edgars2007, Jklamo, RolandUnger:@Jheald, Anvilaquarius, JerryL2017, Diggr, Okkn:. --Liuxinyu970226 (talk) 05:41, 18 August 2018 (UTC)
  • I think we already had this before, I found some at
    @Jura1: The first proposal for deletion is on the basis that the property duplicates located on street (P669), which is irrelevant here. The second only has one actually relevant comment (by Billinghurst), while the other comments are irrelevant to the topic at hand (anyone can change a property label, and there is no officially formalized process for replacing a widely-used property with another one of a different data type). The property proposal for the P969 replacement is about as bad, since the only opposes are from you (I disagree with your oppose vote, but only because qualifiers can't themselves have qualifiers) and Srittau (who wasn't aware that the property had already been unsuccessfully proposed for deletion). The other comments are complaints about the content of the data, even though it is made clear that the property has the same purpose as the old one. Jc86035 (talk) 07:12, 16 August 2018 (UTC)
  • Pictogram voting comment.svg Comment The replacement property before de deletion request? --Fralambert (talk) 17:15, 15 August 2018 (UTC)
    • The royal route would be to create a new property -> move the data -> delete the old property. Yes, this will take time, but that should be no issue. Edoderoo (talk) 19:37, 15 August 2018 (UTC)
    • Well, obviously I'm not proposing that P969 be deleted immediately if the discussion is closed as delete/replace, and the discussion has to go somewhere. Not a lot of people watch the property proposals subpages. Jc86035 (talk) 07:16, 16 August 2018 (UTC)
  • Symbol delete vote.svg Delete As said before, let's do this replacement. --Liuxinyu970226 (talk) 22:42, 15 August 2018 (UTC)
  • Pictogram voting comment.svg Comment If I understand properly, you want to create a new (multilingual) property, do the migration, then delete this property? If you will do all of this, then yes I agree. Syced (talk) 03:00, 16 August 2018 (UTC)
  • Pictogram voting comment.svg Comment Total items with P969 - 813000, items without P131 - 16700, items without P17 - 1450, items without P17 & P131 - 950. --Voll (talk) 08:28, 16 August 2018 (UTC)
    @Voll: Does the count of 950 include statements in which located at street address (P969) is used as a qualifier? I guess those would have language added based on the object/value rather than the subject/item. Jc86035 (talk) 11:30, 16 August 2018 (UTC)
    It counts only real statements, no qualifiers. I wanted to say that using P17 in the migration is better, then P131. --Voll (talk) 15:03, 16 August 2018 (UTC)
    @Voll, Jc86035: I would love to know how this property is used on items that neither have P17 nor P131, are they mis-used this as e.g. IP addresses? --Liuxinyu970226 (talk) 06:02, 18 August 2018 (UTC)
    Is it enough for the investigation?
    SELECT ?item ?itemLabel ?street
      ?item wdt:P969 ?street.
      MINUS {?item wdt:P131 ?where}.
      MINUS {?item wdt:P17 ?country}.
      SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". }
    Try it! --Voll (talk) 13:24, 19 August 2018 (UTC)
  • Pictogram voting comment.svg Comment the property is used as a qualifier outside of the the above examples, eg. to qualify births and death addresses, and to require those in multiple languages does not seem relevant, and in fact would seem detrimental to the available data if it is language particular. So maybe it useful for the major uses that you envisage, I do not see it universally advantageous where I add it. This aspect needs to be addressed as many places do not have multiple languages in place, and it appears that you are just making data addition harder. This has been raised previously, and again the proponents are not offering solutions.

    It would be useful to see reports of where the property is used as a qualifier and to see the scenarios where it would be an advantage, and where it is a disadvantageous.  — billinghurst sDrewth 06:03, 18 August 2018 (UTC)

    @billinghurst: For places of birth/death, we already have place of birth (P19) and place of death (P20) for several decades years, why they still wanna full addresses for them, to reflect what things? Using monolingual text datatype can also introduce a stable way to sync translations of addresses, at least zhwiki users always translate foreign addresses in infoboxes of place articles, nothing is hard in this topic area by translating. I also believe that the Jc86035 is helping to find solution of this stable way, and if you think digging more and more property usage is indeed on this page, feel free to ping me in any free time, as I'm online here at least 8 hours per day. --Liuxinyu970226 (talk) 06:12, 18 August 2018 (UTC)
    Truly asking that? Specific information that is regularly added to biographical articles now and in the 19thC, has been captured here as a qualifier and you are saying that it isn't pertinent? Why would ask for me to justify that? With burial data, we collect a place. Saying we ignore the cemetery? ignore the plot data?  — billinghurst sDrewth 06:25, 18 August 2018 (UTC)
    Fwiw, such informations that are about fictional things, are called as dōjin (Q1272707) in Asian countries, and how these "dojin"s are also needed here? --Liuxinyu970226 (talk) 06:35, 18 August 2018 (UTC)

Template:Vote not delete to see language it should have qualifier('s) language of work or name (P407), otherwise the language is default for local postal service. Monolingual property, instead of it is for now, would overuse the purpose of "postal address" by localizations that is not necessary in wikidata, that localisations should be done in local projects .--Avatar6 (talk) 17:32, 18 September 2018 (UTC)

@Avatar6: Please see what I said before at Wikidata:Project_chat/Archive/2018/08#P969 concern, there are really a number of Wikipedias which don't have function to query qualifiers, thus P407 can't actually work for them. --Liuxinyu970226 (talk) 04:56, 19 September 2018 (UTC)
Symbol delete vote.svg Delete This property should learn How official name works. -- 02:15, 22 September 2018 (UTC)
  • Caution Concerns similar to User:Billinghurst above. I am currently using this as a qualifier to place of publication (P291) based on catalogue records for some 18th century maps, using data from MARC field 264 in the library records. Once all the data is in, it will be valuable to be able to see and sanity-check what different addresses are given for the same person, and how these may correlate to other information in the records. I can guess that the language of that statement corresponds to the language of the work, but I can't be sure (in some cases, it may have been added by the cataloguer, for example). Jheald (talk) 16:52, 28 September 2018 (UTC)
    @Jheald: Why not just specify them as Latin (la)? --Liuxinyu970226 (talk) 04:04, 30 September 2018 (UTC)

Symbol delete vote.svg Delete I really can't agree some opinions like @Avatar6:'s "otherwise the language is default for local postal servic", Avatar6 I must tell you that the post stations in Canada always use both English and French for each place AT SAME TIME! Thus we the Canadian really wanna show the languages of addresses that a random place has. -- 23:32, 1 November 2018 (UTC)

AniDB ID (P1688)[edit]

AniDB ID (P1688): (delete | history | links | entity usage | logs | discussion)

Values of this property is migrated to AniDB anime ID (P5646), AniDB character ID (P5648) or AniDB creator ID (P5649). Batch of deletion: 3794 --ValterVB (talk) 12:10, 19 August 2018 (UTC)

Symbol delete vote.svg Delete per ValterVB (property migrated). --Epìdosis 20:45, 22 August 2018 (UTC)
Symbol delete vote.svg Delete. It makes sense. Thierry Caro (talk) 15:53, 23 August 2018 (UTC)
Symbol delete vote.svg Delete, per nomination. Nomen ad hoc (talk) 18:53, 23 August 2018 (UTC).
Pictogram voting comment.svg Comment @4th-otaku, Pigsonthewing, Yakiv Gluck: Sorry I forgot... --ValterVB (talk) 19:08, 23 August 2018 (UTC)
Symbol delete vote.svg Delete, taking on trust that values have been migrated as stated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:22, 23 August 2018 (UTC)
Could someone post a link to where the Ukrainian Wikipedia (which is using this property) was notified? - Nikki (talk) 20:51, 23 August 2018 (UTC)
@AlexKozur, Avatar6, Bunyk, Vovchyck, MMH:@Base, Yakiv Gluck: let's just ping them here. --Liuxinyu970226 (talk) 10:54, 15 September 2018 (UTC)
Symbol delete vote.svg Delete per ValterVB. Possibly as ID episode\song in pop-anime. But I think it is better to create such ID. --AlexKozur (talk) 21:15, 17 September 2018 (UTC)
Symbol delete vote.svg Delete Cwf97 (talk) 16:29, 21 October 2018 (UTC)

Quais du polar writer ID (P5666)[edit]

Quais du polar writer ID (P5666): (delete | history | links | entity usage | logs | discussion)

Ce site n'est en aucun cas un site de référence des littératures policières. C'est juste le site Internet d'un festival qui propose des pages sur leurs invités sans aucun objectif encyclopédique, sans aucun intérêt littéraire et sans jamais que ces fiches (qui ne sont même pas des fiches signalétiques construites) ne soient signées par qui que ce soit. --Matpib (talk) 13:03, 19 August 2018 (UTC)

La proposition a etais fait par @Thierry Caro: qu'il pourrait expliquer. - yona b (talk) 08:31, 22 August 2018 (UTC)
@ديفيد عادل وهبة خليل 2, Nomen ad hoc, Pintoch: from the proposal discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:23, 23 August 2018 (UTC)
Symbol keep vote.svg Keep: no serious reason to delete. Nomen ad hoc (talk) 19:25, 23 August 2018 (UTC).
Symbol keep vote.svg Keep. Covers the biggest crime literature festival in France. Thierry Caro (talk) 19:38, 23 August 2018 (UTC)
Symbol keep vote.svg Keep Cwf97 (talk) 16:30, 21 October 2018 (UTC)

candidacy in election (P3602)[edit]

candidacy in election (P3602): (delete | history | links | entity usage | logs | discussion)

Pinging participants in both proposal discussions: @Shlomo, Danrok, Micru, Susannaanas, ChristianKl, Stryn:. This property was proposed in 2014, rejected as an inverse of candidate (P726), proposed again in 2017 on the basis that "For each municipality there can be tens or hundreds of candidates in municipal elections". (Incidentally, when re-proposing a property one should ping the participants of the original discussion imo.) I dispute that there are commonly elections where there be hundreds of different distinct options on the ballot. Does anyone know of any examples? I think it's very important not to have extra redundant properties in this area, as the two versions will quickly fall out of sync and be harder to use.

Yair rand (talk) 18:20, 22 August 2018 (UTC)

  • I think such elections are called general elections. Not all countries just elect a single candidate per electoral district.
    --- Jura 18:29, 22 August 2018 (UTC)
    • @Jura1: I don't understand the relevance. Whether a single candidate or a group of candidates voted as a single option, we're only going to have one item listed as candidate, otherwise we wouldn't be able to list things like number of votes, right? --Yair rand (talk) 18:36, 22 August 2018 (UTC)
      • Some systems are more complicated. Anyways, I don't see an advantage in not having this property.
        --- Jura 18:39, 22 August 2018 (UTC)
        • I'm new to election-related editing. Please consider Vermont elections, 2018 (Q55389072). I don't know the best way to model it in Wikidata, but it is commonly spoken of as the Vermont 2018 general election. The offices to be filled include 1 representative in Congress, the governor, several state-wide offices, around 5 offices in each of 14 counties, and justices of the peace in every town. There are nearly 2000 justices of the peace. I asked at project chat just now about how to handle this. Jc3s5h (talk) 19:03, 22 August 2018 (UTC)
  • Symbol neutral vote.svg Neutral This kind of property, to me, may or maynot be useful. But I'd love to know if there are overlapped properties or not. --Liuxinyu970226 (talk) 15:51, 23 August 2018 (UTC)
  • Symbol keep vote.svg Keep I observe that there are many interrelated election items and properties, many of which are absent for many elections and candidates. By having inverse properties, readers will find it easier to navigate when the set of ideal information is incomplete, and editors will find it easier to navigate while finding omissions and filling them. Also, this property is displayed for a candidate in the interactive interface if one clicks in the "show derived statements" box, provided the appropriate "candidate" property has been added to an election item. If this property were deleted, wouldn't this feature stop working? Jc3s5h (talk) 21:04, 23 August 2018 (UTC)
  • Symbol keep vote.svg Keep Inverse of candidate (P726) property is good only for elections with low number of candidates (like presidential elections), but very impractical for elections with high number of candidates (general elections, local elections). For these candidacy in election (P3602) is the only way to record such information.--Jklamo (talk) 10:21, 25 August 2018 (UTC)

ChristianKl Oravrattas Tagishsimon Jacksonj04 Owenpatel Markcridge Louisecrow Nomen ad hoc Tubezlob Siwhitehouse Mhl20 Alexsdutton Danadl Teester Zache a_ka_es Hasive Nat965 masti Papuass Jklamo Kellyjeanne9 ProtoplasmaKid Jmmuguerza

Pictogram voting comment.svg Notified participants of WikiProject every politician


bilibili ID (P5733): (delete | history | links | entity usage | logs | discussion)

Pointed out by other users that the identifier is also assigned to series hosted on the site apparently without legitimate copyright license granted to the site (i.e. pirated content) C933103 (talk) 16:16, 9 September 2018 (UTC)

Symbol keep vote.svg Keep Copyright problems are not this wiki concerned, if you have other reasons to nominate deletion than copyright, let's continue. --Liuxinyu970226 (talk) 23:11, 13 September 2018 (UTC)
Or to put this in another way: I was anticipating to be able to reuse data from links via this identifier to help fill information and claims at wikidata. However with pirate=unofficial content being included in resources available via this identifier, some parameters that would have been made available via this identifier might no longer be certain to be true, and an originally anticipated purpose of the identifier to enable linking from wikipedia articles via the identifier to legitimate platforms that host content about related articles could not be automatically achieved, and thus losing part of the value of the property. C933103 (talk) 06:40, 21 September 2018 (UTC)

analog or derivative of (P5000)[edit]

analog or derivative of (P5000): (delete | history | links | entity usage | logs | discussion)

Property represents analog (Q50824047) which is ambiguous and inaccurate and so it's incorrect from a chemistry perspective. It mixes different concepts of functional analog, structural analog, derivative and molecular similarity and some others; concepts that are neither synonymous nor similar, concepts that shouldn't be equated with each other. Problem of chemical classification is one of the most important and most challenging in WD's chemistry scope, but Wikiproject Chemistry hasn't been notified about this proposal and I found this property by accident. Fortunately, there is only one use of this property.

This property should be deleted as it's incorrect and importing data from the indicated sources can lead to addition of a huge collection of chaotic and inaccurate data. Discussion about chemical classification should be continued in Wikiproject Chemistry and such bypass solutions should not be created.

Jasper Deng
Egon Willighagen
Denise Slenter
Daniel Mietchen
Andy Mabbett
Emily Temple-Wood
Pablo Busatto (Almondega)
Antony Williams (EPA)
Devon Fyson
Samuel Clark
Pictogram voting comment.svg Notified participants of WikiProject Chemistry, pinging participants of the property proposal discussion: @Andrew Su, YULdigitalpreservation, Okkn, ديفيد_عادل_وهبة_خليل_2, Andrawaag, Gstupp:. —Wostr (talk) 13:21, 23 September 2018 (UTC)

  • Symbol keep vote.svg Keep I see it is useful and has no problem.The description can be improved David (talk) 14:03, 23 September 2018 (UTC)
    • Could you explain how this property is useful? Wostr (talk) 14:42, 23 September 2018 (UTC)
    • I have to ping you, David, as I would like to know the answer or some argument for keeping this property. Especially in the light of my comment of September 24 (below, the long one beginning with I'm not sure), in which I pointed out major problems with the sources that were to be used to populate this property. Wostr (talk) 20:34, 12 November 2018 (UTC)
  • I understand your concern. Do you have any plans to create more specific properties replacing this property? Or should we force this property to be used with a qualifier of object has role (P3831) (Functional analog (Q25205085), Structural analog (Q485014), Substrate analog (Q7632163), or Transition state analog (Q17087414))? Actually, the term "analog" is used ambiguously in molecular biology and in medicine, such as nucleic acid analogue (Q15057699) and Insulin analog (Q742283). Also, I'd like to hear what is the chemically correct relationships between 2-chlorodiazepam (Q15408412) and diazepam (Q210402), or between fexofenadine hydrochloride (Q27255526) and fexofenadine (Q415122). Regards, --Okkn (talk) 09:10, 24 September 2018 (UTC)
    • I'm not sure that properties are needed here at all. We had in Wikiproject Chemistry some initial discussions about chemical classification (e.g. here), but these discussions are not finished, as we in WP Chemistry have a lot to do before this (e.g. determining what we already have in WD and cleaning up after mass bot imports). From my POV the basic chemical classification should be based on classes of chemical compounds using instance of/subclass of (e.g. diazepam has a benzodiazepine, chloroaromatic classes; these classes are subclasses of more general classes etc.; this way diazepam and 2-chlorodiazepam are a member of the same classes). But this is my POV that has not been accepted (as any other) to be used in WD; and that's not the only option that can be present in WD. With the analogs, derivatives and so on there are IMHO too many problems: one can say that 2-chlorodiazepam is an analogue of diazepam, but there are really no clear and objective boundaries – methanol is an analog of methane? one can say that; diazepam is a structural analog of methane? some may argue that this is also true, really, I had that kind of discussions in, because we have 'derivatives' and 'similar compounds' parameteres in infoboxes...
      The problem here is also that we would have several thousands of statements imported to WD and that's it. Many users like to import data to WD, but no one likes to curate that data, no one is checking whether imported data is correct or not. And in this case it would certainly be incorrect: just look what is the purpose of 'analogs & derivatives' in MeSH: It is used when the specific chemical heading is not available and no appropriate group heading exists i.e. it is used where there is no chemical class to be used for classification, so this is a kind of a substitute property, a replacement for something that is missing right now. ChEBI 'functional parent' have more sense (A has_functional_parent B if and only if given any a, a instantiates A , has molecular graph ag and a obo: has_part some functional group fg, then there is some b such that b instantiates B, has molecular graph bg and has functional group fg’ such that bg is the result of a graph transformation process on ag resulting in the conversion of fg into fg'.), but I don't think that such relationships are needed in WD, at least not right now.
      My point is that: classification should be thoroughly discussed first and there should not be mass imports before that, because there are always people who wants to import something (no matter if this is correct or not), but there are no volunteers for cleaning this up. Wostr (talk) 14:06, 24 September 2018 (UTC)
  • I understand that a property like this makes interesting browsing, but I think it can be done differently. I agree with the point that analog and derivative are not so well defined, but my worries stems particularly from the fact that it is unbound and will lead to many links between chemical structures. I'm slightly in favor of removing. --Egon Willighagen (talk) 16:45, 25 September 2018 (UTC)
  • Symbol delete vote.svg Delete or at least rename based on a more specific relation. We already discussed the problem in WikiProject Chemistry and only relations based on a clear definition have to be used. Snipre (talk) 23:18, 7 October 2018 (UTC)


does not have part (P3113): (delete | history | links | entity usage | logs | discussion)

Has only 106 uses, and is redundant to has part (P527) with a value of "no value". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:40, 3 October 2018 (UTC)

@Pigsonthewing: how is it redundant to has part (P527) with a value of "no value"? Where do you indicate the value from the does not have part (P3113) statement? ArthurPSmith (talk) 14:46, 3 October 2018 (UTC)
  • Symbol keep vote.svg Keep Invalid reason, per ArthurPSmith Germartin1 (talk) 12:52, 12 October 2018 (UTC)
  • Symbol keep vote.svg Keep per ArthurPSmith. Jc86035 (talk) 15:38, 1 November 2018 (UTC)
  • @ArthurPSmith, Jc86035, Pigsonthewing: What would work however, and is equivalent, is to use
    subject > has parts of the class (P2670) View with SQID < type of part >
    quantity (P1114) View with SQID < 0 >
    author  TomT0m / talk page 19:13, 2 November 2018 (UTC)
  • Symbol keep vote.svg Keep per ArthurPSmith. @TomT0m: I don't think this is a good idea. In my eyes wherever possible a mainsnak should also be valid without its qualifier, This proposal is actually dangerous since all querying has part (P527) without also querying the qualifier quantity (P1114) would get exactly the opposite of what is meant. --Marsupium (talk) 20:56, 2 November 2018 (UTC)
    I tend to agree, that’s why I did not support the deletion proposal. I guess we should put the constraints that the number of parts should be generally positive. Wondering if we need « don’t has part of that type » but I don’t think so. author  TomT0m / talk page 21:06, 2 November 2018 (UTC)

Soccerway player ID (P2369)[edit]

Soccerway player ID (P2369): (delete | history | links | entity usage | logs | discussion)

This property retrieves the same data from the same database as the Scoresway soccer person ID (P3043). When a player becomes a coach, his statistics disappear on Soccerway[18][19][20], but it still remains on Scoresway[21][22][23]. —Сидик из ПТУ (talk) 11:12, 18 October 2018 (UTC)

Commons category (P373)[edit]

Commons category (P373): (delete | history | links | entity usage | logs | discussion)

Systematically redundant property, merge with topic's main category (P910). For an item which has a direct interproject link to Commons category, this property is duplicate of the interproject link and it requires redundant maintenance work to keep the two linking forms consistent. For items which have a property topic's main category (P910), the property Commons category (P373) is redundant because the linked Commons category should be joined by an interproject link with the P910 target category. Before deletion of P373 property, all P373 data should by transformed to interproject links, either directly, or through the P910 target item. —ŠJů (talk) 15:42, 2 November 2018 (UTC)

  • Request for clarification: Wikidata went against the general consensus of Commons users by favoring gallery (main space) pages on Commons over the Category pages, which most of us on Commons consider primary. That means there are a lot of items that are sitelinked to an (often useless) Commons gallery (main space) page in preference to a meaningful Commons category.
  • If I understand correctly, your rationale is that in those cases there will always be a corresponding item on Wikidata for the category in question linked via topic's main category (P910) and that the Commons category will always be sitelinked from that item for the category, or that if it is not we can solve that with a bot before eliminating this property. Have I understood you correctly? - Jmabel (talk) 19:08, 2 November 2018 (UTC)
    @Jmabel: Generally, gallery pages never were a real equivalent of articles. The fact that both of them have no prefix at their projects doesn't mean that they have anything in common. While categories and articles should be unique for its items, one item can have more various gallery pages in one project. Commons gallery (P935) is similar to image (P18). Gallery pages should have no interproject links, such as file pages have no interwikis and no interproject links at Wikidata. Gallery pages are something like a collage image, in principle. Unique relations to item-unique pages should be linked through interproject/interwiki links, while 1:N links or links to examples or digests (selected images or galleries) should be properties.
    As long as some items have two item-pages on Wikidata (one for article pages and one for category pages), we should to keep the existing preferences: if the item have its own category on at least one Wikipedia project, the Commons category should by linked with the Wikipedia category and category item page. If the item has no category at non-Commons projects, the Commons category should be joined to the basic Wikidata item page (i.e. directly with articles of that item), unless it is blocked by Commons gallery page. In such case, we are forced to use two Wikidata item pages: first one for article and gallery pages, second one for Commons category page. --ŠJů (talk) 01:01, 3 November 2018 (UTC)
    • I agree entirely that Wikidata's preference for gallery pages is misguided, and is based on a misapprehension of their nature.
    • I think where you are headed with this is reasonable: just so long as Commons categories are understood to be the main relevant sitelink to Commons, and they won't ever be omitted entirely in favor of something else on Commons. - Jmabel (talk) 06:43, 3 November 2018 (UTC)
  • Symbol oppose vote.svg Oppose Commons category (P373) would be useless if Wikidata hadn't preferred the useless galleries over category pages. Therefore, the fix shouldn't be going through a two-step path to find the meaningful Commons category but to have it as preferred option when it comes to an interproject link. --Discasto (talk) 19:23, 2 November 2018 (UTC)
    @Discasto: There are two basal problems. The first of them is that one item has two item pages on Wikidata, in some cases. The second one is a incomprehension of character of gallery pages. You mention only the second problem, while the first problem is more urgent to be treated and compensated. --ŠJů (talk) 01:12, 3 November 2018 (UTC)
  • Symbol keep vote.svg Keep topic's main category (P910) has a different datatype and merging would only be possible in the way described by Jmabel which isn't nice outlook. --Marsupium (talk) 21:17, 2 November 2018 (UTC)
    @Marsupium: It is rather a bug that topic's main category (P910) has a different datatype than Commons category (P373). The proposed merge can solve the bug elegantly. --ŠJů (talk) 01:12, 3 November 2018 (UTC)
    @ŠJů: I don't think I'd consider to create ~2M – wild guess, you might want to calculate it – single-sitelink Wikimedia category (Q4167836) items to be elegant. --Marsupium (talk) 01:24, 3 November 2018 (UTC)
  • Pictogram voting comment.svg Comment I support this in the long run, but this request is probably a bit early. For background info, Pi bot (talkcontribslogs) has added hundreds of thousands of commons sitelinks over the last year, as the sitelinks are used by commons:Template:Wikidata Infobox. That was primarily based on Commons category (P373) values, but other matches have also been used (IDs and image (P18) values in particular). And as a temporary measure, the bot updates P373 values where they differ from the sitelink and they point to a commons category redirect. However, there are still quite a few P373 values that need manually resolving/the correct sitelink adding. Plus the gallery vs. category issue that Jmabel mentions above (although @Jheald: mostly fixed that by creating new category items for those cases, which are linked by topic's main category (P910)/category's main topic (P301)). And then there are all of the uses of this property outside of Wikidata ... I would however Symbol support vote.svg Support marking this property as deprecated, and resolving the remaining issues so that we can move over to using the sitelinks instead - but that will probably still take some time to accomplish. Thanks. Mike Peel (talk) 22:58, 2 November 2018 (UTC)
  • Symbol support vote.svg Support marking as deprecated and cleaning up as needed. No definite opinion on the best route to clean up, but I support the effort to reduce redundant maintenance of data. Kaldari (talk) 00:41, 3 November 2018 (UTC)
  • I don't think P373 can be deprecated as long as there's no official solution to the gallery sitelink problem. There was no consensus to prefer Commons category sitelinks to gallery links, last time I asked, and category items with only a sitelink to Commons are still prohibited by Wikidata:Notability. I'd also like to know if the Wikimedia software, when creating toolbar links in other projects, actually checks for a linked category item with a Commons sitelink. It's possible that a lot of links to Commons in other projects would be lost (or category links replaced with links to galleries). Ghouston (talk) 04:35, 3 November 2018 (UTC)
    I agree. All steps must be taken successively so that no information is lost.--ŠJů (talk) 11:18, 3 November 2018 (UTC)
    Unfortunately, the page Wikidata:Notability is completely out of reality and out of real consensus.
    • It e.g. claims that "a sitelink cannot point to a redirect" and ignores consensually existing and useful item-pages for Wikimedia disambiguation page (Q4167410).
    • It claims that "items to category pages on Wikimedia Commons are allowed if and only if they are linked with category pages on other Wikimedia sites" while such relations were massively, consensually and effectively used long before the start of Wikidata and there was no consensus to destroy such relations or to make them unfunctional.
    • It claims that a Wikidata item-page "contains at least one valid sitelink", while really, there was and is a consensus to import monuments from monument lists (even for monuments which have no separate page – as an analogy of the external tool Commons:Monuments database) or streets from official street registers (even for streets which have no image uploaded and no category or article created yet). (I would be glad if this note did not inspire anyone to destroy this great work.) --ŠJů (talk) 11:45, 3 November 2018 (UTC)
  • Sort of. I don't think your 3rd point is valid, since an item only needs to meet one of the 3 criteria, and the monuments can meet 2) instead of 1). For your first point, there's a footnote that says "Currently, the community has chosen to have redirects allowed, although the necessary changes have yet to be deployed on Wikidata." The second point is a problem though. I tried a while ago to change it (Wikidata_talk:Notability/Archive_4#Category_items) but there was some opposition and it just got archived without reaching consensus. Ghouston (talk) 22:38, 3 November 2018 (UTC)
  • Symbol keep vote.svg Keep Per Ghouston. Not the proper channel IMHO. Choosing how Wikidata should model its relation with Commons should not happen in a Property deletion request but... in a RFC. Additionally, I may add es.wikipedia (at least) is using P373 to fill two highly used templates. strakhov (talk) 22:31, 3 November 2018 (UTC)
  • Pictogram voting comment.svg Comment Interesting proposal, but a couple of points: (1) P373 is currently being used massively by the MediaWiki configuration on most Wikipedias to determine what sitelink to show to Commons. Re-tooling to see whether (i) there is a topic's main category (P910), (ii) with a sitelink, (iii) that goes to Commons would need to be investigated and proven first. (2) That three-step process is significantly slower for big queries than looking up a P373 -- so, for example, in WDQS it is currently possible to count the number of uses of P373; but it is not (I think) possible to count the number of sitelinks within the query time-out. (eg: query to get total number of Commons categories with sitelinks already takes 40 seconds; query to see how many of those have P910 times out). This can have implications for various sorts of maintenance queries. Jheald (talk) 10:47, 4 November 2018 (UTC)
Another long-standing issue with P373 is that there are many categories on Commons that are the target of P373 statements from more than one main-type Wikidata item. See this query for some of the most popular: Some further queries to try to identify some of the Wikidata items which may not be primary matches to the Commons category can be found here: Property_talk:P373#More_queries. The community would need to definitively think about the desirability (or not) of these multi-matches, and which one to choose, or whether to take some other action, before retiring P373. Jheald (talk) 11:39, 4 November 2018 (UTC)
  • @Multichill: fyi--- Jura 12:01, 4 November 2018 (UTC)
  • Symbol keep vote.svg Keep massive usage, not a good alternative. Multichill (talk) 12:33, 4 November 2018 (UTC)
  • Delete. I have long supported deletion of this property in favor of storing the categories with topic's main category. Let's do that and use Wikidata for the power the property provides us. Yes, we add a few million items, but we're already at 50M. We can figure out which ones are the best targets for creation if we want, or we can take them all. (I'm inclined to take them all TBH; there will be value when we get around to SDC Soon.) Let's get WD:N fixed regarding those category items while we're at it. --Izno (talk) 13:39, 4 November 2018 (UTC)
  • Symbol oppose vote.svg Oppose too soon, show me the migration plan, with some examples of a process. Slowking4 (talk) 23:55, 7 November 2018 (UTC)

demonym (P1549)[edit]

demonym (P1549): (delete | history | links | entity usage | logs | discussion)

I think this property could be replaced with one that links to senses (e.g. sense 1 of Kenyan (L35249)); this would be especially useful for words with lots of conjugations. I have not created a new property proposal because it would be more appropriate to have the discussion in one place.

I've already created 161 English noun lexemes which would be able to replace current uses; it would also be necessary to create equivalent items for adjectives, as well as to create the relevant senses for the noun and adjective lexemes (I've only added a sense to L35249 so far). —Jc86035 (talk) 10:33, 4 November 2018 (UTC)

Notified 94 contributors to the property and its talk page: User:Nikki User:Abián User:Jura1 User:VIGNERON User:Tubezlob User:Jheald User:Lockal User:Infovarius User:Putnik User:Laddo User:Kalogeropoulos User:Innocent bystander User:Event User:Jakec User:Vinhtantran User:MaGa User:Labant User:K175 User:Autom User:Robin van der Vliet User:Matěj Suchánek User:Janezdrilc User:Ctschiebout User:Kevin Scannell User:Maria zaos User:Horcrux User:Soued031 User:Metsavend User:Obaid Raza User:İncelemeelemani User:Pinky sl User:Andreasmperu User:Рөстәм Нурыев User:Pmt User:Gustavo Rubén User:Oriciu User:Mr. Ibrahem User:زكريا User:ToJack User:Renessaince User:Arnaugir User:MisterSynergy User:AmaryllisGardener User:Beta16 User:Mahir256 User:Спасимир User:Asierog User:Avatar6 User:Wylve User:Şêr Jc86035 (talk) 10:39, 4 November 2018 (UTC) User:Krupolskiy Anonim User:YMS User:ಶಿವಕುಮಾರ್ ನಾಯಕ್ User:Hibm98 User:GAllegre User:Epìdosis User:Jklamo User:David1010 User:SR5 User:Máté User:Ślimaczek User:HakanIST User:FocalPoint User:Allen4names User:Mbch331 User:Zygimantus User:Fnielsen User:Peppepz User:Geraki User:Supaplex User:Thierry Caro User:NMaia User:Loischantada User:ANDROBETA User:Marklar2007 User:Kikos User:Raid5 User:Doostdar User:Palapa User:Octahedron80 User:Милан Јелисавчић User:Frokor User:Rippitippi User:Conny User:Qllach User:Miguillen User:יונה בנדלאק User:Liuxinyu970226 User:桂鷺淵 User:Bjankuloski06 User:Thomas11 User:Ayack User:Чаховіч Уладзіслаў User:Александр Сигачёв Jc86035 (talk) 10:41, 4 November 2018 (UTC)

I would like to note that the property is used as label for country of citizenship (P27) at huwiki. If the property is deleted, the current data needs to be imported into the newly accepted structure, and huwiki needs to be notified to create a workaround to the new structure if possible. Ideally, the new structure should make it possible. – Máté (talk) 12:10, 4 November 2018 (UTC)

This is also the case for WD powered templates at svwiki, frwiki and probably many more. /Autom (talk) 13:13, 4 November 2018 (UTC)
@Máté, Autom: Where is it used on huwiki/svwiki/frwiki? Those are not listed in the box on the talk page, perhaps the script which looks for property usage can be improved. @Jc86035: Please notify the projects using this property too. - Nikki (talk) 14:52, 4 November 2018 (UTC)
@Nikki: hu:Sablon:Személy infobox of the top of my head. – Máté (talk) 14:58, 4 November 2018 (UTC)
@Nikki: On svwp, it is used by the module Wikidata2, which in invoked by a lot of templates (like Faktamall biografi WD in biografies). I know frwiki had a similar system a year ago (it's possible it has change since then). /Autom (talk) 18:25, 4 November 2018 (UTC)
  • Symbol delete vote.svg Delete but probably wait some weeks/months until Lexemes are more stable. Cdlt, VIGNERON (talk) 12:17, 4 November 2018 (UTC)
  • I agree that we should eventually replace the existing property with lexemes, but we shouldn't delete this until people are able to switch to using lexemes. We still need to decide how we want to link things together. - Nikki (talk) 14:52, 4 November 2018 (UTC)


attributed to (P1773): (delete | history | links | entity usage | logs | discussion)

Apparently this shouldn't be used per Wikidata:WikiProject_Visual_arts/Item_structure#Use_of_creator_(P170)_in_uncertain_cases. So we might as well delete it. --- Jura 14:46, 5 November 2018 (UTC)

  • Symbol delete vote.svg Delete, but deletion is the easiest part, migration has to be done first. --Marsupium (talk) 17:25, 7 November 2018 (UTC)
  • Are we sure no other domains are using it besides art? I would like to first complete the migration to the new model. I don't think that can be done fully automatic because it needs a bit of checking and sourcing. When the property is no longer in use it can probably be deleted. Multichill (talk) 12:35, 10 November 2018 (UTC)

participant of (P1344)[edit]

participant of (P1344): (delete | history | links | entity usage | logs | discussion)

Is an inverse statement really necessary? It seems to contain a lot of duplicate data. Alternatively, participant (P710) should be removed. —U+1F360 (talk) 16:42, 10 November 2018 (UTC)

There may be situations where one or the other is useful as a qualifier. I agree that it's an unfortunate duplication when they are used directly in statements and are redundant inverses. Perhaps participant (P710) could be marked for use in qualifiers only. Ghouston (talk) 00:50, 11 November 2018 (UTC)
  • Clear Symbol keep vote.svg Keep. This property is predominantly used as main value in the field of sportspersons. For sportpersons, this property including its qualifiers is the place to look at when filling an infobox with their participations/successes in Wikipedia. It would be very difficult to retrieve all this information from somewhere else, as we cannot use queries while building infoboxes; the same more or less holds for the inverse participant (P710) (and participating team (P1923)). —MisterSynergy (talk) 07:05, 11 November 2018 (UTC)
    • The inverse thing is unfortunate. When querying data, you'd actually need to run the query in both directions and merge the results, since the inverses are often missing. Some properties, like employer (P108), exist without inverses, and isn't participant of (P1344) similar to that? Ghouston (talk) 22:07, 12 November 2018 (UTC)
      • I don’t care about the inverse character of the property, I just want to have this property kept for use in infoboxes. Together with participating team (P1923) and participant (P710) it forms kind of a triangle which can’t fully inverse all statements anyway. —MisterSynergy (talk) 12:28, 13 November 2018 (UTC)
  • Abstain: I'd favour not storing inverse data, in general, but we need a project-wide policy on when and when not to do so, rather than case-by-case deletion proposals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:22, 13 November 2018 (UTC)

NSZL name authority ID (P3133)[edit]

NSZL name authority ID (P3133): (delete | history | links | entity usage | logs | discussion)

The Hungarian Szechenyi Könyvtár has the maintenance this database closed. You find no any data on this links not now and not in the future. —Texaner (talk) 08:59, 13 November 2018 (UTC)

The data is still available via the Wayback Machine (example) and so I have updated the formatter URL accordingly; but for just 36 IDs, it is probably not worth keeping. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 13 November 2018 (UTC)
Hi, I have checked after you changes the Wayback Machine, but there also no any links. This seems to be a really dead thing. Texaner (talk) 15:50, 13 November 2018 (UTC)
VIAF has these IDs stored (HuBpOSK), so we can still potentially add these IDs and use the Wayback link. – Máté (talk) 12:38, 13 November 2018 (UTC)