Open main menu

Wikidata β

Wikidata:Properties for deletion

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

Edit


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.


Contents

RequestsEdit

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


RecipientEdit


MigrationEdit

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 worksEdit

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

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

What property do you think I want to keep?

original language of work (P364)

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

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

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

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

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

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

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

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

Movies (or possibly Japanese animes)Edit

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

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

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

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

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

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


  Notified participants of WikiProject Anime and Manga for more help on it)

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

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

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

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

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

Specific movie exampleEdit

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

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

What about P2439?Edit


Moving forward and alternative proposalEdit

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

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

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

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

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

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

Closure of stale threadEdit

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

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

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

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

FINAL VOTE: Suggested closure reasonsEdit

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

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

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

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

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

  Support --Liuxinyu970226 (talk) 14:34, 20 December 2017 (UTC)
  Support --Pasleim (talk) 13:41, 21 December 2017 (UTC)
  Oppose even after months no reason is provided why the language of a movie should be described in a different way than for examples songs, websites or books --Pasleim (talk) 18:16, 27 March 2018 (UTC)
  Support and P794 has to be relabelled as movie original language to avoid any other use of this property. Snipre (talk) 21:30, 28 December 2017 (UTC)
  Support and change label per Snipre ArthurPSmith (talk) 21:52, 5 February 2018 (UTC)
  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)

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

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

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

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

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

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

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

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

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

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

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

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

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

download link (P4945)Edit

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

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

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

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

Full   Support for Dhx1 arguments. --Jasc PL (talk) 14:55, 20 April 2018 (UTC)
  •   Delete Needs to come through proper property proposal process.--Jklamo (talk) 07:57, 31 May 2018 (UTC)
  •   Keep --Niridya (talk) 14:47, 16 August 2018 (UTC)

island of location (DEPRECATED) (P5130)Edit


Property:P3183Edit

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 https://en.wikipedia.org/wiki/Wikipedia:Templates_for_discussion/Log/2017_November_16#Template:WSJ_topic Gotitbro (talk) 21:44, 21 May 2018 (UTC)

  •   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)
  •   Delete if it was discontinued. Doesn't really seem to be used (~100).
    --- Jura 14:14, 1 June 2018 (UTC)
  •   Delete Ok, I'll go along with that, seems not much point to keep it now. ArthurPSmith (talk) 15:07, 13 June 2018 (UTC)
  •   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)

item for this sense (P5137)Edit

item for this sense (P5137): (delete | history | links | entity usage | logs | discussion)

Prematurely created (like no label (P5190) above) – the Sense datatype, which this property is supposed to be used on, is not available yet and probably won't be ready for some time. This should be undeleted when the time comes. (property proposal link) – Pizza1016 (talk | contribs) 22:29, 28 May 2018 (UTC)

  • Not quite like. P5190 was incorrectly defined and created with the wrong datatype. Apparently P5137 can be used in a couple of weeks.
    --- Jura 06:34, 29 May 2018 (UTC)
  • @Jura1: According to Léa the Senses will be available in at least 3 months. I think it is a long time to wait with this property created and not be able to use it. For that reason   Delete --Micru (talk) 06:51, 29 May 2018 (UTC)
    • I think it was maximum, not "at least".
      --- Jura 06:57, 29 May 2018 (UTC)
  •   On hold. Judging from how long these deletion discussions often take, we may as well keep this property in limbo until Senses are released and then start using it. Deryck Chan (talk) 11:45, 11 June 2018 (UTC)

Property:P1676Edit


I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Liuxinyu970226 (talk) 23:17, 14 August 2018 (UTC)

Amphibian Species of World ID (P5354)Edit


I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Liuxinyu970226 (talk) 23:17, 14 August 2018 (UTC)

patron (DEPRECATED) (P1962)Edit


Merge: Heritage Building in Finland ID (DEPRECATED) (P4237) and Protected Buildings Register in Finland ID (P5310)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)
  •   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)
  •   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)

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).
  •   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)
  •   Keep   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).
  •   Keep I still see no valid reason for splitting the current property. Cdlt, VIGNERON (talk) 07:23, 14 August 2018 (UTC)

Wikidata project (P4570)Edit

Wikidata project (P4570): (delete | history | links | entity usage | logs | discussion)

@Ivan A. Krestinin, ديفيد عادل وهبة خليل 2, Was a bee, Pigsonthewing, Pasleim:@JakobVoss: According to the discussion on Wikidata:Property proposal/Maintained by Wikiproject, it would be more useful to have this property with datatype item. Therefore I propose to: (1) create a new property with datatype item with the same labels, (2) move existing data to new property, (3) delete P4570. Additionally I would modify the scope of the new property so that it is used on property pages, which I believe it would be more useful than to use this property on item pages.--Micru (talk) 20:57, 1 August 2018 (UTC)

Ping I forgot: @Jura1:--Micru (talk) 21:01, 1 August 2018 (UTC)
  SupportIvan A. Krestinin (talk) 21:05, 1 August 2018 (UTC)
  Comment Similarly as the nominated property Wikidata project (P4570), the proposed property would also be useful for structural items (those which are really structural items, i.e. used in large number by other items). I don’t think the proposed one’s scope should be limited to properties. —MisterSynergy (talk) 22:49, 1 August 2018 (UTC)
The current property is not restricted to structural items, but we could limit the new property to structural items and properties if you think that it is a valid scope.--Micru (talk) 07:11, 2 August 2018 (UTC)
“Structural item” is unfortunately not a well-defined term. I think of items such as physicist (Q169470) which could be maintained by WikiProject Physics (Q8487193), not but items about individual physicists with backlinks, which many of us consider to be “structural items” as well. —MisterSynergy (talk) 11:22, 2 August 2018 (UTC)
  •   Conditional support On the condition that the new property proposal passes and we migrate all existing uses of this property to the new property. Deryck Chan (talk) 10:29, 2 August 2018 (UTC)
  • There is no need for a new proposal in the case of datatype changes. If this PfD passes, then the steps outlined above will be implemented.--Micru (talk) 11:35, 2 August 2018 (UTC)

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)

  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)
  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 (Q56085807). Jc86035 (talk) 06:34, 15 August 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 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)
  •   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)
  •   Delete As said before, let's do this replacement. --Liuxinyu970226 (talk) 22:42, 15 August 2018 (UTC)
  •   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)
  •   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)