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.






for permissions

for deletions


for deletion

for comment



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, с. 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: The Farewell (Q14955307). 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: The Farewell (Q14955307). 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 The Farewell (Q14955307). 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 (language of work or name (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), Lost (season 5) (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 two properties can sometimes be a mess, but, e.g., for Silent Night (Q172152) it makes sense to me. The original language of work (P364) is German (Q188) while it exists in a number of other languages. Splitting the item into translated versions seems to babelfuscate language links? — Finn Årup Nielsen (fnielsen) (talk) 19:45, 22 January 2016 (UTC)

Wikidata example properties[edit]

I proposed these before I realised there is a better way of recording examples, using Wikidata property example (P1855); see [2] for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 30 July 2015 (UTC)

I prefer keeping them. Your other approach introduces uses as qualifiers for exisiting properties. And, no, it's not appropriate to change all uses before the end of this discussion. Please undo your edits where this hasn't been done yet. --- Jura 13:00, 30 July 2015 (UTC)
@Jura1: What's wrong with "introducing uses as qualifiers for existing properties" ? We have already done this in a big way with is a list of (P360) -- see the results of eg this query for qualifiers used on P360 statements. Jheald (talk) 17:02, 8 October 2015 (UTC)
Symbol keep vote.svg Keep, seems useful in sandboxes or in docs to have properties with some sample datatypes we can use without messing around with properties actually used for real datas, at least. author  TomT0m / talk page 09:10, 15 August 2015 (UTC)
@TomT0m: There are also sandbox properties Sandbox-CommonsMediaFile (P368), Sandbox-Item (P369), Sandbox-String (P370), Sandbox-TimeValue (P578), Sandbox-GeoCoordinateValue (P626), Sandbox-URL (P855), sandbox-quantity (P1106), Sandbox Monolingual text (P1450) --Pasleim (talk) 20:55, 16 August 2015 (UTC)
OK, then if they are useless after all, don't see don't see a good reason to oppose deletion. author  TomT0m / talk page 16:16, 18 August 2015 (UTC)
Actually, the problem mentioned remains (samples messing around with properties used for real data), especially since we can now use properties on properties. --- Jura 13:33, 20 August 2015 (UTC)
@TomT0m: In that case, please strike your "keep", above, to avoid confusion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 5 January 2016 (UTC)
Symbol delete vote.svg Delete. Reusing the property itself in the example is much clearer than using those properties. Thierry Caro (talk) 01:35, 20 August 2015 (UTC)
Symbol delete vote.svg Delete per andy. Joe Filceolaire (talk) 23:21, 20 August 2015 (UTC) It looks like we will need these as placeholder properties for defining rules for transitive; reflexive; etc properties. See Wikidata:WikiProject Reasoning. GZWDer: note that we will need a sandbox property for each datatype so that is pretty much all of these. Joe Filceolaire (talk) 18:44, 31 August 2015 (UTC)
@Filceolaire: Does Sandbox-Property (P2368) satisfy this, for you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 5 January 2016 (UTC)
Redefine Wikidata example property value (P1863) as a sandbox property, delete the rest--GZWDer (talk) 05:02, 26 August 2015 (UTC)
@GZWDer: have you checked how they are being used? --- Jura 05:35, 26 August 2015 (UTC)
@Jura1: Their current usage should be cleared once the discussion is closed.--GZWDer (talk) 05:37, 26 August 2015 (UTC)
@GZWDer: I created Sandbox-Property (P2368) as sandbox property with datatype property. --Pasleim (talk) 22:10, 30 November 2015 (UTC)
@GZWDer: Does Sandbox-Property (P2368) satisfy this, for you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 5 January 2016 (UTC)
So what is the actual outcome of this discussion, if any? Should we stop using them? Should we replace them all? Will they be deleted? (Sorry for the noise.) Matěj Suchánek (talk) 20:36, 30 November 2015 (UTC)
I had closed this as no consensus to delete, considering it had been open for a long time with little to no discussion. I have, however, reopened it, per request, to see if any further discussion takes place.  Hazard SJ  02:29, 3 January 2016 (UTC)
Symbol delete vote.svg Delete Reusing the existing properties in examples is clearer and causes less confusion than the use of those properties. Already the discussion above shows that many users are confused and mistake those example properties with sandbox properties. --Pasleim (talk) 20:20, 5 January 2016 (UTC)
Symbol delete vote.svg Delete I agree that using the properties themselves in examples is clearer. - Nikki (talk) 19:29, 6 January 2016 (UTC)
Symbol keep vote.svg Keep use these for test/sample/sandbox data on property items. Entering samples with actual properties mixes test/sample/sandbox data into production dataset. Samples on property documentation look the same with these properties than they do with actual properties, so the clarity is the same. Using these properties makes users focus on actually defining samples, making sure they are ready to define samples.
--- Jura 19:40, 6 January 2016 (UTC)
@Jura1: I'm not sure I agree. If you look at the example Andy gave (diff), it seems to me that it doesn't "mix test/sample/sandbox data into production dataset".
The value 18049321 doesn't become a value of the property wt:P2011, it becomes a value of the qualifer pq:P2011, attached in the specific context of the exemplar property Wikidata property example (P1855) -- something which should be straightforward enough to filter out, even in the rare occasion that one were to be specifically querying for the property used in a qualifier context.
In my view this is something well worthwhile, for the clear benefit of using the immediately apparent Cooper-Hewitt Person ID (P2011) to show how P2011 is used, rather than the much less clear Wikidata example string (P1858) syntax. Jheald (talk) 21:39, 6 January 2016 (UTC)
@Pigsonthewing: please don't change qualifiers before this deletion debate is over. Multichill (talk) 22:35, 9 January 2016 (UTC)
The two are not mutually exclusive. In any case, I merely reverted a more recent change which itself was made while this deletion proposal was taking place. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 9 January 2016 (UTC)
This duplicates Jura1's comment of 30 July 2015. Double-counting should be avoided. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 9 January 2016 (UTC)
Symbol delete vote.svg Delete as a new property creator I was confused by this for a week or two - using the actual property as a qualifier in the example is actually a good test that things are working as well as demonstrating use. I would be happy to help replacing old uses of these if there's a consensus to do that before deleting. ArthurPSmith (talk) 19:05, 14 January 2016 (UTC)
Pictogram voting comment.svg Comment Months ago I wrote a script which should move some property metadata from talk pages to statements, including those examples. This discussion has however been blocking me since then. Is there any chance on closing this soon?
Advantage of using the property itself is that the value can automatically get formatted by the gadget (in the future by the software). Matěj Suchánek (talk) 12:09, 24 January 2016 (UTC)

Language of Instruction / Medium of instruction[edit]

I think we need a separate property for Language of Instruction / Medium of instruction in schools and I don't think a generic 'Language' property can do this. Before I start the proposal I thought I would test the waters here. Joe Filceolaire (talk) 22:45, 27 August 2015 (UTC)

@Filceolaire: Not the best place to discuss this kind of topic. I think go to the property proposal pages and explain in details what you need and the case you want to describe. Snipre (talk) 16:19, 28 August 2015 (UTC)

input set (P1851)[edit]

(delete | history | links | logs | discussion)

Unclear definition AS (talk) 01:11, 27 May 2015 (UTC)

I have reviewed the creation discussion and still have no idea what this is for. Symbol delete vote.svg Delete unless @TomT0m, Danneks, Cuvwb: can shed some light on this. Filceolaire (talk) 10:35, 3 June 2015 (UTC) Vote changed - see discussion below. Joe Filceolaire (talk) 20:03, 27 October 2015 (UTC)

@Filceolaire: you provided incorrect discussion link. It is about different property. -- Vlsergey (talk) 20:15, 16 June 2015 (UTC)
@AS, Filceolaire: This property can help to describe functions whose domains are too complicated, and maybe not notable by themselves. It is not used much at the moment, but functions (e.g. in set-theoretic sense) are widely used in mathematics, so I think that it may be potentially useful. Danneks (talk) 18:22, 3 June 2015 (UTC)
@Filceolaire, AS: It's the A set in this mathworld definition. It's commonly used for example for the inverse function on the real, who has no value in R for 0, but still has R as input set, for example. The real domain of the function is nonzero real number (Q19546578) (View with Reasonator). TomT0m (talk) 11:22, 6 June 2015 (UTC)
what is the difference between domain (P1568) and input set (P1851)? Can you provide an example when domain (P1568) is not enought? -- Vlsergey (talk) 20:15, 16 June 2015 (UTC)
@Vlsergey: It's done, see my previous message. TomT0m (talk) 20:49, 16 June 2015 (UTC)
@TomT0m: let me make it clear. You want to express that and , right? But we have . Why do we need to duplicate that in function itself? -- Vlsergey (talk) 20:55, 16 June 2015 (UTC)
@Vlsergey: One can be used when we speak of a relation on any sets to any set, not only to functions. For example a database, when a customer can be registered but has not yet bought anything, or a complicated function like 1/(x-1)(x-2)(x-3). The input set of the relation beetween customer and transactions would still be customer, but some may have no relations at all. domain is clearly out of scope here. input set can be applied to function. It's unlikely that the item R minus {1,2,3} will be created either. TomT0m (talk) 21:03, 16 June 2015 (UTC)
@TomT0m: okay, i understood about math functions. Still this can be expressed with qualifiers (R except...). For database relationship it is still not clear for me. What is item and why we can't put "customer" into domain (P1568)? (with broader domain (P1568) definition of course). It would be better to provide an example with actual Wikidata entries. I care little about abstract concepts, sorry. Vlsergey (talk) 21:12, 16 June 2015 (UTC)
I have many example of non total functions, halting problem (Q622849) (View with Reasonator) involves a HALT function which is from programs to 1,0 which has programs as input set but is undecidable. partial function (Q1756942) (View with Reasonator) provides other examples. The notion of domain is also non applicable for relations ( ordering relation (Q1069998) (View with Reasonator) ) like 1<2 or other binary relation (Q130901) (View with Reasonator). It's well know that functions can be seen as binary relations iRo with i (input set) as their domain and o (output set) as their range. TomT0m (talk) 07:21, 17 June 2015 (UTC)
We may speak of a function from R2 to R2 when we really mean one from U in R2 to V in R2. In my opinion this is important for characterizing the function type. For example I want all 2D vector fields, no matter what particular subset of R2 they are defined on, to be noted as such. So in short, Symbol keep vote.svg Keep.--Jasper Deng (talk) 22:06, 13 August 2015 (UTC)
Jasper Deng: References would help. --Succu (talk) 22:16, 13 August 2015 (UTC)
@Succu: Do you even understand what I'm saying?--Jasper Deng (talk) 22:52, 13 August 2015 (UTC)
Jasper Deng: Mind to translate R2, U and V for beeings not living in a vector space (Q125977)? Please give a clear definition of the mathematical terms domain (P1568) and input set (P1851). What exactly renders them to be different? And stop guessing! --Succu (talk) 20:49, 14 August 2015 (UTC)
@Succu: I don't think you understand the level of math at which I'm talking since I'm not talking about general vector spaces. But out of these two, only domain is well-defined. In my comment, R2 is the "input set".--Jasper Deng (talk) 06:10, 15 August 2015 (UTC)
@Filceolaire: Are you satisfied with the current discussion or do you have other questions ? If you still don't understand, it's maybe useful to say that it's a notion we study on secondary school in maths courses, so a not so advanced one. Maybe pinging other mathematicians like @HB: for support will help :) I'll left a message on the french math wikiproject, it's a cool opportunity to communicate around Wikidata. author  TomT0m / talk page 09:07, 15 August 2015 (UTC)
It's difficult for me to write english. So please, be kind with me and improve my text. There is a difference between set of departure and domain. The set of departure is defined for a binary relation(binary relation (Q130901)). See this definition for example. So, the set of departure of a partial function(partial function (Q1756942)) is defined like the set of departure of a binary relation. @Succu:In Deutsch, set of departure = Vorbereich und domain = Definitionsbereich[3]. For exemple, the function f(x)=1/x is a partial function whose set of departure is R. It's a total function[4] whose domain is R - {0}. Mostly, the domain is the better property of a function but if we cannot precise the domain , the set of departure is a good property indeed. Its also a good property for classes of functions like functions of a real variable(function of a real variable (Q861681)) whose set of departure is R and domain a subset of R. We may delete set of departure-property and put in domain-property the value set of X but it would be a pity since the notion of set of departure does exist. Symbol keep vote.svg Keep for me HB (talk) 13:57, 15 August 2015 (UTC)
Nachträglich anpingen funktioniert nicht, aber ich vermute mal er bekommt's auch so mit. --Nenntmichruhigip (talk) 16:11, 15 August 2015 (UTC)
HB: Thank you for your explanation. I'd tried to understand the problem, and failed because I think I learned other German terms for these at school. But that’s a while ago. --Succu (talk) 15:25, 16 August 2015 (UTC)
page I am familiar with set theory. That isn't where my confusion lies. All the wonderful discussion of functions above is, as far as I am concerned, irrelevant because it doesn't have an example of a practical example here on wikidata - where we call the functions "properties" and the sets "classes". You need to give an example of an actual statement where it is useful to state the 'input set' of an item instead of stating the 'domain'.
We also need an example where 'input set' is useful for making a statement about a property. Joe Filceolaire (talk) 20:36, 16 August 2015 (UTC)
@Filceolaire: Properties are not functions, they are relation (Q203066) (View with Reasonator) :) And in relations it is not required at all that any member of the input set or the output set are members of the relation at all. When we say that the domain of a property is "human beeing" this does not imply at all that humans has a value for this property. I know it's not that easy to find examples, but I'm pretty sure if I need this property in the future and that I'll have to pass to the whole review process, I'll be sad and I'm not sure I'll attempt. It's so long and boring ... On the other hand a ready property just in case for a defined notion is not really costly, that's why I presented a consistent plan with domain/input set/image/output set initially that seemed reasonable and pretty well known in maths. Maybe 6 months, and it's still not over. This implies I'm totally on something else now. So much discussion for a such small problem is a love breaker. I know there is Bonnie and Clyde problems in advanced maths for generalized functions like complex logarithm (Q2520206) can have pretty complex domains (discontinuous on the negative numbers for example) although its input set in clearly the complex numbers. I would not be able to express this easily if I want to. This has an impact on potential queries : If I want to know all functions on the complexes in math, if the Domain is C-Z or whatever, the query will be more complex to implement for example. author  TomT0m / talk page 12:06, 17 August 2015 (UTC)
Symbol keep vote.svg Keep - @TomT0m: First of all, sorry for my English. All the values in domain must have a correspondent value in image set. e.g. the domain of the function "VIAF ID" is a set which all the persons that have a VIAF ID. I, for one, can not be in this group, because I do not have a VIAF ID. But the entry set of the "VIAF ID" may be all the instance of (P31) human (Q5), since there can be an element of the entry set for which there is no corresponding image. Almondega (talk) 02:03, 18 August 2015 (UTC)
Hi and welcome on Wikidata. Looks like someone is reading my talkpage :) author  TomT0m / talk page 12:33, 18 August 2015 (UTC)
So no one can think of even one example where we should use this property rather than "domain". I'm still voting delete. Joe Filceolaire (talk) 15:05, 18 August 2015 (UTC)
@Filceolaire: I reread the en:Partial_function article and I found a funny example of elementary maths: the domain function that computes the difference beetween two numbers with the result in N as a range. if you take this as a partial function from NxN->N, then the domain is (x,y) such that x>y, not that easy to express :) The subclass relationship subclass (Q3965271) is probably a better example. Imagine a function "smallest wrt. inclusion" with input sets A,B -> C as A and B classes, and that returns A if A is included in B, and B if converse. If neither A is included in B and B in A, then the result would be undefined. author  TomT0m / talk page 16:15, 18 August 2015 (UTC)
@Filceolaire:. This property is already used in tangent (Q1129196) and cotangent (Q1264373). What would put as domain in theses cases? HB (talk) 16:54, 18 August 2015 (UTC)
Thank you HB. At last a concrete example. Now if you can just explain to me why "domain:real numbers" is incorrect then we will finally be getting somewhere. Joe Filceolaire (talk) 15:50, 19 August 2015 (UTC)
@Filceolaire: The domain of a function, by definition, is the set of all "permitted inputs", for which the function has a value. The cotangent function, for example, is not defined at zero, because \tfrac 10 is not a number. It can be regarded as a point on the Riemann sphere, but it would be another function. Danneks (talk) 17:36, 19 August 2015 (UTC)
Thank you Danneks and now we are almost there. So the Domain is the set that includes all 'permitted inputs' and excludes all 'non-permitted inputs'. (I presume that is what you were trying to say above) while the input set is the set that includes all 'permitted inputs' and may also include some 'non-permitted inputs'. Is that it HB, TomT0m?
Such a pity no one said this earlier. If this is the definition then it sounds like we need another property to identify non-permitted inputs' wherever we use 'input set' so we can say <tangent - 'input set:real numbers', 'non-permitted inputs:90°, 270°'>. Joe Filceolaire (talk) 11:32, 20 August 2015 (UTC)
@Filceolaire: We might better need properties like Union of / intersection of / set substraction to express more complicated sets, like for example real numbers minus integers or something. This is more general. And "non permitted inputs" is not really general enough as there is infinite sets involved for example in the example HB showed. In the end if we are able to express the set, we would just need domain and create an item for the set. Which is not a goal we can easily achive, at least with current Wikidata status, as we try to explain since the beginning of this discussion. Can we settle this and close this discussion ? As you're the proposer this would be cool you removes the proposal so we can move on :) author  TomT0m / talk page 14:46, 27 October 2015 (UTC)
TomT0m: Vote changed per discussion above. As a 'non-permitted inputs' property can have multiple values and can link to sets as well as to individual values I still think it would work. multiple values = Union of. Value with qualifier = intersection of.
@Filceolaire: This seems not really robust to me. Wikidata's semantics about multiple values is somewhat not really clear. If we have two date of birth for example we can't really interpret that as a union but more as an either date1 or date2 situation, we can't assume there might not be other values because of the "open world" issue (that's the same reason I proposed a qualifier on the "union of/union" proposal who is still on hold) ... Does not seems to be right to rely on that to model maths :) Plus we would need to discriminate sets and member values. This needs more thinking and more care to be done right. author  TomT0m / talk page 20:42, 27 October 2015 (UTC)
You're probably right. Either way it's a separate discussion.
Anyway I have changed the description of 'input set (P1851)' so it matches the discussion here. Joe Filceolaire (talk) 20:03, 27 October 2015 (UTC)
This is another topic but "permitted value" does not really make mathematical sense, we're not talking of computational functions but of mathematical one, so the function is simply undefined for those values. Not sure this is clear for everyone ;) author  TomT0m / talk page 20:42, 27 October 2015 (UTC)
TomT0m If 'non-permitted values' is incorrect then can you come up with a better phrase for the set of values that are included in the 'input set' but which are not included in the 'domain'? We need to include such a phrase in the description of 'input set' to make it clear how 'input set' is different from 'domain'. How about "values for which the function is undefined"? The description for input set (P1851) can then be
a superset of the domain of a function or relation that may include some inputs for which the function is not defined. Use Domain (P1568) for the set of inputs for which the function is defined.
OK? Then we can create a new property labelled "Values for which the function is not defined" to work alongside input set (P1851). Joe Filceolaire (talk) 03:45, 28 October 2015 (UTC)
Symbol keep vote.svg Keep. I have slightly modified the description to a superset of the domain of a function or relation that may include some inputs for which the function is not defined; to specify the set of only those inputs for which the function is defined use domain (P1568). By the way, the number of items using this property is rising. ;-) Can we close this PfD now? Petr Matas 08:09, 4 January 2016 (UTC)
The proposed property "Values for which the function is not defined" would have data type Item and its value would be equal to input set (P1851) minus domain (P1568), which is no simpler than domain (P1568). Furthermore, the value would depend on both input set (P1851) and domain (P1568), whereas the latter two properties are to some extent independent. So I would not vote for such property. Petr Matas 08:09, 4 January 2016 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. author  TomT0m / talk page 20:41, 22 January 2016 (UTC)

