Page semi-protected from being moved
Shortcut: WD:PFD

Wikidata:Properties for deletion

From Wikidata
Jump to: navigation, search

This is the properties for deletions page. To nominate a property for deletion, complete the following steps:

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

Requests may be closed after 7 days, but may be extended if consensus is not reached. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Add a new request


On this page, old requests are archived. An overview of all archives can be found at this page's archive index. The current archive is located at Properties/1.

Edit


Administrators'
noticeboard

Development
team

Translators'
noticeboard

Bureaucrats'
noticeboard

Requests
for permissions

Requests
for deletions

Property
proposal

Properties
for deletion

Requests
for comment

Partnerships
and imports

Bot
requests

Project
chat



Requests[edit]

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]

(delete | history | links | logs | discussion)

By using the FRBR system we don't need anymore two properties to describe language of a work: one language propery is enough per item in case of work and translated edition. The original language of the work can be retrieved from the language property of the work item for every translated edition. This implies for sure the possibility to access to several items from one WP article, but as this feature is in development we can already prepare the merge of these two properties. Snipre (talk) 22:48, 8 January 2015 (UTC)
Complementary information: The proposed action is to merge original language of work (P364) and language of work or name (P407) in one property "Language" which can be used for all cases where an item or a statement has to be defined according to its language. This can be for work, but for name or other kind of items. Snipre (talk) 16:04, 26 May 2015 (UTC)

I see there is a lot of good arguments, but the two properties can´t be merged easily. In cases where p 364 is uses as it should be, it must be deleted and secured that p 364 is added to the corresponding work item. In many (thousands) of other cases p364 is used not the way as it is intended instead of p407. So p364 is messed up much more than p 407. I find the concept of p407 is easier to understand, so I suggest to change the RFD round to delete p364 instead, no matter how often the property is used. Once it is done properly, a bot can change the number within hours.--Giftzwerg 88 (talk) 18:42, 18 January 2015 (UTC)
  • I suppose that language of work or name (P407) is used also for other types of entities, for example, in names. Which is not easily convertible to original language of work (P364). --Infovarius (talk) 14:03, 20 February 2015 (UTC)
  • I have used language of work or name (P407) a lot on WikiNews items. Several of them had multiple languages attached. I would therefor keep it. Edoderoo (talk) 22:19, 22 March 2015 (UTC)
    @Infovarius: What is the problem if we merge both properties into "language" ?Snipre (talk) 13:05, 23 March 2015 (UTC)
    @Edoderoo: Can you provide an example please ? And if the new property is called "language", is it still a problem ? Snipre (talk) 13:05, 23 March 2015 (UTC)
    @Edoderoo: How can you use a language property for a wikinews article ? As I see there is a French corresponding article so why English and not French ? Snipre (talk) 16:26, 27 March 2015 (UTC)
    Because English *and* French. I'm Dutch, so for me the English and the French go perfectly together on the same property without any issue ;-) Edoderoo (talk) 22:07, 27 March 2015 (UTC)
    A wikinews can be in language "A" about some public speech which was performed in another language "B". I suppose we can point both languages with different properties (language of work or name (P407) for A, original language of work (P364) for B). --Infovarius (talk) 08:36, 2 April 2015 (UTC)
    @Edoderoo, Infovarius: You mix different concept: the language of the wikinews and the language of the object of the wikinews article. For the first language, this is redundant with the sitelink information. If you want a French article you filter the sitelinks and select the ones which are in French. The example you gave was an typical example of the problem of redundancy: the language properties were not updated according to the sitelinks. And this organization is not applied in the others items: the language property is never used to describe the language of the WPs connected to the item. Look at apple (Q89): 153 sitelinks and around the same number of different languages. But no use of language of work or name (P407) or original language of work (P364). So why do we have to have another practice for wikinews articles ?
    Then about the language of the object of the article. Here we have a problem of definition: Is the item about the wikinews article or about the object of the article ? The classification of the item is clear in your example: instance of Wikinews article. So the language of the object in not part of this item. You should use Israeli legislative election, 2015 (Q17012412) to define the language of the object of the article, and how can an election have a language property ? Here we have a confusion based on the relation "the election is in Israel", "Hebrew is speaking in Israel" so "language of election is Hebrew". Snipre (talk) 14:31, 7 April 2015 (UTC)
  • @Snipre: Which "language property of the work item" are you referring to? As far as I can tell, it's possible to create an item without any language property except for language of work or name (P407) unless someone uses title (P1476) and signifies the language. There are occasionally works that have titles in more than one language, despite the text only being in one, so going by the title language doesn't make sense to me. The way the descriptions are written, I've always used original language of work (P364) as the language of the first edition, not necessarily the current translation. To me, that's been language of work or name (P407). Hazmat2 (talk) 15:42, 27 April 2015 (UTC)
    The idea is to have one language property called "Language" and to use this property for work AND editions items. The use of the merged property "Language" can be used to retrieve all works in a defined language as well to define the language of the editions in the original language or the language of the translated editions. No need any more of a original language property for work and another property for the editions items. We can't use the language of the title because the language of the title can be different from the language of the work/edition. --Snipre (talk) 16:05, 10 May 2015 (UTC)
  • Understood. Thank you, Hazmat2 (talk) 20:21, 26 May 2015 (UTC)
