| 0 |
- '###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input: liturgical_rank_(P9002): Kept . Consensus to [MASK] this. Thanks. ( ) Kept . Consensus to [MASK] this. Thanks. ( ) The creation is still in process (as you can see, obviously not all steps of the creation process have been completed, yet) and there were no outstanding issues on a months-old proposal. I would argue all four creation criteria were met in this case, and the proposal was mentioned in multiple other places over the course of the past half year to seek further input. -- ( ) please ask a property creator to look into it once issues are sorted out. --- It would be helpful to know which issues are outstanding. On the proposal itself none were raised, bar a question whether this property could be used for other religions where applicable, and this question was affirmed. I will delete the property if there is indeed an issue left that I have missed. -- ( ) The issue of how this property behaves outside of Christian tradition seems to be open. ❪ ❫ As already pointed out twice it is applicable for every religion which has a similar concept of religious feasts. I'd like to add that this is a nonproblem simply by the fact that no other religion is known to have such a sophisticated liturgy. – Yes, seconded - I don't know others that would need it, but I also don't see a problem with them using it. -- Apriori I think it's possible that while other religions not have the same concept of religious feasts as Christianity, they have similar holy days that are somehow labeled with something like a rang. Narrowing this to religious feasts when another religion doesn't think of their holy days as being about feasts can complicate reuse. That's why it makes sense to look at the needs of other religions before creating the property. – The preceding comment was added by ( • ). We are not discussing about here, which references "feast days". We are talking about an additional aspect for this already existing, widely used property. If such a hypothetical calendar of another religion comes up, they can use "liturgical rank" as well. If the term "liturgical rank" is not fit for them, it can surely be changed to something more general ( is however already not a Christianity-specific term). -- It would be helpful to know which issues are outstanding. On the proposal itself none were raised, bar a question whether this property could be used for other religions where applicable, and this question was affirmed. I will delete the property if there is indeed an issue left that I have missed. -- ( ) The issue of how this property behaves outside of Christian tradition seems to be open. ❪ ❫ As already pointed out twice it is applicable for every religion which has a similar concept of religious feasts. I'd like to add that this is a nonproblem simply by the fact that no other religion is known to have such a sophisticated liturgy. – Yes, seconded - I don't know others that would need it, but I also don't see a problem with them using it. -- Apriori I think it's possible that while other religions not have the same concept of religious feasts as Christianity, they have similar holy days that are somehow labeled with something like a rang. Narrowing this to religious feasts when another religion doesn't think of their holy days as being about feasts can complicate reuse. That's why it makes sense to look at the needs of other religions before creating the property. – The preceding comment was added by ( • ). We are not discussing about here, which references "feast days". We are talking about an additional aspect for this already existing, widely used property. If such a hypothetical calendar of another religion comes up, they can use "liturgical rank" as well. If the term "liturgical rank" is not fit for them, it can surely be changed to something more general ( is however already not a Christianity-specific term). -- The issue of how this property behaves outside of Christian tradition seems to be open. ❪ ❫ As already pointed out twice it is applicable for every religion which has a similar concept of religious feasts. I'd like to add that this is a nonproblem simply by the fact that no other religion is known to have such a sophisticated liturgy. – Yes, seconded - I don't know others that would need it, but I also don't see a problem with them using it. -- Apriori I think it's possible that while other religions not have the same concept of religious feasts as Christianity, they have similar holy days that are somehow labeled with something like a rang. Narrowing this to religious feasts when another religion doesn't think of their holy days as being about feasts can complicate reuse. That's why it makes sense to look at the needs of other religions before creating the property. – The preceding comment was added by ( • ). We are not discussing about here, which references "feast days". We are talking about an additional aspect for this already existing, widely used property. If such a hypothetical calendar of another religion comes up, they can use "liturgical rank" as well. If the term "liturgical rank" is not fit for them, it can surely be changed to something more general ( is however already not a Christianity-specific term). -- As already pointed out twice it is applicable for every religion which has a similar concept of religious feasts. I'd like to add that this is a nonproblem simply by the fact that no other religion is known to have such a sophisticated liturgy. – Yes, seconded - I don't know others that would need it, but I also don't see a problem with them using it. -- Apriori I think it's possible that while other religions not have the same concept of religious feasts as Christianity, they have similar holy days that are somehow labeled with something like a rang. Narrowing this to religious feasts when another religion doesn't think of their holy days as being about feasts can complicate reuse. That's why it makes sense to look at the needs of other religions before creating the property. – The preceding comment was added by ( • ). We are not discussing about here, which references "feast days". We are talking about an additional aspect for this already existing, widely used property. If such a hypothetical calendar of another religion comes up, they can use "liturgical rank" as well. If the term "liturgical rank" is not fit for them, it can surely be changed to something more general ( is however already not a Christianity-specific term). -- Yes, seconded - I don't know others that would need it, but I also don't see a problem with them using it. -- Apriori I think it's possible that while other religions not have the same concept of religious feasts as Christianity, they have similar holy days that are somehow labeled with something like a rang. Narrowing this to religious feasts when another religion doesn't think of their holy days as being about feasts can complicate reuse. That's why it makes sense to look at the needs of other religions before creating the property. – The preceding comment was added by ( • ). We are not discussing about here, which references "feast days". We are talking about an additional aspect for this already existing, widely used property. If such a hypothetical calendar of another religion comes up, they can use "liturgical rank" as well. If the term "liturgical rank" is not fit for them, it can surely be changed to something more general ( is however already not a Christianity-specific term). -- Apriori I think it's possible that while other religions not have the same concept of religious feasts as Christianity, they have similar holy days that are somehow labeled with something like a rang. Narrowing this to religious feasts when another religion doesn't think of their holy days as being about feasts can complicate reuse. That's why it makes sense to look at the needs of other religions before creating the property. – The preceding comment was added by ( • ). We are not discussing about here, which references "feast days". We are talking about an additional aspect for this already existing, widely used property. If such a hypothetical calendar of another religion comes up, they can use "liturgical rank" as well. If the term "liturgical rank" is not fit for them, it can surely be changed to something more general ( is however already not a Christianity-specific term). -- We are not discussing about here, which references "feast days". We are talking about an additional aspect for this already existing, widely used property. If such a hypothetical calendar of another religion comes up, they can use "liturgical rank" as well. If the term "liturgical rank" is not fit for them, it can surely be changed to something more general ( is however already not a Christianity-specific term). -- [MASK] There were 2 supporting comments in the proposal discussion, although neither one used the support template to express that, which is unusual. was one of the two, however, so should have requested the proposal be created by an independent property creator. Please check how other property creations are done before creating another one, thanks. ( ) @ : I don't think that comments from people who don't know the property creation process well enough to use the support template should be seen as demonstrating consensus for creation when there are people who are familiar with our process that still point to open issues. Our policy does say "i.e. an opposing voice with no thought behind it should not block creation, but a single reasonable opposing voice against many supporters may do so". ❪ ❫ @ : But there weren't any opposing voices either, reasonable or unreasonable. All questions raised had been addressed. Not sure what your point is here. ( ) @ : I don't think that comments from people who don't know the property creation process well enough to use the support template should be seen as demonstrating consensus for creation when there are people who are familiar with our process that still point to open issues. Our policy does say "i.e. an opposing voice with no thought behind it should not block creation, but a single reasonable opposing voice against many supporters may do so". ❪ ❫ @ : But there weren't any opposing voices either, reasonable or unreasonable. All questions raised had been addressed. Not sure what your point is here. ( ) @ : But there weren't any opposing voices either, reasonable or unreasonable. All questions raised had been addressed. Not sure what your point is here. ( ) For ease of access, is the original proposal. -- [MASK] as one of the supporting persons in the proposal. Also I fail to see any open issues – ###Output: '
- '###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input: language_of_work_or_name_(P407)and_original_language_of_film_or_TV_show(P364): I close this deletion proposal as undecided , because of change of basis of the proposal. Its basis changed since was created earlier this year. Both properties are kept for now, but new deletion proposals may be started accounting the the existance of . ( ) I close this deletion proposal as undecided , because of change of basis of the proposal. Its basis changed since was created earlier this year. Both properties are kept for now, but new deletion proposals may be started accounting the the existance of . ( ) @ , , , : What's FRBR? --- . In simple words, work, translations and edition are described in different items. ( ) . In simple words, work, translations and edition are described in different items. ( ) What is the other property that you are talking about? ( ) vs. . ( ) So you want ot merge and . Since is more specific than , and since you wrote "we don't need anymore two properties to describe language of a work [...] The original language of the work can be retrieved from the language property of the work item", then I suggest to delete instead of/and not . ( ) I am pragmatic: use of : 95129, use of : 7588. See ( ) vs. . ( ) So you want ot merge and . Since is more specific than , and since you wrote "we don't need anymore two properties to describe language of a work [...] The original language of the work can be retrieved from the language property of the work item", then I suggest to delete instead of/and not . ( ) I am pragmatic: use of : 95129, use of : 7588. See ( ) So you want ot merge and . Since is more specific than , and since you wrote "we don't need anymore two properties to describe language of a work [...] The original language of the work can be retrieved from the language property of the work item", then I suggest to delete instead of/and not . ( ) I am pragmatic: use of : 95129, use of : 7588. See ( ) I am pragmatic: use of : 95129, use of : 7588. See ( ) What would happen with films in FRBR? --- Same as translations for book: a new items for each translated version in order to put the name of the "voices". ( ) Same as translations for book: a new items for each translated version in order to put the name of the "voices". ( ) 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 [MASK] 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. -- ( ) I suppose that is used also for other types of entities, for example, in names. Which is not easily convertible to . -- ( ) I have used a lot on WikiNews items. Several of them had multiple languages attached. I would therefor [MASK] it. ( ) @ : What is the problem if we merge both properties into "language"\xa0? ( ) @ : Can you provide an example please\xa0? And if the new property is called "language", is it still a problem\xa0? ( ) @ :, find an example here: . In case "language of work" will be cancelled completely, yes, then "language" would be a replacement. ( ) About 60 of the 8000+ occurences are now on WikiNews articles. But I found more weird occurences, like given names with this property. ( ) @ : How can you use a language property for a wikinews article\xa0? As I see there is a French corresponding article so why English and not French\xa0? ( ) 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\xa0;-) ( ) 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 ( for A, for B). -- ( ) @ , : 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 : 153 sitelinks and around the same number of different languages. But no use of or . So why do we have to have another practice for wikinews articles\xa0? 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\xa0? 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 to define the language of the object of the article, and how can an election have a language property\xa0? 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". ( ) @ : What is the problem if we merge both properties into "language"\xa0? ( ) @ : Can you provide an example please\xa0? And if the new property is called "language", is it still a problem\xa0? ( ) @ :, find an example here: . In case "language of work" will be cancelled completely, yes, then "language" would be a replacement. ( ) About 60 of the 8000+ occurences are now on WikiNews articles. But I found more weird occurences, like given names with this property. ( ) About 60 of the 8000+ occurences are now on WikiNews articles. But I found more weird occurences, like given names with this property. ( ) @ : How can you use a language property for a wikinews article\xa0? As I see there is a French corresponding article so why English and not French\xa0? ( ) 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\xa0;-) ( ) 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 ( for A, for B). -- ( ) @ , : 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 : 153 sitelinks and around the same number of different languages. But no use of or . So why do we have to have another practice for wikinews articles\xa0? 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\xa0? 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 to define the language of the object of the article, and how can an election have a language property\xa0? 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". ( ) @ : How can you use a language property for a wikinews article\xa0? As I see there is a French corresponding article so why English and not French\xa0? ( ) 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\xa0;-) ( ) 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 ( for A, for B). -- ( ) @ , : 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 : 153 sitelinks and around the same number of different languages. But no use of or . So why do we have to have another practice for wikinews articles\xa0? 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\xa0? 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 to define the language of the object of the article, and how can an election have a language property\xa0? 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". ( ) @ : How can you use a language property for a wikinews article\xa0? As I see there is a French corresponding article so why English and not French\xa0? ( ) 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\xa0;-) ( ) 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 ( for A, for B). -- ( ) @ , : 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 : 153 sitelinks and around the same number of different languages. But no use of or . So why do we have to have another practice for wikinews articles\xa0? 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\xa0? 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 to define the language of the object of the article, and how can an election have a language property\xa0? 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". ( ) 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\xa0;-) ( ) 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 ( for A, for B). -- ( ) @ , : 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 : 153 sitelinks and around the same number of different languages. But no use of or . So why do we have to have another practice for wikinews articles\xa0? 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\xa0? 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 to define the language of the object of the article, and how can an election have a language property\xa0? 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". ( ) @ , : 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 : 153 sitelinks and around the same number of different languages. But no use of or . So why do we have to have another practice for wikinews articles\xa0? 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\xa0? 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 to define the language of the object of the article, and how can an election have a language property\xa0? 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". ( ) @ : 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 unless someone uses 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 as the language of the first edition, not necessarily the current translation. To me, that's been . ( ) 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. -- ( ) 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. -- ( ) Understood. Thank you, ( ) Understood. Thank you, ( ) Understood. Thank you, ( ) Support merging two properties ( and ) into one. Target name shall be "Language". -- ( ) @ , , , , : and @ , , , : I modified a little the description text of the proposed action: The proposed action is to merge and 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. ( ) If and will be merged, then how to handle in a case when the original text is unknown, but we know the original language? -- ( ) @ : Please provide an example. I don't understand the problem. ( ) The example: — we know the translator — , the author — and the original language — , but we don't known the original text. -- ( ) @ : What you say about this example? -- ( ) @ : 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. ( ) The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- ( ) Does your original exist or not\xa0? 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 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. ( ) Does your original exist or not\xa0? — 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. by has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from , but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia: В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся. 431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250: Не молись за меня! -- может быть, это грех, Но в мольбу я не верю, не верю судьбе! Помолись, моя милая, лучше за тех, Кто еще не измучен в борьбе... Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн. : Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб. , 1871, с. 172. — , . The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see in ru-ws). -- ( ) 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 All details about document X according to item about text Z author: AA, source: item about document X language: OL, source: item about document X item about text Y translation of\xa0: item about text Y translator: TT, source: item about document X language: TL, source: item about document X ( ) You have a mistake: Y and Z is muddled.\xa0 ;-) But this is not impotant in a case of unknown original text ( ). -- ( ) Thanks. ( ) @ : Please provide an example. I don't understand the problem. ( ) The example: — we know the translator — , the author — and the original language — , but we don't known the original text. -- ( ) @ : What you say about this example? -- ( ) @ : 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. ( ) The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- ( ) Does your original exist or not\xa0? 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 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. ( ) Does your original exist or not\xa0? — 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. by has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from , but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia: В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся. 431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250: Не молись за меня! -- может быть, это грех, Но в мольбу я не верю, не верю судьбе! Помолись, моя милая, лучше за тех, Кто еще не измучен в борьбе... Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн. : Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб. , 1871, с. 172. — , . The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see in ru-ws). -- ( ) The example: — we know the translator — , the author — and the original language — , but we don't known the original text. -- ( ) @ : What you say about this example? -- ( ) @ : 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. ( ) The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- ( ) Does your original exist or not\xa0? 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 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. ( ) Does your original exist or not\xa0? — 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. by has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from , but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia: В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся. 431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250: Не молись за меня! -- может быть, это грех, Но в мольбу я не верю, не верю судьбе! Помолись, моя милая, лучше за тех, Кто еще не измучен в борьбе... Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн. : Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб. , 1871, с. 172. — , . The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see in ru-ws). -- ( ) @ : 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. ( ) The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- ( ) Does your original exist or not\xa0? 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 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. ( ) Does your original exist or not\xa0? — 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. by has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from , but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia: В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся. 431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250: Не молись за меня! -- может быть, это грех, Но в мольбу я не верю, не верю судьбе! Помолись, моя милая, лучше за тех, Кто еще не измучен в борьбе... Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн. : Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб. , 1871, с. 172. — , . The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see in ru-ws). -- ( ) The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- ( ) Does your original exist or not\xa0? 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 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. ( ) Does your original exist or not\xa0? — 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. by has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from , but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia: В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся. 431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250: Не молись за меня! -- может быть, это грех, Но в мольбу я не верю, не верю судьбе! Помолись, моя милая, лучше за тех, Кто еще не измучен в борьбе... Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн. : Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб. , 1871, с. 172. — , . The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see in ru-ws). -- ( ) Does your original exist or not\xa0? 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 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. ( ) Does your original exist or not\xa0? — 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. by has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from , but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia: В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся. 431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250: Не молись за меня! -- может быть, это грех, Но в мольбу я не верю, не верю судьбе! Помолись, моя милая, лучше за тех, Кто еще не измучен в борьбе... Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн. : Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб. , 1871, с. 172. — , . The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see in ru-ws). -- ( ) Does your original exist or not\xa0? — 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. by has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from , but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia: В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся. 431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250: Не молись за меня! -- может быть, это грех, Но в мольбу я не верю, не верю судьбе! Помолись, моя милая, лучше за тех, Кто еще не измучен в борьбе... Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн. : Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб. , 1871, с. 172. — , . The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see in ru-ws). -- ( ) 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 All details about document X according to item about text Z author: AA, source: item about document X language: OL, source: item about document X item about text Y translation of\xa0: item about text Y translator: TT, source: item about document X language: TL, source: item about document X item about document X All details about document X according to All details about document X according to item about text Z author: AA, source: item about document X language: OL, source: item about document X author: AA, source: item about document X language: OL, source: item about document X item about text Y translation of\xa0: item about text Y translator: TT, source: item about document X language: TL, source: item about document X translation of\xa0: item about text Y translator: TT, source: item about document X language: TL, source: item about document X ( ) You have a mistake: Y and Z is muddled.\xa0 ;-) But this is not impotant in a case of unknown original text ( ). -- ( ) Thanks. ( ) You have a mistake: Y and Z is muddled.\xa0 ;-) But this is not impotant in a case of unknown original text ( ). -- ( ) Thanks. ( ) Thanks. ( ) 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 ( ), but can provide different backgroud languages (so can be used as qualifier for them). -- ( ) 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 . ( ) 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 . ( ) [MASK] the both properties. Instead of deleting, we should impose the rule about and : either only (for the original works) or both (for the translated/dubbed works). -- ( ) Delete Merge the two properties. Per Snipre. -- ( ) 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. ( ) [MASK] both properties. It's easier to have a separate property than a property plus a qualifier for the main use case. --- @ : 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. ( ) 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. --- @ : 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 in an item of a movie\xa0? Just to say that a movie exists in a certain language\xa0? What's about the publication or release date of the synchronized versions\xa0? What's about the name of the voices in the translated versions\xa0? 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. ( ) @ : 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. ( ) 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. --- @ : 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 in an item of a movie\xa0? Just to say that a movie exists in a certain language\xa0? What's about the publication or release date of the synchronized versions\xa0? What's about the name of the voices in the translated versions\xa0? 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. ( ) 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. --- @ : 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 in an item of a movie\xa0? Just to say that a movie exists in a certain language\xa0? What's about the publication or release date of the synchronized versions\xa0? What's about the name of the voices in the translated versions\xa0? 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. ( ) @ : 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 in an item of a movie\xa0? Just to say that a movie exists in a certain language\xa0? What's about the publication or release date of the synchronized versions\xa0? What's about the name of the voices in the translated versions\xa0? 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. ( ) @ : 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: [ ], 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. ( ) @ : 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: [ ], 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. ( ) @ : 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: [ ], 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. ( ) @ : 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: [ ], 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. ( ) 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. -- ( ) Just add P364 and you are fine. --- Just add P364 and you are fine. --- 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 . ( ) @ : The creation of a specific item for each edition/translation is already a "rule" in WD (see ) because each translation has dedicated properties which have to be distinguished from the original edition. How can you specify the , , , , , and all others identifiers which are different for each edition/translation if you mix several editions/translations into the same item\xa0? The question is not the deletion of one property, the question is to have one system so if you want to [MASK] 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. ( ) 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. ( ) @ : 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\xa0? 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\xa0? 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\xa0? What is not\xa0? ( ) Take a deep breath, other people disagree with you, it will happen in life. ( ) @ : The creation of a specific item for each edition/translation is already a "rule" in WD (see ) because each translation has dedicated properties which have to be distinguished from the original edition. How can you specify the , , , , , and all others identifiers which are different for each edition/translation if you mix several editions/translations into the same item\xa0? The question is not the deletion of one property, the question is to have one system so if you want to [MASK] 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. ( ) 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. ( ) @ : 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\xa0? 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\xa0? 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\xa0? What is not\xa0? ( ) Take a deep breath, other people disagree with you, it will happen in life. ( ) 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. ( ) @ : 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\xa0? 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\xa0? 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\xa0? What is not\xa0? ( ) Take a deep breath, other people disagree with you, it will happen in life. ( ) @ : 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\xa0? 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\xa0? 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\xa0? What is not\xa0? ( ) Take a deep breath, other people disagree with you, it will happen in life. ( ) Take a deep breath, other people disagree with you, it will happen in life. ( ) @ : Thank you to admit that your opposition is based on nothing. And by the way, is not a simple help page because it is the result of a : there was a choice behind that RfC, and the community agreed about one solution. ( ) @ : Thank you to admit that your opposition is based on nothing. And by the way, is not a simple help page because it is the result of a : there was a choice behind that RfC, and the community agreed about one solution. ( ) @ : Thank you to admit that your opposition is based on nothing. And by the way, is not a simple help page because it is the result of a : there was a choice behind that RfC, and the community agreed about one solution. ( ) @ : Thank you to admit that your opposition is based on nothing. And by the way, is not a simple help page because it is the result of a : there was a choice behind that RfC, and the community agreed about one solution. ( ) @ : Thank you to admit that your opposition is based on nothing. And by the way, is not a simple help page because it is the result of a : there was a choice behind that RfC, and the community agreed about one solution. ( ) @ : Thank you to admit that your opposition is based on nothing. And by the way, is not a simple help page because it is the result of a : there was a choice behind that RfC, and the community agreed about one solution. ( ) 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 or . Cdlt, ( ) 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)? --- Why can't «\xa0other\xa0» works use FRBR\xa0? FRBR is «\xa0Functional Requirements for Bibliographic Records\xa0»\xa0; 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, ( ) 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. --- 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)? --- Why can't «\xa0other\xa0» works use FRBR\xa0? FRBR is «\xa0Functional Requirements for Bibliographic Records\xa0»\xa0; 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, ( ) 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. --- Why can't «\xa0other\xa0» works use FRBR\xa0? FRBR is «\xa0Functional Requirements for Bibliographic Records\xa0»\xa0; 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, ( ) 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. --- 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. --- [MASK] 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. ( ) "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. -- ( ) Can you explain how one should identify the original language for a film if you merge the two properties? --- 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. -- ( ) Let's take this one as a sample: . 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. --- @ : assuming this entity is about movie, and not about translation, I moved (copied) "de" to edition property: . 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 . This example assumes we are too lazy to create distinct entity for each translation. -- ( ) Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work ( ), 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 ( ). --- @ : 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 [MASK], leaving "sv" as single value of 407. -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) "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. -- ( ) Can you explain how one should identify the original language for a film if you merge the two properties? --- 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. -- ( ) Let's take this one as a sample: . 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. --- @ : assuming this entity is about movie, and not about translation, I moved (copied) "de" to edition property: . 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 . This example assumes we are too lazy to create distinct entity for each translation. -- ( ) Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work ( ), 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 ( ). --- @ : 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 [MASK], leaving "sv" as single value of 407. -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) Can you explain how one should identify the original language for a film if you merge the two properties? --- 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. -- ( ) Let's take this one as a sample: . 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. --- @ : assuming this entity is about movie, and not about translation, I moved (copied) "de" to edition property: . 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 . This example assumes we are too lazy to create distinct entity for each translation. -- ( ) Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work ( ), 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 ( ). --- @ : 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 [MASK], leaving "sv" as single value of 407. -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) 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. -- ( ) Let's take this one as a sample: . 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. --- @ : assuming this entity is about movie, and not about translation, I moved (copied) "de" to edition property: . 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 . This example assumes we are too lazy to create distinct entity for each translation. -- ( ) Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work ( ), 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 ( ). --- @ : 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 [MASK], leaving "sv" as single value of 407. -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) Let's take this one as a sample: . 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. --- @ : assuming this entity is about movie, and not about translation, I moved (copied) "de" to edition property: . 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 . This example assumes we are too lazy to create distinct entity for each translation. -- ( ) Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work ( ), 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 ( ). --- @ : 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 [MASK], leaving "sv" as single value of 407. -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) @ : assuming this entity is about movie, and not about translation, I moved (copied) "de" to edition property: . 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 . This example assumes we are too lazy to create distinct entity for each translation. -- ( ) Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work ( ), 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 ( ). --- @ : 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 [MASK], leaving "sv" as single value of 407. -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work ( ), 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 ( ). --- @ : 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 [MASK], leaving "sv" as single value of 407. -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) @ : 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 [MASK], leaving "sv" as single value of 407. -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) 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? --- 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be [MASK]. 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. -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) 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! --- 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) 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. -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- 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) -- ( ) 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) -- ( ) [MASK] 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. ( ) I don't see arguments regarding merging or non-merging properties. It is not FRBR requirement to merge or [MASK] 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). -- ( ) 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 ). 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. ( ) 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. -- ( ) I don't see arguments regarding merging or non-merging properties. It is not FRBR requirement to merge or [MASK] 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). -- ( ) 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 ). 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. ( ) 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. -- ( ) 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 ). 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. ( ) 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. -- ( ) 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. -- ( ) Delete Let's [MASK] the language or name scheme as simple as possible. Delete Merge the two properties. Per Snipre. ( ) [MASK] , 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. -- ( ) @ : 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 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\xa0? 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. ( ) @ : 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. -- ( ) @ : 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 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\xa0? 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. ( ) @ : 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. -- ( ) @ : 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. -- ( ) 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. --- 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. 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. --- The simplier solution is to apply strictly the . 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. ( ) Maybe we could do that by simply linking to some other cat. --- 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. 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. --- 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. --- The simplier solution is to apply strictly the . 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. ( ) Maybe we could do that by simply linking to some other cat. --- Maybe we could do that by simply linking to some other cat. --- Delete I've been thinking about this issue for a while. Let me give an example: American TV-Movies that premiered on theaters in Spain, and vice-versa ( change between and ). 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 vs. "wide/free" television. Usually TV series premiere in pay television (codified, only subscriptors) before than wide access television ("en abierto" in spanish). [MASK] also aka (depending on browser) I have seen hundreds of P407. "I have seen hundreds of P407" -- it's not a valid reason to [MASK], actually. -- ( ) "I have seen hundreds of P407" -- it's not a valid reason to [MASK], actually. -- ( ) [MASK] The two properties can sometimes be a mess, but, e.g., for it makes sense to me. The is while it exists in a number of other languages. Splitting the item into translated versions seems to babelfuscate language links? — ( ) You have 2 values for , 6 for (with missing qualifiers), 5 for (with missing qualifiers again!), 4 for , 4 for , 3 for ... I would say this is a very good example of one-item-for-all-languages-mess, and that's exactly why it shall be split (and properties -- merged). -- ( ) You have 2 values for , 6 for (with missing qualifiers), 5 for (with missing qualifiers again!), 4 for , 4 for , 3 for ... I would say this is a very good example of one-item-for-all-languages-mess, and that's exactly why it shall be split (and properties -- merged). -- ( ) [MASK] 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. -- ( ) 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\xa0? – The preceding comment was added by ( • )\xa0at . 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\xa0? – The preceding comment was added by ( • )\xa0at . Delete in favor of , Neutral on -- ( ) And a procedural note: Since this deletion request was started, was created, which changes the basis for this discussion. I would recommend to close this discussion, keeping both properties, but create two new separate deletion requests, based on the existence of the new property. -- ( ) And a procedural note: Since this deletion request was started, was created, which changes the basis for this discussion. I would recommend to close this discussion, keeping both properties, but create two new separate deletion requests, based on the existence of the new property. -- ( ) Delete - merge these two -- ( ) @ : Can you close this RfD\xa0? Change lead to reformulate the deletion request. ( ) ###Output: '
- "###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input: P3917_(P3917): Consensus to migrate to and delete —\xa0Martin ( · ) Consensus to migrate to and delete —\xa0Martin ( · ) @ , : do you have any opinion? To me, I do not see why number is not the correct datatype. Do you mean it should be external identifier? If so, to which link? Or string? Or something else? ( ) We don't have a number datatype and the quantity type we do has it's +/- interval by default. I don't have strong feelings but would be okay with migrating it to . ❪ ❫ When I proposed P3917, I ignored many things about how Wikidata work. Now, I agree with migrating it to . -- We don't have a number datatype and the quantity type we do has it's +/- interval by default. I don't have strong feelings but would be okay with migrating it to . ❪ ❫ When I proposed P3917, I ignored many things about how Wikidata work. Now, I agree with migrating it to . -- Delete a number is not a quantity, store information in a new property with the correct datatype: external identifier. ( ) [MASK] Used by some MediaWiki extensions, Please consult MediaWiki.org before deletions. -- @ : ^^ Is this really? ^^ -- ( ) I have no idea but I haven't been able to find references to P3917 myself, on mediawiki.org or in a search of most MediaWiki extension repositories. -- @ : ^^ Is this really? ^^ -- ( ) I have no idea but I haven't been able to find references to P3917 myself, on mediawiki.org or in a search of most MediaWiki extension repositories. -- I have no idea but I haven't been able to find references to P3917 myself, on mediawiki.org or in a search of most MediaWiki extension repositories. -- Delete Agree with migration to P528. -- ( ) [MASK] In use at at the Spanish Wikipedia. Please discuss at the first. -- ( ) I will make sure the module is updated before deleting the property —\xa0Martin ( · ) I will make sure the module is updated before deleting the property —\xa0Martin ( · ) , , Done Property [MASK], all templates have been adjusted -- ( ) ###Output: "
|
| 1 |
- '###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input: Property:P9091: Kept . No consensus for deletion. ( ) Kept . No consensus for deletion. ( ) [MASK] All the remarks have been addressed. ( ) . [MASK] The property is a main statement for 3,685 items, and is the sole external identifier for many of those creative works of cultural and other significance. ― ( ) [MASK] Already used by more that 3000 items. -- ( ) ###Output: '
- '###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input: Property:P6482: consensus to [MASK]. -- ( ) consensus to [MASK]. -- ( ) [MASK] Unless if Jura1 has a fresh new reason that this property should be [MASK], I doubt if there's need to restart any discussions here. -- Liuxinyu970226, this is about the closure(s), I don't understand why you start a 2nd or a 3rd discussion. --- @ : When you repeat your reason of deletion, you are just re-starting it, it's true for every humans that edit wikis, anyone, anywhere and anyhow, please do not make so-called "connections" between and me, this IP range has nothing to 5W1H-do and be with me, and just a violation of . -- ( ) Sorry, I thought it was you logged out. Anyways, no it's not another deletion discussion as you and the ip seem to think. It's a meta question for administrators. Would you know if the IP is one? --- @ : When you repeat your reason of deletion, you are just re-starting it, it's true for every humans that edit wikis, anyone, anywhere and anyhow, please do not make so-called "connections" between and me, this IP range has nothing to 5W1H-do and be with me, and just a violation of . -- ( ) Sorry, I thought it was you logged out. Anyways, no it's not another deletion discussion as you and the ip seem to think. It's a meta question for administrators. Would you know if the IP is one? --- Sorry, I thought it was you logged out. Anyways, no it's not another deletion discussion as you and the ip seem to think. It's a meta question for administrators. Would you know if the IP is one? --- @ , , , , :@ , , , , :@ : Do you all still think that this property should be kept? -- ( ) [MASK] , for the reasons given above. ( ) [MASK] -- ( ) [MASK] , for the reasons given above. ( ) [MASK] -- ( ) I'm also wondering that why in our world does Jura1 want this property to be [MASK], even they know that there are too many [MASK] concerns, what's their "solutions"? I can't believe that any person that does never do things like can frequently PFD a property for more than 3 times, just because they want that "to be [MASK]" even won't happen. -- ( ) Why this section is restored by you, @ :? -- ( ) [MASK] What a nonsense PFD. -- [MASK] , I don't see any reason to delete this… − ( ) ###Output: '
- '###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input: Property:P4174: Consensus to [MASK] , given that it's not in quality different than storing and similar identifiers. The property is not to be used to reveal the identity of users who didn't disclose their identity publically and doing so would be subject to sanctions as explained in the usage instructions of the property. ( ) ) Consensus to [MASK] , given that it's not in quality different than storing and similar identifiers. The property is not to be used to reveal the identity of users who didn't disclose their identity publically and doing so would be subject to sanctions as explained in the usage instructions of the property. ( ) ) Delete " ". -- ( ) Delete - created while several unresolved Strong oppose - real problem with -- ( ) There were no "unresolved" opposes; the opposition based on WMF privacy policy was addressed and refuted: the data was already held using ; the new property makes it easier to monitor such use. There were no "unresolved" opposes; the opposition based on WMF privacy policy was addressed and refuted: the data was already held using ; the new property makes it easier to monitor such use. [MASK] Otherwise items like will be nonsense. -- ( ) Also ping supporters @ , , , , :@ , , : -- ( ) Also ping supporters @ , , , , :@ , , : -- ( ) [MASK] . But delete the warning message. There is no reason to have for Wikimedia a special policy that we don't have for Facebook or Instagram. ( ) Neutral this property shouldn't have been created until a consensus had been reached on how to use it but now that is has been created, I see no real reason to delete it. PS: I have no illusion, the property is not really the issue here, with or without this property, the exact same data can, were and will be stored (prior to this property creation there was already a hundred of wikimedia user name store in various ways). Cdlt, ( ) [MASK] per my arguments made in the creation conversation — not least that the information is already held; at least this way it can be monitored more sensibly. — [MASK] . Arguments of are right: there is no difference between a Wikimedia username and an other username in an other website (for example Twitter, where a lot of people also use a pseudonym). ( ) Are you saying that you wont be respecting WMF policies even in fields where it's applicable? --- oh yes, there is an enormous difference - on Facebook, you have to use your real name (per FB rules)\xa0; there is NO privacy of FB, per FB rules - on wikimedia, there is an official !! - it is totally different -- ( ) I challenged you in the property proposal to cite any part of WMF policy which means we can't have this property. You failed to do so. You cannot do so. Are you saying that you wont be respecting WMF policies even in fields where it's applicable? --- oh yes, there is an enormous difference - on Facebook, you have to use your real name (per FB rules)\xa0; there is NO privacy of FB, per FB rules - on wikimedia, there is an official !! - it is totally different -- ( ) I challenged you in the property proposal to cite any part of WMF policy which means we can't have this property. You failed to do so. You cannot do so. I challenged you in the property proposal to cite any part of WMF policy which means we can't have this property. You failed to do so. You cannot do so. Delete : I'm really worried about the privacy part. If people [MASK] adding and without source, who says they will do it for this one? Our policies and tools are not good enough for something like this. Attempts to get better policies were useless so far. Delete useless with current "usage instructions". Encouraging users to create items about themselves is not a good idea.-- ( ) [MASK] without this property, the data just gets stored in / . For privacy concerns, this doesn't make any difference. -- ( ) After this is [MASK], I don't think it should be stored with that property. Already now, some seem to have used that other property as a way to circumvent as creation of this property was refused due to privacy concerns before. --- @ : I guess the template should use this property? So let's withdraw so-called "privacy" problems. -- ( ) After this is [MASK], I don't think it should be stored with that property. Already now, some seem to have used that other property as a way to circumvent as creation of this property was refused due to privacy concerns before. --- @ : I guess the template should use this property? So let's withdraw so-called "privacy" problems. -- ( ) @ : I guess the template should use this property? So let's withdraw so-called "privacy" problems. -- ( ) [MASK] As every properties, this one is intended for public and referenced information. If it used differently, we have for the disclosure of non-public personal information (with oversighters to remove such data and administrators to ban transgressors). As noticed by , this property allows to store Wikimedia usernames in a single place, making possible to monitor and detect bad usage much more easily than the actual situation. I also agree with : Wikimedia usernames don't differ from or , and I see no one stating that they were created to doxx Twitter and Instagram users... -- ( ) [MASK] per many of the above. Furthermore, this property passed a property proposal in the last few days. PfD should not be used to circumvent that process; the claim of "lack of consensus " is false. Well, that "it passed a property proposal" is a strongly disputed claim here. -- ( ) That it passed a property proposal is an undisputable truth. The claims that it should not have done so are far from "strong", and have no merit. They're made by the original objectors, who aren't happy at being in the losing minority - but the proposal was closed by a neutral admin. Even if the admin was at fault, then the avenue for remedy would be the Admin Noticeboard (or Project Chat), not PfD. Well, that "it passed a property proposal" is a strongly disputed claim here. -- ( ) That it passed a property proposal is an undisputable truth. The claims that it should not have done so are far from "strong", and have no merit. They're made by the original objectors, who aren't happy at being in the losing minority - but the proposal was closed by a neutral admin. Even if the admin was at fault, then the avenue for remedy would be the Admin Noticeboard (or Project Chat), not PfD. That it passed a property proposal is an undisputable truth. The claims that it should not have done so are far from "strong", and have no merit. They're made by the original objectors, who aren't happy at being in the losing minority - but the proposal was closed by a neutral admin. Even if the admin was at fault, then the avenue for remedy would be the Admin Noticeboard (or Project Chat), not PfD. [MASK] - the arguments on the property proposal page against this were unconvincing, as the concerns could be solved with policy and simple queries to [MASK] things in check. We should not be outright deleting a property because it might be a problem, when the utility is clearly demonstrated. -- ( ) @ : could you demonstrate such a simple query that would "[MASK] things in check"? --- @ : could you demonstrate such a simple query that would "[MASK] things in check"? --- wrt to this thing being the same as twitter or facebook or instagram, it is an undisputable truth in those social networks users can protect their accounts with a lock, not allowing common people to scrutinize their actions, pictures or vapid fantasies. In Wikimedia projects all your contributions are open , with the exact time you saved them, every topic, every comment in every discussion. We even offer tools to stalk user's edits. And it's not possible to hide any of that under a little tiny lock. It's not even possible to delete your account here. It's not exactly the same. Strakhov ( ) thanks , this is exactly the problem\xa0: this makes too easy scrutinizing edits of a user, by persons who, without this property, would not be able to link the username to the real-life identity… only voluntary disclosure by concerned users should be allowed to avoid risks for contributors in their private and/or professional life -- ( ) thanks , this is exactly the problem\xa0: this makes too easy scrutinizing edits of a user, by persons who, without this property, would not be able to link the username to the real-life identity… only voluntary disclosure by concerned users should be allowed to avoid risks for contributors in their private and/or professional life -- ( ) [MASK] as any personal identifier it makes no sense to allow home page, but prohibit social media accounts (incl this). Personal web pages are not replacement to other accounts (e.g. youtube cannot replace homepage and vice versa). We could improve any description in order to follow any policy - it is strange to remove property. ( ) Comment many lawbreaking things could be entered in - should we remove them? .. Please don't make this slippery slope argument every time. This is not specific to properties or even specific property . ( ) Delete until issues on "only the account owner is able to..." are resolved. We are not in a hurry, since people willing to disclose their Wikimedia alias already discovered how to store this data circumventing and, after all, there are not so many legitimate uses. Strakhov ( ) By the way, our labour here is about constructing a collaborative database, not losing or winning proposals. Strakhov ( ) Comment First, I'd like to see a comment from WMF's legal staff or quotation of privacy policy that states that this property should not exist. Second, this property had actually existed as / before this one was created, so in my opinion there didn't have to be any discussion about its existence. ( ) @ : Would you be able to have an official viewpoint from WMF from the appropriate staff member? Thanks. \xa0 — Also @ : the leader of . -- ( ) and I have talked (and consulted with legal) and while we don't believe it is a violation of the Privacy Policy (and so wouldn't try to block it etc) we do note that it does have the potential of being used for harassment or outing (in violation of the Terms of Use) if done without the blessing of the user involved and/or when it isn't pubic knowledge. There are lots of users who are very public with the fact that they are the same person who an article is about (hence the existence of well used talk page templates or user boxes) but it can also be a problematic thing if they're trying to preserve their privacy online like many of us try to do. ( ) @ : Would you be able to have an official viewpoint from WMF from the appropriate staff member? Thanks. \xa0— Also @ : the leader of . -- ( ) and I have talked (and consulted with legal) and while we don't believe it is a violation of the Privacy Policy (and so wouldn't try to block it etc) we do note that it does have the potential of being used for harassment or outing (in violation of the Terms of Use) if done without the blessing of the user involved and/or when it isn't pubic knowledge. There are lots of users who are very public with the fact that they are the same person who an article is about (hence the existence of well used talk page templates or user boxes) but it can also be a problematic thing if they're trying to preserve their privacy online like many of us try to do. ( ) and I have talked (and consulted with legal) and while we don't believe it is a violation of the Privacy Policy (and so wouldn't try to block it etc) we do note that it does have the potential of being used for harassment or outing (in violation of the Terms of Use) if done without the blessing of the user involved and/or when it isn't pubic knowledge. There are lots of users who are very public with the fact that they are the same person who an article is about (hence the existence of well used talk page templates or user boxes) but it can also be a problematic thing if they're trying to preserve their privacy online like many of us try to do. ( ) [MASK] : I'm for keeping it, but to use it only when a profile page on any Wikimedia project already discloses this information. This profile page should then be added as reference URL. -- ( ) [MASK] if a bot can actively revert all changes involving this property by non-autoconfirmed users (on the assumption that all autoconfirmed users are aware of and adhere to the WMF's privacy policy). ( ) [MASK] property similar to properties for other social network. Same policy should be applied. ( ) [MASK] We have properties for user accounts on other sites that are less relevant than Wikimedia. -- ( ) [MASK] per @ , @ and @ . -- ( ) [MASK] Wikidata has many properties for things that count as sensitive personal data: birth date, gender, sexual orientation, union membership and online account are examples. A breach of privacy comes when people use these inappropriately , adding speculative or inappropriately obtained data. The fact that Wikidata can represent such data is not the fault. Hence it is a fallacy to argue against the existence of the property on grounds of possible misuse. None of the arguments for removal seem solid. ( ) [MASK] . Valid identifier with unique values. ( ) [MASK] -- ( ) [MASK] under @ 's terms. ~ @ : Just close it by you, the petition above is successed. -- ( ) @ : I can't determine what you mean. @ : 5vote delete - 17vote [MASK] - 2neutral, isn't enough to close as clearly no consensus (maybe this must be closed by an uninvolved sysop, but who)? -- ( ) @ : I can't determine what you mean. @ : 5vote delete - 17vote [MASK] - 2neutral, isn't enough to close as clearly no consensus (maybe this must be closed by an uninvolved sysop, but who)? -- ( ) @ : 5vote delete - 17vote [MASK] - 2*neutral, isn't enough to close as clearly no consensus (maybe this must be closed by an uninvolved sysop, but who)? -- ( ) ###Output: '
|