officeholder (P1308)[edit]

(delete | history | links | logs | discussion)

Proposal pages: Original proposal (accepted, property created), later duplicated proposal (rejected), third duplicate proposal (rejected, most participants not aware that the property already existed afaict). This property is an inverse of position held (P39), which could result in many position items having literally hundreds or thousands of values set, making the item potentially unusable. Regardless of whether inverses are ever sensible, it's fairly clear that in this case it would be thoroughly unmanageable. --Yair rand (talk) 09:39, 14 June 2015 (UTC)

Pinging original proposer @Jdforrester: and property creator @Jakec:. (Apparently the property_proposer and property_creator parameters in Template:Request for deletion don't actually do anything.) --Yair rand (talk) 09:43, 14 June 2015 (UTC)
  • Symbol delete vote.svg Delete With arbitrary access rolling out, this property should be deleted. —Wylve (talk) 13:13, 17 June 2015 (UTC)
  • Pictogram voting comment.svg Comment there is actually a third way doing more or less the same: head of government (P6) and head of state (P35).
    officeholder (P1308) has the advantage of not overloading items for countries as does head of government (P6).
    position held (P39) does work well to make lists like Governors of Vermont --- Jura 09:54, 18 June 2015 (UTC)
  • Symbol keep vote.svg Keep; P6 and P35 are inappropriate for the wider needs, as widely discussed at the time. Individuals' unwillingness to help build the data right now isn't a good criterion for whether we should have the flexibility to express it. James F. (talk) 02:28, 22 June 2015 (UTC)
    @Jdforrester: This is redundant to position held (P39), not head of government (P6) and head of state (P35). Many offices (though not, afaik, offices of head of state/government) have been held by thousands of people. --Yair rand (talk) 11:36, 22 June 2015 (UTC)
    @Yair rand: San Marino elects at least 4 head of states every year. And Stockholm has 12 kommunalråd. -- Innocent bystander (talk) 13:12, 15 July 2015 (UTC)
    @Yair rand: Except it's precisely the ontological reverse of position held (P39), which allows us to model more complex things (like parallel office holders, pretenders, etc.). James F. (talk) 00:41, 28 June 2015 (UTC)
    I don't understand what you're saying. (This is probably because I don't recognize the term "ontological reverse".) Do you disagree that this is just a simple inverse of position held (P39), and adds no new data? If so, could you give an example of data this property could be used for that position held (P39) couldn't be used for? --Yair rand (talk) 16:53, 28 June 2015 (UTC)
    If it is the inverse of another property it adds new data per definition. If A is connected to B by one property B is connected to A by its inverse, so deleting the inverse would require another inverse propery to replace it. - cycŋ - (talkcontribslogs) 12:18, 15 July 2015 (UTC)
    No, it would not. Properties are not required to have inverse properties. This inverse in particular is completely unmanageable. --Yair rand (talk) 18:19, 15 July 2015 (UTC)
    @Yair rand: While you are totally right concerning proper database design, Wikidata is currently not working this way (at least for what I can tell). Giving an easy example: I want to find out the Mayor of New York. The corresponding item is Mayor of New York City (Q785304). With officeholder (P1308) I can find out the current Mayor is Bill de Blasio (Q4911497), but how could I find out if officeholder (P1308) was deleted? (Still, from Bill de Blasio (Q4911497) I could find out that he is Mayor of New York by position held (P39), but I'm looking for de Blasio, so I indeed need the inverse way.) // Symbol keep vote.svg Keep as long as the inverse view is not implemented properly in the Wikidata MediaWiki software. Yellowcard (talk) 12:39, 16 October 2015 (UTC)

Symbol delete vote.svg Delete It is nonsense to store 2 twice the same information in a queryable database. Louperivois (talk) 20:47, 16 August 2015 (UTC)

While I don't like the property as it is unclear that it reverse "position held" it could be useful for periods of interregnum to state "vacant", similarly occasions when it is browsed data, gaps will be more obvious and invite someone to fill. I would like to see how it is proposed to be used for pretenders. @Jdforrester: an example would be helpful to further the argument.
  • IMO these are totally different properties, and I am not sure, if this is a translation problem. According to the German title of officeholder (P1308) would hold "Barack Obama", "Angela Merkel" or "Vladimir Putin", and position held (P39) would hold "President of the United States", "Chancellor of Germany" or "President of Russia". Furthermore {{P|1308]] can only be appield to people incumbant in their function. Former holders of the offices described in position held (P39) cannot have officeholder (P1308) attached. According to the actual German translations of these propertys it must be Symbol keep vote.svg Keep, but I won't rule out that the translations are wrong. --Matthiasb (talk) 10:16, 16 October 2015 (UTC)
  • Symbol keep vote.svg Keep To me there can only be one officeholder, and at some stage it will become defunct and not be filled, or it will be abolished, temporarily not filled, etc. in other words it will have a history all of its own, and that should be retained -- an officeholder will have a start date, and either an open-ended or a fixed date for completion, each individually defined. Conversely there can be many people who have held a position, and that would be a continuously held, or it can have gaps, etc. With officeholder it can clearly show periods of no position, not so easily when you work the reverse. Have to run a query to get that data is not feasible in many circumstances for most people, and those who see that as a solution are not accounting for the needs of the whole populace.  — billinghurst sDrewth 20:52, 10 November 2015 (UTC)
  • strong Symbol keep vote.svg Keep as with Yellowcard, billinghurst, James F., matthiasb we have many inverse properties, this is no reason for deletion. Until now the database query is limitated. So at this moment queryable database is no reason to delete. And @Yair rand: as we do not have "hundreds or thousands of values set" also panic is no reason to delete. This property is the only one simple giving the name of the person actual in charge like:Barack Obama. And as there is only one in charge at a time there will never be "hundreds or thousands of values set", just the name of the person actual in charge.--Oursana (talk) 02:27, 12 January 2016 (UTC)
    @Oursana: There are currently 14,816 items that have position held (P39) member of parliament in France (Q3044918), all of which could be listed as officeholder (P1308) of member of parliament in France (Q3044918). The property isn't limited by time, nor is it limited to single-holder offices. The original proposal specifically included former members of parliaments. I could probably add all 14,816 items to member of parliament in France (Q3044918) in one edit by means of a script, but it would probably break Wikidata. We should not have properties where proper use literally breaks the project. --Yair rand (talk) 04:15, 12 January 2016 (UTC)

opposite of (P461)[edit]

(delete | history | links | logs | discussion)

This property is very badly used. In the huge majority of uses the world is far too complicated to find a real opposite. A binary vision is quite dangerous in our data.--Kvardek du (talk) 17:05, 1 August 2015 (UTC)

Any examples? Sjoerd de Bruin (talk) 16:18, 4 August 2015 (UTC)
Well, I pretty much see this used as in black/white for example, which is not really a good example of meaning, but nobody would say that yellow FFFF00 is the opposite of blue 0000FF as 000000 (black) is the opposite of FFFFFF (white). Is "love" the "opposite" of "hate" ? We actually also speaks of "love"/"hate" relationships. We should take some example and study if there is anything to so with them at all. author  TomT0m / talk page 09:22, 15 August 2015 (UTC)
"Love–hate relationship (Q1030284)" is about having two opposite emotions for the same object. Things like "war" or "indifference" are sometimes said to be opposite to specific cases of "love" in specific expressions, but love (Q316) is about the most generic "love". --AVRS (talk) 08:49, 24 August 2015 (UTC)
I agree this does not make sense in a huge majority of cases. A really better definition would be based on the "complement" notion of the set theory. If we can divide (lets take a bad example) the human action set into good actions and evil actions, and that an action is either good or bad, but nether both, then the "good action" class is the complement of the "bad action" class in the "human action" class. In the same spirit I proposed strongly defined "union of" and "disjoint union of" properties (see Wikidata:Property proposal/Generic § subclass). author  TomT0m / talk page 16:47, 4 August 2015 (UTC)
Some example taken from Man / woman : the opposite, really ? Big Bang, Big Crunch ? Internet / extranet ?
What's true is that if we take all human, then remove all women, we get all men, and conversely. In math we say that men complements women in the set of human. This has a meaning, and is a proposed property we could work with, for example, but I would not know how an intranet is the opposite of internet. author  TomT0m / talk page 09:22, 15 August 2015 (UTC)
Except the complement of all women is all men + all intersex. --Izno (talk) 18:34, 15 August 2015 (UTC)
@Izno: Yes, it's good to find good and accurate examples :) Actually it's the proposed Wikidata:Property proposal/Generic § subclass disjoint union of (partitioned into?) that would fit here :
< human (Q5) (View with Reasonator) > disjoint union of search < Woman >
together with search < Man >
together with search < Intersex >
. It's not approved yet thought, although there is a lot of example of use cases here. author  TomT0m / talk page 09:29, 16 August 2015 (UTC)
Delete. I agree with the proposer's rationale. --Izno (talk) 18:34, 15 August 2015 (UTC)
Not sure if the property is terribly useful, but that can be said about a few others as well.
For some of the pairs, it might be worth adding a qualifier to indicate what differentiates/opposes them. --- Jura 07:03, 16 August 2015 (UTC)
Concerning colors and man/woman, there may be a property specifying the "frame of reference" (similar to approved by (P790)). I don't know about color models, but there is "gender binary (Q5530970)". --AVRS (talk) 08:49, 24 August 2015 (UTC)
gender binary (Q5530970) even has a French label. "frame of reference" could be a good start for the qualifier. --- Jura 07:02, 26 August 2015 (UTC)
I think that the "opposite" could be interesting for a property, but it has been used weirdly. Perhaps the scope is too broad. I like the suggestion by Jura1 to indicate somehow in what respect the pair of items represent opposites. I was surprised to find opposite pairs like Gibraltar (Q1410) and Te Arai (Q7690759), which are merely antipodes on the globe. It is clarified with a instance of (P31) antipodes (Q319909) as a qualifier, I'm not sure it is the right way to indicate it, but something like that should be added, by obligation IMHO. If so, I say Symbol keep vote.svg Keep. Lymantria (talk) 17:51, 29 August 2015 (UTC)
There is just such a qualifier: criterion used (P1013), and I agree it should be mandatory. In your example, a better qualifying statement would be criterion used (P1013) geographic coordinate system (Q22664), but "antipode" might be sensibly proposed as a subproperty of opposite of (P461) Swpb (talk) 15:20, 29 December 2015 (UTC)
  • Symbol keep vote.svg Keep. Add documentation, clean up where necessary, create better properties where possible, relist if still not satisfied. --AVRS (talk) 10:44, 13 September 2015 (UTC)
  • I suggest reading en:Opposite_(semantics)#Antonyms. Opposite can mean different things. Probably this property could be made more exact using qualifiers to state what kind of oposition it means in each statement, or it could be split in more precise properties. Anyway, in its present state it isn't machine-readable (as Wikidata should be) because it's need a human decide it's meaning in each item. It's more a trivial section than a fact statement - it doesn't harm but I don't see it very useful as of now.--Pere prlpz (talk) 17:47, 6 November 2015 (UTC)
    @Pere prlpz: Everything is in the "Word" in the "pair of words". Wikidata do not speak of words at this point, this is for Wiktionary. For some cases here, we use opposite for the "complement" notion (I simplify for the example : (for simplification I just ignore the LGBT and co. cases at first) : "every human is either a man or a woman". To express this, at this point, some people on Wikidata would use "man : opposite : woman". In the proposition "Wikidata:Property proposal/Generic § subclass" we have the possibility to say that the set of all men and the set of all women are disjoint, and that when taken together (the union of the set of all man and all woman is the set of all human. This can be said in maths language "the set of men is the complement of the set of women in the set of human". If we add the set of all "transgender" or others as needed, we kind express this as "Human is the disjoint union of men, women, transgender, ..." author  TomT0m / talk page 18:01, 6 November 2015 (UTC)
  • Symbol keep vote.svg Keep But I have encountered plenty of claims which don't make sense to me. For example, monohull (Q1999103) has been claimed to be the opposite of multihull (Q1642862). Perhaps something has been lost in translation? Danrok (talk) 16:02, 18 December 2015 (UTC)
  • Symbol keep vote.svg Keep, but require qualifier criterion used (P1013); create subproperties like antiparticle (P2152) as warranted. Swpb (talk) 15:12, 29 December 2015 (UTC)

structure replaces (P1398)[edit]

(delete | history | links | logs | discussion)

Label went wrong at creation, needs to be deleted and re-created as "structure replaces" (not "structure replaced by"). See talk page of property. --- Jura 11:33, 30 October 2015 (UTC)

  • Pictogram voting comment.svg Comment See the above deletion discussion for P1398's sibling, #Property:P167. The best label might be like "spatially replaces" if that's what distinguishes this from replaces (P1365). Mrwojo (talk) 15:39, 30 October 2015 (UTC)
  • Pictogram voting comment.svg Comment this seems fairly straight-forward, could we go ahead with this? --- Jura 13:55, 13 December 2015 (UTC)
  • Symbol oppose vote.svg Oppose This property has fewer than 20 uses. It can be repurposed, without the need for deletion, if there is consensnus to do so in the ongoing discussion in its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 17 December 2015 (UTC)
    • Can you provide any reference for a possibility to "repurpose" properties? Given that you seem to be editing as a resident Wikipedia, can you clarify if your editorial contributions are endorsed by the Royal Society of Chemistry and/or reflect the views of the Royal Society of Chemistry? --- Jura 10:56, 17 December 2015 (UTC)
      • Jura, knock it off. His POV is irrelevant to this discussion and most others on Wikidata. --Izno (talk) 17:58, 17 December 2015 (UTC)
        • Good point. I suppose I'd better ignore him going forward. So can someone close this? --- Jura 07:57, 18 December 2015 (UTC)
  • Symbol oppose vote.svg Oppose Label has been fixed, no need to delete. Useful concept. Danrok (talk) 15:56, 18 December 2015 (UTC)
    • There is no issue with the concept as such. It's just that (someone) broke the label just after it was created. Now all downstream references to the property were and maybe still are incorrect. An no, the labels are not all fixed. Just create a new property and move the applicable parts there, nothing really complicated. --- Jura 16:02, 18 December 2015 (UTC)

number of edges (P1569)[edit]

(delete | history | links | logs | discussion)

number of vertices (P1570)[edit]

(delete | history | links | logs | discussion)

(Notifying original proposer @Zolo: and creator @Jakec:.)

Both of these properties are little used and redundant to has part (P527) (and sometimese has facet polytope (P1312)) qualified by quantity (P1114). --Yair rand (talk) 10:03, 22 December 2015 (UTC)

  • Symbol delete vote.svg Delete per nominator's rationale. Swpb (talk) 15:38, 29 December 2015 (UTC)

compressor type (P1221)[edit]

(delete | history | links | logs | discussion)

Unused (only 2 items), can be done with instance of (P31). --- Jura 18:46, 28 December 2015 (UTC)

after a work by (P1877) etc.[edit]

vice-county (P1887)[edit]

(delete | history | links | logs | discussion)

Still unused: the property doesn't seem to have any practical use and the proposer seems to have suggested it without ever using it. --- Jura 07:15, 25 January 2016 (UTC)

  • Keep and procedural close ASAP. vice-county (P1887) was recently discussed on this page, also nominated by Jura1, with no support whatsoever. The discussion was closed as "keep" as recently as 17 December 2015. The claim that the property "doesn't seem to have any practical use" is utterly bogus, as is the claim that the property is "unused", and both are contradicted in that previous discussion, in comments to which Jura1 posted responses. Once again, I was not notified of this nomination. Furthermore, this renomination, when there are another 255 properties with fewer than 3 uses, appears very pointed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 31 January 2016 (UTC)
    • The property was created in May 2015‎ and it's used only once. I'm sure that if this is a useful property that it can be used more? I'll check back in a couple of weeks. If it's still barely used it will probably be deleted, if it's usage is better we can keep it. Also @Jheald: Multichill (talk) 17:43, 5 February 2016 (UTC)
    • In the meantime, Pigsonthewing had another 8 weeks to find uses for this property, but apparently this wasn't possible, just as much as during the 8 weeks of the previous nomination. This despite posting 5-10 comments about the property. In the previous discussion, it wasn't even clear if the only other keep vote was supporting the property as they had another use in mind.
      --- Jura 06:22, 8 February 2016 (UTC)
      • I wasn't aware that we were up against a deadline (nor indeed that it was my personal responsibility to ensure that the deadline was met). Please can someone point out where it is documented? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:22, 10 February 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)