The proposed action is to merge original language of work (P364) and language of work or name (P407) in one property "Language" which can be used for all cases where an item or a statement has to be defined according to its language. This can be for work, but for name or other kind of items.
Please provide your support or opposition to this request in order to progress to a decision. If you are not convinced better vote {{oppose}} but this wiil help at least to close the discussion. Thank you. Snipre (talk) 16:18, 26 May 2015 (UTC)
  • If original language of work (P364) and language of work or name (P407) will be merged, then how to handle in a case when the original text is unknown, but we know the original language? -- Sergey kudryavtsev (talk) 10:02, 27 May 2015 (UTC)
    @Sergey kudryavtsev: Please provide an example. I don't understand the problem. Snipre (talk) 10:44, 27 May 2015 (UTC)
    The example: s:ru:Я целый день изнемогаю (Гейне/Фет) — we know the translator — Afanasy Fet (Q314212), the author — Heinrich Heine (Q44403) and the original language — German (Q188), but we don't known the original text. -- Sergey kudryavtsev (talk) 11:30, 27 May 2015 (UTC)
    @Snipre: What you say about this example? -- Sergey kudryavtsev (talk) 03:55, 4 June 2015 (UTC)
    @Sergey kudryavtsev: The rule is for translation to have a different item. So in your case you should create an item for the original text and a second one for the translation. We don't care about the original text because we use concept in WD. So in the item of the original text we use "language": german and in the second "language": russian. Snipre (talk) 08:07, 4 June 2015 (UTC)
    The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- Sergey kudryavtsev (talk) 10:28, 4 June 2015 (UTC)
    Does your original exist or not ? If you have proof that a translation was made (like a reference) so you can't say that the text was hypothetical or non real. In summary if you have enough sources to say that the author was Heinrich Heine (Q44403) and that the original language was German to put that information (all information should normally have sources in WD) in the item of the translated text, you have enough proofs to be able to create an item for the original text. Snipre (talk) 20:29, 4 June 2015 (UTC)
    Does your original exist or not ? — we don't know this until the original will be found. The text in the books has a subttle "From Heine", but not say which exactly. The subtitle may be true or false — we don't know. E.g. this poem by Dmitry Minaev (Q4293952) has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from Thomas Moore (Q315346), but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia:
    В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся.
    431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250:
    Не молись за меня!-- может быть, это грех,
    Но в мольбу я не верю, не верю судьбе!
    Помолись, моя милая, лучше за тех,
    Кто еще не измучен в борьбе...
    Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн.: Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб., 1871, с. 172.no label (Q4061691), Мур и русские поэты 40--50-х годов: А. Фет, И. Крешев и др.-- Отзвуки популярности Мура в русской литературе второй половины XIX века.
    The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see this poem in ru-ws). -- Sergey kudryavtsev (talk) 11:43, 5 June 2015 (UTC)
    Sorry I wasn't accurate when I was asking if the original text. WD like WP don't need to have a proof of existence to create an item or an article, they just need to have a document with some authority saying that was true (or not) and then you create your item based on that source and you cite the source in the different statements.
    If you have a document X saying that text Y is a translation of text Z and that the original language was OL with the author AA and the translation was done by TT in language TL, you can create three items:
    • item about document X
    • item about text Z
      • author: AA, source: item about document X
      • language: OL, source: item about document X
    • item about text Y
      • translation of : item about text Y
      • translator: TT, source: item about document X
      • language: TL, source: item about document X
    Snipre (talk) 16:23, 7 June 2015 (UTC)
    You have a mistake: Y and Z is muddled. ;-) But this is not impotant in a case of unknown original text (s:ru:Я целый день изнемогаю (Гейне/Фет)). -- Sergey kudryavtsev (talk) 17:59, 7 June 2015 (UTC)
    Thanks. Snipre (talk) 11:40, 10 June 2015 (UTC)
  • Symbol oppose vote.svg Oppose There can be situations when 1 property can be not enough. I can not find convincing example, but here is another one. A film (for example, animated) can be in language A originally (original language of work (P364)), but voice actor (P725) can provide different backgroud languages (so language of work or name (P407) can be used as qualifier for them). --Infovarius (talk) 10:21, 27 May 2015 (UTC)
    Already treated: in the data structure of WD your scenario is described by two items: one for the original movie with the main voices and then a second item for the second language with another set of voices. You can't mix now all voices for different languages in one item. The only open question is about subtitled versions. But you can perhaps show the problem using this item Shrek the Third (Q486588). Snipre (talk) 10:35, 27 May 2015 (UTC)
  • Symbol keep vote.svg Keep the both properties. Instead of deleting, we should impose the rule about language of work or name (P407) and original language of work (P364): either only language of work or name (P407) (for the original works) or both (for the translated/dubbed works). -- Sergey kudryavtsev (talk) 10:28, 4 June 2015 (UTC)
  • Symbol delete vote.svg Delete Merge the two properties. Per Snipre. --Casper Tinan (talk) 11:43, 4 June 2015 (UTC)
  • Symbol delete vote.svg Delete. Merge the two properties. Name the merged property "Language of Work". Create a new property named "Language" for names and other things that aren't creative works. Filceolaire (talk) 20:56, 18 June 2015 (UTC)
  • Symbol keep vote.svg Keep both properties. It's easier to have a separate property than a property plus a qualifier for the main use case. --- Jura 17:10, 26 June 2015 (UTC)
    @Jura1: Sorry but I don't see where you find the mention of a qualifier: we don't need a qualifier because according to the general structure for works in WD you create different items for the different versions of a work. And when you need the language of the original version you use the data of the item of the work and not the items of the versions. Snipre (talk) 12:36, 1 July 2015 (UTC)
    I don't see people creating items for each synchronized version of a film. Original language is sufficient as a property for these (P364). Add additional languages with the other property if you must. It would be a horrible mess if we would create multiple items for the same film or tv series. --- Jura 12:42, 1 July 2015 (UTC)
    @Jura1: You don't see people creating items for synchronized versions because they aren't trained to do it. But now the question it to now for which purpose you want to add language of work or name (P407) in an item of a movie ? Just to say that a movie exists in a certain language ? What's about the publication or release date of the synchronized versions ? What's about the name of the voices in the translated versions ? Just think about anime movies where for each language and for each character you have a different person. "It would be a horrible mess if we would create multiple items for the same film or tv series." That's what we are doing for books and this was never a problem. Snipre (talk) 15:29, 15 July 2015 (UTC)
@Snipre: It's not as simple as training people to create multiple items for a film. The size of that task is very large, there are nowhere near enough contributors. Consider Star Wars, for example: [[1]], see how complicated it gets? If we are to have an item for each release/edition of a film, this work will have to be automated. So, the automation part needs to be solved before these properties can be merged. I would support merging after seeing a proper plan on exactly how all of this will be done. Danrok (talk) 15:29, 23 September 2015 (UTC)
  • Symbol delete vote.svg Delete Merge the two properties. - The use of the 2 different properties is a mess while treating articles in periodicals. One Language property is enough. --Hsarrazin (talk) 12:17, 1 July 2015 (UTC)
    • Just add P364 and you are fine. --- Jura 12:42, 1 July 2015 (UTC)
  • A book can be a translation in a specific language from a specific original language. If we remove the original language, then we must always have an item for the original work. We get away with one less property, but must add a whole bunch of new items for the works themselves. But then, translations should be a directed graph… The language is a property of the original work, and the translation is done from a previous work and into a new one, implying the new work should have its own language likewise the old work. Will there always be an item for the old work? If not then we need an original language. Jeblad (talk) 22:39, 29 July 2015 (UTC)
    • @Jeblad: The creation of a specific item for each edition/translation is already a "rule" in WD (see help:Sources#Books) because each translation has dedicated properties which have to be distinguished from the original edition. How can you specify the place of publication (P291), publisher (P123), publication date (P577), illustrator (P110), editor (P98), number of pages (P1104) and all others identifiers which are different for each edition/translation if you mix several editions/translations into the same item ? The question is not the deletion of one property, the question is to have one system so if you want to keep original language you have to create "original place of publication", "original publisher", "original ISBN",... We have to be coherent. Try just once to provide some specific data of one edition/translation and you will understand why you need each time one item per edition/translation. Snipre (talk) 07:18, 30 July 2015 (UTC)
      • That is a help page and not a policy. Try to create items for news articles with a bunch of reprints, when you only have an approximate idea who is the first publisher. We need to be both accurate for important works and to provide something usable in the simpler cases. Jeblad (talk) 06:13, 31 July 2015 (UTC)
        • @Jeblad: There are no simple cases: what is the benefit to know that an article is translated in Japanese if you have no way to find it ? And nobody asks you to create items for all editions/translation of a document, only one for the document you want to use. Who asks you to look for the data of the first publication ? Nobody. If you have a reprint, just create the item for your reprint and create an empty item for the work in order to link later all reprints. If you don't want to do that better avoid to add data: useless data stay useless even when mix with good data. The data in WD have to be read by people and machines, I really want to know how machines will understand your concept of simple cases and important works. What is an important work ? What is not ? Snipre (talk) 14:03, 31 July 2015 (UTC)
          • Take a deep breath, other people disagree with you, it will happen in life. Jeblad (talk) 14:27, 31 July 2015 (UTC)
@Jeblad: Thank you to admit that your opposition is based on nothing. And by the way, help:sources is not a simple help page because it is the result of a RfC: there was a choice behind that RfC, and the community agreed about one solution. Snipre (talk) 16:49, 8 August 2015 (UTC)
  • merge the two properties, with the FRBR system (which is already widely used on Wikidata and everywhere outside) it's very easy to understand (for both human and robot) to understand if the merged property should be understand as language of work or name (P407) or original language of work (P364). Cdlt, VIGNERON (talk) 21:40, 6 September 2015 (UTC)
    • I think you are confusing books with works in general. About "widely used": do you have any samples and references for films (on Wikidata and outside)? --- Jura 08:09, 10 September 2015 (UTC)
      • Why can't « other » works use FRBR ? FRBR is « Functional Requirements for Bibliographic Records » ; it's not specific to books. And even if the FRBR or a similar system isn't used for some works (which is proably not a good idea in the long run but this is completely understable), I still don't see the need for two porperties. Cdlt, VIGNERON (talk) 17:41, 12 September 2015 (UTC)
        • I'm attempting to address your argument that this is "widely used", but apparently, by not responding to it, you confirm that this isn't the case. --- Jura 15:43, 23 September 2015 (UTC)
  • Symbol keep vote.svg Keep for now. Merging these two properties without having a well thought out plan on exactly how data will be collected would be a mistake. For example, creating new items for each language release of a film is a very large and complex task. It is not a simple as one might imagine, there can be dozens of releases of a single movie across differing media, i.e. theater, VHS, DVD, Blu-ray, etc. Bear in mind, in the case of Blu-ray, several languages may be encoded on to the disc. This cannot possibly be done by humans, unless we have a few thousand contributors willing to work on this. I'd suggest looking at this again in the future, when we may have more suitable automated tools available. Danrok (talk) 15:13, 23 September 2015 (UTC)
    • "we can't create items for each language" is not an argument against single property. You are not required to create multiple entries. Would one like to describe new element such as different edition -- he can create new item. From work complexity point of view it does not matter would it be new item or existing one. In addition, single property does not prevent you from using single item to describe multiple editions. -- Vlsergey (talk) 15:23, 23 September 2015 (UTC)
      • Can you explain how one should identify the original language for a film if you merge the two properties? --- Jura 15:43, 23 September 2015 (UTC)
        • So, what current entity is about? Is it about single translation or original movie? In first case you shall (but not required) to create new item and specify it as P629 value of translation. By next step you either specify language on new entity itself or as qualifier of P629 property. Also P629 can reference itself -- you won't need to create separate item, but self-referencing will be very confusing. Also one can set "unknown value" (if too lazy to create separate item) and put all "original movie" properties as qualifier of P629 property. Back to second case -- when current element is original movie and one want to describe translation. Just add "unknown value" (if too lazy to create separate item) to P747 property and describe language as qualifier. -- Vlsergey (talk) 11:10, 24 September 2015 (UTC)
          • Let's take this one as a sample: Q14955307#P407. You merge the properties and we end up with "languages: sv, de". How do we know that the original language is sv? Assuming no new items are created. --- Jura 11:37, 24 September 2015 (UTC)
            • @Jura1: assuming this entity is about movie, and not about translation, I moved (copied) "de" to edition property: Q14955307#P747. You can add additional properties here (like date of publication of de-edition or additional codes special for de-edition). Thus language of original work will be value of Q14955307#P407. This example assumes we are too lazy to create distinct entity for each translation. -- Vlsergey (talk) 11:57, 24 September 2015 (UTC)
              • Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work (P364), doesn't it? It might as well work with the existing property. It would have the benefit that we know what the original language is -- currently we don't because both sv and de are listed as language of work (Property:P407). --- Jura 12:34, 24 September 2015 (UTC)
                • @Jura1: 1. Well, nothing really requires to delete the property. It just makes things more complicated and confusing from model point of view. In this particular case 361 is not a original language, but language of the same element. In other cases it is duplication of property from "parent work" entity. 2. I kept "de" in P407 property just to make sure not to break any infoboxes. It could be deleted, leaving "sv" as single value of 407. -- Vlsergey (talk) 20:20, 24 September 2015 (UTC)
                  • I'm not really sure if the original language is sv or sv+de. I picked this sample as the item used it in a way that items would use if this proposal would go through. If deletion is not required and in order to close this discussion, would you oppose the deletion proposal so we can move on? --- Jura 09:31, 25 September 2015 (UTC)
                    • 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be deleted. When I said "nothing really requires" i just reflected your opinion that usage of my scenario doesn't require deletion of property. But this is like trying to prove that you don't need to stop littering to hire a cleaning guy. You need both: to hire a cleaning guy to cleanup the mess AND to stop creating more mess. We need to select some scenario to reduce mess with translations (incl. movie translations) AND we need to prevent such mess from arising again in future by deleting "original language" property. -- Vlsergey (talk) 14:43, 28 September 2015 (UTC)
                      • You will be needing a cleaning guy for your solution as it's not clear what people should enter in the merged "language" field. Currently it's clean! --- Jura 19:58, 29 September 2015 (UTC)
                        • It is completely clean that language field shall contain original language of entity and language of derived items should be in "language" property of separate item. Current solution with language+original language is a mess. It indulges people to put all data into single item for all languages and all translation, creating real mess from movie item. -- Vlsergey (talk) 13:51, 5 October 2015 (UTC)
                          • A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- Jura 17:18, 5 October 2015 (UTC)
                            • Well it is. Clearly my fear already realized. I already see items that include both original work information and translation information, thus creating mess with structure and data even for other properties (such as date of publication or voice actors list) -- Vlsergey (talk) 12:40, 6 October 2015 (UTC)
  • Symbol keep vote.svg Keep for now. Regardless of whether other types of works should be modeled according to FRBR, I think it's apparent that at this point, they aren't. The redundancy from reciprocal properties is a much more manageable and reversible issue than the one that would arise from a hasty merge that disrupts the existing workflow for a category such as films. FRBR is not a panacea, and is not the sort of drag-and-drop solution it is being made out to be. Dancter (talk) 19:34, 23 September 2015 (UTC)
    • I don't see arguments regarding merging or non-merging properties. It is not FRBR requirement to merge or keep properties, it is just that FRBR model can be used as example of model where two properties are not required. You still can use single element to display information about single movie with all it's translations (if one would like to). But for sure you will need to create new element as soon as one would like to describe translation voice actors (and not mess them up in case there are 2 or more translations to single language). -- Vlsergey (talk) 11:10, 24 September 2015 (UTC)
      • What specifically are you asking for? Not requiring two properties is not the same thing as requiring one property. Redundant properties should be a relatively manageable issue, particularly reciprocal properties such as these. Disrupting the existing workflow for film category edits by removing a property without firmly establishing a consensus, guidance, and transition for a replacement protocol is more problematic. FRBR is the justification being offered for the merge, despite the fact that the model is not being used everywhere on Wikidata. Effectively imposing that model (or whatever you want to call the particular work-edition model being proposed here) to other domains is not that simple, especially with only cursory nods to implementation, and it should not be something decided in a discussion ostensibly about the deletion of language of work or name (P407)). My other objections go more to Wikidata philosophy in general (deleting, merging, property discussions, qualifiers, redundancy, etc.) and are probably beyond the scope of this discussion. Dancter (talk) 19:25, 24 September 2015 (UTC)
        • I assume you have in mind "current" workflow (perhaps with multiple translations in single element) and want to have some formal discussion regarding moving from one workflow to another. But sorry, there is no such distinguished "workflow discussion pages", and property deleting discussion page is already used for such things. -- Vlsergey (talk) 20:24, 24 September 2015 (UTC)
  • Symbol delete vote.svg Delete Let's keep the language or name scheme as simple as possible. author  TomT0m / talk page 19:13, 4 October 2015 (UTC)
  • Symbol delete vote.svg Delete Merge the two properties. Per Snipre. Carlos Porto (talk) 00:03, 16 October 2015 (UTC)
  • Symbol keep vote.svg Keep, there are books in English that are translations of French editions of Dutch books. The language of the edition is thus English; the source from which it was translated in French; but the original language of the work is Dutch. I am thinking specifically here of The Waning of the Middle Ages, where the first English editions were (badly) translated from the French; the edition more recently translated directly from the Dutch has a different title. This sort of intermediate translation happens with high regularity for ancient texts (The first English translation of Hammurabi's Code was made from the German translation of the original) and so there needs to be a way to distinguish current language, source language, and original language. Eliminating the distinction without having a plan in place to accommodate this sort of data would not be a wise move. --EncycloPetey (talk) 02:28, 27 October 2015 (UTC)
@EncycloPetey: Thanks to mention that particular case but I think just multiplying the languages properties in an item will be a problem because for most contributors there is only one language for one edition.
For the mentioned case I think the relation between translated works should be made using edition or translation of (P629) and perhaps even create a different property to distinguish between "edition of" and "translation of". For example if I want to know the language of the edition used as source (this edition can be the original one or a already translated edition) I extract that information from the corresponding item. I completely not understand why we have to create special properties for language and not for author. If we need current language, source language, and original language why don't we do the same for translator, translator of the source and author of the original work ?
The logical way is to put all relevant information in the appropriate item and to link the different items in order to be able to look for the information at the correct place. Snipre (talk) 12:31, 27 October 2015 (UTC)
@Snipre: Thanks for your comments. Perhaps we can agree that a merge at this time is premature? A larger discussion is probably needed to decide how to deal with the related issues. If a suitable method can be found, then a merge might be possible, but I think a merge at this time would merely result in a loss of information. --EncycloPetey (talk) 19:53, 27 October 2015 (UTC)
  • Pictogram voting comment.svg Comment an easier solution for the library catalog problem might be to create a separate namespace/entity-type (sample: "E") for books. These could link back to works in the usual Q-namespace. Maybe some other thing would be better there as well. --- Jura 14:26, 27 October 2015 (UTC)
    There was this prototype for source Wiki-database some Wikidata Weekly weeks ago. But I think another namespace will actually create more problems that it would solve. author  TomT0m / talk page 14:49, 27 October 2015 (UTC)
    Wasn't that just a copy of something unrelated already running elsewhere? Obviously, it would need some coordination per namespace, but not necessarily more than is needed now on "every" item. It could also solve some of the issues with wikisource. --- Jura 15:27, 27 October 2015 (UTC)
    The simplier solution is to apply strictly the FRBR model. Using that structure we store each data in only one item and when we need to have data from other items we look for it in the other items. Snipre (talk) 15:40, 27 October 2015 (UTC)
    Maybe we could do that by simply linking to some other cat. --- Jura 15:55, 27 October 2015 (UTC)
  • Symbol delete vote.svg Delete I've been thinking about this issue for a while. Let me give an example:

This summer I added some Spanish release dates (with publication date (P577)) for movies, tv series, tv seasons and tv episodes. Usually I also added original network (original network (P449), for TV-Movies) and title (title (P1476)). My method was simple: every fact comes with a qualifier place of publication (P291) => Spain (Q29). See some examples: The Hunger Games: Mockingjay – Part 1 (Q4142083), Pushing Daisies (Q515621), season 5 of Lost (Q840781), Pilot (Q16165171).

However, I didn't know how to handle particular cases like:

  • American TV-Movies that premiered on theaters in Spain, and vice-versa (instance of (P31) change between film (Q11424) and television film (Q506240)).
  • The same for other distribution mediums, like VHS, DVD, Blu-Ray... all have different release dates, and maybe different titles.
  • Voice actors. Sometimes re-releases have new dubbing.
  • Different release dates for pay television (Q721830) vs. "wide/free" television. Usually TV series premiere in pay television (codified, only subscriptors) before than wide access television ("en abierto" in spanish).

Finally, I realised that I was wrong. I was mixing "original" properties with "edition" properties. All dates I've added are valid for spanish dubbed versions of the movies, so I should create new items for dubbed movies, TV series, TV seasons and TV episodes. Also new items for re-releases if there are changes in voice actors, titles... Yes, it's a tough, hard task, but I think that it's the only way to store all that information. Is there another way? Otherwise, if we keep language of work or name (P407) different from original language of work (P364), why shouldn't we do the same with title (P1476), original network (P449), publication date (P577)...? --Escudero (talk) 15:45, 10 November 2015 (UTC)

  • Symbol keep vote.svg Keep Gangleri also aka user:I18n (depending on browser) I have seen hundreds of P407.07:46, 12 January 2016 (UTC)
    • "I have seen hundreds of P407" -- it's not a valid reason to keep, actually. -- Vlsergey (talk) 19:23, 13 January 2016 (UTC)
  • Symbol keep vote.svg Keep the both properties. I like 'language of work or name', I use it with property 'named after'. I can live with 'language of work or name' (P407) as subproperty of 'original language of work' (P364), as well. --Chris.urs-o (talk) 09:01, 12 March 2016 (UTC)
    • Chris.urs-o The question is not to know if you like one property or not but to know if having only one property 'language' is a problem for your work ?  – The preceding unsigned comment was added by Snipre (talk • contribs) at 02:01, 20 March 2016‎ (UTC).

doubles record (P555) and singles record (P564)[edit]

(delete | history | links | logs | discussion) (delete | history | links | logs | discussion)

Can be replaced by wins (P1355) and losses (P1356) with qualifiers. Even if it is not replaced, it should replaced by four properties with number datatype.--GZWDer (talk) 16:28, 2 February 2016 (UTC)

  • Delete per the nominator--these should be replaced since a wins/losses combined property is non-granular semantic information (indicated by the expected dash). --Izno (talk) 13:59, 8 March 2016 (UTC)
  • Delete. Thierry Caro (talk) 08:56, 12 March 2016 (UTC)
  • Symbol keep vote.svg Keep for now. Four properties make more sense, but this property should be kept until then. Qualifiers are not an appropriate substitute for sub-properties, though. --Srittau (talk) 02:45, 25 March 2016 (UTC)
    "but this property should be kept until then" - We have the replacement properties and just need to do the replacement. Voting keep based on the fact it's being used is not a valid reason for keeping. Lastly, sub-properties are a bad thing. --Izno (talk) 12:14, 28 March 2016 (UTC)
    What are those properties? I only see wins (P1355) and losses (P1356), we are still lacking "games won in singles/doubles", "games lost in singles/doubles". --Srittau (talk) 19:12, 28 March 2016 (UTC)
    @Srittau: something generic like wins of (P642) "singles tennis match" (which would be P31 types of tennis match (Q1967745) and P279 tennis match P279 competition or similar). --Izno (talk) 16:20, 26 April 2016 (UTC)
  • Symbol delete vote.svg Delete wins (P1355) and losses (P1356) can be used but we need a good qualifier to make the distinction between single/double/mixed matches. --Pasleim (talk) 10:05, 6 April 2016 (UTC)
    of (P642)? --Edgars2007 (talk) 10:31, 6 April 2016 (UTC)

comment (P2315)[edit]

(delete | history | links | logs | discussion)

This property is currently being used for (at least) three separate things, which I think is a bad idea because Wikidata is about structured data and storing comments as data only makes sense if the properties are well defined (i.e. we know what the comments are for, who they're aimed at and when they should be shown).

This property was originally added to store comments for property constraints and was not intended to be used just yet. Unfortunately, the original label and description were too vague. The description was then changed, which redefined the property and turned it a property for usage instructions instead (see also phab:T97566). The label is still vague, so it's also being used as a generic comment property whenever people want to add a comment to something (some of the ones I've seen appear to be people wanting to add custom edit summaries, which is covered by phab:T47224).

I'm proposing to delete this property as it is currently poorly defined and none of the uses are what it was actually created for. Instead, I suggest that we add a new property to replace the original approved property (with a better label and description, "Wikidata property constraint comment" might work) and create two new property proposals for the other uses. If the new proposals are accepted, the existing statements for this property should be migrated to the new properties. If they are rejected and this deletion request is accepted, the existing statements should be deleted.

- Nikki (talk) 16:03, 24 February 2016 (UTC)

See Wikidata:Property_proposal/Generic#Wikidata_usage_instructions and Wikidata:Property_proposal/Generic#comment for the two new proposals I mentioned. - Nikki (talk) 16:09, 24 February 2016 (UTC)
Pictogram voting comment.svg Comment Property Wikidata usage instructions (P2559) created as a result of this request, but no other new property. Original property is retained. -- LaddΩ chat ;) 22:57, 7 March 2016 (UTC)
  • Delete per the nominator. Clearly is not being used correctly, and the talk page suffices for a comment. --Izno (talk) 13:56, 8 March 2016 (UTC)
  • Symbol delete vote.svg Delete Overloaded property. --Srittau (talk) 02:46, 25 March 2016 (UTC)
  • Pictogram voting comment.svg Comment I cleaned up the most of the remaining uses. Going forward, usage instructions that are in descriptions, can use Wikidata usage instructions (P2559). Once the MediaWiki feature is available, this can be removed from descriptions. Notes that are in qualifiers, can continue to use this property. Obviously, it needs to be monitored to avoid that it isn't misused. To limit this, I changed the property label (the problem with the current label was already pointed out before it was actually created). Currently the bulk of inappropriate uses were those that should have been using P2559, but weren't converted when that property was requested and created. Seems like someone didn't follow up on the creation → fixed. There were a few cases liked this, where actual content was added in the property. It seems the property now works as it should.
    --- Jura 11:27, 25 March 2016 (UTC)
    • Please don't change labels of properties in substantive fashion while there is an ongoing deletion request. I should have but didn't realize that the edits I made earlier today were to this property. --Izno (talk) 12:12, 28 March 2016 (UTC)
      • Sorry about that, I thought I had cleared up the problematic uses and the only remaining ones are the ones where this covers a gap between the new property and the remaining uses. To avoid future problems, the label needs to be changed (as already suggested before creation, on first discussion, etc.). If there are no arguments against it, we can finish sorting this out and can close this discussion.
        --- Jura 10:20, 16 April 2016 (UTC)
  • Symbol delete vote.svg Delete obviously. Cdlt, VIGNERON (talk) 14:56, 8 April 2016 (UTC)
  • Symbol delete vote.svg Delete, has no connection with structured data.--ԱշոտՏՆՂ (talk) 21:13, 6 May 2016 (UTC)

manufacturer (P176) and main building contractor (P193)[edit]

These property's descriptions (in English) do not seem to differ substantially and fundamentally come down to "the builder of a thing", and even share an alias. One of the properties is used more than the other. A "manufacturer" of a building might be a little weird to some people, but I think having one property for "constructor"/"builder" would be preferable to the two. Lastly, while neither had any substantial discussion, P193 has only a single user agreeing to its creation, leading me to believe it was not reviewed thoroughly by the community (both were created prior to having a well-established property creation process). I am suggesting that we should delete main building contractor (P193) in favor of manufacturer (P176) and merge any claims as appropriate. --Izno (talk) 11:23, 5 May 2016 (UTC)

  • very Symbol keep vote.svg weak keep. I believe that these are representing separate concepts, but I'm having a hard time trying to put this feeling into words (which is why the "very weak"). I'll keep thinking though. Thryduulf (talk: local | en.wp | en.wikt) 14:29, 10 May 2016 (UTC)
  • Symbol keep vote.svg Keep I don't know if this is true for other languages, but certainly in English, one doesn't usually speak of manufacturing a building. And manufacturing and construction are generally considered quite distinct domains/industries. Manufacturing usually involves creating many a large number of very similar items (e.g. a car manufacturer will produce thousands of cars of each model, all close to identical) whereas construction generally involves building unique individual items (no two buildings will be alike – that might not always be true, but very often is). I think it will be confusing to editors and readers to conflate these two concepts, even if logically one could get away with it. SJK (talk) 14:09, 17 May 2016 (UTC)
  • Weak Symbol keep vote.svg Keep as well. Sub-property that implies a few things that manufacturer (P176) does not imply. --Srittau (talk) 15:39, 17 May 2016 (UTC)
  • Symbol keep vote.svg Keep Agree with Srittau. Technically it would work to handle main building contractor (P193) as a manufacturer (P176), if construction works like any other manufacturing, but I do not think that is the case. -- Innocent bystander (talk) 06:20, 18 May 2016 (UTC)

number of faces (P1658)[edit]

Recently the properties number of edges and number of vertices were replaced by has part (P527) with qualifier quantity (P1114). number of faces (P1658) is a property of the same kind and can also be replaced by has part (P527). @Tobias1984, Zolo: ping property proposer and creator --Pasleim (talk) 12:37, 10 May 2016 (UTC)

  • With face (Q3064117)? Delete if so. --Izno (talk) 12:59, 10 May 2016 (UTC)
  • Is it possible to query the qualifiers of has part (P527) using the sparql interface? And as usual I would like to remind everyone that Wikidata is capable of handling multiple ontologies. has part (P527) and other, more specific properties, can happily coexist. So currently I favour Symbol keep vote.svg Keep. --Tobias1984 (talk) 20:52, 10 May 2016 (UTC)
    • We can "handle" multiple ontologies, but we should not due to a shit ton of reasons. There may be some exceptions, but this should not be one of them. --Izno (talk) 14:55, 11 May 2016 (UTC)
  • Delete definitely. (A) it looks like everything that could use this property is already using has part (P527) with the suggested qualifier. There are a relatively small number of named three-dimensional polyhedra that this could apply to so it really doesn't seem useful to keep a custom property around for this. (B) from a mathematical standpoint, "face" is a 3-dimensional concept and I don't think we'd want to generalize this to the corresponding properties in each higher dimension for any special objects of mathematical interest, especially since the corresponding properties for edges and vertices have already been removed. On Tobias's question - yes, you can query for qualifiers via the wikidata SPARQL interface but it's a little more complicated as you need to use the full statements rather than the "truthy" ones. ArthurPSmith (talk) 18:59, 11 May 2016 (UTC)
  • @Tobias1984: sample query to get the number of faces. --Pasleim (talk) 19:30, 11 May 2016 (UTC)
@Pasleim: Thanks for sharing the query. I guess that addresses my main concerns and I can along with the deletion. --Tobias1984 (talk) 16:46, 12 May 2016 (UTC)
    • Hi guys; has part (P527) [SQID] or has part of the type search ? Technically there is many instances of this kind of polygons. author  TomT0m / talk page 17:19, 17 May 2016 (UTC)
      • This is a class to class relation. --Izno (talk) 18:10, 17 May 2016 (UTC)
        • Oh yes right, I'm tired ... author  TomT0m / talk page 18:13, 17 May 2016 (UTC)
  • Agree with delete per similar changes to the handling of vertices / edges. Deryck Chan (talk) 16:55, 20 May 2016 (UTC)

ISO standard (P503)[edit]

(delete | history | links | logs | discussion)

Bad datatype. Should be item like ISO/IEC 80000 (Q568496) View with Reasonator and this one should be deleted/redeployed with a domain of iso norms. For example I just put it on ISO/IEC 80000 (Q568496) View with Reasonator ...--author  TomT0m / talk page 08:43, 18 May 2016 (UTC)

Well, we would need two properties: "ISO standard this is standardized in" and "this is the item for ISO standard #1234". This property could be repurposed for the latter. Also, we should have the replacement items first, before deleting this one. --Srittau (talk) 11:57, 18 May 2016 (UTC)
Were we to pursue the action of repurposing (which I think I support), I would suggest a rename as well to "standard number" or similar, so that we can apply this outside the realm of ISO with e.g. MIL-STD. --Izno (talk) 12:11, 18 May 2016 (UTC)
@TomT0m: I vaguely recall asking if this property existed a while ago, heh. It has the wrong domain for the question at the time. That said, oppose deletion per Srittau, and support a new property (if necessary) called "specification"/"specified in", for the same domain as P503 with item datatype. --Izno (talk) 12:11, 18 May 2016 (UTC)

Freebase ID (P646)[edit]

(delete | history | links | logs | discussion)

Freebase (Q1453477) has gone offline. Result for a random P646 link: "Es wurden keine mit deiner Suchanfrage - knowledge graph search api - übereinstimmenden Dokumente gefunden" (google.de).--Kolja21 (talk) 16:34, 20 May 2016 (UTC)

  • If the formatter url doesn't work, it should be deprecated (or, if that doesn't help, be removed). This has nothing to do with the identifier as such.
    --- Jura 16:38, 20 May 2016 (UTC)
  • Is not there dumps of freebase available somewhere ? Then the information should not be deleted and made hardly available. author  TomT0m / talk page 16:42, 20 May 2016 (UTC)
  • Keep per the TomTom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 23 May 2016 (UTC)

phone number (URL) (P1244)[edit]

(delete | history | links | logs | discussion)

Unused duplicate of phone number (P1329)--Srittau (talk) 15:07, 23 May 2016 (UTC)

phone number (P1329)[edit]

(delete | history | links | logs | discussion)

Duplicate of phone number (URL) (P1244), created for use until tel: is available. In the meantime, it's possible to activate the tel: prefix for URLs and this would solve the many malformed input on this property. Conversion of existing entries will be taken care of.
--- Jura 15:15, 23 May 2016 (UTC)

  • How would using an URL fix the malformed inputs? There is nothing preventing you from entering URLs that don't conform to the format prescribed by tel:. --Srittau (talk) 15:27, 23 May 2016 (UTC)
    Also Symbol oppose vote.svg Oppose, phone number (P1329) has clearly won the popularity contest and is the better property, since representing phone numbers as URLs adds an unnecessary level of abstraction. --Srittau (talk) 15:29, 23 May 2016 (UTC)
  • Use of phone number (URL) (P1244) was always planned, but is currently not possible. It can now be activated and Lydia asked for community feedback before. URLs have formatting constraints built in while strings don't.
    --- Jura 15:39, 23 May 2016 (UTC)
    Telephone numbers are not URLs. No need to "activate" an inferior property when we already have a superior one. Especially when tel: URLs are not supported yet and supporting them would require valuable developer resources. --Srittau (talk) 15:49, 23 May 2016 (UTC)
    It's an accepted prefix. It wont make them http-urls obviously and the change needed has been identified and is fairly trivial. I noticed you didn't respond when being asked for help to find a solution to clean-up Wikidata:Database_reports/Constraint_violations/P1329#.22Format.22_violations in the project chat discussion: Wikidata:Project_chat#phone_number_.28URL.29_.28P1244.29_and_phone_number_.28P1329.29.
    --- Jura 15:55, 23 May 2016 (UTC)
    Because all violations have been fixed in the meantime. --Srittau (talk) 16:01, 23 May 2016 (UTC)
    Thanks for doing that. I had cleaned up some entries before and was looking for a solution to prevent malformed entries. The problem is that given the few entries that use the property, the ratio of problematic entries is -IMHO- too high. If we don't want to keep cleaning them up, we need to find a solution that prevents problems beforehand. P1244 is such an option.
    --- Jura 16:15, 23 May 2016 (UTC)

    What formatting constraints built in do you think exist, and have you confirmed that with the tech team? I don't believe that what you are saying is true.

    That aside, what are your primary constraints concerns? --Izno (talk) 09:19, 24 May 2016 (UTC)

  • Symbol oppose vote.svg Oppose deletion. @Nikki, Pigsonthewing: from the PC discussion. --Izno (talk) 09:16, 24 May 2016 (UTC)
  • Symbol keep vote.svg Keep As per project chat discussion. - Nikki (talk) 09:36, 24 May 2016 (UTC)