outcome,text,pred
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P394:   DELETED - Alright, if this is really depreciated I'm fine with deleting it.  I really don't like what's happened with this thread and the one below it; deletion discussions are not the proper forum for discussing which of several implementation options should be used to convey a piece of data, that is a discussion for a more viewed forum such as the community portal or a task force talk page.  However it looks like a consensus has settled.  Any admin should feel free to undo this without consulting me if they feel that this close is in error.  DELETED - Alright, if this is really depreciated I'm fine with deleting it.  I really don't like what's happened with this thread and the one below it; deletion discussions are not the proper forum for discussing which of several implementation options should be used to convey a piece of data, that is a discussion for a more viewed forum such as the community portal or a task force talk page.  However it looks like a consensus has settled.  Any admin should feel free to undo this without consulting me if they feel that this close is in error.  Keep/Discuss - Origin of the property aside, it seems like a good idea.  I'd be willing to keep it around if anyone else here agrees.  Redundant: See .  -- ( ) Redundant: See . -- ( ) Support - I created the property before the creation of - but it is now duplicate.  According to ""What links here"" P394 isn't used anymore, and P405 is used - so keep P405 and delete P394.  ( ) Currently unused => please delete.  -- at ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P378: Deleted.   Convert into ""UTC offset"" sound like a good idea.   sv:Mall:Stadsfakta has four parameters for timezone, one for link to article about timezone, one for utc-offset, and two of the same kind for DST.   -- ( ) I went to Australia and maybe found a problem: and others can have some language-related problems.   In Swedish time is written as h.m, not h:m.   This is technically solvable for a single project, but this can affect several projects.   -- ( ) I went to Australia and maybe found a problem: and others can have some language-related problems.   In Swedish time is written as h.m, not h:m.   This is technically solvable for a single project, but this can affect several projects.   -- ( ) I was leaning to keep , given that they have different datatypes, and one can be used as a qualifier for the other.   But I'm neutral.   — Delete .   Created without discussion, and without any documentation about how time zones should be recorded in a language-independent way.   Also seems redundant with .   I'd welcome a ""UTC offset"" property, but this should have a quantity datatype, not string, so a new property would need to be created for that.    -- ( ) Delete . -- ( ) Delete – Agree with Avenue.   ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P9:   TLDR: No consensus (and therefore no change), with closer recommending that an RfC on Project chat be held after the deployment of Phase III on Wikdata TLDR: No consensus (and therefore no change), with closer recommending that an RfC on Project chat be held after the deployment of Phase III on Wikdata Strong oppose it's not redundant, it's used a lot here and I want to use it at the Dutch Wikipedia.  Dutch doesn't have a word for sibling, we just use brother and sister.  Will drop a note for the Dutch community.  ( ) Strong oppose This proposal results in nonsense to Dutch.  <> and sibling is non-existent in Dutch.  Oppose -- Based on the above, I must also oppose the merge. Oppose -- not sure why sibling would be a better choice.  Oppose unnecessary, and loss of detail.  -- Wrong. It is not usable in this context. Regards, [2] fachsprachlich, Singular: eines der Geschwister [1] Falsch, eben doch; aber um Linguistik geht's hier nicht. — [2] fachsprachlich, Singular: eines der Geschwister [1] Falsch, eben doch; aber um Linguistik geht's hier nicht. — I'm confused. You want us to combine the ""sibling"" property with the ""sex"" property which does not define the ""sibling"" property but the item itself? That does not tell whether or not it is a sister or a brother. What are you talking about? I've said by checking both, sibling and sex properties, finding out whether the subject is a sister or brother can be done automatically. — What are you talking about? I've said by checking both, sibling and sex properties, finding out whether the subject is a sister or brother can be done automatically. — How is it ""not the point""? If there are languages that do not have a word for ""sibling"", then merging the items is a bad idea. My concern is more: How to handle items that hasn't been filled with such things as ""sex"" yet? I have a feeling that we will have a large backlag, since Wikipedia is several years older than Wikidata and is still growing. A large part of the articles do not have a category or an infobox, that a robot can collect information from. On some projects the interest the tecnical ability to construct a robot is limited to a few very busy users. -- ( ) There are languages that do not have a word for sister as well.  The structure of the kinship voabulary varies widely across the World.  Properties are supposed to define relations between items, not what the item is about.  ""Male"" or ""female"" are attributes of the item themselves, not of the logical relation between them.  In this case, the logical relation is ""sibling"", whether the word exists in all languages or not.  Actually I am French and there is no word for sibling in French either, but I cannot see anything wrong with using ""brother/sister"" instead.  It is possible that the practical reasons for having separate properties for brothers and sisters dominate the logical reason why it is unnecessary, but linguistic reasons alone are not sufficient.  -- ( ) (EC) I don't get it. Why is a perfectly fitting label in every language a criteria for properties? Despite the fact that's pretty much impossible for almost every property, given there are 200+ human languages, the property's actual meaning is of interest to us, not its arbitrary label. — My concern is more: How to handle items that hasn't been filled with such things as ""sex"" yet? I have a feeling that we will have a large backlag, since Wikipedia is several years older than Wikidata and is still growing. A large part of the articles do not have a category or an infobox, that a robot can collect information from. On some projects the interest the tecnical ability to construct a robot is limited to a few very busy users. -- ( ) There are languages that do not have a word for sister as well.  The structure of the kinship voabulary varies widely across the World.  Properties are supposed to define relations between items, not what the item is about.  ""Male"" or ""female"" are attributes of the item themselves, not of the logical relation between them.  In this case, the logical relation is ""sibling"", whether the word exists in all languages or not.  Actually I am French and there is no word for sibling in French either, but I cannot see anything wrong with using ""brother/sister"" instead.  It is possible that the practical reasons for having separate properties for brothers and sisters dominate the logical reason why it is unnecessary, but linguistic reasons alone are not sufficient.  -- ( ) (EC) I don't get it.  Why is a perfectly fitting label in every language a criteria for properties?  Despite the fact that's pretty much impossible for almost every property, given there are 200+ human languages, the property's actual meaning is of interest to us, not its arbitrary label.  — In Swedish we have a word for ""uncle"", but I never hear it.  The word for ""mothers brother""  (morbror)  can sometimes also include ""mothers brother in-law"".  To be onest: I do not think this set of properties will ever be used on svwp.  --  ( )  (EC)  A bot should check every person linked by P7/P9 so far for missing sex-statements.  If there are any, we can secure this data before merging.  — You know what?  I think I agree with you now.  So when is this merger taking place?  Ther will be no merging.  We will keep brothers and sisters, the sex can be added in any case and the property can be used for Bots to help. --  ( )  In Swedish we have a word for ""uncle"", but I never hear it.  The word for ""mothers brother""  (morbror)  can sometimes also include ""mothers brother in-law"".  To be onest: I do not think this set of properties will ever be used on svwp.  --  ( )  (EC)  A bot should check every person linked by P7/P9 so far for missing sex-statements.  If there are any, we can secure this data before merging.  — You know what?  I think I agree with you now.  So when is this merger taking place?  Ther will be no merging.  We will keep brothers and sisters, the sex can be added in any case and the property can be used for Bots to help. --  ( )  In Swedish we have a word for ""uncle"", but I never hear it.  The word for ""mothers brother""  (morbror)  can sometimes also include ""mothers brother in-law"".  To be onest: I do not think this set of properties will ever be used on svwp.  --  ( )  (EC)  A bot should check every person linked by P7/P9 so far for missing sex-statements.  If there are any, we can secure this data before merging.  — You know what?  I think I agree with you now.  So when is this merger taking place?  Ther will be no merging.  We will keep brothers and sisters, the sex can be added in any case and the property can be used for Bots to help. --  ( )  You know what?  I think I agree with you now.  So when is this merger taking place?  Ther will be no merging.  We will keep brothers and sisters, the sex can be added in any case and the property can be used for Bots to help. --  ( )  Ther will be no merging.  We will keep brothers and sisters, the sex can be added in any case and the property can be used for Bots to help. --  ( )  Strong support – How two people are related  (in this case that they share parent(s), and what sex one of them has, is two distinct things which not should be mixed up in a database.  A database should have different fields for the relationship and sex, so each user can then combine them as wanted, for instance to match the words in one's language or other purposes.  It is impossible to suit all with such predefined combinations of different concepts.  To have separate properties for sister and brother can be compared to splitting  (shares border with)  up into separate properties for  (shares border with a republic)  and  (shares border with a monarchy), which I don't hope that anyone would propose.  Some may say that it wouldn't work because some countries are neither republics or monarchies, but that keeps the analogy to sister and brother, as you now have no way to indicate intersexed siblings.  But the intersex argument isn't the primary one, it is that it is bad to combine two things  (kind of relationship and sex)  in one property.  ( )  Support – The argument that a word does not exist in a language is not a good one.  Siblingness  (having the same two parents)  is a property which obviously exists independently of sex.  I'm sure it can be expressed in some way or another in any language, even if it is something like ""has the same two parents as."" --  ( )  Question Could we perhaps resolve this with qualifiers?  E.g. — I do not see any need for this: once the transclusion syntax is fully deployed, ""brother"" or ""sister"" can be easily inferred from the sex of the person.   --  ( )  I do not see any need for this: once the transclusion syntax is fully deployed, ""brother"" or ""sister"" can be easily inferred from the sex of the person.   --  ( )  Support , one ""sibling"" property will do.  If there is a need to use a more specific, gendered word, the item can be queried to determine the subject's gender.  Using ""brother"" and ""sister"" breaks down when dealing with subjects that identify with non-binary genders.  — Strong oppose So we should also replace father and mother, son and doughter with ""parent"" and ""child"".  Makes the world more easy, especialy, when the child has two mothers or changes its gender--  ( )  Uh ?  Yes, if we have just one property for brother and sister we should also have just one property for son and daughter, but this is .  --  ( )  Why is it that none of the opposers actually cared to read the linked discussions?  — Am I missing something, or is the 'strong oppose' vote above actually arguing in support of the proposed merger?  ( )  Uh ?  Yes, if we have just one property for brother and sister we should also have just one property for son and daughter, but this is .  --  ( )  Why is it that none of the opposers actually cared to read the linked discussions?  — Am I missing something, or is the 'strong oppose' vote above actually arguing in support of the proposed merger?  ( )  support merging , unless someone provides a more sensible reason for having two separate properties.  --  ( )  I have none, but can the be closed before we start the merging-process?  --  ( )  Agree, this page seems to have more traffic, but the RFC should be the starting point.  --  ( )  I personally think it is better to do it in phases.  The first phase being merging all redundant sex-specific properties, for which this is the test whether the community is okay with it.  Afterwards we can keep on discussion which kinship relations are redundant to each other.  — I have none, but can the be closed before we start the merging-process?  --  ( )  Agree, this page seems to have more traffic, but the RFC should be the starting point.  --  ( )  I personally think it is better to do it in phases.  The first phase being merging all redundant sex-specific properties, for which this is the test whether the community is okay with it.  Afterwards we can keep on discussion which kinship relations are redundant to each other.  — Agree, this page seems to have more traffic, but the RFC should be the starting point.  --  ( )  I personally think it is better to do it in phases.  The first phase being merging all redundant sex-specific properties, for which this is the test whether the community is okay with it.  Afterwards we can keep on discussion which kinship relations are redundant to each other.  — I personally think it is better to do it in phases.  The first phase being merging all redundant sex-specific properties, for which this is the test whether the community is okay with it.  Afterwards we can keep on discussion which kinship relations are redundant to each other.  — Support I can't see why we need two properties when one could do the job very well. --  ( )  Strong oppose in French, we don't have a word for ""sibling"" : we use ""frère""  (brother), ""sœur""  (sister)  or ""frère et sœur""  (brother and sister).  The word the nearest we have is ""fratrie"" but it include every child of a person  (there is no distinction between ""me"" and ""them"", there is only ""us"").  ( )  Could you also point out why this is a problem?  — Could you also point out why this is a problem?  — Strong oppose there is often a big difference culturally in what is valid for a brother or a sister. .  ( )  What do you mean by this?  These properties are used to indicate the biological kinship relation of sharing the same parents.  This is a physical reality independent of cultural background.  And if I understand you correctly, you are against having separate brother and sister properties as well.  — What do you mean by this?  These properties are used to indicate the biological kinship relation of sharing the same parents.  This is a physical reality independent of cultural background.  And if I understand you correctly, you are against having separate brother and sister properties as well.  — Comment – Some opponents argue with what words are available in their language, and that brothers and sisters should be differentiated.  Brothers and sisters can still be differentiated after a merge by querying the sex property of the sibling, so I kindly ask these opponents to tell why having separate properties for brothers and sisters should be a better way to organize data than by using independent properties for siblingness and sex.  This is not about what data should be available, but about how to best organize the data.  Thank you,  ( )  "" Brothers and sisters can still be differentiated after a merge by querying the sex property of the sibling ""  If a user speaks a language that does not have a cognate of 'sibling', then how would they query for sibling in the first place?   It doesn't seem possible.   That is the essence of the Dutch's objection to merging 'brother' and 'sister' into 'sibling'.  ( ) The merged property could be labeled with translations of ""brother or sister"" or ""have at least one common parent"", and then you make a query with that property and the sex of the object.  Why shouldn't that be possible?  ( ) Labeling the property ""brother or sister"" in languages that don't have a term for ""sibling"" seems like a workable solution.   What do the Dutch think of this?  ( ) Again, Wikidata is about machine readable data.  You query for P7 in any case.  — Wikidata is about human- and machine-readable data alike.   Could you point me to an example of the query syntax?  ( ) — "" Brothers and sisters can still be differentiated after a merge by querying the sex property of the sibling "" If a user speaks a language that does not have a cognate of 'sibling', then how would they query for sibling in the first place?   It doesn't seem possible.   That is the essence of the Dutch's objection to merging 'brother' and 'sister' into 'sibling'.  ( ) The merged property could be labeled with translations of ""brother or sister"" or ""have at least one common parent"", and then you make a query with that property and the sex of the object.  Why shouldn't that be possible?  ( ) Labeling the property ""brother or sister"" in languages that don't have a term for ""sibling"" seems like a workable solution.   What do the Dutch think of this?  ( ) Again, Wikidata is about machine readable data.  You query for P7 in any case.  — Wikidata is about human- and machine-readable data alike.   Could you point me to an example of the query syntax?  ( ) — The merged property could be labeled with translations of ""brother or sister"" or ""have at least one common parent"", and then you make a query with that property and the sex of the object.  Why shouldn't that be possible?  ( ) Labeling the property ""brother or sister"" in languages that don't have a term for ""sibling"" seems like a workable solution.   What do the Dutch think of this?  ( ) Labeling the property ""brother or sister"" in languages that don't have a term for ""sibling"" seems like a workable solution.   What do the Dutch think of this?  ( ) Again, Wikidata is about machine readable data.  You query for P7 in any case.  — Wikidata is about human- and machine-readable data alike.   Could you point me to an example of the query syntax?  ( ) — Wikidata is about human- and machine-readable data alike.   Could you point me to an example of the query syntax?  ( ) — — Delete .  The extra property supplies absolutely zero additional data.  -- ( ) Strong support Wikidata should organize data only based on semantics.  For Chinese, there is even no brother (or sister), only one character for elder-brother (sister) and another one for younger-brother (sister).  We simply put the two characters together when referring to brother (sister).   And for sibling, there is a (four-character idiom), , just putting these characters together. -- Support strongly, as per other parts - we shouldn't distinguish semantically-irrelevant properties.  ( ) Support - semantics - Support .  In terms of a qualifier, I believe that would be sufficient.  Regards, Support - I now support the merger based on my comments above.  7 days are over now, but Wait until — I don't see any clear consensus for doing this.  Just close this request to end this nonsense.  ( ) Return to the subject when there is more obvious that this information is available in other ways.  Today we do not have the tools to show it.  -- ( ) Well, I see a consensus since the opposers' arguments have been crushed and they don't care to express new ones or even respond. — I don't see any clear consensus for doing this. Just close this request to end this nonsense. ( ) Return to the subject when there is more obvious that this information is available in other ways. Today we do not have the tools to show it. -- ( ) Well, I see a consensus since the opposers' arguments have been crushed and they don't care to express new ones or even respond.  — Return to the subject when there is more obvious that this information is available in other ways.  Today we do not have the tools to show it.  -- ( ) Well, I see a consensus since the opposers' arguments have been crushed and they don't care to express new ones or even respond.  — Strong oppose - There is certainly no consensus.  I still see no reason for this deletion/renaming.  It sounds to me that people from some languages try to enforce that some other languages go find a fictional word, purely based on the arrogance that some languages do have a world for something.  We make here an international database which should be human readable as well, and for this important aspect of family relations is no word in many languages, while there is an alternative available that works for almost all languages, if not every language.  Why should we replace a property that works (almost) everywhere for some which doesn't work in many languages?  I have still not seen any reasonable answer to that question.  Wikidata is here for machines and humans, not for machines only.  That is forgotten here too much.  ( ) I think you are arguing against a strawman when you say ""try to enforce that some other languages go find a fictional word"".  No one has said that.  For languages where there is not a word for both a brother and a sister, one can put ""brother/sister"" (or something like that).  The reason it should be replaced, as argued above, is that we should attempt to keep ""what a person's sex/gender is"" separate from ""who they are related to"".  Also, these properties do not handle an intersex relationship, as is noted above.  -- ( ) And as has  already been said there are languages that do not have a word for ""brother"" or ""sister"". If there is arrogance somewhere, it is from people opposing the merger based on no other argument than ""wharf, that's not how we do things at home"". -- ( ) I think you are arguing against a strawman when you say ""try to enforce that some other languages go find a fictional word"".  No one has said that.  For languages where there is not a word for both a brother and a sister, one can put ""brother/sister"" (or something like that).  The reason it should be replaced, as argued above, is that we should attempt to keep ""what a person's sex/gender is"" separate from ""who they are related to"".  Also, these properties do not handle an intersex relationship, as is noted above.  -- ( ) And as has  already been said there are languages that do not have a word for ""brother"" or ""sister"". If there is arrogance somewhere, it is from people opposing the merger based on no other argument than ""wharf, that's not how we do things at home"". -- ( ) Strong oppose completely unnecessary.  -- 20:20, 11 May 2013 (UTC) double vote Support after reading this discussion, merging P7 and P9 makes sense to me. Regards, Comment In English wikipedia, I see ""A sibling is one of two or more individuals having one or both parents in common"". Do we need to differentiate the sibling having one parent in common and the sibling having both parents in common? In Chinese, no simple word for either one. I think if there is also no simple word in most other languages, then it's fair. We just create properties like ""has the same parents as"" as said above, and ""has the same father (mother) as"" . The other reason for this is that it will not generate too much redundancy. Items for a person probably don't have and . Having one or both parants in common cannot be determined like brother and sister for these persons. -- I have until now understood both the brother and sister property to mean ""having at least one parent in common"", but the precise meaning is not stated on the talk pages of the properties, and I don't know of any discussion about if halfbrothers and halfsisters are included or not.  That should be determined no matter the result of this merge discussion.  ( ) If we continue down either path described in , we won't have to have this ambiguous property either.  Siblingness is always a function of parentage.  -- ( ) If we continue down either path described in , we won't have to have this ambiguous property either. Siblingness is always a function of parentage. -- ( ) Support Properties that can be trivially deduced from other properties should not exist.   My main concern about the proposed merger has been addressed: labeling the property ""brother or sister"" in languages that don't have a term for ""sibling"" seems like a workable solution.  ( ) Oppose These properties (brother/sister) cannot be ""trivially"" deduced from the other properties (like sibling and sex), because you would have to query the property of another item, which is not yet possible using {{#property:}} syntax.  Even if this feature will be developed in the future, I still think it's a good idea to have separate properties for brother and sister, because in many languages (including French, Dutch, Romanian, etc) there is no word for ""sibling"" (and it would be awkward to have a property named ""brother or sister"").  Also, sometimes redundancy is a good thing, for performance reasons and for providing another way to double-check the correctness of data.  ( ) How is a query like 'get items that are siblings of the subject and female' not trivial?   I don't see the fact that query syntax is unavailable as a significant issue: if it is, then it will be moot in a few weeks.   Are there any large-scale implementations of P9 that need to differentiate siblings between sex, which would be disrupted if P9 were merged before query syntax is available?  The points about the benefits of redundancy with regard to performance and validation need further explanation.   Noone would dispute that redundancy can sometimes be help performance, but why would it do so in this particular case?   And wouldn't redundancy of this sort introduce at least as much potential for inconsistent data as it would potential for consistent data?   Unless there are compelling reasons to keep this redundant property, I think the more succinct, normalized option should be preferred.  ( ) The query ""get items that are siblings of the subject and female"" may be easily expressed in plain english, but try to write it in a computer language (any computer language that supports Wikidata querying).  Redundancy may be useful in this case because using a query for the ""sister"" property directly (instead of using a compound query, based on ""sibling"" and ""sex"") may probably use an index or some pre-cached data.  If we use the ""brother"" and ""sister"" properties (as well as ""sex""), inconsistent data may be more easily detected (by a bot) and after that they will be corrected (by a human); without the brother/sister properties, inconsistent data in the ""sex"" property may only be detected by a human or by comparing the data with external sources (such as Wikipedia or other sites).  ( ) How is a query like 'get items that are siblings of the subject and female' not trivial?   I don't see the fact that query syntax is unavailable as a significant issue: if it is, then it will be moot in a few weeks.   Are there any large-scale implementations of P9 that need to differentiate siblings between sex, which would be disrupted if P9 were merged before query syntax is available?  The points about the benefits of redundancy with regard to performance and validation need further explanation.   Noone would dispute that redundancy can sometimes be help performance, but why would it do so in this particular case?   And wouldn't redundancy of this sort introduce at least as much potential for inconsistent data as it would potential for consistent data?   Unless there are compelling reasons to keep this redundant property, I think the more succinct, normalized option should be preferred.  ( ) The query ""get items that are siblings of the subject and female"" may be easily expressed in plain english, but try to write it in a computer language (any computer language that supports Wikidata querying).  Redundancy may be useful in this case because using a query for the ""sister"" property directly (instead of using a compound query, based on ""sibling"" and ""sex"") may probably use an index or some pre-cached data.  If we use the ""brother"" and ""sister"" properties (as well as ""sex""), inconsistent data may be more easily detected (by a bot) and after that they will be corrected (by a human); without the brother/sister properties, inconsistent data in the ""sex"" property may only be detected by a human or by comparing the data with external sources (such as Wikipedia or other sites).  ( ) The query ""get items that are siblings of the subject and female"" may be easily expressed in plain english, but try to write it in a computer language (any computer language that supports Wikidata querying).  Redundancy may be useful in this case because using a query for the ""sister"" property directly (instead of using a compound query, based on ""sibling"" and ""sex"") may probably use an index or some pre-cached data.  If we use the ""brother"" and ""sister"" properties (as well as ""sex""), inconsistent data may be more easily detected (by a bot) and after that they will be corrected (by a human); without the brother/sister properties, inconsistent data in the ""sex"" property may only be detected by a human or by comparing the data with external sources (such as Wikipedia or other sites).  ( ) Support not more redunancy than necessary.  -- ( ) Support Redundant. -- ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P280: Deleted.   Unused => Please delete.   -- at Support deletion. According to it is intended to describe languages. Maybe a property for that can be useful, but the datatype if needed should be the item for the book, not Commons file as here, so it created with wrong datatype. ( ) Support as an unused property.... , Support as I also didn't understand the purpose of this property -- ( ) Support deletion.   Basically it's trivia, and practically it's impossible to define - natural languages evolve and there is rarely a clear first book, so it can only be used in reality for a handful of artificial languages.   ( ) Support deletion as unused and unnecessary.   Support deletion.   Unused, unnecessary property.   ( ) Support deletion.   I'm not really sure why this matters to items concerning authors or how it could be used usefully. ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P116:   Deleted , clear consensus.  -- Deleted , clear consensus. -- Support -- ( ) Support , of course. -- Support deletion.  Per the same reasons as P96.  ( ) Support - ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P445:   This and the entry below it have a solid consensus for deletion.  I've done the changeover myself (at least in the mainspace), so I'm hitting the killswitch.  This and the entry below it have a solid consensus for deletion.  I've done the changeover myself (at least in the mainspace), so I'm hitting the killswitch.  Support .  -- ( ) Delete redundant. ( ) Delete . -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P446: Deleted.   Support .   -- ( ) Delete ( ) Delete ( ) Delete . Redundant. -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P48:   Deletion pending - Once a bot has processed this and made the needed changes, this will be deleted.  Done Deletion pending - Once a bot has processed this and made the needed changes, this will be deleted.  Done Delete it's redundant and hasn't been in massive use by now.  ( ) Delete ( ) Delete , but weakly.  Seems mildly redundant.  Info : Since consensus appears to be reached, I'm developing a script to quickly remove this property from items – only if item.p48 == item.p85.p51, of course.  -- So now all the information has been deleted.  Who is responsible for restoring the links?  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P526:   Closed per ongoing discussion up the page.  -- ( ) Closed per ongoing discussion up the page. -- ( ) ###Output: ",2
keep,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P576:   Consensus is pretty strongly in favor of keeping this, at least for now.  Consensus is pretty strongly in favor of keeping this, at least for now.  Keep I thing when merging, there will be problem with correct label of property - people have dates of birth/death, but clubs or companies date of founding/dissolution.  And naming this propery date of birth/founding/creation seems to be very strange.  ( ) Neutral , linguistic reasons alone are not enough for having two properties, and as far as I can see, date of foundation is logically equivalent to date of birth (some external sources like the BNF conflate them ).  On the other hand, it may indeed sound odd to use ""date of birth"" for an organization, and that might scare away a few users.  Given that the difference between ""foundation"" and ""birth"" seems intuitively clear, that should not be too difficult to maintain two properties.  -- ( ) Keep It just doesn't sound right to say ""date of birth/death"" for an organization. comment: I'm wondering if both sets of these templates couldn't just be done with qualifiers. Have a general ""start date"" with qualifier ""birth"" or with ""foundation""? Not structured enough? Not easily queried? That would actually associate the foundation of companies with their actual foundation... -- ( ) Comment See: — Comment .  If we keep two properties, we have to define the scope of each.  To me, the intuitive meaning of  ""foundation date"", and even ""creation date"" is ""date when a conscious agent created it"" (and so would not be applicable  to natural objects, nor to ).  -- ( ) I think might like to have a word with you about that. ;P -- ( ) Keep per comments above.  ( ) I think might like to have a word with you about that.  ;P -- ( ) Keep per comments above. ( ) Strong delete : in the future it will be possible to ajust the label according to the entity type. Nor the conflict of scope is clearly solved. -- Keep May be second foundation and second close.  With people not be.  Sorry English. -- ( ) Keep May be second foundation and second close. With people not be. Sorry English.-- ( ) Keep these two things are related, but not the same.  Maybe in the future things will be possible and we might even reconsider, but we live in the now.  ( ) ###Output: ",1
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P526:   Deleted ( ) Deleted ( ) Where is the ""located in geographical region""-property?  -- ( ) We don't have one yet. — Cannot be used for ""located in geographical regions""? -- ( ) We don't have one yet.  — Cannot be used for ""located in geographical regions""?  -- ( ) Cannot be used for ""located in geographical regions""? -- ( ) Delete Would be best handled some other way such as .  Many things are located on or in other things, so probably best to use a generic property rather than lots of specific ones.  ( ) How do you think this should be differentiated?  ""probably best"" seems hard use a criterion.  -- at How do you think this should be differentiated? ""probably best"" seems hard use a criterion. -- at A property called located in geographical feature could cover many situations, so we can say it is located on this island, mountain, in this valley, and so on.  ( ) A property called located in geographical feature could cover many situations, so we can say it is located on this island, mountain, in this valley, and so on.  ( ) A property called located in geographical feature could cover many situations, so we can say it is located on this island, mountain, in this valley, and so on.  ( ) Change meaning of P526 .  Instead first creating located in geographical feature , and then merge it with this property, couldn't we redefine P526 to be located in geographical feature .  ( ) I would like to see P131 changed to ""located in geographical feature"".  -- ( ) ""geographical feature"" is one of the terms used in . If we rename this property, it's likely to become rather messy, combining physical geography and administrative units. -- at I would like to see P131 changed to ""located in geographical feature"".  -- ( ) ""geographical feature"" is one of the terms used in . If we rename this property, it's likely to become rather messy, combining physical geography and administrative units. -- at OK, so how about located in/on the landform ?  ( ) OK, so how about located in/on the landform ?  ( ) OK, so how about located in/on the landform ?  ( ) Comment I think we should focus on the question whether identifying the island a place is on is important or not and should be done through a property.  If yes, I think P526 is an easy way to enter this information and retrieve it.  I don't think the other suggestions address this.  -- at I'm afraid the easy ways are lost since long! I think ""The church of Roma"" is located in ""Roma"", ""Roma"" is located in ""Roma Parish"", ""Roma Parish"" is located in ""Gotland Municipality"", ""Gotland Municipality"" is located in ""Gotland"", and ""Gotland"" is an instance of an ""island"" will be the natural way to go. A more serious problem is to separate ""groups of islands"" from ""islands"". -- ( ) Question How is that a problem?  — The item ""Gotland"" is a group of islands with one large island and many small.  I am not aware of any item about the main island.  If there is any, it had to be added above the parish-item, but below the municipality-item.  I do not think it is a big problem in this case.  You have to be more alert in the Greenland-case, where I think there is an item about the main island, and since all ""administrative units"" are both about the main island and the surrounding smaller islands, every item about smaller objects have to have a relation to an island-item.  I think it will be solved.  -- ( ) We have to create items for the main islands in these cases. Just checked: There isn't even and item for the Australian mainland, because there are only Wikipedia articles about the surrounding smaller islands and the continent as a whole, which also describes the mainland in detail. This merge is reasonable for an encyclopedia, but not for a database. — I'm afraid the easy ways are lost since long! I think ""The church of Roma"" is located in ""Roma"", ""Roma"" is located in ""Roma Parish"", ""Roma Parish"" is located in ""Gotland Municipality"", ""Gotland Municipality"" is located in ""Gotland"", and ""Gotland"" is an instance of an ""island"" will be the natural way to go. A more serious problem is to separate ""groups of islands"" from ""islands"". -- ( ) Question How is that a problem?  — The item ""Gotland"" is a group of islands with one large island and many small.  I am not aware of any item about the main island.  If there is any, it had to be added above the parish-item, but below the municipality-item.  I do not think it is a big problem in this case.  You have to be more alert in the Greenland-case, where I think there is an item about the main island, and since all ""administrative units"" are both about the main island and the surrounding smaller islands, every item about smaller objects have to have a relation to an island-item.  I think it will be solved.  -- ( ) We have to create items for the main islands in these cases.  Just checked: There isn't even and item for the Australian mainland, because there are only Wikipedia articles about the surrounding smaller islands and the continent as a whole, which also describes the mainland in detail.  This merge is reasonable for an encyclopedia, but not for a database.  — Question How is that a problem?  — The item ""Gotland"" is a group of islands with one large island and many small.  I am not aware of any item about the main island.  If there is any, it had to be added above the parish-item, but below the municipality-item.  I do not think it is a big problem in this case.  You have to be more alert in the Greenland-case, where I think there is an item about the main island, and since all ""administrative units"" are both about the main island and the surrounding smaller islands, every item about smaller objects have to have a relation to an island-item.  I think it will be solved.  -- ( ) We have to create items for the main islands in these cases.  Just checked: There isn't even and item for the Australian mainland, because there are only Wikipedia articles about the surrounding smaller islands and the continent as a whole, which also describes the mainland in detail.  This merge is reasonable for an encyclopedia, but not for a database.  — The item ""Gotland"" is a group of islands with one large island and many small.  I am not aware of any item about the main island.  If there is any, it had to be added above the parish-item, but below the municipality-item.  I do not think it is a big problem in this case.  You have to be more alert in the Greenland-case, where I think there is an item about the main island, and since all ""administrative units"" are both about the main island and the surrounding smaller islands, every item about smaller objects have to have a relation to an island-item.  I think it will be solved.  -- ( ) We have to create items for the main islands in these cases.  Just checked: There isn't even and item for the Australian mainland, because there are only Wikipedia articles about the surrounding smaller islands and the continent as a whole, which also describes the mainland in detail.  This merge is reasonable for an encyclopedia, but not for a database.  — We have to create items for the main islands in these cases.  Just checked: There isn't even and item for the Australian mainland, because there are only Wikipedia articles about the surrounding smaller islands and the continent as a whole, which also describes the mainland in detail.  This merge is reasonable for an encyclopedia, but not for a database.  — We also have which is a similar concept.  ( ) Rename to ""located on terrain feature"" (or create a new property for that and change all items to use it instead of P526) (similar to Danrok's proposal, but more clearly only for natural features).   This would be used when the value is a physical terrain feature, such as or .   We would continue to use when the value was a governmental/man-made concept, such as (the U.S. state).   I think a general property is more useful than one limited to islands.   For instance, I think I've had a case where I wanted to say it was on/in a body of water.   I don't think we have a general property for this yet, but we should take this opportunity to make/repurpose one.  is not really suitable, since it's awkward to say e.g. a house on an island is ""part of"" an island.  And it really doesn't work at all if you say an buoy on the Black Sea is ""part of"" the Black Sea.  - Support 'located in terrain feature' or 'located in natural geographical feature'.  ( ) Support 'located in terrain feature' or 'located in natural geographical feature'.  ( ) Support 'located in terrain feature' or 'located in natural geographical feature'.  ( ) Keep : useful precision.  ( ) Delete : what a ridiculous label... it wouldn't be the first deleted property by .  -- There's no need to make this personal.   We can disagree and still be civil.  - There's no need to make this personal.   We can disagree and still be civil.  - Delete per above.  ( ) ###Output: ",0
keep,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P158:   Kept per consensus of comments.  Kept per consensus of comments.  Useful for infoboxes - how to select the right image if item have several images?  ( ) Comment Note that image is up for deletion above.  ( ) Keep per -- at Keep Similar comment as mine at : This property is not redundant to : It provides an actual seal image, not just the link to an article about the seal.  This is more specific than ; more specific properties (such as this one) should always be used instead.  ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P75:   Closing as no consensus to delete, with no prejudice for or against future renomination pending the outcome of the referenced RFC.  -- ( ) Closing as no consensus to delete, with no prejudice for or against future renomination pending the outcome of the referenced RFC. -- ( ) Comment See .  -- ( ) Keep it's in use, valid and recursion is not possible yet.  Also see the comments on the rfc.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P100_(P100):   Consensus for deletion is clearly reached.  I'm writing a bot script for migration, and I'm going to delete the property once orphan.  -- Consensus for deletion is clearly reached. I'm writing a bot script for migration, and I'm going to delete the property once orphan. -- Support Redundant.  — Support on the condition that the domain of P463 is changed, so it is not just persons, but also organisations, countries and subdivisions of countries, and maybe more (What else can be a member?) ( ) This property seems to be for a fairly finite group of organizations which all have the same set of members to pick from.  It seems easier to edit membership for these on the item of the organization than on items for each individual member state.  Bots can than replicate that to the item for the member state.  -- at All of us agree the state restriction isn't viable. So you are actually proposing flooding items like the with way over 100,000 members. — Have you actually built anything recently? -- at Is this supposed to be a PA?  — It's a personal question: we are attempting to determine what you mean with ""viable"" in terms of building a database.  -- at All of us agree the state restriction isn't viable. So you are actually proposing flooding items like the with way over 100,000 members. — Have you actually built anything recently? -- at Is this supposed to be a PA?  — It's a personal question: we are attempting to determine what you mean with ""viable"" in terms of building a database.  -- at Have you actually built anything recently? -- at Is this supposed to be a PA?  — It's a personal question: we are attempting to determine what you mean with ""viable"" in terms of building a database.  -- at Is this supposed to be a PA? — It's a personal question: we are attempting to determine what you mean with ""viable"" in terms of building a database. -- at It's a personal question: we are attempting to determine what you mean with ""viable"" in terms of building a database.  -- at Support .  This item is defined the wrong way round - it should be ""is member [state/country/whatever] of"".  In a sense already covers this so this one is redundant.  ( ) Support .  This property never made sense to me, I'd rather use .  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  family_name_(P734):   Not deleted - consensus to delete not reached, at least not until the right data type becomes available. -- ( ) Not deleted - consensus to delete not reached, at least not until the right data type becomes available. -- ( ) Keep Good property, allows to link article about surname and surname owners. Gender is not problem at least in Russian. This is only forms of one surname. For example is about both male (Кузнецов) and female (Кузнецова) forms. — ( ) That's what I'm saying, the item is about both Кузнецов and Кузнецова, but is only labeled as Кузнецов. If you use this property in an article about , you will get the male form of the name as a result... (together with the correct link, that's right).-- ( ) That's what I'm saying, the item is about both Кузнецов and Кузнецова, but is only labeled as Кузнецов.  If you use this property in an article about , you will get the male form of the name as a result... (together with the correct link, that's right). -- ( ) There. Fixed. I renamed the items as 'Němec/Němcová' and 'Kuznetsov / Kuznetsova' so you can use P734 to link to this and it is right whether the subject is a man or a woman. ( ) You should add also 'Nemec', 'Nemcova' and 'Nimets' (as for now). But could a statement like this be used in a Wikipedia infobox (or elsewhere)?-- ( ) Currently have link to report ""all persons with this name"".  Current implementation is not good because it finds the substring in page names only.  Implementation based on will be more reliable.  — ( ) It surely will.  But the MultilingualText datatype will enable you to control the search better.  The Item gives you a set of all people who use any form of the name.  E.g. if you'll be looking for , you will get everybody called ""Петр"", but also everybody called Peter, Petr, Pierre, Pedro, Petur, Petelo, Pit, Pêr etc.  Is this what you want?  If there will be a property with the exact form of the name, you can design the query to find just the form(s) of the name you want. -- ( ) Note that Multilingual datatype won't help here since it only allows one English and one Russian value. ( ) It will help. One value per language and person is enough. will get (en:Němcová,ru:Немцова,...) while will get (en:Kuznetsova,ru:Кузнецова,...)-- ( ) There.  Fixed.  I renamed the items as 'Němec/Němcová' and 'Kuznetsov / Kuznetsova' so you can use P734 to link to this and it is right whether the subject is a man or a woman.  ( ) You should add also 'Nemec', 'Nemcova' and 'Nimets' (as for now).  But could a statement like this be used in a Wikipedia infobox (or elsewhere)? -- ( ) Currently have link to report ""all persons with this name"". Current implementation is not good because it finds the substring in page names only. Implementation based on will be more reliable. — ( ) It surely will. But the MultilingualText datatype will enable you to control the search better. The Item gives you a set of all people who use any form of the name. E.g. if you'll be looking for , you will get everybody called ""Петр"", but also everybody called Peter, Petr, Pierre, Pedro, Petur, Petelo, Pit, Pêr etc. Is this what you want? If there will be a property with the exact form of the name, you can design the query to find just the form(s) of the name you want.-- ( ) You should add also 'Nemec', 'Nemcova' and 'Nimets' (as for now).  But could a statement like this be used in a Wikipedia infobox (or elsewhere)? -- ( ) Currently have link to report ""all persons with this name"". Current implementation is not good because it finds the substring in page names only. Implementation based on will be more reliable. — ( ) It surely will. But the MultilingualText datatype will enable you to control the search better. The Item gives you a set of all people who use any form of the name. E.g. if you'll be looking for , you will get everybody called ""Петр"", but also everybody called Peter, Petr, Pierre, Pedro, Petur, Petelo, Pit, Pêr etc. Is this what you want? If there will be a property with the exact form of the name, you can design the query to find just the form(s) of the name you want.-- ( ) Currently have link to report ""all persons with this name"".  Current implementation is not good because it finds the substring in page names only.  Implementation based on will be more reliable.  — ( ) It surely will.  But the MultilingualText datatype will enable you to control the search better.  The Item gives you a set of all people who use any form of the name.  E.g. if you'll be looking for , you will get everybody called ""Петр"", but also everybody called Peter, Petr, Pierre, Pedro, Petur, Petelo, Pit, Pêr etc.  Is this what you want?  If there will be a property with the exact form of the name, you can design the query to find just the form(s) of the name you want. -- ( ) It surely will. But the MultilingualText datatype will enable you to control the search better. The Item gives you a set of all people who use any form of the name. E.g. if you'll be looking for , you will get everybody called ""Петр"", but also everybody called Peter, Petr, Pierre, Pedro, Petur, Petelo, Pit, Pêr etc. Is this what you want? If there will be a property with the exact form of the name, you can design the query to find just the form(s) of the name you want.-- ( ) Note that Multilingual datatype won't help here since it only allows one English and one Russian value.  ( ) It will help.  One value per language and person is enough.  will get (en:Němcová,ru:Немцова,...) while will get (en:Kuznetsova,ru:Кузнецова,...)-- ( ) It will help. One value per language and person is enough. will get (en:Němcová,ru:Немцова,...) while will get (en:Kuznetsova,ru:Кузнецова,...)-- ( ) Delete It was deleted once before as and (see and search in ).  ( ) Why would an item covering both Němec and Němcová be used for a person who has one of those names?  Shouldn't a more specific item be used?  Also, being useless for Wikipedia doesn't mean we should delete the property.  Wikipedia is not the sole use-case for the free knowledge base.  -- ( ) The same reason, why would covering both and be used for a person who has on of those names.  These are not two names, just two forms of the same name.  In some languages.  While other languages may use only one form.  Or three forms.  Your other point sounds stronger.  We don't have to delete a property which is essentially correct just because we don't have any use for it in the Wikipedia.  We can have one family name property as an item datatype and another one as a multilingual text.  Actually, we can use them together, one as a qualifier of the other.  I'm just afraid of sourcing the item-typed name-properties.  We surely can find a source that assignes to the given name ""George"".  But is it enough to assign him to the item which is defined by 40 forms of the name, if we cannot bring a source for all of them?  And especially, if some of them clearly don't match with the person (but can't be separeted from the name-item)?  The problem is more obvious for the given names, but is essentially the same for the family names. -- ( ) The same reason, why would covering both and be used for a person who has on of those names.  These are not two names, just two forms of the same name.  In some languages.  While other languages may use only one form.  Or three forms.  Your other point sounds stronger.  We don't have to delete a property which is essentially correct just because we don't have any use for it in the Wikipedia.  We can have one family name property as an item datatype and another one as a multilingual text.  Actually, we can use them together, one as a qualifier of the other.  I'm just afraid of sourcing the item-typed name-properties.  We surely can find a source that assignes to the given name ""George"".  But is it enough to assign him to the item which is defined by 40 forms of the name, if we cannot bring a source for all of them?  And especially, if some of them clearly don't match with the person (but can't be separeted from the name-item)?  The problem is more obvious for the given names, but is essentially the same for the family names. -- ( ) No, this is a bad example.  You can stultify any property (good or bad) by choosing unappropriate value for it.  If you use the ""correct"" ones, you'll get - which is bad enough, if you change language e.g. to Slovak or Finnish...-- ( ) Those were incorrect sitelinks. I've moved the Finnish ""Yrjö"" to and Slovak ""Juraj (prvé meno)"" to where they belong. -- ( ) Well done.  Please change (or remove) the corresponding labels in cases like this, if you can.  There's a lot of mismatched names like these and I'm afraid not all of them can be corrected.  I'm happy though that a discussion over these properties brings some improvement in this field ;)-- ( ) Those were incorrect sitelinks. I've moved the Finnish ""Yrjö"" to and Slovak ""Juraj (prvé meno)"" to where they belong. -- ( ) Well done.  Please change (or remove) the corresponding labels in cases like this, if you can.  There's a lot of mismatched names like these and I'm afraid not all of them can be corrected.  I'm happy though that a discussion over these properties brings some improvement in this field ;)-- ( ) Well done. Please change (or remove) the corresponding labels in cases like this, if you can. There's a lot of mismatched names like these and I'm afraid not all of them can be corrected. I'm happy though that a discussion over these properties brings some improvement in this field ;)-- ( ) See undeleted .  ( ) Delete .  I don't see any good reason to keep this.  -- ( ) Comment Uh, I can't remember. What was the reason for Wikidata again? Ahhh, query data. If we aren't able to query a person which surname is 'XYZ', then we should close Wikidata immediately. -- ( ) Comment We can use search engine to find names.  What next?  Maybe ""middle name"" property... -- ( ) I don't have any clue what you're talking about ""using search engine""? Internal or external search engine? However, here something you should read: . -- ( ) Comment Uh, I can't remember.  What was the reason for Wikidata again?  Ahhh, query data.  If we aren't able to query a person which surname is 'XYZ', then we should close Wikidata immediately.  -- ( ) Comment We can use search engine to find names. What next? Maybe ""middle name"" property... -- ( ) I don't have any clue what you're talking about ""using search engine""?  Internal or external search engine?  However, here something you should read: .  -- ( ) Comment We can use search engine to find names. What next? Maybe ""middle name"" property... -- ( ) I don't have any clue what you're talking about ""using search engine""?  Internal or external search engine?  However, here something you should read: .  -- ( ) I don't have any clue what you're talking about ""using search engine""? Internal or external search engine? However, here something you should read: . -- ( ) Keep Use this as a qualifier for or for a 'name' property with string/monolingual datatype.  ( ) Keep -- ( ) Comment : Can we turn this into vote on changing the property type (for both) to multilingual text, instead of deletion? ( ) I'd like to agree, I'm just not sure if this is technically possible.-- ( ) I'd like to agree, I'm just not sure if this is technically possible. -- ( ) Keep pending the possibility of data type change.  ( ) Keep until the same with ""multilingual text"" is created, then Delete .  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P283_(P283),_P284_(P284),_P285_(P285):   Consensus for deletion of all three.  Will be deleted once deprecated.  ( ) Consensus for deletion of all three.  Will be deleted once deprecated.  ( )    I would tend to agree that these can be replaced using either or (P361 might be more appropriate in most cases.).  -- ( ) I'm thinking of an RfC for language taxonomy representation. There are a fair number of issues to sort out around how exactly to relate languages to families and families to other families (assuming we make the distinction). ( ) An RfC wouldn't get any attention, so don't loose your time with it. -- ( ) If you are not interested in linguistic, that doesn't mean that others also don't.  I believe that the RfC would be useful.  ( ) I'm thinking of an RfC for language taxonomy representation.  There are a fair number of issues to sort out around how exactly to relate languages to families and families to other families (assuming we make the distinction).  ( ) An RfC wouldn't get any attention, so don't loose your time with it.  -- ( ) If you are not interested in linguistic, that doesn't mean that others also don't. I believe that the RfC would be useful. ( ) An RfC wouldn't get any attention, so don't loose your time with it. -- ( ) If you are not interested in linguistic, that doesn't mean that others also don't.  I believe that the RfC would be useful.  ( ) If you are not interested in linguistic, that doesn't mean that others also don't.  I believe that the RfC would be useful.  ( ) Delete and use subclass of.  -- ( ) Delete ( ) Delete per nom. -- ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P986: ( ) Deleted.   ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P540_(P540)_or_P766_(P766):   Consensus appears to be clearest for deleting Venue and only Venue.  Venue will be deleted as soon as all instances of venue are replaced with location.  Consensus appears to be clearest for deleting Venue and only Venue.  Venue will be deleted as soon as all instances of venue are replaced with location.    This property was recently created by its proposer at all.  This property is redundant to .  P131 that says it applies only to geographical features, but it could be changed to include events.  Keep , these are different relation types.  Current ru-label ""находится в административной единице"" does not allow to use this property for events.  — ( ) Actually the current labels for both of these only allow them to be used for events, except in Russian where ""venue"" doesn't have a label.  ( ) Actually the current labels for both of these only allow them to be used for events, except in Russian where ""venue"" doesn't have a label.  ( ) Keep , it isn't redundant to as this property is limited to only administrative units .  How will you make e.g. this statement here ?  The German Embassy isn't an administrative unit, so it can't be used.  ?  Doesn't work also.  And even if you find (or create) a property for locating non-administrative unit, this would mean we have events spread over two different properties.  Not easy or logical when you're searching all events for a specific location, because you've always to considering both properties.  -- ( ) Comment BTW: I'm not an English native speaker, but I believe even in English the term ""is in administrative unit"" doesn't fit for events. -- ( ) Comment Thanks for the explanation, I understand your reasoning and have amended my deletion request.  But what about ?  We still have two properties for what is basically the same concept, i.e. the place where the event was held.  In English it doesn't sound quite right to say that the was held at a venue, but the Italian label for is ""luogo""  (location), the French one is ""lieu""  (location), the Catalan is ""lloc""  (location), the Dutch is ""locatie""  (again, location), so there is much ambiguity.  I think we should either delete and give a broader sense to , or just delete .  What do you think?  ( )  I think administrative units instances corresponds to geographical locations, but other kind of geographical location  (like a mountain)  tends to be more geographically stable other time  (a mountain does move but in geological times :)).  For administrative units, it's not the same : some can disappear, appear, move, ... so the statement will make sense if we also have the date.  But I agree, when we give the place of an event, we should give a geographical location  (a subclass of geographical location instance).  The problem is wether or not we consider if we have an administrative unit and a date, we also have a geographical location.  If we consider that as a fact, then we can have one generic property.  ( )  Comment Funny.  I never saw the venue property.  Otherwise I wouldn't created P766.  It's a shame the venue property didn't get any ""also know aliases"".  I think venue could work for events.  But I can't tell if it's suitable for all kind of events and what's about other languages.  It seems 'venue' is used for scheduled events with audience  (event = Veranstalltung), not for events which just happens  (event also = Ereignis), like a disaster.  But it really seems like venue and location/place are very similar or redundant.  Even so, we have to decide which to delete and which to remain.  --  ( )  Actually you did good, while I made the deletion proposal too hastily and on bad assumptions.  Even if you didn't know about , you created a much better property because it covers all events that don't have a venue and also those that just happen.  So my new proposal is to keep and delete .  If you agree, please update your vote accordingly.  ( )  Cool we were able to discuss this out.  Yes, now I'm voting for Delete for .  --  ( )  I think administrative units instances corresponds to geographical locations, but other kind of geographical location  (like a mountain)  tends to be more geographically stable other time  (a mountain does move but in geological times :)).  For administrative units, it's not the same : some can disappear, appear, move, ... so the statement will make sense if we also have the date.  But I agree, when we give the place of an event, we should give a geographical location  (a subclass of geographical location instance).  The problem is wether or not we consider if we have an administrative unit and a date, we also have a geographical location.  If we consider that as a fact, then we can have one generic property.  ( )  Comment Funny.  I never saw the venue property.  Otherwise I wouldn't created P766.  It's a shame the venue property didn't get any ""also know aliases"".  I think venue could work for events.  But I can't tell if it's suitable for all kind of events and what's about other languages.  It seems 'venue' is used for scheduled events with audience  (event = Veranstalltung), not for events which just happens  (event also = Ereignis), like a disaster.  But it really seems like venue and location/place are very similar or redundant.  Even so, we have to decide which to delete and which to remain.  --  ( )  Actually you did good, while I made the deletion proposal too hastily and on bad assumptions.  Even if you didn't know about , you created a much better property because it covers all events that don't have a venue and also those that just happen.  So my new proposal is to keep and delete .  If you agree, please update your vote accordingly.  ( )  Cool we were able to discuss this out.  Yes, now I'm voting for Delete for .  --  ( )  Actually you did good, while I made the deletion proposal too hastily and on bad assumptions.  Even if you didn't know about , you created a much better property because it covers all events that don't have a venue and also those that just happen.  So my new proposal is to keep and delete .  If you agree, please update your vote accordingly.  ( )  Cool we were able to discuss this out.  Yes, now I'm voting for Delete for .  --  ( )  Cool we were able to discuss this out.  Yes, now I'm voting for Delete for .  --  ( )  One question in general: Will in such cases a bot change all existing 'venue' to 'location'?  Is this possible and/or already done before?  I think we should  have such a bot which can be used to change the property to another property.  --  ( )  A request can be made at .  I'm not sure if it has been done before but it shouldn't be too difficult.  is currently used on just .  ( )  A request can be made at .  I'm not sure if it has been done before but it shouldn't be too difficult.  is currently used on just .  ( )  Should the labels  (en, de, fr, ?)  for the property not be more specific and indicate that is only suitable for events ?  As for example the property clearly indicates by its label, that it is only suitable for creative works .  For geographical objects one could then use or  (the first one explicitely mention also events in its description; how to deal with that?). --  ( )  ok, is ""event location"" good?  --  ( )  Fine by me.  ( )  Well, then a bot should begin change all venue to location, after this 'venue' can be deleted.  --  ( )  ""Event location"" is fine for the English label.  I changed the German label, added some aliases and a description.  What would be suitable in French? --  ( )  There is a discussion on the page for ""location"" about widening this property so it can be used for objects as well as events.  Please don't change the labels until this is resolved.  ( )  ok, is ""event location"" good?  --  ( )  Fine by me.  ( )  Fine by me.  ( )  Well, then a bot should begin change all venue to location, after this 'venue' can be deleted.  --  ( )  ""Event location"" is fine for the English label.  I changed the German label, added some aliases and a description.  What would be suitable in French? --  ( )  There is a discussion on the page for ""location"" about widening this property so it can be used for objects as well as events.  Please don't change the labels until this is resolved.  ( )  Well, then a bot should begin change all venue to location, after this 'venue' can be deleted.  --  ( )  Well, then a bot should begin change all venue to location, after this 'venue' can be deleted.  --  ( )  ""Event location"" is fine for the English label.  I changed the German label, added some aliases and a description.  What would be suitable in French? --  ( )  There is a discussion on the page for ""location"" about widening this property so it can be used for objects as well as events.  Please don't change the labels until this is resolved.  ( )  ""venue"" could also work to list home stadiums and the like.   -- at We can also use ""location"" for home stadiums, perhaps together with qualifier. No need for this very similar property. -- ( ) We can also use ""location"" for home stadiums, perhaps together with qualifier.  No need for this very similar property.  -- ( ) Keep both.  In my opinion, location is preferable for geographic names (states, cities, towns) and venue is preferable for specific buildings/stadiums.  For events and objects in states, cities, towns I think we should use ""is in the administrative unit"".  For events and objects on rivers, mountains, lakeshore etc. we should use ""located on geographical feature"".  For events and objects in stadiums, museums, galleries, streets, villages (where these have items) we should use ""location"".  ""Venue"" could be used for stadiums and theatres but not for museums and streets so it should (in my opinion) be deleted and ""location"" used instead.  ( ) For events and objects in states, cities, towns I think we should use ""is in the administrative unit"".  For events and objects on rivers, mountains, lakeshore etc. we should use ""located on geographical feature"".  For events and objects in stadiums, museums, galleries, streets, villages (where these have items) we should use ""location"".  ""Venue"" could be used for stadiums and theatres but not for museums and streets so it should (in my opinion) be deleted and ""location"" used instead.  ( ) Delete Venue.  Keep 'location' but widen it's use so it can be used for things like the museum an art work is in.  heading over to to  propose this now.  ( ) Keep We need both properties then the definitions should be modified: we need a property for event and one property for physical place.  Some events take place at different places so we need to use sometimes twice the same property and as we have now already two properties we can use both of them.  Discussion ( ) What do you mean by a ""property for event"" and a ""property for physical place""?  Both of these properties have ""event"" as their subject/domain (the page they are used on) and a physical place as their object/range (the page they point to).  If an event takes place in two places then use the same property twice.  Please don't use two different properties  for the same concept.  ( ) What do you mean by a ""property for event"" and a ""property for physical place""?  Both of these properties have ""event"" as their subject/domain (the page they are used on) and a physical place as their object/range (the page they point to).  If an event takes place in two places then use the same property twice.  Please don't use two different properties  for the same concept.  ( ) Delete (merge) because a is a .  The word venue is not limited to specific types of places, in the English language.  Any place can be a venue.  ( ) Delete French labels currently state just the same: location of an event.  label could be made more general and its constraint widened to cover both events & places - Delete There are some interesting language issues brought up above, but in the two languages that I understand it seems that is a location, and is thus not needed.  ( ) Comment I have started a more general .   Part of that is looking at whether we might delete both of these.  ( ) Unnecessary RfC which wouldn't get any attention like all RfCs I remember.  -- ( ) Unnecessary RfC which wouldn't get any attention like all RfCs I remember. -- ( ) Please, would any admin FINALLY delete 'venue'?  Isn't the voting not clear enough?  How many discussions and RfC should we start before someone finally act?   -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Some_Statistics_Sweden_(Q1472511)-codes:   Speedy deleted.  Speedy deleted.  Looks like a correct observation.   -- ( ) ###Output: ",0
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P114:   No consensus for deletion.  ( ) No consensus for deletion.  ( ) Neutral Airline alliance is a parameter of the infobox .  If we merge it with p463 it might be more difficult to fill in this infobox with data from wikidata.  -- ( ) Keep per Pasleim. Weak delete: I usually tend toward delete for such things, per . I'm not quite sure what to think of with the ""this organization can be part of multiple other organizations"" and how that might trivially be dealt with from the querying side. -- ( ) Delete.  This seems to be a bit too specialised a property and there doesn't seem to be a good reason not to use a more general one like 'member of' or even 'part of'.  This can always take a qualifier if needed to avoid confusion with the infobox.  – The preceding comment was added by ( • ). ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Image_properties:   Keep all, at least for the time being.  Consensus is pretty clear on not deleting any of these while they are in use on the Wikipedias.  -- ( ) Keep all, at least for the time being. Consensus is pretty clear on not deleting any of these while they are in use on the Wikipedias. -- ( ) @ : @ : @ : @ : @ : @ : Please do the appropriate taggings too.  -- I have done.-- ( ) @ :My (and Tobias1984, TomT0m, Avenue, Ypnypn, Filceolaire and Felix Reimann's) purpose is to use as qualifier instead of a lot of properties below.  I have done. -- ( ) @ :My (and Tobias1984, TomT0m, Avenue, Ypnypn, Filceolaire and Felix Reimann's) purpose is to use as qualifier instead of a lot of properties below. @ :My (and Tobias1984, TomT0m, Avenue, Ypnypn, Filceolaire and Felix Reimann's) purpose is to use as qualifier instead of a lot of properties below. @ :: For chemicals, a could be the structural formula, a 3D model (e.g. ball and stick, or space filling), a photograph of the pure chemical. Hence, I think that you should be specific. Otherwise, we will have one type for some chemicals and another type for others. is also too unspecific. -- One general comment for all of the properties: While using only a ""generic"" image property ( ) with a qualifier ( ) seems more efficient, having separate properties for things like logos, flags, etc. is easier for the user interface, the projects that use the data (infoboxes on Wikipedia, etc.), constraints, and querying, at least for now.  ( ) this is being used by en, simple, ocwiki. -- ( ) Keep Honestly, there was not enough widescale participation in that RFC, with only 8 participants. I see no reason to delete this property, which is already in wide use across three wikis and several items, and is a showcase of what Wikidata can do, as noted in several newsletters. Using qualifiers will make accessing this property much more difficult. -- Keep Nope.  Not deleting a property we've already put hard work into deploying across three wikis (well, two wikis, ocwiki articles were mainly created by that one bot a while back).  My views are pretty much aligned with Rschen's.  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep Would be okay with a migration to a general ""map"" property, but a generic image property would add difficulty to use while not adding much utility. — Keep Honestly, there was not enough widescale participation in that RFC, with only 8 participants. I see no reason to delete this property, which is already in wide use across three wikis and several items, and is a showcase of what Wikidata can do, as noted in several newsletters. Using qualifiers will make accessing this property much more difficult. -- Keep Nope.  Not deleting a property we've already put hard work into deploying across three wikis (well, two wikis, ocwiki articles were mainly created by that one bot a while back).  My views are pretty much aligned with Rschen's.  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep Would be okay with a migration to a general ""map"" property, but a generic image property would add difficulty to use while not adding much utility. — this is being used by cswiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- See .  we can create items for flag images, and use for these items.  It is more useful to have a item, because there're a lot of property now can be added to flag items. -- ( ) Keep We can create items for flags, but AFAIK we still have no access to the values of their properties from a Wikipedia article connected to the country/region/community/whatever item.  As soon as this feature is available, we can (should...) consider moving the flag pictures to a more proper place, but in the meantime please keep the flag picture property at a place accessible from Wikipedias.  Otherwise, we would do a great disservice to the Wikipedias who already started using these properties, and especially to the Wikidata supporters there, who - believe me or not - do not always have an easy job. -- ( ) Keep We can create items for flags, but AFAIK we still have no access to the values of their properties from a Wikipedia article connected to the country/region/community/whatever item.  As soon as this feature is available, we can (should...) consider moving the flag pictures to a more proper place, but in the meantime please keep the flag picture property at a place accessible from Wikipedias.  Otherwise, we would do a great disservice to the Wikipedias who already started using these properties, and especially to the Wikidata supporters there, who - believe me or not - do not always have an easy job. -- ( ) Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep Having a flag-item with and other properties and relating this flag-item by with the main item sounds good, however, first we need a querying tool.  Until then, please do not delete it.  -- ( ) Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep Having a flag-item with and other properties and relating this flag-item by with the main item sounds good, however, first we need a querying tool.  Until then, please do not delete it.  -- ( ) Delete as soon as the technical ability to get the equivalent data on Wikipedias is available, per Pasleim and Shlomo. -- ( ) this is being used by cswiki. -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep as for now.  Same reasons as for . -- ( ) Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Delete , as soon as it can be done without breaking the Wikipedias. -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep as for now. Same reasons as for .-- ( ) Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Delete , as soon as it can be done without breaking the Wikipedias. -- ( ) this is being used by cswiki. -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Question In the properties P109 and P18 are uesd. If we merge these properties now , is there a way that the infobox will still work? -- ( ) In the theory, it can be distinguished by a qualifier (as soon as we have one...).  Since all the data required are accessible from the Wikipedia, it should be possible to write a Lua script that will do this job.  The only problem is, I'm not that experienced programmer.  If you somebody shows me a working example, I'd try to adapt it for the infobox mentioned above.  Keep Practically, I think that signature image is specific enough data to have it's own property.  On the contrary, I'd prefer to create also a ""portrait"" property for person related items and separate the portrait data from the which seems to general to me.-- ( ) In the theory, it can be distinguished by a qualifier (as soon as we have one...). Since all the data required are accessible from the Wikipedia, it should be possible to write a Lua script that will do this job. The only problem is, I'm not that experienced programmer. If you somebody shows me a working example, I'd try to adapt it for the infobox mentioned above. Keep Practically, I think that signature image is specific enough data to have it's own property. On the contrary, I'd prefer to create also a ""portrait"" property for person related items and separate the portrait data from the which seems to general to me.-- ( ) Keep the given reason for deletion is ""this is being used by cswiki"".  i don't think this is a valid request.  ( ) Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is probably not being used by wiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Which property should be used as an alternative in your opinion?  -- Replied above.-- ( ) Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Replied above.-- ( ) Replied above. -- ( ) Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is probably not being used by wiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is probably not being used by wiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is probably not being used by wiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is probably not being used by wiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is being used by cs, svwiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is probably not being used by wiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is probably not being used by wiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) this is probably not being used by wiki.-- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best.  -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. -- Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties.  Ontologically join so different properties to one only because have the same datatype is without sense, for me.  In this manner we could use only one properties for datatype and use qualifier to distinguish them!  Another question: what about constraints?  @ : now it is possible to use constraint also with qualifiers?  -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P992_(function/mission):   Consensus to delete ( ) Consensus to delete ( ) Delete -- ( ) Delete per nom. -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P168_(type_of_structure):   Consensus to delete ( ) Consensus to delete ( ) Delete after replacement.  -- ( ) Delete Move to ""instance of"" and delete.-- ( ) Delete .  I proposed it, but now it makes no sense with .  — ( ) Delete , redundant with and .  ( ) Delete .  -- ( ) Delete per others.  — , ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P45:   Consensus to delete ( ) Consensus to delete ( ) Delete .  I suspect there aren't actually any cases where it's currently used where replacing it with would even be necessary.  -- ( ) Delete Not needed anymore, it can be moved to ""relative (P1038) + type of kinship=granparent"".-- ( ) Keep and delete P1038.  It is possible to delete both properties after fix (but not before).  — ( ) P1038 is for use in those cases where we don't have enough information to describe the relationship using and and and .  These cases will still exist even after that bug is fixed.  ( ) Are you sure that so unstructured information can be useful?  — ( ) Sure is a strong word, but I imagine it would be useful sometimes, e.g. for certain historical figures.  -- ( ) P1038 is for use in those cases where we don't have enough information to describe the relationship using and and and . These cases will still exist even after that bug is fixed. ( ) Are you sure that so unstructured information can be useful? — ( ) Sure is a strong word, but I imagine it would be useful sometimes, e.g. for certain historical figures. -- ( ) Are you sure that so unstructured information can be useful?  — ( ) Sure is a strong word, but I imagine it would be useful sometimes, e.g. for certain historical figures.  -- ( ) Sure is a strong word, but I imagine it would be useful sometimes, e.g. for certain historical figures. -- ( ) Delete : Seems pretty clear that there is support for nixing the old properties like this one.  -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P54_(member_of_sports_team):   Consensus is to keep this property.  Any further discussion as to what to do with it from here should be directed to the property's talk page.  Consensus is to keep this property.  Any further discussion as to what to do with it from here should be directed to the property's talk page.  Keep This is one of those cases where I feel that merging to a broader property will create more issues than it solves.  The average professional footballer will play for several clubs, and if they're good, also the national team, the under 17 national team, the under 19 national team, and so on.  But what if they're also a member of a philanthropic organization or a national Olympic committee?  Then you're mixing up two very different types of organization in one property, and that's going to be a pain to work with.  I'm skeptical of that claim.  All you have to do is check the related item for what kind of organization it is.  This is most certainly a property that could go the way of the dodo.  -- ( ) You can also be a member of a sports club without playing for it, like e.g. has been a member of . This case could be distinguished by a ""type of membership"" qualifier (active member, passive member, honorary member, executive member, ...), but I think a dedicated property would be easier. Then again, P54 only says that someone ""represents"" that club. -- ( ) I'm skeptical of that claim.  All you have to do is check the related item for what kind of organization it is.  This is most certainly a property that could go the way of the dodo.  -- ( ) You can also be a member of a sports club without playing for it, like e.g. has been a member of . This case could be distinguished by a ""type of membership"" qualifier (active member, passive member, honorary member, executive member, ...), but I think a dedicated property would be easier. Then again, P54 only says that someone ""represents"" that club. -- ( ) You can also be a member of a sports club without playing for it, like e.g. has been a member of .  This case could be distinguished by a ""type of membership"" qualifier (active member, passive member, honorary member, executive member, ...), but I think a dedicated property would be easier.  Then again, P54 only says that someone ""represents"" that club.  -- ( ) Delete, per the nomination and per my disagreement with Sven. -- ( ) Delete Once you know all the organizations the person is ""member of"", you can filter them by organization type.  This property is redundant. -- ( ) Keep I see a huge difference between team membership (always qualified by a period of time) and ""club"" membership in an organization (beginning and end usually not known).  Therefore should be refined to teams/cadres and the like: As already pointed out a soccer club might have members, IIRC the players in its professional teams (plural!) are employees and one would have to check their contracts to decide whether they are obliged to be club members (and in this case they would not meet the ""free will"" criterion of ).  might simultaneously apply with ""employee""-qualified relation to the club.  -- ( ) Keep They may sound and spell similar but they are two different items/objects. This one here just describes if someone was ""playing for"" some organization, the other being a ""member of"" some organization. Maybe it should be renamed or added a clearer description?! -- ( ) Keep per Sven Manguard.  -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Taxonomic_rank_properties:   As per Succu's summary, these properties have been marked as deprecated.  -- ( ) As per Succu's summary, these properties have been marked as deprecated. -- ( )         This is folly.  Many taxons change over time exactly because those intermediate taxons are deprecated or included or whatever.  Without this information this cannot be expressed.  Thanks, ( ) I am confused, if intermediate taxa are unstable, that seems like a good reason to favor computing them using rather than hardcoding them, as it will minimize the number of items to update.  What am I missing ?  -- ( ) Maybe if the items shouldn't be updated, but be complemented instead? If scientific article A by scientist B et al, in 197X told that C was a specie in genus D of family E, and we today, since 199Y instead tells C is a specie of genus F of family G. Then it is large risk that the relation between C and E will be hard to find in the tree of inheritance. -- ( ) Thats what 'end date' qualifiers are for.  We should have values for 'Parent taxon' for each of the various taxa which have been used in the past with an end date for when it stopped being used.  ( ) That is true, but I am not always sure that statement A automaticly gets an end date, with the start date of statement B in cases like this.  It's not even always true in cases of geographic inheritance.  -- ( ) To me ""C genus: D, end date: 2000 "", means ""in 2000, C ceased to be in genus D, not , in 2000, a new study found that C was actually not part of genus D. The new study says that C has actually never been in genus D, not that is was in genus C until 2000 and stopped being in it after 2000. I think Lavallen's point is valid, even though I do not know how important it is in practice. If article A was only about species C, then it is probably important to know that it classified it in genus D. Is it also important to know that it classified it in family E ? I would imagine that the article's author did not think much about it, the topic of his article is the relation between C and D, not between D and E. -- ( ) There are two things that make this not-a-problem: Qualifiers. ""Date of scientific description"" is probably the best one to use. Rankings. These will allow us to show what the preferred taxon is now. I don't know the specifics of how they will work, but I expect that I will be able to have multiple first-order rankings on a particular claim—thus indicating that the classification of an item is currently in dispute. As a third point somewhat, the fact that they change over time still makes these relations duplicates to ""parent taxon"". -- ( ) I am confused, if intermediate taxa are unstable, that seems like a good reason to favor computing them using rather than hardcoding them, as it will minimize the number of items to update. What am I missing ? -- ( ) Maybe if the items shouldn't be updated, but be complemented instead? If scientific article A by scientist B et al, in 197X told that C was a specie in genus D of family E, and we today, since 199Y instead tells C is a specie of genus F of family G. Then it is large risk that the relation between C and E will be hard to find in the tree of inheritance. -- ( ) Thats what 'end date' qualifiers are for. We should have values for 'Parent taxon' for each of the various taxa which have been used in the past with an end date for when it stopped being used. ( ) That is true, but I am not always sure that statement A automaticly gets an end date, with the start date of statement B in cases like this. It's not even always true in cases of geographic inheritance. -- ( ) To me ""C genus: D, end date: 2000 "", means ""in 2000, C ceased to be in genus D, not , in 2000, a new study found that C was actually not part of genus D. The new study says that C has actually never been in genus D, not that is was in genus C until 2000 and stopped being in it after 2000.  I think Lavallen's point is valid, even though I do not know how important it is in practice.  If article A was only about species C, then it is probably important to know that it classified it in genus D. Is it also important to know that it classified it in family E ?  I would imagine that the article's author did not think much about it, the topic of his article is the relation between C and D, not between D and E. -- ( ) Maybe if the items shouldn't be updated, but be complemented instead? If scientific article A by scientist B et al, in 197X told that C was a specie in genus D of family E, and we today, since 199Y instead tells C is a specie of genus F of family G. Then it is large risk that the relation between C and E will be hard to find in the tree of inheritance. -- ( ) Thats what 'end date' qualifiers are for.  We should have values for 'Parent taxon' for each of the various taxa which have been used in the past with an end date for when it stopped being used.  ( ) That is true, but I am not always sure that statement A automaticly gets an end date, with the start date of statement B in cases like this.  It's not even always true in cases of geographic inheritance.  -- ( ) To me ""C genus: D, end date: 2000 "", means ""in 2000, C ceased to be in genus D, not , in 2000, a new study found that C was actually not part of genus D. The new study says that C has actually never been in genus D, not that is was in genus C until 2000 and stopped being in it after 2000. I think Lavallen's point is valid, even though I do not know how important it is in practice. If article A was only about species C, then it is probably important to know that it classified it in genus D. Is it also important to know that it classified it in family E ? I would imagine that the article's author did not think much about it, the topic of his article is the relation between C and D, not between D and E. -- ( ) Thats what 'end date' qualifiers are for. We should have values for 'Parent taxon' for each of the various taxa which have been used in the past with an end date for when it stopped being used. ( ) That is true, but I am not always sure that statement A automaticly gets an end date, with the start date of statement B in cases like this. It's not even always true in cases of geographic inheritance. -- ( ) To me ""C genus: D, end date: 2000 "", means ""in 2000, C ceased to be in genus D, not , in 2000, a new study found that C was actually not part of genus D. The new study says that C has actually never been in genus D, not that is was in genus C until 2000 and stopped being in it after 2000. I think Lavallen's point is valid, even though I do not know how important it is in practice. If article A was only about species C, then it is probably important to know that it classified it in genus D. Is it also important to know that it classified it in family E ? I would imagine that the article's author did not think much about it, the topic of his article is the relation between C and D, not between D and E. -- ( ) That is true, but I am not always sure that statement A automaticly gets an end date, with the start date of statement B in cases like this.  It's not even always true in cases of geographic inheritance.  -- ( ) To me ""C genus: D, end date: 2000 "", means ""in 2000, C ceased to be in genus D, not , in 2000, a new study found that C was actually not part of genus D. The new study says that C has actually never been in genus D, not that is was in genus C until 2000 and stopped being in it after 2000. I think Lavallen's point is valid, even though I do not know how important it is in practice. If article A was only about species C, then it is probably important to know that it classified it in genus D. Is it also important to know that it classified it in family E ? I would imagine that the article's author did not think much about it, the topic of his article is the relation between C and D, not between D and E. -- ( ) To me ""C genus: D, end date: 2000 "", means ""in 2000, C ceased to be in genus D, not , in 2000, a new study found that C was actually not part of genus D. The new study says that C has actually never been in genus D, not that is was in genus C until 2000 and stopped being in it after 2000.  I think Lavallen's point is valid, even though I do not know how important it is in practice.  If article A was only about species C, then it is probably important to know that it classified it in genus D. Is it also important to know that it classified it in family E ?  I would imagine that the article's author did not think much about it, the topic of his article is the relation between C and D, not between D and E. -- ( ) To me ""C genus: D, end date: 2000 "", means ""in 2000, C ceased to be in genus D, not , in 2000, a new study found that C was actually not part of genus D. The new study says that C has actually never been in genus D, not that is was in genus C until 2000 and stopped being in it after 2000. I think Lavallen's point is valid, even though I do not know how important it is in practice. If article A was only about species C, then it is probably important to know that it classified it in genus D. Is it also important to know that it classified it in family E ? I would imagine that the article's author did not think much about it, the topic of his article is the relation between C and D, not between D and E. -- ( ) There are two things that make this not-a-problem: Qualifiers. ""Date of scientific description"" is probably the best one to use. Rankings. These will allow us to show what the preferred taxon is now. I don't know the specifics of how they will work, but I expect that I will be able to have multiple first-order rankings on a particular claim—thus indicating that the classification of an item is currently in dispute. Qualifiers. ""Date of scientific description"" is probably the best one to use. Rankings. These will allow us to show what the preferred taxon is now. I don't know the specifics of how they will work, but I expect that I will be able to have multiple first-order rankings on a particular claim—thus indicating that the classification of an item is currently in dispute. As a third point somewhat, the fact that they change over time still makes these relations duplicates to ""parent taxon"". -- ( ) How to use in ? — ( ) P. S. You forget notify users about this nomination. It is not really possible before is solved, but once it is, we would need to iterate until we find an item with taxonomic rank ""regnum"" and so on. It is more complicated, but it is easier to update. -- ( ) How to use it is rather irrelevant to whether we should build a flexible database. As it is, the as a (local) copy of taxobox that shows the proof of concept. -- ( ) Keep at least until somebody will create based on . Flexible database is good idea, but there are another more important thinks: database must be usable and easy to use. — ( ) Must be usable when? Why now? You always seem to assert that it must be now (without saying as much), but that's not supported by anything by your opinion. I would rather a flexible database now and leave the wikis to hang (which for the most part already have the infoboxes filled in manually) rather than have to delete properties after the fact. Just see the stupidity and the time that it is taking to delete one property (GND main type). That's pain that we should do everything to prevent. -- ( ) Actually, is using only to build hierarchy. ( ) It is not really possible before is solved, but once it is, we would need to iterate until we find an item with taxonomic rank ""regnum"" and so on. It is more complicated, but it is easier to update. -- ( ) How to use it is rather irrelevant to whether we should build a flexible database. As it is, the as a (local) copy of taxobox that shows the proof of concept. -- ( ) Keep at least until somebody will create based on . Flexible database is good idea, but there are another more important thinks: database must be usable and easy to use. — ( ) Must be usable when? Why now? You always seem to assert that it must be now (without saying as much), but that's not supported by anything by your opinion. I would rather a flexible database now and leave the wikis to hang (which for the most part already have the infoboxes filled in manually) rather than have to delete properties after the fact. Just see the stupidity and the time that it is taking to delete one property (GND main type). That's pain that we should do everything to prevent. -- ( ) Keep at least until somebody will create based on . Flexible database is good idea, but there are another more important thinks: database must be usable and easy to use. — ( ) Must be usable when? Why now? You always seem to assert that it must be now (without saying as much), but that's not supported by anything by your opinion. I would rather a flexible database now and leave the wikis to hang (which for the most part already have the infoboxes filled in manually) rather than have to delete properties after the fact. Just see the stupidity and the time that it is taking to delete one property (GND main type). That's pain that we should do everything to prevent. -- ( ) Must be usable when? Why now? You always seem to assert that it must be now (without saying as much), but that's not supported by anything by your opinion. I would rather a flexible database now and leave the wikis to hang (which for the most part already have the infoboxes filled in manually) rather than have to delete properties after the fact. Just see the stupidity and the time that it is taking to delete one property (GND main type). That's pain that we should do everything to prevent. -- ( ) Actually, is using only to build hierarchy. ( ) I would support the deletion of these properties. However, the may not support deletion at this time . I'll go drop them a note. -- ( ) My vote is fix . It today looks essential to the progress of this project! I'm afraid we will stay here in terra incognita until that is solved. -- ( ) I don't see that these can be deleted at this time . This is especially true for ""family"", which has great practical value.  Before deletion is seriously considered,  a) the bug needs to be fixed, and  b) ""parent taxon""  needs to be implemented fully (or nearly so).  But certainly these properties are to be deprecated.  Do note that, as a rule, there is no ""end date"" for a taxonomic placement.  The truism applies here that any scientific theory or viewpoint will die out only as the people who were taught it when young die out; it is a long-drawn-out process (taking decades), not one point in time.  A minor point is that ""Date of scientific description"" is not very useful.  There exist ""date of discovery"", ""date of first scientific description"" and ""date when the name was published"".  What is generally known is the ""date when the name was published"", but this may be decades, or centuries (sometimes millennia) after a taxon was discovered or first described.  - ( ) I don't see that these can be deleted at this time .  This is especially true for ""family"", which has great practical value.  Before deletion is seriously considered,  a) the bug needs to be fixed, and  b) ""parent taxon""  needs to be implemented fully (or nearly so).  But certainly these properties are to be deprecated.  Do note that, as a rule, there is no ""end date"" for a taxonomic placement.  The truism applies here that any scientific theory or viewpoint will die out only as the people who were taught it when young die out; it is a long-drawn-out process (taking decades), not one point in time.  A minor point is that ""Date of scientific description"" is not very useful.  There exist ""date of discovery"", ""date of first scientific description"" and ""date when the name was published"".  What is generally known is the ""date when the name was published"", but this may be decades, or centuries (sometimes millennia) after a taxon was discovered or first described.  - ( ) I don't see that these can be deleted at this time .  This is especially true for ""family"", which has great practical value.  Before deletion is seriously considered,  a) the bug needs to be fixed, and  b) ""parent taxon""  needs to be implemented fully (or nearly so).  But certainly these properties are to be deprecated.  Do note that, as a rule, there is no ""end date"" for a taxonomic placement.  The truism applies here that any scientific theory or viewpoint will die out only as the people who were taught it when young die out; it is a long-drawn-out process (taking decades), not one point in time.  A minor point is that ""Date of scientific description"" is not very useful.  There exist ""date of discovery"", ""date of first scientific description"" and ""date when the name was published"".  What is generally known is the ""date when the name was published"", but this may be decades, or centuries (sometimes millennia) after a taxon was discovered or first described.  - ( ) Delete .  This will take a while to implement but in the meantime these can be marked as deprecated and a note added telling people to use Parent taxon and Taxon rank instead.  ( ) Delete we should not hurry with deleting them, especially no bot runs for now.  Currently, they can be used for data management, to deploy , , and , and for identifying constraint violations.  However, marking them already as deprecated is important as this would prevent creation of client modules.  For those who doubt the applicability of P171, please see (even if still a preliminary test).   — ( ) Delete Before to delete a well-made taxon, I would open a discussion to the to evaluate pros and cons of the two different systems of classification.  A small consideration: before to make these big changes, I would wait queries, to understand what system work better.  -- ( ) 10:29, 8 December 2013 (UTC) I'm sorry, I saw now the discussion in the project chat. As Emw told below, when the discussion finished and the transition was done, it can be deleted. -- ( ) Delete like FelixReimann, I think these properties should be deleted, but I don't think we need to be in a big hurry to do so.   However, unlike Felix, I think the generic property would be better than as a replacement.  ( ) Delete use .  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P173_(P173):   The result was delete , which will happen when all 200-odd links to the property have been removed.  -- ( ) The result was delete , which will happen when all 200-odd links to the property have been removed.  -- ( ) suffers the same problems as the general type properties. -- ( ) .  flat and not standardized classification.  Delete .  Use P31.   — ( ) Comment - See also .  -- ( ) 08:13, 21 February Delete Looks simple to replace... -- ( ) Delete .  It is unnecessary and can be replaced with .  This property only can take a few values, often irrelevant to specify them (stms. due to the title of the entity), being more simple ≫ election , or if you want to be more precise, ≫ general election , etc.  -- ( ) Delete As for other similar property, election can be managed using a hierarchy made with P31/P279. -- ( ) Keep as explain in the discussion there is no way to have constraint check if we use .  As explain by , it's simple to replace by , but doing the contrary would be impossible.  That's show that there is more meaning in than in , and what is important is to have information and not only data.  In the previous position I see opinions but not facts.  -- ( ) I do not know everything about constaints, but I really think the change from P173 to P31 is reversible, since all kinds of elections should be within a limited subclass. -- ( ) @ :, can you explain me how it's possible to replace by ?  -- ( ) It's a pretty trivial replacement. The constraints can be dealt with using {{ }} and {{ }} and other assorted constraints. -- ( ) @ :My question is how will you convert the existing constraint {{Constraint:Value type|class=Q40231|relation=subclass}} that exists for in ?  -- ( ) You don't need to. The constraint doesn't help you do anything that saying x subclass of election and y instance of x doesn't already tell you. You're using a constraint where a constraint doesn't need to be used. -- ( ) I do not know everything about constaints, but I really think the change from P173 to P31 is reversible, since all kinds of elections should be within a limited subclass.  -- ( ) @ :, can you explain me how it's possible to replace by ? -- ( ) It's a pretty trivial replacement.  The constraints can be dealt with using {{ }} and {{ }} and other assorted constraints.  -- ( ) @ :My question is how will you convert the existing constraint {{Constraint:Value type|class=Q40231|relation=subclass}} that exists for in ? -- ( ) You don't need to.  The constraint doesn't help you do anything that saying x subclass of election and y instance of x doesn't already tell you.  You're using a constraint where a constraint doesn't need to be used.  -- ( ) @ :, can you explain me how it's possible to replace by ? -- ( ) It's a pretty trivial replacement.  The constraints can be dealt with using {{ }} and {{ }} and other assorted constraints.  -- ( ) @ :My question is how will you convert the existing constraint {{Constraint:Value type|class=Q40231|relation=subclass}} that exists for in ? -- ( ) You don't need to.  The constraint doesn't help you do anything that saying x subclass of election and y instance of x doesn't already tell you.  You're using a constraint where a constraint doesn't need to be used.  -- ( ) It's a pretty trivial replacement. The constraints can be dealt with using {{ }} and {{ }} and other assorted constraints. -- ( ) @ :My question is how will you convert the existing constraint {{Constraint:Value type|class=Q40231|relation=subclass}} that exists for in ?  -- ( ) You don't need to. The constraint doesn't help you do anything that saying x subclass of election and y instance of x doesn't already tell you. You're using a constraint where a constraint doesn't need to be used. -- ( ) @ :My question is how will you convert the existing constraint {{Constraint:Value type|class=Q40231|relation=subclass}} that exists for in ?  -- ( ) You don't need to. The constraint doesn't help you do anything that saying x subclass of election and y instance of x doesn't already tell you. You're using a constraint where a constraint doesn't need to be used. -- ( ) You don't need to.  The constraint doesn't help you do anything that saying x subclass of election and y instance of x doesn't already tell you.  You're using a constraint where a constraint doesn't need to be used.  -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  scheduled_service_destination_(P521):   No consensus .  This has been open for almost four months and has only attracted one comment.  -- ( ) No consensus . This has been open for almost four months and has only attracted one comment. -- ( ) Keep For small airports there are not too many to maintain.  Even for big airports, which have hundreds of destinations, these don't change that often.  Useful for wikivoyage.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Freebase_ID_(P646):   Consensus to keep the property.  ( ) Consensus to keep the property.  ( ) Could you explain why this property should be deleted?  [ ] Keep We can link to others, they can link to us.  It will be to our benefit in the end.  ( ) Keep .  Bizarre nomination.  ( ) Speedy keep It seems this nomination was made by mistake.  -- ( ) Speedy keep This nom seems like a test. -- Comment This should be speedily closed as it was filed by a cross-wiki vandal (see their edits to mediawiki and meta).  -- ( ) Delete Most of the times freebase site linked from item includes just old copy of wikipedia, links to another wikipedias or data from wikidata, so no value is added (just wasting resources of wikidate). If not deleted, usage of that property shold be limited only to freebase sites with some added value. -- ( ) Delete Freebase is just copy of Wikipedia and Wikidata as I see.  It can not be used for data verification, can not be used in Wikipedia templates.  What applications use or will use this property?  — ( ) Comment One edit account, see , probably intended trolling about relationship on Wikidata and Wikibase.  I say remove the proposal.  Keep Please note a tool / gadget request at .  gangLeri ( ) This is the of .  We get a new class of "" contributors "".  See .  gangLeri ( ) Keep -- ( ) Question @ :, @ :, @ :, @ :, @ : Could you explain your position in details?  Why we need this property?  What tasks will use it?  — ( ) This is linked datas.  One of the success of Wikidata at that point is the vast collection of identifier mappings such as authoritative databases, and specialized databases such as MusicBrainz and others.  Freebase is a major database, whatever you think about it, this is enough.  Comment It is getting ridiculous.  is a clown with one contribution only.  I assume he is loud laughing about our bureaucratism.  can be used as a link to a non-disambiguous ontology because no language conflicts are known to me.  The wording is short which avoids allusions to different topics which is not the case in WMF articles linked together on a "" similar as "" / "" related to "" (redirects) WMF custom / arrogance base.  gangLeri ( ) @ : Please state the facts about the user (i.e. ""this is clearly a test from a user who only has one edit here"") without calling them a clown.  -- Like said. -- , a nomination initiated with the one-word rationale ""Can."" is absurd and not worth discussing.   Beyond that, my rationale for keeping this property is based upon Denny's comment in : This is linked datas.  One of the success of Wikidata at that point is the vast collection of identifier mappings such as authoritative databases, and specialized databases such as MusicBrainz and others.  Freebase is a major database, whatever you think about it, this is enough.  Comment It is getting ridiculous.  is a clown with one contribution only.  I assume he is loud laughing about our bureaucratism.  can be used as a link to a non-disambiguous ontology because no language conflicts are known to me.  The wording is short which avoids allusions to different topics which is not the case in WMF articles linked together on a "" similar as "" / "" related to "" (redirects) WMF custom / arrogance base.  gangLeri ( ) @ : Please state the facts about the user (i.e. ""this is clearly a test from a user who only has one edit here"") without calling them a clown.  -- @ : Please state the facts about the user (i.e. ""this is clearly a test from a user who only has one edit here"") without calling them a clown. -- Like said.  -- , a nomination initiated with the one-word rationale ""Can."" is absurd and not worth discussing.   Beyond that, my rationale for keeping this property is based upon Denny's comment in : If you or someone else want to have this property deleted then I recommend closing this nomination, and re-opening another a well-written rationale that takes into account Denny's comment above and the discussions in and .   I would likely still oppose deleting this 'Freebase identifier' property.  ( ) If you or someone else want to have this property deleted then I recommend closing this nomination, and re-opening another a well-written rationale that takes into account Denny's comment above and the discussions in and .   I would likely still oppose deleting this 'Freebase identifier' property.  ( ) Thinks for clarify.  I have no interest for Sak4510 and his actions.  Some time ago I reviewed IMDB, VIAF and some other.  Its contain information that can be used for data verification and/or data import.  I review Freebase too, but all found information was copied from Wikipedia and Wikidata by bot.  Is Freebase too young or dead project maybe? ... — ( ) Thinks for clarify.  I have no interest for Sak4510 and his actions.  Some time ago I reviewed IMDB, VIAF and some other.  Its contain information that can be used for data verification and/or data import.  I review Freebase too, but all found information was copied from Wikipedia and Wikidata by bot.  Is Freebase too young or dead project maybe? ... — ( ) Thinks for clarify.  I have no interest for Sak4510 and his actions.  Some time ago I reviewed IMDB, VIAF and some other.  Its contain information that can be used for data verification and/or data import.  I review Freebase too, but all found information was copied from Wikipedia and Wikidata by bot.  Is Freebase too young or dead project maybe? ... — ( ) Comment (continued) I want to point out that two things:  a) Is the Freebase - Wikidate relation is a "" one way "" issue?  Are we able to create a peer to ask for new Freebase identifiers?  Maybe some WD contributors are both skilled and willing to add WD related information to Freebase.  Here some links: "" perfect "" – (208 items) – (16 items) The second link is a point to start identifying Freebase records and adding them to WD.  If necessary FrB records should be created first.  shows 171.182 hits.  One reason might be that Freebase is mainly related / linked to en.Wikipedia and GND is not a copy of de.Wikipedia it is a national library database.  This amount of data can not be handled by but with some maintenance / signaling conventions one could "" mark "" WD items which are ready to be used for semi-automatic Freebase record generation.  b) The massive import of data into WD was made with different care.  While I have not found OSM properties in disambiguation page I found the following: - (17 items) for - (78 items) for – (31 items) for - (1127 items) for - (29 items) for Manual addition as a first step helps getting aware of the arriving issues: - (1 items) for - fixed see for ( ) - (0 items) for helps to identify the presence of some property values; the search for Freebase - using SLASHES - fails.  Unfortunately there are no tools known to me to verify the backward links.  I have seen a dozen of faulty links but there is no place to post them, it seems that nobody is willed to take care of them.  The most evident method would be to use WD inline quality statements.  No person and no bot can say it was not aware of their presence.  Regards gangLeri ( ) Comment (continued) I want to point out that two things:  a) Is the Freebase - Wikidate relation is a "" one way "" issue?  Are we able to create a peer to ask for new Freebase identifiers?  Maybe some WD contributors are both skilled and willing to add WD related information to Freebase.  Here some links: "" perfect "" – (208 items) – (16 items) The second link is a point to start identifying Freebase records and adding them to WD.  If necessary FrB records should be created first.  shows 171.182 hits.  One reason might be that Freebase is mainly related / linked to en.Wikipedia and GND is not a copy of de.Wikipedia it is a national library database.  This amount of data can not be handled by but with some maintenance / signaling conventions one could "" mark "" WD items which are ready to be used for semi-automatic Freebase record generation.  b) The massive import of data into WD was made with different care.  While I have not found OSM properties in disambiguation page I found the following: - (17 items) for - (78 items) for – (31 items) for - (1127 items) for - (29 items) for Manual addition as a first step helps getting aware of the arriving issues: - (1 items) for - fixed see for ( ) - (0 items) for helps to identify the presence of some property values; the search for Freebase - using SLASHES - fails.  Unfortunately there are no tools known to me to verify the backward links.  I have seen a dozen of faulty links but there is no place to post them, it seems that nobody is willed to take care of them.  The most evident method would be to use WD inline quality statements.  No person and no bot can say it was not aware of their presence.  Regards gangLeri ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Dharma_Drum_Institute_of_Liberal_Arts_place_ID_(P1188):   No consensus.  ( ) No consensus.  ( ) Weak keep .  The DDBC a good authority database and the property is only one month old.  Let's wait some more time.  ( ) Keep .  It looks like a useful authority, and they say they have APIs so it should be easy to sync.  I have manually added a place Id onto .  ( ) Comment I've added this property into a few more items.  -- ( ) Keep -- ( ) Not deleted There's no consensus to delete this after about 5 months, and additionally, there's no active discussion about it. ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  number_of_cylinders_(P1100):   consensus to keep -- ( ) consensus to keep -- ( ) Keep , same as .  — ( ) Keep .  Same argument as my argument to keep now.  I may support a proposal giving a better alternative.  Regards, ( ) Delete per .  ( ) Keep : ""number of cylinders"" ( ): per .  --- ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P969_(P969):   Consensus to keep property.  Consensus to keep property.  P969 includes more than p669.  If we have , , , , , , , , what else do we need?  -- ( ) « P969 includes more than p669 » ? what can not be include with P669 ? Cdlt, ( ) is string. is item. is only one part of . Some other parts has corresponding properties , , , ). Some another parts do not have corresponding properties. For example ""район"", ""корпус"", ""станция метро"", ""номер квартиры"", ""номер офиса"" are used also in Russia (maybe incorrect translation: ""region"", ""corpus"", ""metro station"", ""flat number"", ""office number""). Another countries can have another specific. So covers more situations, but it is less structural. I think we need to save both properties. But recommend to use , , , and other if its are enough to specify exact address.  — ( ) Couldn't the informations you spoke be inserted with qualifiers ? shouldn't we at least have a constraint « if , don't add » to avoid case like ? Cdlt, ( ) Couldn't the informations you spoke be inserted with qualifiers ? shouldn't we at least have a constraint « if , don't add » to avoid case like ? Cdlt, ( ) Keep No, it is definitely not a duplicate . For starters, is a string and is an item. That is the difference, and it can be a big difference because data strings do not dynamically change as data items do. Streets and buildings can change their names over time, addresses can cease to exist. as a string allows us to explicitly state a precise address for an item at a given point in time, as sourced from formal and official sources, e.g. Companies House in England, for companies registered in England and Wales, company listings on stock exchange websites, etc. ( ) Can't qualifiers be used to « explicitly state a precise address for an item at a given point in time, as sourced from formal and official sources » ? Cdlt, ( ) Can't qualifiers be used to « explicitly state a precise address for an item at a given point in time, as sourced from formal and official sources » ? Cdlt, ( ) I wonder why is item. We won´t have items for each street in a city even lesser in all places.-- ( ) is used with as a qualifier, who contain the street number.  Personnaly I use for street without item number and when we have article in one of the wikipedias.  -- ( ) Item seems the logical type for an adress to me. We won’t « have items for each street in a city even lesser in all places » but we will have items for each street needed in other items. Cdlt, ( ) I wonder why is item. We won´t have items for each street in a city even lesser in all places.-- ( ) is used with as a qualifier, who contain the street number.  Personnaly I use for street without item number and when we have article in one of the wikipedias.  -- ( ) Item seems the logical type for an adress to me. We won’t « have items for each street in a city even lesser in all places » but we will have items for each street needed in other items. Cdlt, ( ) is used with as a qualifier, who contain the street number. Personnaly I use for street without item number and when we have article in one of the wikipedias. -- ( ) Item seems the logical type for an adress to me.  We won’t « have items for each street in a city even lesser in all places » but we will have items for each street needed in other items.  Cdlt, ( ) Item seems the logical type for an adress to me.  We won’t « have items for each street in a city even lesser in all places » but we will have items for each street needed in other items.  Cdlt, ( ) Comment Note that this property is used by when is unused.  -- ( ) As shown by , is currently more often used with , but yes, it is sometimes used with p969 as well.  Note that in some places, like Paris, just about every street has an item.  This property seems to be useful when no item is available.  For the ordinary user, it is much more convenient to copy-paste a string than to create an item, and add a statement with the required qualifiers.  However, I do not really know if we should recommend not use this property when an equivalent is available.  It would seem to make sense, but Danrok's argument seems reasonable.  -- ( ) True, is more simple for user but it's seems to me ambiguous and unusable properly (adresses are not strictly monolingual).  Why shouldn’t we the more precise and clear property ?  It seems a good recommendation to me.  Cdlt, ( ) As shown by , is currently more often used with , but yes, it is sometimes used with p969 as well.  Note that in some places, like Paris, just about every street has an item.  This property seems to be useful when no item is available.  For the ordinary user, it is much more convenient to copy-paste a string than to create an item, and add a statement with the required qualifiers.  However, I do not really know if we should recommend not use this property when an equivalent is available.  It would seem to make sense, but Danrok's argument seems reasonable.  -- ( ) True, is more simple for user but it's seems to me ambiguous and unusable properly (adresses are not strictly monolingual). Why shouldn’t we the more precise and clear property ? It seems a good recommendation to me. Cdlt, ( ) True, is more simple for user but it's seems to me ambiguous and unusable properly (adresses are not strictly monolingual). Why shouldn’t we the more precise and clear property ? It seems a good recommendation to me. Cdlt, ( ) Two different ways to do the same thing is not the best solution for sure. If we keep the data structure this way and use street as qualifier to adress, we need at least much more explanations on the properties description boxes and also some more examples how to use it.-- ( ) Danrok's point was that sometimes we need a precise street as an address, we do not need to just get the meaning right.  I am not sure how important this is however.  If this is just for very technical legal information, people should probably not turn to Wikipedia/Wikidata for that anyway.  Another isue is no case where a string property does not sound too convenient: is non latin script.  Take China: addresses are often provided both in Chinese and in English (but not in other languages).  Though the Chinese -> English tranformation usually follows a regular pattern, it more complex to retrieve programmatically than a mere transliteration (四川北路44号 -> ""44 Sichuan Rd (N)."" not ""sichuan beilu 44 hao"").  Given that an address in English (+ Arabic, Russian etc?) seems necessary for many people to understand, that requires at least two statements).  By the way, it suggests that the datatype is more monolingual text than string.  I tend to think the ideal solution would be: let users type string and have (smart) bots that can turn them into items when they can make sure that it matches.  -- ( ) Danrok's point was that sometimes we need a precise street as an address, we do not need to just get the meaning right.  I am not sure how important this is however.  If this is just for very technical legal information, people should probably not turn to Wikipedia/Wikidata for that anyway.  Another isue is no case where a string property does not sound too convenient: is non latin script.  Take China: addresses are often provided both in Chinese and in English (but not in other languages).  Though the Chinese -> English tranformation usually follows a regular pattern, it more complex to retrieve programmatically than a mere transliteration (四川北路44号 -> ""44 Sichuan Rd (N)."" not ""sichuan beilu 44 hao"").  Given that an address in English (+ Arabic, Russian etc?) seems necessary for many people to understand, that requires at least two statements).  By the way, it suggests that the datatype is more monolingual text than string.  I tend to think the ideal solution would be: let users type string and have (smart) bots that can turn them into items when they can make sure that it matches.  -- ( ) Keep and have different usages and different datatypes. The label of the item pointed to by this property can be translated and transcribed into any language. on the other hand is the complete address in the local language and charachter set (i.e. what you have to write on the envelope of a letter if you want it to be delivered to the right place). For example, ""Свеавеген"" is a perfectly acceptable name in russian for the street , but the address is still ""Sveavägen"". This actually made more sense before someone changed the labels. / Hi , could you change and document to match the concept « adress »? Right now, the label and the description is not « adress » at all but « street ». Plus, when you say « adress » what exactly are you talking about ? And why/when do we need this « adress » property ? (especially when the adress can be infered from other properties like / / /etc.) Cdlt, ( ) Hi , could you change and document to match the concept « adress »? Right now, the label and the description is not « adress » at all but « street ». Plus, when you say « adress » what exactly are you talking about ? And why/when do we need this « adress » property ? (especially when the adress can be infered from other properties like / / /etc.) Cdlt, ( ) Hi , could you change and document to match the concept « adress »? Right now, the label and the description is not « adress » at all but « street ». Plus, when you say « adress » what exactly are you talking about ? And why/when do we need this « adress » property ? (especially when the adress can be infered from other properties like / / /etc.) Cdlt, ( ) Keep per Esquilo. — Keep As the discussion shows, it is not possible to merge properties with different valuetypes string and item. The questioned property can not be replaced easily. This property is not completely stuctured, so it can contain more than . Even if we have hypothetically an item for every street that is described as a value for {(P|969)}, we can not cover every possible usage of P969 like the russian additional informations in the adresses, there are also some cases, where there is no street contained in the adress. -- ( ) Keep ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P1597_(P1597):   consensus to delete -- ( ) consensus to delete -- ( ) Delete — ( ) Delete - As the proposer, I don't object deletion if the idea is to use for all heritage (although someone could've notified me about this request), just please make sure to migrate all the uses before deleting - my bot requests tend to be ignored.  Thank you.  — Right now, there are that have this property.  Would be a job for a bot to move them?  ( ) Tanks .  Il beleived by the form of the deletion request that you where directly notified.  Il will do directly next time on the page of people who voted for the property.  -- ( ) As the proposer, I don't object deletion if the idea is to use for all heritage (although someone could've notified me about this request), just please make sure to migrate all the uses before deleting - my bot requests tend to be ignored.  Thank you.  — Right now, there are that have this property.  Would be a job for a bot to move them?  ( ) Tanks .  Il beleived by the form of the deletion request that you where directly notified.  Il will do directly next time on the page of people who voted for the property.  -- ( ) Right now, there are that have this property. Would be a job for a bot to move them? ( ) Tanks . Il beleived by the form of the deletion request that you where directly notified. Il will do directly next time on the page of people who voted for the property. -- ( ) Tanks .  Il beleived by the form of the deletion request that you where directly notified.  Il will do directly next time on the page of people who voted for the property.  -- ( ) Comment At the same time, other people are specific properties from the more generic; not least so that we can use .  We need to agree a project-wide policy on this.  @ : The generic/specific properties will probably like a ""chicon/endive"" debate in frwiki, it will be eternal and come back time to time.  I also beleive there is a uge difference between a item and a string property on the generic/specific debate.  For the case of , it is mosty the same property that }, but only for Slovenia.  I am not sure a item property for only one country sould be alowed.  But there is plenty of string properties who use national databases.  -- ( ) Delete I agree with Fralambert that the issue is very different from string-type identifier properties.  Centralizing work in a generic ""heritage property"" appears to work quite well.  @ , :, you have done similar jobs in the past, would you do the migration ?  -- ( ) @ : I can do it, but I'd rather wait for a resolute community statement about whether is the way to go. -- @ : I can do it, but I'd rather wait for a resolute community statement about whether is the way to go.  -- ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P738_(P738):   consensus to delete .  Before statements get removed, templates using this property need to be adjusted.  -- ( ) consensus to delete . Before statements get removed, templates using this property need to be adjusted. -- ( ) Lean keep .  , what you label a ""reversed duplicate"" is typically called an "" "".   These are often useful and widespread on the Semantic Web.   I wouldn't lead an argument for deletion with that rationale.  Your point about the huge number of potential claims that could be made with this property is worth considering, though.   Adding each philosopher influenced by Plato to via influence of would clearly be a bad idea.   However, I think looking at Plato's infobox in various Wikipedias indicates a possible solution to that problem: : Influenced by: Socrates, Homer, Hesiod, Aristophanes, Aesop, Protagoras, Parmenides, Pythagoras, Heraclitus, Orphism Influence of: Most of that came after his works : Influenced by: Socrates, Homer, Hesiod, Aristophanes, Aesop, Protagoras, Parmenides, Pythagoras, Heraclitus, Orphism Influence of: Most of that came after his works : Influenced by: Socrates, Homer, Hesiod, Aristophanes, Aesop, Protagoras, Parmenides, Pythagoras, Heraclitus, Orphism Influence of: Most of that came after his works : Influenced by: Pre-Socratic philosophy, Socrates, Greco-Roman mysteries, Orphism Influence of: Much of Western philosophy; part of : Influenced by: Pre-Socratic philosophy, Socrates, Greco-Roman mysteries, Orphism Influence of: Much of Western philosophy; part of : Influenced by: Pre-Socratic philosophy, Socrates, Greco-Roman mysteries, Orphism Influence of: Much of Western philosophy; part of : Influenced by: Socrates, Archytas, Democritus, Parmenides, Pythagoras, Heraclitus Influence of: Aristotle, almost all European and Middle Eastern philosophers : Influenced by: Socrates, Archytas, Democritus, Parmenides, Pythagoras, Heraclitus Influence of: Aristotle, almost all European and Middle Eastern philosophers : Influenced by: Socrates, Archytas, Democritus, Parmenides, Pythagoras, Heraclitus Influence of: Aristotle, almost all European and Middle Eastern philosophers In other words, for very influential things, simply have the value of influence of be a movement of which their influencees were a part.   Then if we want to do inference down the road, we could look up or deduce the influencee's (or what have you), and infer that the influencer satisfies a large number of more specific influence of claims.  ( ) I really don't see the need for an inverse (and I have already seen several successful PfD done on this ground).  The already allows to do the exact same thing using : you can retrieve all the philosophers that claims to be influenced by Plato.  We are merely doing the same work twice.  And I'm unconvinced by your solution: Most of Western philosophy is quite fuzzy.  There are actually numerous influential western philosophical movements that do not claim an influence from Plato (Epicureanism, Cartenianism, Positivism…).  It's really more suitable to only use and get all the results in a reverse way.  ( ) Wikipedia cannot use Wikidataquery to display info.  Note that some widely used infoboxes like contain ""influenced"" fields.  makes use of this property as a default, though so far with no hits ( ).  When an item is not a ""big influencer"" (say, is p737 value in less than 10 items), a bot should update it automatically.  When there are many potential values, I am not too sure what to do. -- ( ) I really don't see the need for an inverse (and I have already seen several successful PfD done on this ground). The already allows to do the exact same thing using : you can retrieve all the philosophers that claims to be influenced by Plato. We are merely doing the same work twice. And I'm unconvinced by your solution: Most of Western philosophy is quite fuzzy. There are actually numerous influential western philosophical movements that do not claim an influence from Plato (Epicureanism, Cartenianism, Positivism…). It's really more suitable to only use and get all the results in a reverse way. ( ) Wikipedia cannot use Wikidataquery to display info. Note that some widely used infoboxes like contain ""influenced"" fields. makes use of this property as a default, though so far with no hits ( ). When an item is not a ""big influencer"" (say, is p737 value in less than 10 items), a bot should update it automatically. When there are many potential values, I am not too sure what to do.-- ( ) Wikipedia cannot use Wikidataquery to display info.  Note that some widely used infoboxes like contain ""influenced"" fields.  makes use of this property as a default, though so far with no hits ( ).  When an item is not a ""big influencer"" (say, is p737 value in less than 10 items), a bot should update it automatically.  When there are many potential values, I am not too sure what to do. -- ( ) Keep : If we were to get rid of this, then we would have to get rid of Parent or Child, as these can also be considered inverse properties. Staple of data in my mind. ( ) And we should (get rid of child in this case). That parent has been allowed to survive is... a problem. :) -- ( ) You made my day.  ( ) And we should (get rid of child in this case).  That parent has been allowed to survive is.. .  a problem.  :) -- ( ) You made my day. ( ) Delete . This is clearly a property that should be deleted because of problems regarding citeability and scope. And to be honest, it's not important to the person who is doing the influencing; only the person who is influenced . -- ( ) I agree.  Delete .  -- ( ) I agree. Delete . -- ( ) Delete Use only .  --- Delete . I agree with the concern above that the influenced people may not be important to the influencer. For cases where the relationship is important, we already have , , and similar. ( ) Delete I agree this belongs to the influencee, and it's redundant. Delete Per Alexander Doria. ( ) Delete Just used this in Henrik Ibsen and was wondering why I had to use it as it is clearly asymmetrical and unbounded property. I go with Iznos argument, this is a delete. ( ) Comment (updating my comment above) this property is used in the frwiki version of where it matches a prewikidata parameter. It is currently used in . -- ( ) Delete Use Delete confusing. ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P1361_(P1361):   Agreed on deletion, no backlinks.  ( ) Agreed on deletion, no backlinks.  ( ) Pinging original proposer @ : and property creator @ : as per the section above which says the template parameters don't actually do anything.  - ( ) Support totally agree with splitting.  -- ( ) Delete I totally agree too, thanks for splitting. ( ) Delete I agree with deletion and splitting. -- ( ) Delete as redundant. ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Inventari_del_Patrimoni_Arquitectònic_de_Catalunya_code_(P1600):   Consensus to keep.  -- ( ) Consensus to keep. -- ( ) Have a look at the property descriptions on the talk pages.  --- @ : Could you withdraw this or add a notice on its talk page that it's listed for deletion? --- @ , , : -- ( ) Keep give accès to for , usefull for have protection date. -- ( ) I had marked this section as resolved as the nominator failed to follow up on it.  Apparently he chose to cease participation.  IMHO it can be archived.  --- ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  floruit_(P1317):   Strong consensus to keep.  Strong consensus to keep.  Comment P1317 can be used with several dates and different references: the earliest date would be the ""start"", the latest ""end"".  If there is a single date, well that's the only one that is known.  Scope is slightly different ""alive"" <> ""work period"".  Not sure if the new properties are of much use.  Seems that the revised proposal for them lacked support @ : strange that it was actually created.  --- Comment It seemed logic to follow the structure of ""start"" and ""end"", while P1317 can be used for ""point in time"".-- ( ) Comment floruit can be both very large and very specific, not sure if it's really superseded now that and .  Floruit is not exactly about activity but about attestation (we now that someone or something existed at some point in time).  On , most uses seems to be on a single date.  On or , sure we can use others properties (like and or and - at this point of lack of precision, there is no difference anymore - but it will be a bit ridiculous and overkill) Cdlt, ( ) Q2822101 might be an interesting sample for P1317 and P570.  --- Comment It seemed logic to follow the structure of ""start"" and ""end"", while P1317 can be used for ""point in time"".-- ( ) Comment floruit can be both very large and very specific, not sure if it's really superseded now that and .  Floruit is not exactly about activity but about attestation (we now that someone or something existed at some point in time).  On , most uses seems to be on a single date.  On or , sure we can use others properties (like and or and - at this point of lack of precision, there is no difference anymore - but it will be a bit ridiculous and overkill) Cdlt, ( ) Q2822101 might be an interesting sample for P1317 and P570.  --- Q2822101 might be an interesting sample for P1317 and P570. --- Keep Does this proposal mean that when I have only a single floruit date, I should enter it twice in the and properties?  That seems inelegant, and also leaves open the possibility that some editors will not bother to fill in both dates, resulting in doubt over whether the second date was intended to be equal to the first date or is just unknown.  I agree with Jura's comment: an unordered list of dates would do the job just as well.  -- ( ) Keep sometimes a single date or one rough guess is all our sources give us. -- ( ) Keep and should be used when sources give a specific date range for the period of activity.  should be used when only specific points in time are known.   Both are found widely in the literature, depending on what is known; so it is useful to be able to express either type of statement.   Multiple uses of are not a satisfactory substitute for and , because they would not capture the implication that the source identifies this as representative of the whole span of the period of activity.  ( ) Keep per Jheald, but change description so it does not contradict American Heritage Dictionary 3rd edition, which defines floruit as ""The period during which a person, school, or movement was most active or flourishing.""  Given  (a) that the property is date-valued rather than item-valued; and  (b) that the known date of a particular work may not reflect when a person was most flourishing, can I suggest to amend your text to ""A date at which a person, school, or movement was active or flourishing."" ( ) Given  (a) that the property is date-valued rather than item-valued; and  (b) that the known date of a particular work may not reflect when a person was most flourishing, can I suggest to amend your text to ""A date at which a person, school, or movement was active or flourishing."" ( ) ###Output: ",0
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P167:   No consensus to delete.  No consensus to delete.  Keep There is significant ambiguity in the idea of ""replaced by"" when dealing with things that are not explicitly part of a series in the way that presidents (etc.) are.  I think it is useful to have a property that explicitly states the replacement was spatial.  An object could be replaced both spatially and functionally in two different ways.  ( ) Keep per Antrocent.  I have added a statement that this is a 'subproperty of:replaced by'.  Eventually we will be able to search on 'replaced by (including subproperties)'.  ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P1805_(P1805):   consensus to change datatype -- ( ) consensus to change datatype -- ( ) Question Does every drug have 7 different names?  If so, then multilingual datatype is maybe something we should consider in the future?  Not to encourage every name to be translated to icelandic, but to give better space for all of these 7 languages.  -- ( ) @ : We are speaking about WHO INN only not about commercial names or common names.  So there is only 7 translations of WHO INN.  For other names we are using aliases and we wait for the multilingual datatype for the IUPAC name because there is a translation for IUPAC name in each language.  @ : We are speaking about WHO INN only not about commercial names or common names.  So there is only 7 translations of WHO INN.  For other names we are using aliases and we wait for the multilingual datatype for the IUPAC name because there is a translation for IUPAC name in each language.  Change datatype to monolingual text .  If the WHO identifies each name as being associated with a particular language then we need to record that language info and a monolingual text datatype is the best way to do it.  If needed this property can have 7 values - one for each of these languages.  ( ) Support But we have to first create the new property with monolingual datatype and transfer the current data before deleting the current property.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  structure_replaces_(P1398):   consensus to keep -- ( ) consensus to keep -- ( ) Comment See the above deletion discussion for P1398's sibling, .  The best label might be like ""spatially replaces"" if that's what distinguishes this from .  ( ) Comment this seems fairly straight-forward, could we go ahead with this?  --- Oppose This property has fewer than 20 uses. It can be repurposed, without the need for deletion, if there is consensnus to do so in the ongoing discussion in its talk page. Can you provide any reference for a possibility to ""repurpose"" properties? Given that you seem to be editing as a resident Wikipedia, can you clarify if your editorial contributions are endorsed by the Royal Society of Chemistry and/or reflect the views of the Royal Society of Chemistry? --- Jura, knock it off.  His POV is irrelevant to this discussion and most others on Wikidata.  -- ( ) Good point. I suppose I'd better ignore him going forward. So can someone close this? --- Can you provide any reference for a possibility to ""repurpose"" properties?  Given that you seem to be editing as a resident Wikipedia, can you clarify if your editorial contributions are endorsed by the Royal Society of Chemistry and/or reflect the views of the Royal Society of Chemistry?  --- Jura, knock it off. His POV is irrelevant to this discussion and most others on Wikidata. -- ( ) Good point.  I suppose I'd better ignore him going forward.  So can someone close this?  --- Jura, knock it off. His POV is irrelevant to this discussion and most others on Wikidata. -- ( ) Good point.  I suppose I'd better ignore him going forward.  So can someone close this?  --- Good point. I suppose I'd better ignore him going forward. So can someone close this? --- Oppose Label has been fixed, no need to delete.  Useful concept.  ( ) There is no issue with the concept as such.  It's just that (someone) broke the label just after it was created.  Now all downstream references to the property were and maybe still are incorrect.  An no, the labels are not all fixed.  Just create a new property and move the applicable parts there, nothing really complicated.  --- There is no issue with the concept as such. It's just that (someone) broke the label just after it was created. Now all downstream references to the property were and maybe still are incorrect. An no, the labels are not all fixed. Just create a new property and move the applicable parts there, nothing really complicated. --- ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P2466_(P2466):   consensus to delete -- ( ) consensus to delete -- ( ) Delete - same thing according to the descriptions.  ( ) It seems that P1596 wasn't that much used when P2466 was proposed.  This might explain the duplicate.  Odd that the proposer of the first didn't notice the duplicate.  --- I can go either way here; the English connotation of a judicial sentence is more-or-less restricted to criminal cases.  Penalty opens that to civil cases and private arbitration as well, and even lesser items such as parking tickets.  I'm more inclined to delete than not, but there is a different domain of use for these two properties.  -- ( ) Delete almost same meaning as , used only six times. -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Freebase_ID_(P646):   Not deleted - consensus to keep .  -- ( ) Not deleted - consensus to keep .  -- ( ) If the formatter url doesn't work, it should be deprecated (or, if that doesn't help, be removed). This has nothing to do with the identifier as such. --- Is not there dumps of freebase available somewhere ?  Then the information should not be deleted and made hardly available.  Keep per the TomTom.  Yes Keep - the archive.org formatter should work for many items.  ( ) Keep per TomTom and Jura.  -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P2890:   Speedy deleted -- unintentionally created with wrong datatype. ( ) Speedy deleted -- unintentionally created with wrong datatype.  ( ) ###Output: ",0
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P2541: -- ( ) Withdrawn.-- ( ) Oppose This was suggested and rejected when was .   If it is merged ""places served"" is not a good label as P2541 includes areas that are not ""served"" - e.g. does not ""serve"" rather it is jointly responsible for investigating accidents that occur there, and doesn't serve rather it is an umbrella organisation that supports its members wherever they are in the world.   ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P3062:   Speedy deleted, wrong datatype.  07:17, 4 September 2016 (UTC) (done a lot earlier) Speedy deleted, wrong datatype.  07:17, 4 September 2016 (UTC) (done a lot earlier) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  uses_property_(P3176):   Please notify the involved people, there is no mention on the property talk page or proposal.  Keep if it wasn't clear on the original proposal page, I definitely supported the creation of this property.  It has been used 7 times so far that I can see; perhaps Andy can explain how an alternative property would suffice for those 7 cases if he so strongly feels it should be deleted?  His argument on the proposal page was simply incorrect - main subject is NOT the right solution here.  ( ) Keep if it wasn't clear on the original proposal page, I definitely supported the creation of this property.  It has been used 7 times so far that I can see; perhaps Andy can explain how an alternative property would suffice for those 7 cases if he so strongly feels it should be deleted?  His argument on the proposal page was simply incorrect - main subject is NOT the right solution here.  ( ) @ : -- ( ) Keep Disagree with Andy's conclusion about missing consensus.  Furthermore I consider the property useful.  ( ) Keep I misunderstood the property proposal at first, but withdrew my opposition when that became clear.  Now I've seen it in action I can clearly understand the value in it and would have explicitly supported (although maybe ""uses Wikidata property"" might be a better label).  At e.g. it's clear that is not an appropriate property for this use case, and I'm not aware of any other existing or proposed ones that are.  ( ) Keep Disagree with Andy's conclusion about missing consensus.  Furthermore I consider the property useful.  ( ) Keep I misunderstood the property proposal at first, but withdrew my opposition when that became clear.  Now I've seen it in action I can clearly understand the value in it and would have explicitly supported (although maybe ""uses Wikidata property"" might be a better label).  At e.g. it's clear that is not an appropriate property for this use case, and I'm not aware of any other existing or proposed ones that are.  ( ) Kept no grounds or consensus for deletion at all.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  member_of_political_party_(P102):   consensus to keep -- ( ) consensus to keep -- ( ) is not a political party/organisation.  Yes, there are a lot of potential problems with P102.  One is that the adding of this property into a database like Wikidata could be illegal where I live.  Another is that if you have a seat in a national or local parliament for a political party, does not mean that you have to be a member of that party.  -- ( ) Can you explain the relevance of Q327591, or of the law in your local jurisdsiction? @ : (Failed to see your Q until now.) The relevant law is , which is a part of the Swedish constitution. Adding membership of political party into a database is definitely problematic. If I remember correctly, both the Security police and the have been caught doing this. And the only intension of this by the railway company was marketing toward group travellers. Not only membership of a political party can be problematics, but all records of political opinions. -- ( ) Frankly this is irrelevant for Wikidata.  That the Swedish national railway company is using political party affiliation as part of its marketing campaign is bad, but Wikidata is only storing political party preference for people who are either politicians standing for office, or notable people who have declared their party membership (plenty of celebrities and columnists describe how they are registered members of some party or the other).  In both cases, that is public information that has been published in a source.  Just the same as with data on religious belief, sexual orientation and so on.  — ( ) @ : That somebody is ""standing for office"" for a political party, does not prove that they are members of anything.  It still happens in local elections here that some people got elected for a political party they are not a member of.  In one case, a V-supporter wrote his own name on a SD-ballot and succeeded to get a seat representing a political party he hates.  It is one thing for a political party to win X seats in an election, another thing to fill those seats with supporters and a third thing to keep them loyal to the party for four years.  On county-level that last thing has become a huge problem for the governing majority here.  -- ( ) @ : That seems a pretty niche problem.  In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose.  Apply Pareto's Principle: in most cases, if someone says ""I'm a member of the Labour Party"", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party.  In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of ""Vote money, get monkey"".  Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor.  We can handle these kind of odd exceptions with other constructions rather than by deleting P102.  — ( ) @ : That somebody ""steals"" a seat in this manner is very unusual.  But that somebody ""represents"" a party they are not member of is more common than most of us think.  Sometimes you vote for a list of persons on a list with mixed persons.  They represents ""The conservatives"", but ""The conservatives"" is not a political party.  It is a technical cooperation between close related parties.  The voting-system here favours large parties at the cost of the small ones.  When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2.  List D got 3 seats, 2 to H and 1 independent.  When I moved here, SD had one seat in the local election, but no names could be found in the ballots.  The seat became empty. -- ( ) Can you explain the relevance of Q327591, or of the law in your local jurisdsiction? @ : (Failed to see your Q until now.) The relevant law is , which is a part of the Swedish constitution. Adding membership of political party into a database is definitely problematic. If I remember correctly, both the Security police and the have been caught doing this. And the only intension of this by the railway company was marketing toward group travellers. Not only membership of a political party can be problematics, but all records of political opinions. -- ( ) Frankly this is irrelevant for Wikidata.  That the Swedish national railway company is using political party affiliation as part of its marketing campaign is bad, but Wikidata is only storing political party preference for people who are either politicians standing for office, or notable people who have declared their party membership (plenty of celebrities and columnists describe how they are registered members of some party or the other).  In both cases, that is public information that has been published in a source.  Just the same as with data on religious belief, sexual orientation and so on.  — ( ) @ : That somebody is ""standing for office"" for a political party, does not prove that they are members of anything.  It still happens in local elections here that some people got elected for a political party they are not a member of.  In one case, a V-supporter wrote his own name on a SD-ballot and succeeded to get a seat representing a political party he hates.  It is one thing for a political party to win X seats in an election, another thing to fill those seats with supporters and a third thing to keep them loyal to the party for four years.  On county-level that last thing has become a huge problem for the governing majority here.  -- ( ) @ : That seems a pretty niche problem.  In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose.  Apply Pareto's Principle: in most cases, if someone says ""I'm a member of the Labour Party"", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party.  In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of ""Vote money, get monkey"".  Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor.  We can handle these kind of odd exceptions with other constructions rather than by deleting P102.  — ( ) @ : That somebody ""steals"" a seat in this manner is very unusual.  But that somebody ""represents"" a party they are not member of is more common than most of us think.  Sometimes you vote for a list of persons on a list with mixed persons.  They represents ""The conservatives"", but ""The conservatives"" is not a political party.  It is a technical cooperation between close related parties.  The voting-system here favours large parties at the cost of the small ones.  When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2.  List D got 3 seats, 2 to H and 1 independent.  When I moved here, SD had one seat in the local election, but no names could be found in the ballots.  The seat became empty. -- ( ) @ : (Failed to see your Q until now.) The relevant law is , which is a part of the Swedish constitution. Adding membership of political party into a database is definitely problematic. If I remember correctly, both the Security police and the have been caught doing this. And the only intension of this by the railway company was marketing toward group travellers. Not only membership of a political party can be problematics, but all records of political opinions. -- ( ) Frankly this is irrelevant for Wikidata.  That the Swedish national railway company is using political party affiliation as part of its marketing campaign is bad, but Wikidata is only storing political party preference for people who are either politicians standing for office, or notable people who have declared their party membership (plenty of celebrities and columnists describe how they are registered members of some party or the other).  In both cases, that is public information that has been published in a source.  Just the same as with data on religious belief, sexual orientation and so on.  — ( ) @ : That somebody is ""standing for office"" for a political party, does not prove that they are members of anything.  It still happens in local elections here that some people got elected for a political party they are not a member of.  In one case, a V-supporter wrote his own name on a SD-ballot and succeeded to get a seat representing a political party he hates.  It is one thing for a political party to win X seats in an election, another thing to fill those seats with supporters and a third thing to keep them loyal to the party for four years.  On county-level that last thing has become a huge problem for the governing majority here.  -- ( ) @ : That seems a pretty niche problem.  In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose.  Apply Pareto's Principle: in most cases, if someone says ""I'm a member of the Labour Party"", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party.  In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of ""Vote money, get monkey"".  Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor.  We can handle these kind of odd exceptions with other constructions rather than by deleting P102.  — ( ) @ : That somebody ""steals"" a seat in this manner is very unusual.  But that somebody ""represents"" a party they are not member of is more common than most of us think.  Sometimes you vote for a list of persons on a list with mixed persons.  They represents ""The conservatives"", but ""The conservatives"" is not a political party.  It is a technical cooperation between close related parties.  The voting-system here favours large parties at the cost of the small ones.  When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2.  List D got 3 seats, 2 to H and 1 independent.  When I moved here, SD had one seat in the local election, but no names could be found in the ballots.  The seat became empty. -- ( ) Frankly this is irrelevant for Wikidata.  That the Swedish national railway company is using political party affiliation as part of its marketing campaign is bad, but Wikidata is only storing political party preference for people who are either politicians standing for office, or notable people who have declared their party membership (plenty of celebrities and columnists describe how they are registered members of some party or the other).  In both cases, that is public information that has been published in a source.  Just the same as with data on religious belief, sexual orientation and so on.  — ( ) @ : That somebody is ""standing for office"" for a political party, does not prove that they are members of anything.  It still happens in local elections here that some people got elected for a political party they are not a member of.  In one case, a V-supporter wrote his own name on a SD-ballot and succeeded to get a seat representing a political party he hates.  It is one thing for a political party to win X seats in an election, another thing to fill those seats with supporters and a third thing to keep them loyal to the party for four years.  On county-level that last thing has become a huge problem for the governing majority here.  -- ( ) @ : That seems a pretty niche problem.  In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose.  Apply Pareto's Principle: in most cases, if someone says ""I'm a member of the Labour Party"", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party.  In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of ""Vote money, get monkey"".  Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor.  We can handle these kind of odd exceptions with other constructions rather than by deleting P102.  — ( ) @ : That somebody ""steals"" a seat in this manner is very unusual.  But that somebody ""represents"" a party they are not member of is more common than most of us think.  Sometimes you vote for a list of persons on a list with mixed persons.  They represents ""The conservatives"", but ""The conservatives"" is not a political party.  It is a technical cooperation between close related parties.  The voting-system here favours large parties at the cost of the small ones.  When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2.  List D got 3 seats, 2 to H and 1 independent.  When I moved here, SD had one seat in the local election, but no names could be found in the ballots.  The seat became empty. -- ( ) @ : That somebody is ""standing for office"" for a political party, does not prove that they are members of anything.  It still happens in local elections here that some people got elected for a political party they are not a member of.  In one case, a V-supporter wrote his own name on a SD-ballot and succeeded to get a seat representing a political party he hates.  It is one thing for a political party to win X seats in an election, another thing to fill those seats with supporters and a third thing to keep them loyal to the party for four years.  On county-level that last thing has become a huge problem for the governing majority here.  -- ( ) @ : That seems a pretty niche problem.  In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose.  Apply Pareto's Principle: in most cases, if someone says ""I'm a member of the Labour Party"", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party.  In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of ""Vote money, get monkey"".  Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor.  We can handle these kind of odd exceptions with other constructions rather than by deleting P102.  — ( ) @ : That somebody ""steals"" a seat in this manner is very unusual.  But that somebody ""represents"" a party they are not member of is more common than most of us think.  Sometimes you vote for a list of persons on a list with mixed persons.  They represents ""The conservatives"", but ""The conservatives"" is not a political party.  It is a technical cooperation between close related parties.  The voting-system here favours large parties at the cost of the small ones.  When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2.  List D got 3 seats, 2 to H and 1 independent.  When I moved here, SD had one seat in the local election, but no names could be found in the ballots.  The seat became empty. -- ( ) @ : That seems a pretty niche problem.  In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose.  Apply Pareto's Principle: in most cases, if someone says ""I'm a member of the Labour Party"", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party.  In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of ""Vote money, get monkey"".  Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor.  We can handle these kind of odd exceptions with other constructions rather than by deleting P102.  — ( ) @ : That somebody ""steals"" a seat in this manner is very unusual.  But that somebody ""represents"" a party they are not member of is more common than most of us think.  Sometimes you vote for a list of persons on a list with mixed persons.  They represents ""The conservatives"", but ""The conservatives"" is not a political party.  It is a technical cooperation between close related parties.  The voting-system here favours large parties at the cost of the small ones.  When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2.  List D got 3 seats, 2 to H and 1 independent.  When I moved here, SD had one seat in the local election, but no names could be found in the ballots.  The seat became empty. -- ( ) @ : That somebody ""steals"" a seat in this manner is very unusual.  But that somebody ""represents"" a party they are not member of is more common than most of us think.  Sometimes you vote for a list of persons on a list with mixed persons.  They represents ""The conservatives"", but ""The conservatives"" is not a political party.  It is a technical cooperation between close related parties.  The voting-system here favours large parties at the cost of the small ones.  When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2.  List D got 3 seats, 2 to H and 1 independent.  When I moved here, SD had one seat in the local election, but no names could be found in the ballots.  The seat became empty. -- ( ) There are really two slightly different concepts wrapped up together here — a person choosing to be a (paying / voting / supporting) member of a political party (which can be an entirely private matter, but which some people make public: e.g. being a member of ), and an elected politician holding office as a representative of a party. Most of the uses of seem to be the latter, but I suspect it would be better to have that as a qualifier on instead (which would also better handle the cases where someone holds two different offices simultaneously on behalf of two different parties), leaving free for the former — and which would then probably be so infrequent as to be moved to per the suggestion. -- ( ) Oppose Is it really a good idea to delete more specific properties and link to general properties.  I don't see the reason.  The more specific properties allow us to have the redundancy that is necessary to catch outliers/errors.  In some instances any queries (SPARQL) will be simplier when we have specific properties.  We also have .  Should this property then also be deleted?  — ( ) Oppose -- ( ) Oppose This is more specific and that other one is quite generic.  This one is much needed to identify which side then lean.  ( ) Keep divided from any other looking-like properities gives more concrete data.  - ( ) Keep Seems a reasonable subproperty of P463.  Privacy concerns are no more reasonable than those that could be presented for religious affiliation, sexual orientation etc.  — ( ) Keep .  We should also have one such property for the one might belong to.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P448:   consensus to delete -- ( ) consensus to delete -- ( ) Delete - launch point for a spacecraft is always the starting point for its journey so I support this merge ( ) Delete per my comment on -- ( ) Delete per Pasleim for the use of .  ( ) Keep - launch point is a subproperty of starting point, the constraints are different are therefore is very useful to keep it.  — Delete I agree this is unnecessarily duplicative.  ( ) Keep , for spacecraft is located somewhere on manufacturing company territory.  Usually it is very far from launch pad.  — ( ) Delete ( ) Delete .  Keeping separate properties just so we can have different constraints seems very odd.  Delete - ( ) Comment Could someone please provide links to where the projects using this property have been informed?  - ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P969_(P969):   no consensus to change datatype -- ( ) no consensus to change datatype -- ( ) This should not be deleted, until a new property has been created, and data migrated.  Process for this should be made clear somewhere, on the Project Chat I have been told the first step for this is to propose the deletion.  Requests and procedures on Wikidata seem to be all over the place and very unorganized.  ( ) Process for this should be made clear somewhere, on the Project Chat I have been told the first step for this is to propose the deletion.  Requests and procedures on Wikidata seem to be all over the place and very unorganized.  ( ) I do not favour the deletion of this property and its replacement with the alternate proposed property.  This property is simple and easy for the addition of a general street address to qualify a birth or death location, and additional components just complicates for no expressed benefit.   — There looks to have been an update to the label so that it now reflects the proposal.  Can it be closed as unactioned?   — There looks to have been an update to the label so that it now reflects the proposal.  Can it be closed as unactioned?   — ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  World_Health_Organisation_international_non-proprietary_name_numeric_ID_(P3350):   consensus to keep -- ( ) consensus to keep -- ( ) Keep please check the property proposal discussion before making these recommendations - in this case see .  This is an ID vs the other property which is a name, this was known when it was proposed.  ( ) Delete I see, thanks for the clarification.  Still the property holds exactly 0 instances and points to the wrong subject item.  -- ( ) Comment it was created just last month.  If it's still not used in February, I think we should double-check it.  --- Keep as per ArthurPSmith.  These are not the same thing.  Frankly, seems like a better candidate for deletion.  The ID indexes into their database and provides (among other things) all the names.  So this is basically a for disambiguation (i.e., ).  The names themselves should likely just be entered as aliases on our own items.  Keep .  Question These IDs are assigned by the WHO or the FDA?  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  designated_as_terrorist_by_(P3461):   No consensus to delete.  (Pigsonthewing); ; No consensus to delete.  (Pigsonthewing); ; Delete this is only used once (and as GZWDer points out, on an organization not a person, so P31 is fine) - ( ) Note: This was only created on 15 January 2017.  Keep .  At least two reasons: first, is used as an inherent property, whatever the following statements; history shows very clearly the qualification as ""terrorist"" strongly depends of who, what and why ( is by ), more than the intrinsic nature of thing.  Second, should be use with a bunch of such as , , ... without P3461 this data were qualifiers of a qualifier.  ( ) Keep per Kumkum's persuasive reasoning.  ( ) Keep per Kumkum.  It's very important that we don't combine properties that record a POV with those that record statement of fact.  ( ) ###Output: ",0
keep,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P546:   no consensus to delete -- ( ) no consensus to delete -- ( ) Keep ""docking port"" is more equivalent to the particular gate at a terminal that an aircraft uses, and I don't think you would ever assign that using 'via'.  If there's another analogous property then I wouldn't object to merging, but I don't see these two as being anywhere close to equivalent.  ( ) Ok, I agree is a good choice here.  Fine with deleting P546 in that case.  ( ) Ok, I agree is a good choice here.  Fine with deleting P546 in that case.  ( ) Delete but I prefer not to use but instead .  A spaceflight has many key events, and it's excessive to create for each possible event a new property.  On I demonstrated a while ago how this could work.  had two docking ports.  With the current approach you don't know which port was served first and during which time they were served.  Because there are a handful more properties describing key events of the spaceflight, it's in addition hard to extract a timeline of the flight.  With we gain a better overview and can model the whole journey.  -- ( ) Delete per Pasleim for the use of . ( ) Keep per my comment on — Delete per Pasleim. -- ( ) Keep , and are too generic for effective usage.  — ( ) Keep seems to be in use.  --- ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P2656:   consensus to delete -- ( ) consensus to delete -- ( ) Delete as I believe this should simplify things a little.  However, there are hundreds of P2656 entries now, so first they should be migrated to the alternate format?  ( ) I have added the latest ranking without the property to all national men teams.  For example, see --> . ( ) I have added the latest ranking without the property to all national men teams. For example, see --> .  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P2837:   Closing as Delete.  -- Closing as Delete. -- Wrong datatype, should be integer, not quantity.  --- Delete - no idea what Jura's referring to; it looks like is already being used on the months where they are described as subclasses so the data is there.  I really don't think it is helpful to have a property like this that is entirely wikidata-internal and applies to only 12 items, there have to be other ways to do it.  I would question the creation process on this one.  ( ) RE: ""applies to only 12 items"".  You are aware such properties as never can have very widespread usage!  -- ( ) RE: ""applies to only 12 items"". You are aware such properties as never can have very widespread usage! -- ( ) @ : during the property proposal, you mentioned that this property could be used by a (non-existent) script by me.  As I don't plan to use this property, are there any other application where it is needed?  -- ( ) The property talk page links to a series of queries .. it works, but it would work better once integer datatype is available. Once it's available, I think we should convert it. --- Why can't you use the qualifier on for the month instead of having a separate property?  ( ) Probably I'm just too weak with SPARQL or too slow to get it done in 30"". Maybe you manage to re-write the query on . --- @ : I rewrote that query such that it doesn't need -- ( ) Thanks. I like the way you did the sections. BTW, it times out for me. Will we get integer-datatype anytime soon? --- The ticket for the integer datatype is . It doesn't seem we will get it  soon. -- ( ) The property talk page links to a series of queries .. it works, but it would work better once integer datatype is available. Once it's available, I think we should convert it. --- Why can't you use the qualifier on for the month instead of having a separate property? ( ) Probably I'm just too weak with SPARQL or too slow to get it done in 30"".  Maybe you manage to re-write the query on .  --- @ : I rewrote that query such that it doesn't need -- ( ) Thanks.  I like the way you did the sections.  BTW, it times out for me.  Will we get integer-datatype anytime soon?  --- The ticket for the integer datatype is . It doesn't seem we will get it  soon. -- ( ) Why can't you use the qualifier on for the month instead of having a separate property?  ( ) Probably I'm just too weak with SPARQL or too slow to get it done in 30"". Maybe you manage to re-write the query on . --- @ : I rewrote that query such that it doesn't need -- ( ) Thanks. I like the way you did the sections. BTW, it times out for me. Will we get integer-datatype anytime soon? --- The ticket for the integer datatype is . It doesn't seem we will get it  soon. -- ( ) Probably I'm just too weak with SPARQL or too slow to get it done in 30"".  Maybe you manage to re-write the query on .  --- @ : I rewrote that query such that it doesn't need -- ( ) Thanks.  I like the way you did the sections.  BTW, it times out for me.  Will we get integer-datatype anytime soon?  --- The ticket for the integer datatype is . It doesn't seem we will get it  soon. -- ( ) @ : I rewrote that query such that it doesn't need -- ( ) Thanks.  I like the way you did the sections.  BTW, it times out for me.  Will we get integer-datatype anytime soon?  --- The ticket for the integer datatype is . It doesn't seem we will get it  soon. -- ( ) Thanks.  I like the way you did the sections.  BTW, it times out for me.  Will we get integer-datatype anytime soon?  --- The ticket for the integer datatype is . It doesn't seem we will get it  soon. -- ( ) The ticket for the integer datatype is .  It doesn't seem we will get it  soon.  -- ( ) Delete I don't see any further use cases of this property which couldn't be solved with . -- ( ) The change brought the query closer to time-out limit.  I restored the use of this property.  This should be converted to integer datatype once available.  --- The change brought the query closer to time-out limit.  I restored the use of this property.  This should be converted to integer datatype once available.  --- Keep Given that there are probably many queries where it makes sense to look at this property and it increases the speed of those queries, I'm okay with keeping the property. ( ) Delete , little need. ( ) Delete complicating properties for minor performance benefit of querries? No. ( ) Can you illustrate what you think is complicated ? --- It's actually the opposite: it avoids using a qualifier on the somewhat random statement.  --- Can you illustrate what you think is complicated ? --- It's actually the opposite: it avoids using a qualifier on the somewhat random statement.  --- Delete In use ≠ cannot be deleted, we can just mark it as DEPRECATED, find a migration way and finally (i.e. migration is done) delete it. -- ( ) This is a horrible hack but I can vote keep if somebody can show me a query where using this bespoke property leads to substantial SPARQL performance savings.  (I mean, is also a horrible hack that gave crazy computational savings.) @ , : Can you give me two example queries that search for the same thing, but one uses the Wikidata month number hack and the other doesn't?  ( ) One example is the above mentioned database report for people who died on their birthday .  I ran the query 10 times with and without the use of P2837 by preventing loading results from cache.  On average, running time of the query with P2837 was 34.5s, without P2837 it was 38,1s.  -- ( ) @ : Hmmm... I wouldn't call that significant advantage. I'd say it needs to shorten the time taken to execute a certain class of queries by a factor of 2 to be worth having a property. Delete . ( ) The problem is that it's just today's value. These things keep timing out and there isn't actually a downside in having the property. --- But if we take Pasleim's results as typical, there would be very few occasions on which using this hack would make the difference between timing out and not timing out.  ( ) If it was 28s instead of 32s would you think it should be kept?  --- No I don't think so.  If it was 16s vs 32s it would convince me, but 28s vs 32s isn't that significant.  A 10-20% difference in runtime can be wiped out quite easily by a coincidental change in the backend algorithm.  ( ) It was significant when the property was created.  Timeout was at 30s and using this property made it possible.  Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random.  I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place.  --- One example is the above mentioned database report for people who died on their birthday . I ran the query 10 times with and without the use of P2837 by preventing loading results from cache. On average, running time of the query with P2837 was 34.5s, without P2837 it was 38,1s. -- ( ) @ : Hmmm...  I wouldn't call that significant advantage.  I'd say it needs to shorten the time taken to execute a certain class of queries by a factor of 2 to be worth having a property.  Delete .  ( ) The problem is that it's just today's value.  These things keep timing out and there isn't actually a downside in having the property.  --- But if we take Pasleim's results as typical, there would be very few occasions on which using this hack would make the difference between timing out and not timing out. ( ) If it was 28s instead of 32s would you think it should be kept? --- No I don't think so.  If it was 16s vs 32s it would convince me, but 28s vs 32s isn't that significant.  A 10-20% difference in runtime can be wiped out quite easily by a coincidental change in the backend algorithm.  ( ) It was significant when the property was created.  Timeout was at 30s and using this property made it possible.  Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random.  I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place.  --- @ : Hmmm... I wouldn't call that significant advantage. I'd say it needs to shorten the time taken to execute a certain class of queries by a factor of 2 to be worth having a property. Delete . ( ) The problem is that it's just today's value. These things keep timing out and there isn't actually a downside in having the property. --- But if we take Pasleim's results as typical, there would be very few occasions on which using this hack would make the difference between timing out and not timing out.  ( ) If it was 28s instead of 32s would you think it should be kept?  --- No I don't think so.  If it was 16s vs 32s it would convince me, but 28s vs 32s isn't that significant.  A 10-20% difference in runtime can be wiped out quite easily by a coincidental change in the backend algorithm.  ( ) It was significant when the property was created.  Timeout was at 30s and using this property made it possible.  Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random.  I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place.  --- The problem is that it's just today's value. These things keep timing out and there isn't actually a downside in having the property. --- But if we take Pasleim's results as typical, there would be very few occasions on which using this hack would make the difference between timing out and not timing out.  ( ) If it was 28s instead of 32s would you think it should be kept?  --- No I don't think so.  If it was 16s vs 32s it would convince me, but 28s vs 32s isn't that significant.  A 10-20% difference in runtime can be wiped out quite easily by a coincidental change in the backend algorithm.  ( ) It was significant when the property was created.  Timeout was at 30s and using this property made it possible.  Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random.  I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place.  --- But if we take Pasleim's results as typical, there would be very few occasions on which using this hack would make the difference between timing out and not timing out. ( ) If it was 28s instead of 32s would you think it should be kept? --- No I don't think so.  If it was 16s vs 32s it would convince me, but 28s vs 32s isn't that significant.  A 10-20% difference in runtime can be wiped out quite easily by a coincidental change in the backend algorithm.  ( ) It was significant when the property was created.  Timeout was at 30s and using this property made it possible.  Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random.  I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place.  --- If it was 28s instead of 32s would you think it should be kept? --- No I don't think so.  If it was 16s vs 32s it would convince me, but 28s vs 32s isn't that significant.  A 10-20% difference in runtime can be wiped out quite easily by a coincidental change in the backend algorithm.  ( ) It was significant when the property was created.  Timeout was at 30s and using this property made it possible.  Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random.  I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place.  --- No I don't think so.  If it was 16s vs 32s it would convince me, but 28s vs 32s isn't that significant.  A 10-20% difference in runtime can be wiped out quite easily by a coincidental change in the backend algorithm.  ( ) It was significant when the property was created.  Timeout was at 30s and using this property made it possible.  Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random.  I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place.  --- It was significant when the property was created. Timeout was at 30s and using this property made it possible. Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random. I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place. --- Delete Old property.  I prefer generic properties.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  eFlora_properties:   no support for deletion -- ( ) no support for deletion -- ( ) http://www.efloras.org/florataxon.aspx? flora_id=1&taxon_id=$1 http://www.efloras.org/florataxon.aspx? flora_id=2&taxon_id=$1                     Because that's the format used by the target website; and because, as shown above, it gives the best results.  And just as in many other properties, such as and .  Oh, and , whose formatter URL is http://www.ipni.org/ipni/idPlantNameSearch.do? id=$1 and .  Assuming you are responding to my question: A search by id is not documented at the , but a search by Latin Name : The formatter URL used for IPNI is a search by id and results in a single record.  -- ( ) This is not the forum to complain about deficiencies in the documentation on the eFlora website; contact details for such purposes may be found on that site. The formatter URL I gave above is also a a search by id and results in a single record; helpfully that record has links pointing to the 20+ (in my example) other records that eFlora holds for the taxon. ROFL, Mr. Mabbett. -- ( ) Assuming you are responding to my question: A search by id is not documented at the , but a search by Latin Name : The formatter URL used for IPNI is a search by id and results in a single record.  A search by id is not documented at the , but a search by Latin Name : The formatter URL used for IPNI is a search by id and results in a single record.  -- ( ) This is not the forum to complain about deficiencies in the documentation on the eFlora website; contact details for such purposes may be found on that site. The formatter URL I gave above is also a a search by id and results in a single record; helpfully that record has links pointing to the 20+ (in my example) other records that eFlora holds for the taxon. ROFL, Mr. Mabbett. -- ( ) This is not the forum to complain about deficiencies in the documentation on the eFlora website; contact details for such purposes may be found on that site.  The formatter URL I gave above is also a a search by id and results in a single record; helpfully that record has links pointing to the 20+ (in my example) other records that eFlora holds for the taxon.  ROFL, Mr. Mabbett.  -- ( ) ROFL, Mr. Mabbett. -- ( ) This proposal reduces, rather than increasing, complexity (one property rather than 20+; one value on an item, rather than 20+ identical values).  No evidence to support the assertion that it would ""make it much more difficult to edit an item"" has been offered.  Also, I found this quote, on the proposal discussion for P1727: . ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P134_(P134):   consensus for deletion but property should be kept until external users switched to -- ( ) consensus for deletion but property should be kept until external users switched to -- ( ) Support I agree with the logic, and this also seems in line with common sense about referencing: ""A is a dialect of B"" is what you'd mostly expect.  ( ) Support I think so, having will be redundant.  Also, it's information that should be on the dialects items (through ), not in the main item.  -- Delete ( ) Delete . -- ( ) Delete provided ""dialect of"" is created first and appropriate jobs are run to transfer the data before deletion.  - ( ) Delete has good replacement.  -- ( ) Delete ( ) Delete or Keep , so long as we only have one property, per my comments at . Weak oppose . I agree that ""[subject] is a dialect of [object]"" is the more useful property, but ""[subject] has dialect(s) [object]"" is useful for infoboxes about languages too. I weakly prefer to have both, but if the consensus is that there can only be one I would rather have the new ""is dialect of"" property. ( ) Delete after creation of ""dialect of"" and transfer of data -- ( ) Delete or Keep per Andy.  ( ) @ : thanks for the reminder!  (the skull is kind of scary though!).  Although there seems to be a consensus for deletion here, it is still not clear if creation of the reverse property is going to happen as has marked the property as not ready.  So notifying the Wikipedias might be premature?  I don't know.  − ( ) Notifications made: ""has_dialect""_to_""dialect_of""_property − ( ) Notifications made: ""has_dialect""_to_""dialect_of""_property  ""has_dialect""_to_""dialect_of""_property − ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P2439:   consensus to delete — ( ) consensus to delete — ( ) Comment There isn't much benefit in combining language of works with languages of names.  was meant to cover this and uses of could be moved there.  The main problem with P2439 is its label.  It tends to be used for anything and the way the language is associated with an item is even less clear (I think Pasleim did quite a lot of cleaning up these days).  We haven't even sorted this out for books yet . .  --- Delete This is just redundant and not-well-defined.  If we need a new language property (do we?), let's make a new proposal with arguments pro and against.  ( ) Delete Unlike which is still controversial based on films, this property even doesn't have any criteria.  -- ( ) Delete But only if it is merged with and if is relabelled ""language"". ( ) Delete per Snipre. ❪ ❫ Delete Will be more clear this way. -- ( ) Keep .  this proprerty . -- ( ) @ : I don't understand your argument. Can you please explain? -- ( ) @ : maybe Arbnos is trying to explain why replace this property by is not OK, so how do you judge this case?  -- ( ) I see that the claim on was changed from to . This seems appropriate, therefore will not be affected from this proposal here. -- ( ) @ : I don't understand your argument.  Can you please explain?  -- ( ) @ : maybe Arbnos is trying to explain why replace this property by is not OK, so how do you judge this case? -- ( ) I see that the claim on was changed from to .  This seems appropriate, therefore will not be affected from this proposal here.  -- ( ) @ : maybe Arbnos is trying to explain why replace this property by is not OK, so how do you judge this case? -- ( ) I see that the claim on was changed from to .  This seems appropriate, therefore will not be affected from this proposal here.  -- ( ) I see that the claim on was changed from to . This seems appropriate, therefore will not be affected from this proposal here. -- ( ) Keep per Arbnos/Matěj Suchánek.  Use this for names going forward.  --- @ : Attention please: Matěj Suchánek is voted delete above, so one of your ""per"" is invalid, would you please pick another user's comment, or just drop that ""field value""? -- ( ) Comment think about it, I'm sure you will figure it out.  --- @ : Attention please: Matěj Suchánek is voted delete above, so one of your ""per"" is invalid, would you please pick another user's comment, or just drop that ""field value""? -- ( ) Comment think about it, I'm sure you will figure it out.  --- Delete a confusing property. -- Delete confusing property - and rename -- ( ) Delete . I don't get what all those language properties are trying to do. ( ) Delete . Consensus can change and it seems that can now be merged back into , now that we have to take care of the subset of cases where some consider it useful to have a more niche property. ( ) Delete ""per Jura"". @ : I can not find any project which is currently using . -- ( ) Thanks .  - can you please check , ?  - can you please check ?  - can you please check ?  in general - please try to mention in the property talk page that modules/templates are using properties so if/when they are getting merged wikidata users can let you know.  Thanks, ( ) - done.  — shouldn't be affected.  P2439 is used there only as one of several options, including P407.  As soon as P2439 is removed, it will disappear from the module as well, but no functionality will be lost.  ( ) For French, @ : this guy can tell me a lot.  -- @ : You just cited me, but I don't know for what ! Unfortunately, I cannot even ping you correctly to get a reply from you because you were connected only by your IP, unless you are still connected with this IP and you visit this wiki rapidly afer my edit here. ( ) @ : The French WP templates don't use anylonger this property, so to my best knowledge this property isn't used anymore on any Wikimedia site. -- ( ) : thanks for pinging.  This was widely used property, so I think it would be best to verify it with wbc_entity_usage table, but here are few other few existing usages that should be updated: , , - please go over - - - // - ( ) Comment For Finnish, pinging @ : would better.  -- ( ) Already removed from the fiwiki modules by Pasleim.  ( ) Thanks .  - can you please check , ?  - can you please check ?  - can you please check ?  - can you please check , ?  - can you please check ?  - can you please check ?  in general - please try to mention in the property talk page that modules/templates are using properties so if/when they are getting merged wikidata users can let you know.  Thanks, ( ) - done.  — shouldn't be affected.  P2439 is used there only as one of several options, including P407.  As soon as P2439 is removed, it will disappear from the module as well, but no functionality will be lost.  ( ) For French, @ : this guy can tell me a lot.  -- @ : You just cited me, but I don't know for what ! Unfortunately, I cannot even ping you correctly to get a reply from you because you were connected only by your IP, unless you are still connected with this IP and you visit this wiki rapidly afer my edit here. ( ) @ : The French WP templates don't use anylonger this property, so to my best knowledge this property isn't used anymore on any Wikimedia site. -- ( ) : thanks for pinging.  This was widely used property, so I think it would be best to verify it with wbc_entity_usage table, but here are few other few existing usages that should be updated: , , - please go over - - - // - ( ) Comment For Finnish, pinging @ : would better.  -- ( ) Already removed from the fiwiki modules by Pasleim.  ( ) - done.  — shouldn't be affected.  P2439 is used there only as one of several options, including P407.  As soon as P2439 is removed, it will disappear from the module as well, but no functionality will be lost.  ( ) For French, @ : this guy can tell me a lot.  -- @ : You just cited me, but I don't know for what ! Unfortunately, I cannot even ping you correctly to get a reply from you because you were connected only by your IP, unless you are still connected with this IP and you visit this wiki rapidly afer my edit here. ( ) @ : The French WP templates don't use anylonger this property, so to my best knowledge this property isn't used anymore on any Wikimedia site. -- ( ) : thanks for pinging.  This was widely used property, so I think it would be best to verify it with wbc_entity_usage table, but here are few other few existing usages that should be updated: , , - please go over - - - // - ( ) Comment For Finnish, pinging @ : would better.  -- ( ) Already removed from the fiwiki modules by Pasleim. ( ) shouldn't be affected. P2439 is used there only as one of several options, including P407. As soon as P2439 is removed, it will disappear from the module as well, but no functionality will be lost. ( ) For French, @ : this guy can tell me a lot. -- @ : You just cited me, but I don't know for what !  Unfortunately, I cannot even ping you correctly to get a reply from you because you were connected only by your IP, unless you are still connected with this IP and you visit this wiki rapidly afer my edit here.  ( ) @ : The French WP templates don't use anylonger this property, so to my best knowledge this property isn't used anymore on any Wikimedia site.  -- ( ) : thanks for pinging.  This was widely used property, so I think it would be best to verify it with wbc_entity_usage table, but here are few other few existing usages that should be updated: , , - please go over - - - // - ( ) Comment For Finnish, pinging @ : would better.  -- ( ) Already removed from the fiwiki modules by Pasleim. ( ) @ : You just cited me, but I don't know for what ! Unfortunately, I cannot even ping you correctly to get a reply from you because you were connected only by your IP, unless you are still connected with this IP and you visit this wiki rapidly afer my edit here. ( ) @ : The French WP templates don't use anylonger this property, so to my best knowledge this property isn't used anymore on any Wikimedia site. -- ( ) : thanks for pinging.  This was widely used property, so I think it would be best to verify it with wbc_entity_usage table, but here are few other few existing usages that should be updated: , , - please go over - - - // - ( ) Comment For Finnish, pinging @ : would better.  -- ( ) Already removed from the fiwiki modules by Pasleim. ( ) @ : The French WP templates don't use anylonger this property, so to my best knowledge this property isn't used anymore on any Wikimedia site. -- ( ) : thanks for pinging.  This was widely used property, so I think it would be best to verify it with wbc_entity_usage table, but here are few other few existing usages that should be updated: , , - please go over - - - // - ( ) Comment For Finnish, pinging @ : would better.  -- ( ) Already removed from the fiwiki modules by Pasleim.  ( ) : thanks for pinging.  This was widely used property, so I think it would be best to verify it with wbc_entity_usage table, but here are few other few existing usages that should be updated: , , - please go over - - - // - , , - please go over - - - // - ( ) Comment For Finnish, pinging @ : would better.  -- ( ) Already removed from the fiwiki modules by Pasleim. ( ) Comment For Finnish, pinging @ : would better. -- ( ) Already removed from the fiwiki modules by Pasleim.  ( ) Already removed from the fiwiki modules by Pasleim.  ( ) is now removed from .  -- ( ) It is now also gone from and . Thanks, this simplifies things. ( ) @ : Can you have again  a look if this property is still somewhere in use? -- ( ) Wd modules: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :/@ :: , @ :: , @ :: , @ :: Other: @ :: , , , ) @ :: ( ) Removed from .  -- ( ) Removed from . Thanks for the notice. Chinese done: . -- ( ) Removed from .  -- ( ) Note: Modules with the name ""Wd"" won't actually break when the property is gone. Yet it is cleaner to remove it from the modules, of course. Simplest way to do this is to update to the latest version of and submodules. ( ) sqwiki done -- ( ) @ : Can you have again  a look if this property is still somewhere in use?  -- ( ) Wd modules: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :/@ :: , @ :: , @ :: , @ :: Other: @ :: , , , ) @ :: ( ) Removed from . -- ( ) Removed from .  Thanks for the notice.  Chinese done: .  -- ( ) Removed from . -- ( ) Note: Modules with the name ""Wd"" won't actually break when the property is gone.  Yet it is cleaner to remove it from the modules, of course.  Simplest way to do this is to update to the latest version of and submodules.  ( ) sqwiki done -- ( ) Wd modules: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :/@ :: , @ :: , @ :: , @ :: Other: @ :: , , , ) @ :: Wd modules: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :/@ :: , @ :: , @ :: , @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :: @ :/@ :: , @ :: , @ :: , @ :: Other: @ :: , , , ) @ :: @ :: , , , ) @ :: ( ) Removed from . -- ( ) Removed from .  Thanks for the notice.  Chinese done: .  -- ( ) Removed from . -- ( ) Removed from .  -- ( ) Removed from . Thanks for the notice. Chinese done: . -- ( ) Removed from .  -- ( ) Removed from . Thanks for the notice. Chinese done: . -- ( ) Removed from .  -- ( ) Chinese done: . -- ( ) Removed from .  -- ( ) Removed from . -- ( ) Note: Modules with the name ""Wd"" won't actually break when the property is gone.  Yet it is cleaner to remove it from the modules, of course.  Simplest way to do this is to update to the latest version of and submodules.  ( ) sqwiki done -- ( ) sqwiki done -- ( ) ###Output: ",2
keep,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P1103:   No consensus.  Feel free to start another discussion or request later.  ( ) No consensus.  Feel free to start another discussion or request later.  ( ) Keep so fix it, deleting it won't solve the problem.  ( ) @ : The problem is that because the data is polluted and half the labels are still wrong, we don't really know if the values are correct.  I suppose all the values could be gone through (this would have to be done manually for all of them) and the labels redone.  ( ) I also have to say Keep : I don't think it's clear what is intended to happen if we were to decide on ""delete"".  Some people are talking about how to store the data (whether to keep this property or use different ones), other people are talking about whether to keep the existing data for this property, and I wouldn't be surprised if someone started talking about whether we want to store this data at all.  Unless we decide we do not want to store this data at all, the data will need checking at some point.  If we delete what we have and start again, it will need checking as it's re-added, therefore I don't think deleting it is very productive.  We should focus instead on finding ways to verify what we have and what people will add in the future.  It shouldn't be that hard to check the labels, identify which ones need fixing and then ping speakers of those languages.  As for the data, I'm only familiar with Germany and the UK (which happen to account for over half of the uses of this property).  Information about German stations is available as open data and the National Rail site has maps of UK stations so the data for those two shouldn't be difficult to verify (although maybe a bit tedious if it can't be automated).  Other countries may have similar resources available.  I think you are probably overestimating the scale of the problem.  I would expect the majority of stations to be small and straightforward stations which produce the same number whether you're counting the right thing or not (e.g. single track plus single platform or two tracks plus two side platforms).  In the UK, smaller stations with islands are likely to accidentally produce the right number too.  In Germany, it's normal to talk about tracks rather than platforms, so those are also likely to be correct.  - ( ) @ : So how do we actually fix those error values?  Do you have a line map on it?  -- ( ) @ : Sorry, I got halfway through replying before being distracted by other things.  I would propose the following: Wait for this discussion to be closed (if the decision is to delete it, there's no point trying to fix it).  Check and fix the labels and descriptions on the property.  This could be done by creating a new section on the property talk page and pinging speakers of those languages.  If there are any which can't be verified after a period of time, remove those until someone who speaks the language can check/fix them.  Check the existing statements with references to make sure those are correct (there aren't many, from what I remember).  Find sources we can use to check the rest of the statements.  I already mentioned knowing of sources for the UK and Germany.  Italy is the next biggest one.  Check the statements against the sources and add references to the ones which have been verified.  How we check the data depends on the sources, some can be automated, others will have to be done by hand.  Decide what to do with the statements which can't be verified.  Not really 7th, it can be done at any point: Discuss somewhere else (on ?) other ways of counting and how we should model those.  Since my last comment, I've checked most of the UK ones.  Over 1500 are correct and about 100 need further investigation for a variety of reasons (not all of them are wrong).  I'm not sure how to add the references though, I think it might need a bot.  - ( ) @ : For China, #4 could be very hard to define because of my comments below.  -- ( ) @ : Note that even stations in London can also have confusing values on platform e.g. - Nástupišť (hran): 20 (+4 neužívaná) - Nifer o blatfformau: 19 - Perronspor: 19 - Number of platforms: 24 (22 in use) (you say that 22 is ""correct"") - Raiteisto: 24 laituriraidetta - Voies: 19 - רציפים בשימוש: 22 - Vágányok száma: 22 - ホーム数: 20 - პლატფორმების რაოდ. : 8 - Perrons: 20 - Plattform(er): 19 - Liczba peronów: 19 - Plataforma: 20 - Количество платформ: 24 - Number of platforms: 20 - Počet nástupíšť: 19 - Antal spår: 20 (+4 oanvända) - Platformlar: 24 - Кількість платформ: 19 - 站台數: 24（22個使用中） @ : The problem is that because the data is polluted and half the labels are still wrong, we don't really know if the values are correct.  I suppose all the values could be gone through (this would have to be done manually for all of them) and the labels redone.  ( ) I also have to say Keep : I don't think it's clear what is intended to happen if we were to decide on ""delete"".  Some people are talking about how to store the data (whether to keep this property or use different ones), other people are talking about whether to keep the existing data for this property, and I wouldn't be surprised if someone started talking about whether we want to store this data at all.  Unless we decide we do not want to store this data at all, the data will need checking at some point.  If we delete what we have and start again, it will need checking as it's re-added, therefore I don't think deleting it is very productive.  We should focus instead on finding ways to verify what we have and what people will add in the future.  It shouldn't be that hard to check the labels, identify which ones need fixing and then ping speakers of those languages.  As for the data, I'm only familiar with Germany and the UK (which happen to account for over half of the uses of this property).  Information about German stations is available as open data and the National Rail site has maps of UK stations so the data for those two shouldn't be difficult to verify (although maybe a bit tedious if it can't be automated).  Other countries may have similar resources available.  I think you are probably overestimating the scale of the problem.  I would expect the majority of stations to be small and straightforward stations which produce the same number whether you're counting the right thing or not (e.g. single track plus single platform or two tracks plus two side platforms).  In the UK, smaller stations with islands are likely to accidentally produce the right number too.  In Germany, it's normal to talk about tracks rather than platforms, so those are also likely to be correct.  - ( ) @ : So how do we actually fix those error values?  Do you have a line map on it?  -- ( ) @ : Sorry, I got halfway through replying before being distracted by other things.  I would propose the following: Wait for this discussion to be closed (if the decision is to delete it, there's no point trying to fix it).  Check and fix the labels and descriptions on the property.  This could be done by creating a new section on the property talk page and pinging speakers of those languages.  If there are any which can't be verified after a period of time, remove those until someone who speaks the language can check/fix them.  Check the existing statements with references to make sure those are correct (there aren't many, from what I remember).  Find sources we can use to check the rest of the statements.  I already mentioned knowing of sources for the UK and Germany.  Italy is the next biggest one.  Check the statements against the sources and add references to the ones which have been verified.  How we check the data depends on the sources, some can be automated, others will have to be done by hand.  Decide what to do with the statements which can't be verified.  Not really 7th, it can be done at any point: Discuss somewhere else (on ?) other ways of counting and how we should model those.  Since my last comment, I've checked most of the UK ones.  Over 1500 are correct and about 100 need further investigation for a variety of reasons (not all of them are wrong).  I'm not sure how to add the references though, I think it might need a bot.  - ( ) @ : For China, #4 could be very hard to define because of my comments below.  -- ( ) @ : Note that even stations in London can also have confusing values on platform e.g. - Nástupišť (hran): 20 (+4 neužívaná) - Nifer o blatfformau: 19 - Perronspor: 19 - Number of platforms: 24 (22 in use) (you say that 22 is ""correct"") - Raiteisto: 24 laituriraidetta - Voies: 19 - רציפים בשימוש: 22 - Vágányok száma: 22 - ホーム数: 20 - პლატფორმების რაოდ. : 8 - Perrons: 20 - Plattform(er): 19 - Liczba peronów: 19 - Plataforma: 20 - Количество платформ: 24 - Number of platforms: 20 - Počet nástupíšť: 19 - Antal spår: 20 (+4 oanvända) - Platformlar: 24 - Кількість платформ: 19 - 站台數: 24（22個使用中） I also have to say Keep : I don't think it's clear what is intended to happen if we were to decide on ""delete"".  Some people are talking about how to store the data (whether to keep this property or use different ones), other people are talking about whether to keep the existing data for this property, and I wouldn't be surprised if someone started talking about whether we want to store this data at all.  Unless we decide we do not want to store this data at all, the data will need checking at some point.  If we delete what we have and start again, it will need checking as it's re-added, therefore I don't think deleting it is very productive.  We should focus instead on finding ways to verify what we have and what people will add in the future.  It shouldn't be that hard to check the labels, identify which ones need fixing and then ping speakers of those languages.  As for the data, I'm only familiar with Germany and the UK (which happen to account for over half of the uses of this property).  Information about German stations is available as open data and the National Rail site has maps of UK stations so the data for those two shouldn't be difficult to verify (although maybe a bit tedious if it can't be automated).  Other countries may have similar resources available.  I think you are probably overestimating the scale of the problem.  I would expect the majority of stations to be small and straightforward stations which produce the same number whether you're counting the right thing or not (e.g. single track plus single platform or two tracks plus two side platforms).  In the UK, smaller stations with islands are likely to accidentally produce the right number too.  In Germany, it's normal to talk about tracks rather than platforms, so those are also likely to be correct.  I don't think it's clear what is intended to happen if we were to decide on ""delete"".  Some people are talking about how to store the data (whether to keep this property or use different ones), other people are talking about whether to keep the existing data for this property, and I wouldn't be surprised if someone started talking about whether we want to store this data at all.  Unless we decide we do not want to store this data at all, the data will need checking at some point.  If we delete what we have and start again, it will need checking as it's re-added, therefore I don't think deleting it is very productive.  We should focus instead on finding ways to verify what we have and what people will add in the future.  It shouldn't be that hard to check the labels, identify which ones need fixing and then ping speakers of those languages.  As for the data, I'm only familiar with Germany and the UK (which happen to account for over half of the uses of this property).  Information about German stations is available as open data and the National Rail site has maps of UK stations so the data for those two shouldn't be difficult to verify (although maybe a bit tedious if it can't be automated).  Other countries may have similar resources available.  I think you are probably overestimating the scale of the problem.  I would expect the majority of stations to be small and straightforward stations which produce the same number whether you're counting the right thing or not (e.g. single track plus single platform or two tracks plus two side platforms).  In the UK, smaller stations with islands are likely to accidentally produce the right number too.  In Germany, it's normal to talk about tracks rather than platforms, so those are also likely to be correct.  - ( ) @ : So how do we actually fix those error values?  Do you have a line map on it?  -- ( ) @ : Sorry, I got halfway through replying before being distracted by other things.  I would propose the following: Wait for this discussion to be closed (if the decision is to delete it, there's no point trying to fix it).  Check and fix the labels and descriptions on the property.  This could be done by creating a new section on the property talk page and pinging speakers of those languages.  If there are any which can't be verified after a period of time, remove those until someone who speaks the language can check/fix them.  Check the existing statements with references to make sure those are correct (there aren't many, from what I remember).  Find sources we can use to check the rest of the statements.  I already mentioned knowing of sources for the UK and Germany.  Italy is the next biggest one.  Check the statements against the sources and add references to the ones which have been verified.  How we check the data depends on the sources, some can be automated, others will have to be done by hand.  Decide what to do with the statements which can't be verified.  Not really 7th, it can be done at any point: Discuss somewhere else (on ?) other ways of counting and how we should model those.  Since my last comment, I've checked most of the UK ones.  Over 1500 are correct and about 100 need further investigation for a variety of reasons (not all of them are wrong).  I'm not sure how to add the references though, I think it might need a bot.  - ( ) @ : For China, #4 could be very hard to define because of my comments below.  -- ( ) @ : Note that even stations in London can also have confusing values on platform e.g. - Nástupišť (hran): 20 (+4 neužívaná) - Nifer o blatfformau: 19 - Perronspor: 19 - Number of platforms: 24 (22 in use) (you say that 22 is ""correct"") - Raiteisto: 24 laituriraidetta - Voies: 19 - רציפים בשימוש: 22 - Vágányok száma: 22 - ホーム数: 20 - პლატფორმების რაოდ. : 8 - Perrons: 20 - Plattform(er): 19 - Liczba peronów: 19 - Plataforma: 20 - Количество платформ: 24 - Number of platforms: 20 - Počet nástupíšť: 19 - Antal spår: 20 (+4 oanvända) - Platformlar: 24 - Кількість платформ: 19 - 站台數: 24（22個使用中） @ : So how do we actually fix those error values?  Do you have a line map on it?  -- ( ) @ : Sorry, I got halfway through replying before being distracted by other things.  I would propose the following: Wait for this discussion to be closed (if the decision is to delete it, there's no point trying to fix it).  Check and fix the labels and descriptions on the property.  This could be done by creating a new section on the property talk page and pinging speakers of those languages.  If there are any which can't be verified after a period of time, remove those until someone who speaks the language can check/fix them.  Check the existing statements with references to make sure those are correct (there aren't many, from what I remember).  Find sources we can use to check the rest of the statements.  I already mentioned knowing of sources for the UK and Germany.  Italy is the next biggest one.  Check the statements against the sources and add references to the ones which have been verified.  How we check the data depends on the sources, some can be automated, others will have to be done by hand.  Decide what to do with the statements which can't be verified.  Not really 7th, it can be done at any point: Discuss somewhere else (on ?) other ways of counting and how we should model those.  Since my last comment, I've checked most of the UK ones.  Over 1500 are correct and about 100 need further investigation for a variety of reasons (not all of them are wrong).  I'm not sure how to add the references though, I think it might need a bot.  - ( ) @ : For China, #4 could be very hard to define because of my comments below.  -- ( ) @ : Note that even stations in London can also have confusing values on platform e.g. - Nástupišť (hran): 20 (+4 neužívaná) - Nifer o blatfformau: 19 - Perronspor: 19 - Number of platforms: 24 (22 in use) (you say that 22 is ""correct"") - Raiteisto: 24 laituriraidetta - Voies: 19 - רציפים בשימוש: 22 - Vágányok száma: 22 - ホーム数: 20 - პლატფორმების რაოდ. : 8 - Perrons: 20 - Plattform(er): 19 - Liczba peronów: 19 - Plataforma: 20 - Количество платформ: 24 - Number of platforms: 20 - Počet nástupíšť: 19 - Antal spår: 20 (+4 oanvända) - Platformlar: 24 - Кількість платформ: 19 - 站台數: 24（22個使用中） @ : Sorry, I got halfway through replying before being distracted by other things.  I would propose the following: Wait for this discussion to be closed (if the decision is to delete it, there's no point trying to fix it).  Check and fix the labels and descriptions on the property.  This could be done by creating a new section on the property talk page and pinging speakers of those languages.  If there are any which can't be verified after a period of time, remove those until someone who speaks the language can check/fix them.  Check the existing statements with references to make sure those are correct (there aren't many, from what I remember).  Find sources we can use to check the rest of the statements.  I already mentioned knowing of sources for the UK and Germany.  Italy is the next biggest one.  Check the statements against the sources and add references to the ones which have been verified.  How we check the data depends on the sources, some can be automated, others will have to be done by hand.  Decide what to do with the statements which can't be verified.  Not really 7th, it can be done at any point: Discuss somewhere else (on ?) other ways of counting and how we should model those.  Wait for this discussion to be closed (if the decision is to delete it, there's no point trying to fix it).  Check and fix the labels and descriptions on the property.  This could be done by creating a new section on the property talk page and pinging speakers of those languages.  If there are any which can't be verified after a period of time, remove those until someone who speaks the language can check/fix them.  Check the existing statements with references to make sure those are correct (there aren't many, from what I remember).  Find sources we can use to check the rest of the statements.  I already mentioned knowing of sources for the UK and Germany.  Italy is the next biggest one.  Check the statements against the sources and add references to the ones which have been verified.  How we check the data depends on the sources, some can be automated, others will have to be done by hand.  Decide what to do with the statements which can't be verified.  Not really 7th, it can be done at any point: Discuss somewhere else (on ?) other ways of counting and how we should model those.  Since my last comment, I've checked most of the UK ones.  Over 1500 are correct and about 100 need further investigation for a variety of reasons (not all of them are wrong).  I'm not sure how to add the references though, I think it might need a bot.  - ( ) @ : For China, #4 could be very hard to define because of my comments below.  -- ( ) @ : Note that even stations in London can also have confusing values on platform e.g. - Nástupišť (hran): 20 (+4 neužívaná) - Nifer o blatfformau: 19 - Perronspor: 19 - Number of platforms: 24 (22 in use) (you say that 22 is ""correct"") - Raiteisto: 24 laituriraidetta - Voies: 19 - רציפים בשימוש: 22 - Vágányok száma: 22 - ホーム数: 20 - პლატფორმების რაოდ. : 8 - Perrons: 20 - Plattform(er): 19 - Liczba peronów: 19 - Plataforma: 20 - Количество платформ: 24 - Number of platforms: 20 - Počet nástupíšť: 19 - Antal spår: 20 (+4 oanvända) - Platformlar: 24 - Кількість платформ: 19 - 站台數: 24（22個使用中） @ : For China, #4 could be very hard to define because of my comments below.  -- ( ) @ : Note that even stations in London can also have confusing values on platform e.g. - Nástupišť (hran): 20 (+4 neužívaná) - Nifer o blatfformau: 19 - Perronspor: 19 - Number of platforms: 24 (22 in use) (you say that 22 is ""correct"") - Raiteisto: 24 laituriraidetta - Voies: 19 - רציפים בשימוש: 22 - Vágányok száma: 22 - ホーム数: 20 - პლატფორმების რაოდ. : 8 - Perrons: 20 - Plattform(er): 19 - Liczba peronów: 19 - Plataforma: 20 - Количество платформ: 24 - Number of platforms: 20 - Počet nástupíšť: 19 - Antal spår: 20 (+4 oanvända) - Platformlar: 24 - Кількість платформ: 19 - 站台數: 24（22個使用中） @ : Some cases are more complicated and will need qualifiers.  I didn't say that 22 is the right number, it's one of the ones which needs more investigation.  It seems that 19 and 24 are correct for the total number (at different times), 19, 20 and 22 are correct for the number in use (at different times) and the sitelink for kawiki was on the wrong item.  - ( ) @ : Unfortunatelly your solutions haven't explain what to do for , that's my key concern.  In stations, the ""physical"" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different.  So.  e.g. which should be the ""correct"" value of ?  5?  But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of ""5"" is unavailable.  3?  that's number of tracks, and one of ""3"" is available for two lines.  4?  So articles in all 3 languages are saying wrong values.  -- ( ) @ : Would a solution like « delete after data fixing » would do the trick ?  A kind of deprecation.  This lacks ous current workflow.  @ : Some cases are more complicated and will need qualifiers.  I didn't say that 22 is the right number, it's one of the ones which needs more investigation.  It seems that 19 and 24 are correct for the total number (at different times), 19, 20 and 22 are correct for the number in use (at different times) and the sitelink for kawiki was on the wrong item.  - ( ) @ : Unfortunatelly your solutions haven't explain what to do for , that's my key concern.  In stations, the ""physical"" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different.  So.  e.g. which should be the ""correct"" value of ?  5?  But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of ""5"" is unavailable.  3?  that's number of tracks, and one of ""3"" is available for two lines.  4?  So articles in all 3 languages are saying wrong values.  -- ( ) @ : Some cases are more complicated and will need qualifiers.  I didn't say that 22 is the right number, it's one of the ones which needs more investigation.  It seems that 19 and 24 are correct for the total number (at different times), 19, 20 and 22 are correct for the number in use (at different times) and the sitelink for kawiki was on the wrong item.  - ( ) @ : Unfortunatelly your solutions haven't explain what to do for , that's my key concern.  In stations, the ""physical"" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different.  So.  e.g. which should be the ""correct"" value of ?  5?  But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of ""5"" is unavailable.  3?  that's number of tracks, and one of ""3"" is available for two lines.  4?  So articles in all 3 languages are saying wrong values.  -- ( ) @ : Some cases are more complicated and will need qualifiers.  I didn't say that 22 is the right number, it's one of the ones which needs more investigation.  It seems that 19 and 24 are correct for the total number (at different times), 19, 20 and 22 are correct for the number in use (at different times) and the sitelink for kawiki was on the wrong item.  - ( ) @ : Unfortunatelly your solutions haven't explain what to do for , that's my key concern.  In stations, the ""physical"" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different.  So.  e.g. which should be the ""correct"" value of ?  5?  But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of ""5"" is unavailable.  3?  that's number of tracks, and one of ""3"" is available for two lines.  4?  So articles in all 3 languages are saying wrong values.  -- ( ) @ : Some cases are more complicated and will need qualifiers.  I didn't say that 22 is the right number, it's one of the ones which needs more investigation.  It seems that 19 and 24 are correct for the total number (at different times), 19, 20 and 22 are correct for the number in use (at different times) and the sitelink for kawiki was on the wrong item.  - ( ) @ : Unfortunatelly your solutions haven't explain what to do for , that's my key concern.  In stations, the ""physical"" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different.  So.  e.g. which should be the ""correct"" value of ?  5?  But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of ""5"" is unavailable.  3?  that's number of tracks, and one of ""3"" is available for two lines.  4?  So articles in all 3 languages are saying wrong values.  -- ( ) @ : Some cases are more complicated and will need qualifiers.  I didn't say that 22 is the right number, it's one of the ones which needs more investigation.  It seems that 19 and 24 are correct for the total number (at different times), 19, 20 and 22 are correct for the number in use (at different times) and the sitelink for kawiki was on the wrong item.  - ( ) @ : Unfortunatelly your solutions haven't explain what to do for , that's my key concern.  In stations, the ""physical"" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different.  So.  e.g. which should be the ""correct"" value of ?  5?  But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of ""5"" is unavailable.  3?  that's number of tracks, and one of ""3"" is available for two lines.  4?  So articles in all 3 languages are saying wrong values.  -- ( ) @ : Unfortunatelly your solutions haven't explain what to do for , that's my key concern.  In stations, the ""physical"" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different.  So.  e.g. which should be the ""correct"" value of ?  5?  But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of ""5"" is unavailable.  3?  that's number of tracks, and one of ""3"" is available for two lines.  4?  So articles in all 3 languages are saying wrong values.  -- ( ) @ : Would a solution like « delete after data fixing » would do the trick ? A kind of deprecation. This lacks ous current workflow. Delete By reading that archived proposal I kindly agree what Pigsonthewing said, in the future we can say with qualifier , with qualifier , with qualifier , etc. I really don't know where's the example which the total number of platforms can't just be numbers of Q2735706+Q2725290+Q877472+... -- ( ) @ : As Thryduulf stated in the prior discussion: some stations (UK, Taiwan, etc.) have independently signallable A/B platforms on the same face, stations in different parts of the world number platforms differently, and so on.  I think several more items/properties might need to be created for those (has part → platform number?), but for most stations should suffice.  ( ) @ : use instead.  This discriminates specified parts (parts for which we have actual items, for the white house for example) from unspecified ones (the whitehouse has wings).  @ : As Thryduulf stated in the prior discussion: some stations (UK, Taiwan, etc.) have independently signallable A/B platforms on the same face, stations in different parts of the world number platforms differently, and so on.  I think several more items/properties might need to be created for those (has part → platform number?), but for most stations should suffice.  ( ) @ : use instead.  This discriminates specified parts (parts for which we have actual items, for the white house for example) from unspecified ones (the whitehouse has wings).  Keep , I am not a fan of ""use this very generic property with this obscure item/qualifier combo"".  Useful property.  ( ) @ : I'd personally prefer to have separate properties for the seven or so ways to count platforms, but the problem remains that this property is not defined correctly in all languages and the data is inconsistent.  If the property is to be kept, the data should ideally be reviewed (or wiped and re-imported) for each rail system where the property is in use.  ( ) @ , : anyway, the de facto usage of this property on stations of China is also confusing due to local usage of where: @ : I'd personally prefer to have separate properties for the seven or so ways to count platforms, but the problem remains that this property is not defined correctly in all languages and the data is inconsistent.  If the property is to be kept, the data should ideally be reviewed (or wiped and re-imported) for each rail system where the property is in use.  ( ) @ , : anyway, the de facto usage of this property on stations of China is also confusing due to local usage of where: Also, this property should NOT be used at stations of Singapore and Malaysia (at least until the fully solutions of platform-related property usage is documented) because of the significant huge number of usage.  -- ( ) Also, this property should NOT be used at stations of Singapore and Malaysia (at least until the fully solutions of platform-related property usage is documented) because of the significant huge number of usage.  -- ( ) ( ) ( ) 21:38, 2 November 2013 (UTC) ( • • )-- 01:13, 3 November 2013 (UTC) (was Hym411) ( ) 06:32, 3 November 2013 (UTC) ( ) 08:28, 9 November 2013 (UTC) ( ) 12:36, 9 November 2013 (UTC) ( ) ( ) 13:59, 25 November 2013 (UTC) ( ) 12:31, 14 December 2013 (UTC) ( ) 21:48, 17 December 2013 (UTC) ( ) 16:30, 14 February 2014 (UTC) 17:39, 17 August 2014 (UTC) ( ) 21:34, 30 August 2015 (UTC) ( ) 16:13, 9 December 2015 (UTC) 18:39, 26 June 2016 (UTC) 22:48, 8 July 2016 (UTC) ( ) 07:32, 15 August 2016 (UTC) ( ) 16:36, 5 September 2016 (UTC) ( | ) 01:33, 10 November 2016 (UTC) ( ) 23:00, 1 February 2017 (UTC) ( ) 09:09, 2 February 2017 (UTC) ( ) 18:17, 21 May 2017 (UTC) ( ) 13:56, 9 June 2017 (UTC) 10:26, 18 June 2017 (UTC) ( ) 05:01, 28 August 2017 (UTC) ( ) 06:04, 22 September 2017 (UTC) ( ) 17:48, 3 June 2018 (UTC) ( ) 23:51, 13 July 2018 (UTC) ( ) 19:29, 17 December 2018 (UTC) ( ) 13:13, 21 May 2019 (UTC) ( ) 00:25, 1 May 2020 (UTC) ( ) 14:20, 26 July 2020 (UTC) ( ) 18:47, 30 July 2020 (UTC) ( ) 15:21, 29 August 2020 (UTC) ( ) 22:04, 20 December 2020 (UTC) ( ) 16:27, 5 September 2021 (UTC) ( ) 07:46, 3 September 2022 (UTC) ( ) 05:17, 14 October 2022 (UTC) ( ) 09:49, 10 August 2023 (UTC) ( ) 09:08, 07 September 2023 (UTC) 16:16, 21 November 2023 (UTC) ( ) 07:02, 16 December 2023 (UTC) ( ) 14:06, 15 May 2024 (UTC) ( ) 14:41, 31 May 2024 (UTC) ( ) 17:52, 4 August 2024 (UTC) ( ) Notified -- ( ) Delete or deprecate .  It's not defined which of the many ways of counting platforms this is intended to represent, nor which of these ways any current use is using.  This means we can't correct the data as we don't even know what is correct, and even if we do decide on a definition there will be no way of verifying whether uses are correct to it without manually looking at plans of the given station - which has no benefit over entering data afresh.  ( ) Comment seems trivial, but each time I looked into this, it left me puzzled.  Maybe as qualifier is needed to state how one counts.  --- Keep Surely there is a confusion between number of platform tracks and number of platforms (even translations of are inconsistent), but in my opinion the solution is to create new number of platforms property and clarify existing data.  Both concepts are widely used in transport-related infoboxes in various languages. -- ( ) @ : Translations confusion can be minor issues, but sometimes it can be border than this problem, see e.g. : @ : Translations confusion can be minor issues, but sometimes it can be border than this problem, see e.g. : I (the value of ""站台面"") in the last year before something wrong, where @ : said: I (the value of ""站台面"") in the last year before something wrong, where @ : said: Oppose Per above, this property is already existing, you might want to request another property for the number of physical platforms. -- ( ) 09:01, 2 February 2017 (UTC) @ , : Updated the proposal to be for number of platform faces; should be updated because it still refers to ""number of platforms"".  did not realize data was taken from en-gb labels ( ) 08:14, 4 February 2017 (UTC) ( ) 14:54, 2 February 2017 (UTC) So I changed to Support , thx for patches of properties.  -- ( ) 13:30, 3 February 2017 (UTC) @ : However, I'm afraid that I already typed the values of ""站台面"" as P1103 value, so am I wrong now? Should I use ""站台数目"" instead now? -- ( ) 13:51, 3 February 2017 (UTC) @ : I think so, yes.  ( ) 08:17, 4 February 2017 (UTC) @ , : Updated the proposal to be for number of platform faces; should be updated because it still refers to ""number of platforms"".  did not realize data was taken from en-gb labels ( ) 08:14, 4 February 2017 (UTC) ( ) 14:54, 2 February 2017 (UTC) So I changed to Support , thx for patches of properties.  -- ( ) 13:30, 3 February 2017 (UTC) @ : However, I'm afraid that I already typed the values of ""站台面"" as P1103 value, so am I wrong now? Should I use ""站台数目"" instead now? -- ( ) 13:51, 3 February 2017 (UTC) @ : I think so, yes.  ( ) 08:17, 4 February 2017 (UTC) So I changed to Support , thx for patches of properties.  -- ( ) 13:30, 3 February 2017 (UTC) @ : However, I'm afraid that I already typed the values of ""站台面"" as P1103 value, so am I wrong now? Should I use ""站台数目"" instead now? -- ( ) 13:51, 3 February 2017 (UTC) @ : I think so, yes.  ( ) 08:17, 4 February 2017 (UTC) @ : I think so, yes.  ( ) 08:17, 4 February 2017 (UTC) Then I the value to 10 which means ""站台数目"", however when I saw other languages: - Bahnsteiggleise: 18 Bahnsteige - Platforms: 10 - Plataformas: 10 - Vágányok száma: 10 - ホーム: 10面20線 島式ホーム2面4線（地下鉄） - Liczba peronów: 10, Liczba krawędzi peronowych: 18 - Antal spår: 20, Nivåer: 4 - 股道数目: 20, 站台数目: 10个,  - 侧式站台: 2个,  - 岛式站台: 8个,  - 站台面: 18个 (note that huwiki 10 is because of my value changing) But if following the newest meaning of P1103 (number of tracks served by a platform at a railway station) it really should be 18 psst.  should be 22 as 18 (for CR(H?)) (should not be 20 because 2 tracks of this station are ) + 4 (for Beijing Subway).  -- ( ) Then I the value to 10 which means ""站台数目"", however when I saw other languages: - Bahnsteiggleise: 18 Bahnsteige - Platforms: 10 - Plataformas: 10 - Vágányok száma: 10 - ホーム: 10面20線 島式ホーム2面4線（地下鉄） - Liczba peronów: 10, Liczba krawędzi peronowych: 18 - Antal spår: 20, Nivåer: 4 - 股道数目: 20, 站台数目: 10个,  - 侧式站台: 2个,  - 岛式站台: 8个,  - 站台面: 18个 (note that huwiki 10 is because of my value changing) But if following the newest meaning of P1103 (number of tracks served by a platform at a railway station) it really should be 18 psst.  should be 22 as 18 (for CR(H?)) (should not be 20 because 2 tracks of this station are ) + 4 (for Beijing Subway).  -- ( ) Delete , per Liuxinyu970226, platform counting styles can always be different between countries, so this property can't reflect all countries. -- I was canvased by to change my opinion to delete.  The current label of the property is ""number of platform tracks"" with description ""number of tracks served by a platform at a railway station"".  What's difficult about this?  Take the number of tracks going through a train station (for example 8 for ) and deduct the tracks that don't have a platform (track 2 and 7 for Haarlem) and you get the result (6 for Haarlem).  So in some countries and languages people didn't stick to this definition.  Go mass remove the property there, but don't destroy the work for the people who did do it properly.  ( ) The original English label is ""number of platforms"".  The label was then changed without notifying translators to update the other labels.  If this property is kept, we have to delete all statements added after the English redefinition and stick to the -- ( ) Indeed, and @ : even we can only consider tracks and ignore any kinds of ""physical"" platforms, please be aware that most stations in rural areas of Southeast Asian countries don't have any possible ""platforms"", on the other hand, a random abandoned station is likely having no tracks anymore? So in both cases are you sure 0 is suitable? NO! Stations without physical platforms are still stations (at least still providing board and alight services), and stations with no tracks are still stations! -- ( ) If you don't know how to use it, don't use it instead of trying to get it deleted.  ( ) The original English label is ""number of platforms"".  The label was then changed without notifying translators to update the other labels.  If this property is kept, we have to delete all statements added after the English redefinition and stick to the -- ( ) Indeed, and @ : even we can only consider tracks and ignore any kinds of ""physical"" platforms, please be aware that most stations in rural areas of Southeast Asian countries don't have any possible ""platforms"", on the other hand, a random abandoned station is likely having no tracks anymore? So in both cases are you sure 0 is suitable? NO! Stations without physical platforms are still stations (at least still providing board and alight services), and stations with no tracks are still stations! -- ( ) If you don't know how to use it, don't use it instead of trying to get it deleted.  ( ) If you don't know how to use it, don't use it instead of trying to get it deleted.  ( ) Keep -- ( ) Keep . We can always argue about the definition of ""a platform"" or ""a platform track"" and there will be borderline cases whatever criterion we go with. Use qualifier or sources if fine distinctions need to be made. ( ) The problem is that there's no qualifier for the existing data, so we don't know how to interpret it. ❪ ❫ The vast majority of railway stations around the world have one track per platform. The definition of a ""platform"" also varies from station to station (e.g. most island platforms count as 2 platforms but there are exceptions), so we ought to allow some ambiguity in the way we record them on Wikidata. Wikimedia projects generally collect verifiable information from other sources and disambiguate as required, not impose our ontology onto the world's railway stations and force disambiguation upon information sourced from external sources. ( ) The problem is that there's no qualifier for the existing data, so we don't know how to interpret it. ❪ ❫ The vast majority of railway stations around the world have one track per platform. The definition of a ""platform"" also varies from station to station (e.g. most island platforms count as 2 platforms but there are exceptions), so we ought to allow some ambiguity in the way we record them on Wikidata. Wikimedia projects generally collect verifiable information from other sources and disambiguate as required, not impose our ontology onto the world's railway stations and force disambiguation upon information sourced from external sources. ( ) The vast majority of railway stations around the world have one track per platform. The definition of a ""platform"" also varies from station to station (e.g. most island platforms count as 2 platforms but there are exceptions), so we ought to allow some ambiguity in the way we record them on Wikidata. Wikimedia projects generally collect verifiable information from other sources and disambiguate as required, not impose our ontology onto the world's railway stations and force disambiguation upon information sourced from external sources. ( ) Comment This property has some 12000 uses. Some refer to platforms others to tracks. Some count platforms, but mean tracks. I don't quite see how this could be sorted out on the existing property in a reasonable way. Using a new way for each might work out. --- @ : The most big problem is, as I mentioned again and again above, the , this means that, if we decided to keep this property, then we should firstly judge stations that are having this kind of platforms ( , , , , , , , , , , , , , , , , , , , , ... should I point more examples?!).  -- ( ) @ : The most big problem is, as I mentioned again and again above, the , this means that, if we decided to keep this property, then we should firstly judge stations that are having this kind of platforms ( , , , , , , , , , , , , , , , , , , , , ... should I point more examples?!). -- ( ) Comment I applause the « has part / number » scheme, but the right property is .  Keep , describe with precision and correct errors.  I support reasons describes by @ :.  There are a lots of properties with very poor use and meaning description in their talk pages.  Usually, the english name is the only ""clue"" to understand what had in mind the creator when done; in addition, a bad translation (interpretation) of labels opens a missunderstanding that must be correct.  However, the destruction of the present situation without write down a new precise ""use of property handbook"" of the new solution will (re)produce -in some time- a similar problem.  Regarding solution « has part / has part of the type + number », I disagree because this generic properties increase the difficulty for ""getting users"" of WD, via query, via API or via WP module to build an infobox, for instance.  Is easier to have an specific data for an specific concept, and  leave these solutions for marginal situations not foreseen in the data model.  Now, I'm working in create a ""WD full powered infobox for stations"" and the data collection for this area of knowledge is not the best we have.  So, keep clear another conceptual inconsistences are prioritari to me than destroy the few content we have now.  Thanks.  ( ) Then this property should have which value?  If there's no criteria way that to be documented then @ : I suggest you to change your keep to delete because the Dutch translation means ""number of railway tracks"" which probably has way to mean ""of a railway line"", the Hungarian usage (currently only one usage) should be checked either @ , :.  -- Let my ask, what's the alternative property when we delete this one ?. I just say that, before delete, we all together must agree with a non ambigous definition and then, or create a new one property or redefine this one and clear  all content that doesn't match with the new definition. My concern is that some people think that deletion must solve the problem (it remind me a President that wanted to chop all forest to avoid the forest fires). I'm not defending present situation, I just want to avoid repeat the problem when someone else try to create a property to ""track lines"" or ""point to get the train"" or ""platform that can be show at display station"" or... or.... Thanks, ( ) Then this property should have which value? If there's no criteria way that to be documented then @ : I suggest you to change your keep to delete because the Dutch translation means ""number of railway tracks"" which probably has way to mean ""of a railway line"", the Hungarian usage (currently only one usage) should be checked either @ , :. -- Let my ask, what's the alternative property when we delete this one ? .  I just say that, before delete, we all together must agree with a non ambigous definition and then, or create a new one property or redefine this one and clear  all content that doesn't match with the new definition.  My concern is that some people think that deletion must solve the problem (it remind me a President that wanted to chop all forest to avoid the forest fires).  I'm not defending present situation, I just want to avoid repeat the problem when someone else try to create a property to ""track lines"" or ""point to get the train"" or ""platform that can be show at display station"" or... or....  Thanks, ( ) Let my ask, what's the alternative property when we delete this one ? .  I just say that, before delete, we all together must agree with a non ambigous definition and then, or create a new one property or redefine this one and clear  all content that doesn't match with the new definition.  My concern is that some people think that deletion must solve the problem (it remind me a President that wanted to chop all forest to avoid the forest fires).  I'm not defending present situation, I just want to avoid repeat the problem when someone else try to create a property to ""track lines"" or ""point to get the train"" or ""platform that can be show at display station"" or... or....  Thanks, ( ) Delete The current property is ambiguous within and between languages and inconsistently used to the point where it is not even possible to say what the correct value for any station more complicated than a single track adjacent to a single platform with a single signalling berth, let alone whether any particular value matches that.  The diagram illustrates just some of the problems, not showing bay platforms for example.  One aspect of the problem is that there are no standard, unambiguous terms for most of the different types of platform and almost no sources specify how the platforms are being counted.  It is not even standard between stations in the UK - Bristol Temple Meads uses the red numbering system, Birmingham New Street uses the blue system, Stratford isn't even consistent within itself (3/3A, 4A/4B and 11/11A are all different layouts).  The way forward is to hammer out what exactly we want to count and then figure out how to describe that, then figure out how to represent that in Wikidata, then figure out how to translate the data into that format.  The current property is not useful for any of that.  ( ) For the record, since it's been more than a year since I nominated this for deletion, if the property is deleted I would prefer to convert everything to statements indicating or (although another property might need to be created for platform numbers like 2A).  I think requiring it be done this way is a better solution, since it's clear (by this point, I hope) that for some reason there is no standard way to count platforms.  ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Quais_du_polar_writer_ID_(P5666):   consensus to keep -- ( ) consensus to keep -- ( ) a etais fait par @ : qu'il pourrait expliquer.  - ( ) @ , , : from the proposal discussion.  Keep : no serious reason to delete.  ( ) .  Keep .  Covers the biggest crime literature festival in France.  ( ) Keep ( ) ###Output: ",0
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P3113:   consensus to keep -- ( ) consensus to keep -- ( ) @ : how is it redundant to with a value of ""no value""?  Where do you indicate the value from the statement?  ( ) Keep Invalid reason, per ArthurPSmith ( ) Keep per ArthurPSmith.  ( ) @ , , : What would work however, and is equivalent, is to use Keep per ArthurPSmith.  @ : I don't think this is a good idea.  In my eyes wherever possible a mainsnak should also be valid without its qualifier, This proposal is actually dangerous since all querying without also querying the qualifier would get exactly the opposite of what is meant.  -- ( ) I tend to agree, that’s why I did not support the deletion proposal.  I guess we should put the constraints that the number of parts should be generally positive.  Wondering if we need « don’t has part of that type » but I don’t think so.  I tend to agree, that’s why I did not support the deletion proposal.  I guess we should put the constraints that the number of parts should be generally positive.  Wondering if we need « don’t has part of that type » but I don’t think so.  Keep I think it's very useful to be able to describe anatomically concepts exactly and ""no value"" doesn't do anything for those usecases.  ❪ ❫ Keep per ArthurPSmith... strakhov ( ) ###Output: ",2
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P3183: Created for such cases.   We should expect more cases like this in the future.  -- ( ) Keep. Created for such cases. We should expect more cases like this in the future.-- ( ) Comment You mean the formatter URL is broken?   That doesn't necessarily mean the identifier is invalid.   If there's more to this perhaps you can link to relevant documentation/discussion?   ( ) @ : WSJ seems to have discontinued the use of topical categories on its website so the formatter URL cannot be fixed at all.   This property is deprecated.   I have already linked the Engish Wikipedia discussion above.   ( ) @ : WSJ seems to have discontinued the use of topical categories on its website so the formatter URL cannot be fixed at all.   This property is deprecated.   I have already linked the Engish Wikipedia discussion above.   ( ) Delete if it was discontinued.   Doesn't really seem to be used (~100).   --- Delete Ok, I'll go along with that, seems not much point to keep it now. ( ) Keep Oh, really? I fixed it. Keep I don't see why we should delete a historic (at this point) identifier. Linking to the Wayback machine is a reasonable fix. I expect we will need to do this for many more external ID properties to come in the following years... -- ( ) Comment I don't know if we can mark a property as deprecated so that it doesn't show up in the suggestions anymore?   Users wanting to still add IDs could do so by pasting the property ID into the search box.   -- ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P1112_(P1112)_+_Pokémon_index_(P1685):   consensus to delete , no consensus on -- ( ) consensus to delete , no consensus on -- ( ) I initially wanted to answer with {{vote_keep}} because I think wikidata should also provide space for very specific types of data.  I like the approach you have with though.  Lets find something similar for 😀 -- ( ) Comment additional properties like this should not be created but this looks like a special exception. Pokémon seem to get sorted by this value in different lists. Before proposing a deletion we should come up with more detailed alternatives and examples. alone is not enough, how about the existing qualifiers? -- ( ) Comment The other property proposals seem to be .  --- P1112 is used for many different listings/catalogues (eg , ), using the unfortunate and ambiguous to distinguish between them (instead of ). The property is also much too specific, per ChristianKl. Using seems like a good solution and we can move/adapt the existing qualifiers. Delete . -- ( ) Question Do Pokemon items currently use for any other purpose?  Comment We should try not to break .  ( ) 20:43, 16 November 2017 (UTC) Nevermind.  That template is a sandbox and the use of Wikidata hasn't made its way to the actual sandbox yet.  ( ) Okay I figured out that no item currently uses both and : ...and it's all qualified using as discussed above: I agree with the proposal: Delete and migrate all to .  ( ) Withdrawing my support for deletion at the moment.  's discovery would mean that it's not possible to delete both and without breaking which uses both, until {{#statements:}} or develop further functionality to select statements with certain qualifier targets only.  ( ) Changing my mind again because I misunderstood the French template.  It's still in draft mode and the use of Wikidata hasn't made it to the actual template yet.  ( ) Okay I figured out that no item currently uses both and :  ...and it's all qualified using as discussed above:  I agree with the proposal: Delete and migrate all to .  ( ) Withdrawing my support for deletion at the moment.  's discovery would mean that it's not possible to delete both and without breaking which uses both, until {{#statements:}} or develop further functionality to select statements with certain qualifier targets only.  ( ) Changing my mind again because I misunderstood the French template.  It's still in draft mode and the use of Wikidata hasn't made it to the actual template yet.  ( ) Withdrawing my support for deletion at the moment.  's discovery would mean that it's not possible to delete both and without breaking which uses both, until {{#statements:}} or develop further functionality to select statements with certain qualifier targets only.  ( ) Changing my mind again because I misunderstood the French template.  It's still in draft mode and the use of Wikidata hasn't made it to the actual template yet.  ( ) Changing my mind again because I misunderstood the French template.  It's still in draft mode and the use of Wikidata hasn't made it to the actual template yet.  ( ) Comment - should also be included in this discussion, as it is essentially the same thing.  -- ( ) I've added P1685 (Pokemon browser number) to this. We should also migrate to . There is no conflict because Pokédex numbers and Pokémon Browser identifiers are in . ( ) I've added P1685 (Pokemon browser number) to this. We should also migrate to . There is no conflict because Pokédex numbers and Pokémon Browser identifiers are in . ( ) Keep In order to sustain consistency and integrity of data, property constraints of (moderately) specific properties are helpful. -- ( ) @ : Constraints on specific types of uses could still be made to work via .  -- ( ) @ : They will work, but the talk page of will become too complex for human to read and to maintain. Specific (sub)property solution is simple and clear. -- ( ) @ : There's no ""actual complex"" in so many property talk pages, if you think will even be complex, then will only be accessable by the Bitcoin mining machines.  -- ( ) When we have or other specific properties, we can describe most property constraints by using , independently of SPARQL language.  Hard-coded SPARQL queries in the complex constraints template reduce the maintainability in exchange for their high flexibility.  There is no necessity for us to lose the simple solution in .  should be just a subproperty of .  -- ( ) @ : Constraints on specific types of uses could still be made to work via . -- ( ) @ : They will work, but the talk page of will become too complex for human to read and to maintain.  Specific (sub)property solution is simple and clear.  -- ( ) @ : There's no ""actual complex"" in so many property talk pages, if you think will even be complex, then will only be accessable by the Bitcoin mining machines. -- ( ) When we have or other specific properties, we can describe most property constraints by using , independently of SPARQL language.  Hard-coded SPARQL queries in the complex constraints template reduce the maintainability in exchange for their high flexibility.  There is no necessity for us to lose the simple solution in .  should be just a subproperty of .  -- ( ) @ : They will work, but the talk page of will become too complex for human to read and to maintain. Specific (sub)property solution is simple and clear. -- ( ) @ : There's no ""actual complex"" in so many property talk pages, if you think will even be complex, then will only be accessable by the Bitcoin mining machines.  -- ( ) When we have or other specific properties, we can describe most property constraints by using , independently of SPARQL language.  Hard-coded SPARQL queries in the complex constraints template reduce the maintainability in exchange for their high flexibility.  There is no necessity for us to lose the simple solution in .  should be just a subproperty of .  -- ( ) @ : There's no ""actual complex"" in so many property talk pages, if you think will even be complex, then will only be accessable by the Bitcoin mining machines. -- ( ) When we have or other specific properties, we can describe most property constraints by using , independently of SPARQL language.  Hard-coded SPARQL queries in the complex constraints template reduce the maintainability in exchange for their high flexibility.  There is no necessity for us to lose the simple solution in .  should be just a subproperty of .  -- ( ) When we have or other specific properties, we can describe most property constraints by using , independently of SPARQL language.  Hard-coded SPARQL queries in the complex constraints template reduce the maintainability in exchange for their high flexibility.  There is no necessity for us to lose the simple solution in .  should be just a subproperty of .  -- ( ) I agree P1685 is too specific, however I agree with that a specific property for Pokédex number has major benefits for data integrity. How would you like to specify similar constraints with P642? -- ( ) Good bye as Pokedexes can also be different between series (don't surprise, PM anime also have characters that ruled different dexes), I can't see a neutral way to create a lot of properties in order to sync something that ≤1000 usages.  -- ( ) Comment I don't understand what's the problem with an unambiguous property used hundreds of times. It's very specific, and so? Personally, I don't have nothing against specific properties: are often more intuitive than broader ones and therefore they make it easier for new editor to contribute; can be linked with external properties as specific as them; can be linked with broader properties via ""subproperty of"" and so they don't cause any problem in the ontology; are easier to manage for Quickstatement, bots and other third party tools than qualifiers.-- ( ) are often more intuitive than broader ones and therefore they make it easier for new editor to contribute; can be linked with external properties as specific as them; can be linked with broader properties via ""subproperty of"" and so they don't cause any problem in the ontology; are easier to manage for Quickstatement, bots and other third party tools than qualifiers. -- ( ) @ , , , , , : I have written a script that will migrate these properties as and when we need it. Test runs: . ( ) While this looks fine, I don't see an example of where you migrated P1685. Furthermore, I still don't like the negative effects this migration has on data integrity, as we can't use effective constraints anymore. -- ( ) I think we can summarize the discussion so far: There is consensus that existing uses of as a qualifier to and should migrate to .  There is consensus that is too specific.  We should deprecate it.  We don't agree whether we should keep .  That leaves us with three possibilities: Keep both properties, do nothing (default outcome, but I think consensus is against this) Deprecate .  Specifically, move all / to / ; move all / to / Deprecate both and .  Move all / and / to / .  I personally prefer 3 > 2 > 1.  (Ping again.) ( ) 2 > 3 > 1 -- ( ) While this looks fine, I don't see an example of where you migrated P1685. Furthermore, I still don't like the negative effects this migration has on data integrity, as we can't use effective constraints anymore. -- ( ) I think we can summarize the discussion so far: There is consensus that existing uses of as a qualifier to and should migrate to .  There is consensus that is too specific.  We should deprecate it.  We don't agree whether we should keep .  That leaves us with three possibilities: Keep both properties, do nothing (default outcome, but I think consensus is against this) Deprecate .  Specifically, move all / to / ; move all / to / Deprecate both and .  Move all / and / to / .  I personally prefer 3 > 2 > 1.  (Ping again.) ( ) 2 > 3 > 1 -- ( ) I think we can summarize the discussion so far: There is consensus that existing uses of as a qualifier to and should migrate to . There is consensus that is too specific. We should deprecate it. We don't agree whether we should keep . That leaves us with three possibilities: Keep both properties, do nothing (default outcome, but I think consensus is against this) Deprecate . Specifically, move all / to / ; move all / to / Deprecate both and . Move all / and / to / . I personally prefer 3 > 2 > 1. (Ping again.) ( ) 2 > 3 > 1 -- ( ) There is consensus that existing uses of as a qualifier to and should migrate to .  There is consensus that is too specific.  We should deprecate it.  We don't agree whether we should keep .  That leaves us with three possibilities: Keep both properties, do nothing (default outcome, but I think consensus is against this) Deprecate .  Specifically, move all / to / ; move all / to / Deprecate both and .  Move all / and / to / .  I personally prefer 3 > 2 > 1.  (Ping again.) ( ) 2 > 3 > 1 -- ( ) Keep both properties, do nothing (default outcome, but I think consensus is against this) Deprecate . Specifically, move all / to / ; move all / to / Deprecate both and . Move all / and / to / . I personally prefer 3 > 2 > 1. (Ping again.) ( ) 2 > 3 > 1 -- ( ) 2 > 3 > 1 -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P4497_(P4497):   Deleted the Microsoft Store artist ID (P4497).  ( ) Deleted the Microsoft Store artist ID (P4497).  ( ) Delete looks like it anyway.  ( ) Delete not useful if closed ( ) Delete Per above, and it was barely used.  ( ) Keep While the website is no longer functional, there are thousands of IDs which can still be obtained due to having been saved in the Internet Archive.  It may be beneficial to keep this data in Wikidata, although there may not be much of a use case at the moment.  ( ) Keep per Jc86035.  Delete 9 uses as of today, 16 months after creation.  --- Delete ; unused so far, it won't be useful in the future. -- Delete .  Too few uses to justify keeping a historical identifier.  ( ) Delete not used and website closed.  -- Delete ; unused so far, it won't be useful in the future.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  LGDB_game_ID_(P5116):   consensus to keep -- ( ) consensus to keep -- ( ) Yeah, I always kept the hope :-( Too bad I did not create a Mix’n’match beforehand − it’s a bit of pain to do it via Internet Archive.  Regarding the property − I think current practice is to change the formatter URL to go to the Internet Archive.  ( ) I tagged the 4 LGDB properties with and added a preferred .  ( ) Looks like the Internet Archive did a fairly good job: Games: ; Emulators: ; Tools: ; Engines: .  ( ) I tagged the 4 LGDB properties with and added a preferred .  ( ) Looks like the Internet Archive did a fairly good job: Games: ; Emulators: ; Tools: ; Engines: .  ( ) Looks like the Internet Archive did a fairly good job: Games: ; Emulators: ; Tools: ; Engines: .  Games: ; Emulators: ; Tools: ; Engines: .  ( ) Keep And - as a meta issue - please can we stop having deletion discussions for identifiers which are no longer issued, but still exist in archives?  Keep I 10000% agree with Pigsonthewing said, plus we should refrain from PFDing for properties that ""met copyright problems"".  -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  X_numeric_user_ID_(P6552):   consensus to keep -- ( ) consensus to keep -- ( ) In what way is it inconsistent?  ( ) Proposal discussion is at: .  Creation by seems perfectly correct.  The sole objection was from Jura1, who wrote only ""Oppose adding both"" with no rationale; and did not give an answer when asked why.  There were four supporters, in addition to the proposer.  Proposal discussion is at: .  Creation by seems perfectly correct.  The sole objection was from Jura1, who wrote only ""Oppose adding both"" with no rationale; and did not give an answer when asked why.  There were four supporters, in addition to the proposer.  Keep , but use only as a qualifier to P2002 (or perhaps vice versa).  Keep .  Not a valid rationale in my view.  ( ) Keep ; the username itself is still useful information.  ( ) Comment @ : It seems that the actual ""we"" are confusing many pro/con lists of both properties, can we please restructure both as one section, to discuss both P2002 and P6552?  -- ( ) Keep Useful because a Twitter user may rename their account, but having a log of the name used has value.  Also there is a known pattern where users will archive their accounts by renaming their account and then creating a new account with the original username.  Having both the username and user id numbers allows us to track this.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P1946_(P1946):   consensus to delete -- ( ) consensus to delete -- ( ) Delete based on the discussion on the property talk page it looks like this has never worked and is simply not a valid id. ( ) There are currently 16,501 uses of this property.  Is the proposal to simply discard that data?  Can nothing be salvaged?  I don't know how much can be salvaged, but .  When the Property example on the property page is incorrect , there is a serious problem.  ( ) @ :, as far as I can tell from the talk page, this property's existence in VIAF has  a) no connection whatsoever with the website data and  b) is really just a mirror of the LCC data anyway.  ( ) In that case, Delete .  I don't know how much can be salvaged, but .  When the Property example on the property page is incorrect , there is a serious problem.  ( ) @ :, as far as I can tell from the talk page, this property's existence in VIAF has  a) no connection whatsoever with the website data and  b) is really just a mirror of the LCC data anyway.  ( ) In that case, Delete .  In that case, Delete .  Delete The very example on the property page is incorrect, and since almost all records are being added based on VIAF records which seem to reflect no actual ID in use at the Library, this is essentially unsalvageable.  ( ) I don't have a vote either way, though I'm edging toward keep.  I originally proposed this based on the data that the library was feeding to VIAF.  It is still feeding that data and they are still digitizing their indices (according to their website).  I think it stands to reason that if a library is actively creating identifiers and giving this data to VIAF that the numbers have meaning and likely use in the future, even if they don't link to anything today.  ( ) @ : Have you looked at the talk page for the property?  Here's what someone who actually asked the NLI wtf was going on got for an answer: ""The VTLS files [prob. referring to software and not any standard] where added to VIAF as a test in 2014 and they had not been able to do any further things with them afterwards. The bibliographical records currently linked do share the same VTLS ID, but are totally independent from the authority record. No correlation whatsoever. The authority record linked in VIAF is correct, but it is not actually a record created by the NLI, it is a downloaded record from the Library of Congress authorities server. So basically a copy of the data with a new number in their own VTLS system.""  They will never ""have meaning"" and they are not actively either ""creating identifiers"" nor ""giving this data to VIAF"", because they're not adding anything further from the original data dump, which was never their data to begin with, but a mirror of LCC authorities.  ( ) Nope.  I wasn't actively following this on the talk page.  All I knew was that there had been new VTLS numbers on VIAF since two years ago.  Probably just evidence of linking on VIAF side then which I took as NLI linking them.  If that's the case then I vote delete as well.  ( ) @ : Have you looked at the talk page for the property?  Here's what someone who actually asked the NLI wtf was going on got for an answer: ""The VTLS files [prob. referring to software and not any standard] where added to VIAF as a test in 2014 and they had not been able to do any further things with them afterwards. The bibliographical records currently linked do share the same VTLS ID, but are totally independent from the authority record. No correlation whatsoever. The authority record linked in VIAF is correct, but it is not actually a record created by the NLI, it is a downloaded record from the Library of Congress authorities server. So basically a copy of the data with a new number in their own VTLS system.""  They will never ""have meaning"" and they are not actively either ""creating identifiers"" nor ""giving this data to VIAF"", because they're not adding anything further from the original data dump, which was never their data to begin with, but a mirror of LCC authorities.  ( ) Nope.  I wasn't actively following this on the talk page.  All I knew was that there had been new VTLS numbers on VIAF since two years ago.  Probably just evidence of linking on VIAF side then which I took as NLI linking them.  If that's the case then I vote delete as well.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  business_division_(P199):   consensus to keep -- ( ) consensus to keep -- ( ) Delete I've never been sure when to use one or the other, and generally have just used .  Also the inverse property makes having two of these complicated.  ( ) Keep Distinction is clear, for separate legal entity, for something else.  Concept for legal entity does not vary from country to country so much.  But I admit that distinction between and is not well described at the moment and even constraint violations are not set completely properly.  I can fix that.  Note that both and are currently used in multiple infoboxes at multiple wikis, so cleary there is a demand to distinct these two.  For inverse properties I use for and for . -- ( ) Ok, that's a reasonable argument. ( ) @ : The current English description doesn't seem to highlite the fact that it's for a separate legal entity. Maybe, we need to change the description to make that more clear? ❪ ❫ Ok, that's a reasonable argument. ( ) @ : The current English description doesn't seem to highlite the fact that it's for a separate legal entity. Maybe, we need to change the description to make that more clear? ❪ ❫ Keep If these are currently used inconsistently, that should be fixed, but they are distinct concepts. -- ( ) Comment I have fixed the English descriptions, examples and constraint violations. -- ( ) Keep ❪ ❫ ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P6779:   deleted by Sannita.  -- ( ) deleted by Sannita. -- ( ) Comment @ : not sure ot understand, for an identifier the license doesn't usually matter (the database can be fully copyrighted, you still have the right to point to this database).  Cheers, ( ) @ : Same as VIGNERON: why would a CC BY-NC license forbid Wikidata from linking to this service?  Wikidata has plenty of identifiers linking to websites which are not CC0 themselves.  Can you also add a link to the property proposal where this was discussed?  − ( ) @ : I believe the property proposal is .  -- ( ) @ : I believe the property proposal is . -- ( ) ###Output: ",0
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P6978:   withdrawn --- withdrawn --- Keep We do not require property creators to resolve all points of discussion before creating a property - I'm grateful the creator finally got around to assessing this one and taking care of it.  There's clearly a need for this property, and plenty of examples of how it would be used.  ( ) Comment Unfortunately, ArthurPSmith changed the proposal after everybody else commented on it and we have no way to sort things out as we do usual.  Let's recall the process: someone proposed a property, people support or oppose it, maybe comment to help improve it, then a property creator assesses the consensus and creates it.  Nothing of that has been followed here.  The property creator didn't even bother reading it.  Let's start this correctly from zero and then decide it.  --- @ : first your description of the situation is really incorrect. It does not seems premature (a lot of property are created more quickly, with less people participating and/or less favourable balance of pro vs. cons), please assume good faith of , didn't change the proposal, he just changed the label and description in English from ""Second family name in Scandinavian names"" to ""middle family name"", this doesn't seem a very big change and we can still put back the previous label, no need to delete the property. Then, this is the pot calling the kettle black: you did the same thing (and even worse as datatype can't be change unlike the label, and more people disagreed with your creation) with . Cheers, ( ) This is to discuss the deletion request. Don't sidetrack the discussion about the nominator: not good VIGNERON. Don't lend people assumptions: not good VIGNERON. --- @ : first your description of the situation is really incorrect.  It does not seems premature (a lot of property are created more quickly, with less people participating and/or less favourable balance of pro vs. cons), please assume good faith of , didn't change the proposal, he just changed the label and description in English from ""Second family name in Scandinavian names"" to ""middle family name"", this doesn't seem a very big change and we can still put back the previous label, no need to delete the property.  Then, this is the pot calling the kettle black: you did the same thing (and even worse as datatype can't be change unlike the label, and more people disagreed with your creation) with .  Cheers, ( ) This is to discuss the deletion request.  Don't sidetrack the discussion about the nominator: not good VIGNERON.  Don't lend people assumptions: not good VIGNERON.  --- This is to discuss the deletion request. Don't sidetrack the discussion about the nominator: not good VIGNERON. Don't lend people assumptions: not good VIGNERON. --- weak keep .  Whoa this one is complicated.  @ : Can you explain whether these middle family names are, in legal documents, given names or family names?  And is the difference between and that is used before the main family name, while is used after the main family name?  ( ) they're a given name.  It's not automatically the mother's maiden name: sometimes it's the family name of the godparent or a (local) notable person.  Like middle names they are often abbreviated to just the letter.  When the full name is written out they are before the family name.  ( ) Keep The PFDer Jura1 has now somethings which match Japanese word ""邪魔"", such as insulting VIGNERON as confusing ""not good XXX"" for multiple times.  -- ( ) Keep These names are in legal documents given names (at least with respect to Norway).  They can not be created into legal double last names.  They comes after the given name, wich can consist of two names, and before the last name, who in general is only one ""name"" combinations of two names may however exist.  But then generally in forms like Egede-Nissen.  Example Johan Martin Rønning Tennøy can in formal use Johan Tennøy.  And then Martin is his second given name Rønning his mothers last name and is middle Family name.  Tennøy his last name.  The middle Family name can not be transfered to the persons children or wife.  ( ) Keep The scandinavian middle family name is pretty weird.  It does not exist in legal terms, it is just a habit to get around the laws for how to build up the name.  We use a given middle name as an additional family name.  Without a specific field the additional family name will sip into the given name, which I believe would be bad.  I belive is wrong about “They can not be created into legal double last names.” given navneloven (7) and first part of “The middle Family name can not be transfered to the persons children or wife.” (4) There are a lot of exceptions, and this version of the law is from 2002.  I'm not familiar with the earlier laws.  ( ) Keep This has been needed for a long time!  I do not know the exact English definition of a ""given name"", so I will used the word ""first name"" here.  In Norway the law quite clearly separates first names from family names.  One can not choose a commonly used family name as the first name for your child, and a commonly used first name can not be used as a family name.  Exceptions are made for foreign names, but there has to be proof of usage in the family.  This means that more or less all names that end with -sen, -son, -berg, -rud, -stad, -øy, -land, etc. are simply illegal as first names.  There are only very few first names that are also used as family names, and the best known is probably Magnus (from journalist ).  (I also have to mention that for us Norwegians the English naming traditions where a name can be both a first name and a family name are seriously confusing at times, since we are used to the strict rules.)  One of the property examples, , puzzle me a bit.  Out of her four names, only Tone is a legal first name.  Tveøy, Strøm and Gundersen are all strictly family names.  So one can wonder if both Tveøy and Strøm are middle family names.  Or if Tveøy is a middle family name, while Strøm Gundersen is a double family name.  The current law (from 2002) apparently states that double family names should have a dash between them, but some sources say that it is not mandatory, so I guess it may have been different in earlier laws.  I do not know the answer here, but I guess the example should be changed, as now it doesn't show as a good example.  ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P7158:   Deleted − ( ) Deleted − ( ) @ :@ , : I'm sure you want to have a say too.  The may have given the impression that merlin.pl is an authority naming authors, but to me it looks just like any web shop api searching for keywords.  Examples metallica shows that it's not authors, nor persons and millennium indicates that it's not always identifying a single entity.  I suggest this ID to be dropped before it gains more use.  Then again, if there's a rule saying that all webshop api keys are notable for use in WD I guess that's the argument where I suggest the use of rather than having specific properties for each site.  ( ) Delete Didn't realize it was a webshop until now.  I though it was database.  -- ( ) Somehow it recognise given name belong to artist, author or direcitor. ( ) Delete Didn't realize it was a webshop until now. I though it was database. -- ( ) Delete Didn't realize it was a webshop until now.  I though it was database.  -- ( ) Somehow it recognise given name belong to artist, author or direcitor. ( ) Delete search string for webshop, nothing but spam.-- ( ) @ : Read my comment above.  Prove it isn't id. ( ) @ : shows that it's not a trustworthy authority for identification.  If it's an ID or not is to me not the question.  The question is: What value will this property bring to Wikidata?  Can you help explain that again?  ( ) @ : Read my comment above.  Prove it isn't id. ( ) @ : shows that it's not a trustworthy authority for identification.  If it's an ID or not is to me not the question.  The question is: What value will this property bring to Wikidata?  Can you help explain that again?  ( ) @ : shows that it's not a trustworthy authority for identification.  If it's an ID or not is to me not the question.  The question is: What value will this property bring to Wikidata?  Can you help explain that again?  ( ) Delete Already fall under AbuseFilter in some Wikipedias.  -- ( ) Delete ###Output: ",0
keep,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P2847:   Consensus to Keep − ( ) Consensus to Keep − ( ) Keep Items point to Wayback Machine ( has been changed), so this property is used on WD and also by other wikis… quite simply.  — ( ) Keep There are archived copies of Google+ pages.  Keep per the above. ###Output: ",0
keep,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P6243:   Consensus to Keep this property, which I have marked as a subproperty of per 's suggestion. In short, this distinction is useful (at least) to draw the line between creative depictions of a work of art, which can be subject to copyright on their own, and faithful digitizations of works, where no creative choice is involved, which can be treated differently for copyright purposes. The copyright status of the work can also be represented separately. − ( ) Consensus to Keep this property, which I have marked as a subproperty of per 's suggestion. In short, this distinction is useful (at least) to draw the line between creative depictions of a work of art, which can be subject to copyright on their own, and faithful digitizations of works, where no creative choice is involved, which can be treated differently for copyright purposes. The copyright status of the work can also be represented separately. − ( ) Delete Convinced by Mike. ( ) . Comment I'm feeling very conflicted about this one. After giving it some thought, I'm much more in favor of 'clean' and separate copyright modeling as suggested by on the , mainly because that solution provides much more consistency in copyright modeling and provides more clear information to people unfamiliar with Wikimedia Commons policies (i.e. the majority of people out there).  That said, faithful two-dimensional digital representations of two-dimensional documents and artworks (aka ' ') are a special category of files, that would benefit from being clearly distinguishable as such.  I'd be interested to hear input from experts familiar with this issue in GLAM data modeling whether a separate property indeed would make sense.  I'll ask around and will post updates here when I succeed in receiving some feedback.  Agree that we should not use this property for copyright hamndling.  Files should have their own copyright status handling.  What we want to know of a file in commons is if there is a artistic influence of the photographer and thus a claim for copyright or just a reproduction of an existing work (either PD or CC).  As this evaluation differs per legislation and has several edge cases we should nog use this property for copyright related issues.  Wha we would like to know of a file is that it is a 1:1 of the seizes of the artwork -- ( ) Agree that we should not use this property for copyright hamndling. Files should have their own copyright status handling. What we want to know of a file in commons is if there is a artistic influence of the photographer and thus a claim for copyright or just a reproduction of an existing work (either PD or CC). As this evaluation differs per legislation and has several edge cases we should nog use this property for copyright related issues. Wha we would like to know of a file is that it is a 1:1 of the seizes of the artwork -- ( ) Keep When a cultural institution scans a historical document to make an exact digital reproduction of it, this relationship between the object and the media file is different in nature from what is described when anything displayed in the image can be added in a ""depicts"" statement.  Absent further explanation, I don't understand the suggestion that a faithful digital representation is the same as a depiction.  ( ) And what to do if I make a picture of a work?  And if I brighten the work?  Or is this property for scans created following official ISO standards for scanning museum objects?  But can't we derive that from the EXIF data?  -- ( ) I agree those questions should have answers. I think what you are suggesting here are reasons for clearly defining a property's scope, but I don't see how deletion is a solution. ( ) The scope should definetely change to keep this porperty. -- ( ) @ : Scans of documents are a different case, which this property as-is doesn't seem to address.  Thanks.  ( ) If you want to replace ""document"" for ""artwork"" in my first comment, I am not sure how that changes the point.  A depiction is not the same as a digitization.  Or, at least, I think you have an obligation to at least attempt to explain why you are calling these redundant, since I don't see that you have.  ( ) @ : Can you give an example, please?  The ones in the property proposal and documentation don't match this use case.  Thanks.  ( ) @ : I am pointing out that there is a substantive semantic difference between a ""faithful digitized representation"" of the Mona Lisa and a work that in some way ""depicts"" the Mona Lisa.  I think the burden is supposed to be on you to make an argument.  From what I understand of your proposal, you seem a bit confused about the purpose of the property in the first place.  ( ) @ : Can you explain how the current property makes that difference, please?  I can't see it myself, beyond the ranking of the depicts statement.  I am ""confused about the purpose of the property in the first place""!  ( ) The words do not mean the same thing.  What are you even asking for here?  ( ) @ : The words and the usage don't match.  I'm asking for this property to either be deleted, or for its usage to be made significantly clearer.  Thanks.  ( ) And what to do if I make a picture of a work?  And if I brighten the work?  Or is this property for scans created following official ISO standards for scanning museum objects?  But can't we derive that from the EXIF data?  -- ( ) I agree those questions should have answers. I think what you are suggesting here are reasons for clearly defining a property's scope, but I don't see how deletion is a solution. ( ) The scope should definetely change to keep this porperty. -- ( ) I agree those questions should have answers.  I think what you are suggesting here are reasons for clearly defining a property's scope, but I don't see how deletion is a solution.  ( ) The scope should definetely change to keep this porperty.  -- ( ) The scope should definetely change to keep this porperty. -- ( ) @ : Scans of documents are a different case, which this property as-is doesn't seem to address.  Thanks.  ( ) If you want to replace ""document"" for ""artwork"" in my first comment, I am not sure how that changes the point.  A depiction is not the same as a digitization.  Or, at least, I think you have an obligation to at least attempt to explain why you are calling these redundant, since I don't see that you have.  ( ) @ : Can you give an example, please?  The ones in the property proposal and documentation don't match this use case.  Thanks.  ( ) @ : I am pointing out that there is a substantive semantic difference between a ""faithful digitized representation"" of the Mona Lisa and a work that in some way ""depicts"" the Mona Lisa.  I think the burden is supposed to be on you to make an argument.  From what I understand of your proposal, you seem a bit confused about the purpose of the property in the first place.  ( ) @ : Can you explain how the current property makes that difference, please?  I can't see it myself, beyond the ranking of the depicts statement.  I am ""confused about the purpose of the property in the first place""!  ( ) The words do not mean the same thing.  What are you even asking for here?  ( ) @ : The words and the usage don't match.  I'm asking for this property to either be deleted, or for its usage to be made significantly clearer.  Thanks.  ( ) If you want to replace ""document"" for ""artwork"" in my first comment, I am not sure how that changes the point.  A depiction is not the same as a digitization.  Or, at least, I think you have an obligation to at least attempt to explain why you are calling these redundant, since I don't see that you have.  ( ) @ : Can you give an example, please?  The ones in the property proposal and documentation don't match this use case.  Thanks.  ( ) @ : I am pointing out that there is a substantive semantic difference between a ""faithful digitized representation"" of the Mona Lisa and a work that in some way ""depicts"" the Mona Lisa.  I think the burden is supposed to be on you to make an argument.  From what I understand of your proposal, you seem a bit confused about the purpose of the property in the first place.  ( ) @ : Can you explain how the current property makes that difference, please?  I can't see it myself, beyond the ranking of the depicts statement.  I am ""confused about the purpose of the property in the first place""!  ( ) The words do not mean the same thing.  What are you even asking for here?  ( ) @ : The words and the usage don't match.  I'm asking for this property to either be deleted, or for its usage to be made significantly clearer.  Thanks.  ( ) @ : Can you give an example, please?  The ones in the property proposal and documentation don't match this use case.  Thanks.  ( ) @ : I am pointing out that there is a substantive semantic difference between a ""faithful digitized representation"" of the Mona Lisa and a work that in some way ""depicts"" the Mona Lisa.  I think the burden is supposed to be on you to make an argument.  From what I understand of your proposal, you seem a bit confused about the purpose of the property in the first place.  ( ) @ : Can you explain how the current property makes that difference, please?  I can't see it myself, beyond the ranking of the depicts statement.  I am ""confused about the purpose of the property in the first place""!  ( ) The words do not mean the same thing.  What are you even asking for here?  ( ) @ : The words and the usage don't match.  I'm asking for this property to either be deleted, or for its usage to be made significantly clearer.  Thanks.  ( ) @ : I am pointing out that there is a substantive semantic difference between a ""faithful digitized representation"" of the Mona Lisa and a work that in some way ""depicts"" the Mona Lisa.  I think the burden is supposed to be on you to make an argument.  From what I understand of your proposal, you seem a bit confused about the purpose of the property in the first place.  ( ) @ : Can you explain how the current property makes that difference, please?  I can't see it myself, beyond the ranking of the depicts statement.  I am ""confused about the purpose of the property in the first place""!  ( ) The words do not mean the same thing.  What are you even asking for here?  ( ) @ : The words and the usage don't match.  I'm asking for this property to either be deleted, or for its usage to be made significantly clearer.  Thanks.  ( ) @ : Can you explain how the current property makes that difference, please?  I can't see it myself, beyond the ranking of the depicts statement.  I am ""confused about the purpose of the property in the first place""!  ( ) The words do not mean the same thing.  What are you even asking for here?  ( ) @ : The words and the usage don't match.  I'm asking for this property to either be deleted, or for its usage to be made significantly clearer.  Thanks.  ( ) The words do not mean the same thing.  What are you even asking for here?  ( ) @ : The words and the usage don't match.  I'm asking for this property to either be deleted, or for its usage to be made significantly clearer.  Thanks.  ( ) @ : The words and the usage don't match.  I'm asking for this property to either be deleted, or for its usage to be made significantly clearer.  Thanks.  ( ) Comment My understanding has been that the difference between and is something like: Broadly agree.   IMO the image on the right of ""Starry Night"", including frame, and taken from a slightly oblique angle, should not have a statement, but should have = at preferred level.  In the case of the Mona Lisa, only the Wikidata item should have = .   IMO, the fact should not be in the structured data for the image itself, the fact should be inherited from Wikidata if the image has a or statement pointing to Q12418.   (This is the ""depicts of depicts"" functionality, which should be arriving for display and for search some time soon).  It's a slightly open question for me, how much ""retouching"" of an image should be allowable, and it still to be appropriate to use P6243.   For example, an image of the Mona Lisa with colours digitally adjusted to how it might have looked at the time of Leonardo IMO probably should not carry a statement -- but it would be useful to know what others think on this. ( ) Broadly agree.  IMO the image on the right of ""Starry Night"", including frame, and taken from a slightly oblique angle, should not have a statement, but should have = at preferred level. In the case of the Mona Lisa, only the Wikidata item should have = .  IMO, the fact should not be in the structured data for the image itself, the fact should be inherited from Wikidata if the image has a or statement pointing to Q12418.  (This is the ""depicts of depicts"" functionality, which should be arriving for display and for search some time soon). It's a slightly open question for me, how much ""retouching"" of an image should be allowable, and it still to be appropriate to use P6243.  For example, an image of the Mona Lisa with colours digitally adjusted to how it might have looked at the time of Leonardo IMO probably should not carry a statement -- but it would be useful to know what others think on this.  ( ) Comment My understanding is that P180 must have an associated Wikidata item that represents the thing that depicts.  On Commons, use of P180 is only possible because other Wikidata items than the Commons file have depicted the thing selected.  In this case, there may not be any associated Wikidata item except for the thing this file is a digital representation of.  Because of the overwhelming majority of such cases on Commons I find this property highly useful.  It gives Commons people at least an indication that the file shows the whole thing described by the associated Wikidata item, albeit in some old sepia print.  This is useful in the case of photos of e.g. old paintings before theft,loss by fire, restoration etc, and e.g. buildings before expansion or demolition.  These properties are by no means related in my view.  ( ) But then we should rename this porperty.  'digital representation' could also mean the best colors etc, but that is not the case.  Instead we could use a definition that states that the file covers exactly the dimensions of the artwork ('the whole thing described by the associated Wikidata item').  It would also mean that it is not only for 2d works, but also for songs and movies that covers exactly the whole movie and the whole song, and 3D files of monuments, that covers exactly that monument.  -- ( ) But then we should rename this porperty. 'digital representation' could also mean the best colors etc, but that is not the case. Instead we could use a definition that states that the file covers exactly the dimensions of the artwork ('the whole thing described by the associated Wikidata item'). It would also mean that it is not only for 2d works, but also for songs and movies that covers exactly the whole movie and the whole song, and 3D files of monuments, that covers exactly that monument. -- ( ) Keep great people.  Barely anyone is participating in the discussion to set up , but instead time is wasted on sabotaging .  You're basically rehashing the discussions of and .  ( ) Keep Per Multichill - ( ) Confused as that discussion about is about 'When to use the PD-scan tag' is about the 'level of originality'.  We should not use this property for evaluation of 'originality' as we now have both for the file in commons as for on Wikidata with qualifiers about the copyright evaluation.  We could use this property when the dimensional overlap between the image and the object is 1:1.  I think we have this discussion because this property is currently meant for copyright evalaution as well as 'is a scan of' -- ( ) Confused as that discussion about is about 'When to use the PD-scan tag' is about the 'level of originality'.  We should not use this property for evaluation of 'originality' as we now have both for the file in commons as for on Wikidata with qualifiers about the copyright evaluation.  We could use this property when the dimensional overlap between the image and the object is 1:1.  I think we have this discussion because this property is currently meant for copyright evalaution as well as 'is a scan of' -- ( ) Comment This is probably the first Commons-only property.  As such, I think it should ultimately be determined on Commons if and how it should be used.  Still, the use should somewhat be consistent with the label and initial description of the property here on Wikidata.  If use should be limit to ""copyright status"" or ""PD-copyright status"" of the 2D artwork photographed or scanned, it should be labelled differently, meaning a property with a different label should be created and this deleted.  Occasionally creating items for , I think use of such items goes beyond that.  Otherwise, I'd probably not bother creating them.  Not really convinced that including that item in P180 would be helpful, but it seems that currently much of Commons modeling is limited to that.   --- Comment if used for prints I am even more confused.  For prints and books we have the individual copy in an archive, and the 'master'.  Probably thia property should link to the individual copy of that particular archive, and depicts should link to the master?  I did so for this map.  I added -> and -> .  Should that be the correct use for prints and books?  That would mean we should only use if we have an item about that individual copy of that print or book page in wikidata, and depicts otherwise?  -- ( ) @ : It's a good question.   A related one is: what sort of items should one be creating on Wikidata?   In particular, if one wants to create an item on Wikidata corresponding to a map that one has a digitisation of, should one be creating an item that is or one that is ?   I flip-flop backwards and forwards a bit on this question; but (unless there is important provenance information to record), my yardstick would be whether there are likely to be visible differences between different exemplars of the edition.   If eg a particular map has hand-colouring, it may make sense to have its own item (and then for the image to be of that).   But if the map is simply as printed, with nothing to apparently difference it from any other copy, then it may make sense to make a Wikidata item for the whole (and in such a case I think it would still make sense to use P6243, to indicate that the image is a representative digital representation of the whole map edition).   Where I don't think one can use P6243 is if the map has hand-colouring that is specific to the individual copy, rather than the edition.   Then I think the image is presenting something more that just a representative of the edition, and it probably makes sense to create a Wikidata item for the individual object (which is always a safe fall-back).   Also, a particular identifiable state of a map or engraving should usually have its own Wikidata item, as it will correspond to an edition in its own right.   A marginal case is where a map from an edition might have acquired particular stains, or perhaps a visible library ownership stamp.   In such a case I believe it would be reasonable to regard such marks as not of particular consequence, and it would be acceptable to describe the image as just a generic representation of the edition; but on the other hand I wouldn't object or nominate the item for deletion, if somebody created a distinct Wikidata item for it.   But it would be useful to know whether this conforms to what other people think and/or are doing in this area.  ( ) @ : It's a good question.   A related one is: what sort of items should one be creating on Wikidata?   In particular, if one wants to create an item on Wikidata corresponding to a map that one has a digitisation of, should one be creating an item that is or one that is ?   I flip-flop backwards and forwards a bit on this question; but (unless there is important provenance information to record), my yardstick would be whether there are likely to be visible differences between different exemplars of the edition.   If eg a particular map has hand-colouring, it may make sense to have its own item (and then for the image to be of that).   But if the map is simply as printed, with nothing to apparently difference it from any other copy, then it may make sense to make a Wikidata item for the whole (and in such a case I think it would still make sense to use P6243, to indicate that the image is a representative digital representation of the whole map edition).   Where I don't think one can use P6243 is if the map has hand-colouring that is specific to the individual copy, rather than the edition.   Then I think the image is presenting something more that just a representative of the edition, and it probably makes sense to create a Wikidata item for the individual object (which is always a safe fall-back).   Also, a particular identifiable state of a map or engraving should usually have its own Wikidata item, as it will correspond to an edition in its own right.   A marginal case is where a map from an edition might have acquired particular stains, or perhaps a visible library ownership stamp.   In such a case I believe it would be reasonable to regard such marks as not of particular consequence, and it would be acceptable to describe the image as just a generic representation of the edition; but on the other hand I wouldn't object or nominate the item for deletion, if somebody created a distinct Wikidata item for it.   But it would be useful to know whether this conforms to what other people think and/or are doing in this area.  ( ) Every print in each museum is very unique.  For digital representations as meant in this property I would be oppose to use this proprty for the concept and only use depicts.  At the other hand, we could also use this property for manifestations of a concept.  See the examples below -- ( ) File:Google 2015 logo.svg -> File:Google 2015 logo.svg -> File:Great coat of arms of Belgium.svg -> -> Keep Because I suspect people are going to want to search for files that are digital representations of (classes of) artworks, rather than just files depicting them; having this property will make such searches far more efficient -- I suspect that just relying on depicts and then filtering would be likely to make corresponding SPARQL queries time out.  This property has a very specific meaning: it means that an image shows the whole of an 2D art object, all of it, faithfully, directly square-on, and nothing but the 2D art object (ie no frame, no adjacent wall, no surrounding gallery, no other work, etc).   It's quite a common situation, encompassing eg works covered by the {{ }} tag (cf ), with approaching 1.4 million transclusions; though of course that's only about 3% of Commons images.   It is useful to have this property, to designate that an image has this nature.  I do not regard the property as a substitute for systematic standard copyright statements -- those should be present too.  But in my view the fact that the image is a direct faithful representation of a particular 2d artwork is worth stating in its own right.  It is also worth pointing out that the statement may apply in a few cases where {{ }} does not apply -- for example a faithful representation of an artwork that is still in copyright, but which has been released by the creator.   P6243 is appropriate in this case too.  I am neutral as to whether an image should also have a parallel P180 statement.   Ideally when ""depicts of depicts"" is implemented for search and display etc, statements would be inheritable via P6243 as well.   That would make any parallel P180 statement redundant, but mostly harmless.  So, overall, keep -- to make it easier to extract images which are faithful reproductions; and also to facilitate the workflow for such images, and to facilitate automatic checking (eg constraint checking) of statements on them (eg copyright statements) against data from the indicated wikidata item. ( ) @ : Would it be possible to do a query for cases where there is only one depicts statement? E.g., to find cases where = that don't also have other depicts statements like = . I really don't like the data duplication inherent in this property (similar to P373!), nor the fact that it's somehow separate from P180. Another option might be a qualifier on P180 to say ""is a faithful reproduction"", which might also be easy to query? Thanks. ( ) @ : Would it be possible to do a query for cases where there is only one depicts statement? E.g., to find cases where = that don't also have other depicts statements like = . I really don't like the data duplication inherent in this property (similar to P373!), nor the fact that it's somehow separate from P180. Another option might be a qualifier on P180 to say ""is a faithful reproduction"", which might also be easy to query? Thanks. ( ) May it be solved by putting → → ? and then you avoid to use if the value is already set with . Will the Structured Data searching tools works with that? if yes that would be great. ( ) @ : That would probably work, but would be an extra layer of abstraction/coding. Why not just use P180? Thanks. ( ) @ : That would probably work, but would be an extra layer of abstraction/coding. Why not just use P180? Thanks. ( ) @ : Is it not related to the copyrights of the depicted artworks? ( ) @ : That's what I thought, but see what I wrote in the deletion nomination above. Thanks. ( ) @ : Is it not related to the copyrights of the depicted artworks? ( ) @ : That's what I thought, but see what I wrote in the deletion nomination above. Thanks. ( ) @ : That's what I thought, but see what I wrote in the deletion nomination above. Thanks. ( ) Keep I dont see, any argument in Mike Peel's proposal, its just about what he think. If I have a look on the description and proposals for and , I can see clear difference. Lets explain it by the example. You have a photograph or scan of a manuscript. What it depicts? It depicts laters/handscript/illustration. What it is a representation of? It is a representation of a manuscript/book, which may have its item on Wikidata.-- ( ) If you have a scan of a book page, we can't say it is a digital representstion of that book.  Or do you propose to create an item for every book page?  -- ( ) No need to talk about hole books. We can stay with one paper maps, handscripts etc. -- ( ) Many artworks are printed in a book and heritage institutions have a lot of scanned books.  So what is the situation for prints and books?  Using , or .   Use if it is a PDF of the whole book?  And whisch should mention the specific book, and which to the concept of the book?  -- ( ) Well even you have one page of a book, you still want to indicate what kind of book it is and for that this property is the right one. ( ) If you have a scan of a book page, we can't say it is a digital representstion of that book. Or do you propose to create an item for every book page? -- ( ) No need to talk about hole books.  We can stay with one paper maps, handscripts etc.  -- ( ) Many artworks are printed in a book and heritage institutions have a lot of scanned books. So what is the situation for prints and books? Using , or .  Use if it is a PDF of the whole book? And whisch should mention the specific book, and which to the concept of the book? -- ( ) Well even you have one page of a book, you still want to indicate what kind of book it is and for that this property is the right one.  ( ) No need to talk about hole books.  We can stay with one paper maps, handscripts etc.  -- ( ) Many artworks are printed in a book and heritage institutions have a lot of scanned books. So what is the situation for prints and books? Using , or .  Use if it is a PDF of the whole book? And whisch should mention the specific book, and which to the concept of the book? -- ( ) Well even you have one page of a book, you still want to indicate what kind of book it is and for that this property is the right one.  ( ) Many artworks are printed in a book and heritage institutions have a lot of scanned books.  So what is the situation for prints and books?  Using , or .   Use if it is a PDF of the whole book?  And whisch should mention the specific book, and which to the concept of the book?  -- ( ) Well even you have one page of a book, you still want to indicate what kind of book it is and for that this property is the right one.  ( ) Delete if the scope of this property stays unclear.  If it used for copyright I am against it, as we have copyright status and the scope is now 2D whereas the new upcoming copyright directive of the EU will also include 3D files and 2D representations of 3D works that can't have copyright by the photograper.  The property will work for paintings, but for logos, prints, books, coins, stamps, plates -  all artworks that have multiple items, it is in the current definition unclear how to deal with it, if it is about the concept or the individual copy.  Heritage institutions and professionals would expect it is linking ot the individual copy of that work as only then it is the digital reprensentation.  And if it is about the concept, can we say a building plan drawing is a digital representation of a building?  A weapon is a digital representation of a Coat of arms?  And how about movies, digital born material?  Is a music score a digital representation of that music?  This property is created for old paintings but not well defined for other works of art.  -- ( ) @ : The EU directive only says there should be no copyright if there is no original creativity by the photographer.  Following the U.S. jurisprudence, expect all photographs of 3D items to pass that creativity threshold.  Also expect the mother of all legal battles as to under what circumstances art repro photographs of 2D works may embody sufficient creativity.  I think it's a 100% certainty that this will be fought very hard by the photo agencies, both at the legislative drafting stages and in the courts, I would expect all the way to the CJEU.   And never bet on the outcome of a court case, because they very seldom go the way you think they are going to. This property was originally intended for faithful images of 2D artworks.  That is how it should remain.  It does a clear and useful job in that respect.  Extending it and blurring its purpose will make it less useful, because query returns for uses of it will become less sharply defined and therefore less valuable. ( ) Sorry but Commons should be independent on current legislation but instead use structured data. We can't say there is no copyrighton the pictures of 2D artowork never and nowhere. It depends on the local copyright rules and let's not mixing up copyright rules with technologies. We already have to declare if a file is a copy and to declare both the copyright for the artwork as well as the photograph or scan. -- ( ) @ : The relevance of for copyright is that (amongst other things) it indicates that the copyright status of the image will depend solely on the information for the wikidata item -- because there is nothing else about the image which could attract copyright.   P6243 is not a substitute nor a replacement for specific copyright statements on the image.   But it indicates (amongst other things) that it should be possible to check/assess their validity entirely from information on Wikidata.  ( ) The copyright status is of a scan of a 2D work is based on a US case ( ) and not a worldwide ruling.  In other countries it can be copyrighte for example in Germany.  It was extended to 3d-works by and limited to exact representations only by .  On Commons to keep representations even when they are copyrighted in the source country.  Using this property for a copyright status is therefore problematic.  -- ( ) @ : The EU directive only says there should be no copyright if there is no original creativity by the photographer.  Following the U.S. jurisprudence, expect all photographs of 3D items to pass that creativity threshold.  Also expect the mother of all legal battles as to under what circumstances art repro photographs of 2D works may embody sufficient creativity.  I think it's a 100% certainty that this will be fought very hard by the photo agencies, both at the legislative drafting stages and in the courts, I would expect all the way to the CJEU.   And never bet on the outcome of a court case, because they very seldom go the way you think they are going to. This property was originally intended for faithful images of 2D artworks.  That is how it should remain.  It does a clear and useful job in that respect.  Extending it and blurring its purpose will make it less useful, because query returns for uses of it will become less sharply defined and therefore less valuable. ( ) Sorry but Commons should be independent on current legislation but instead use structured data. We can't say there is no copyrighton the pictures of 2D artowork never and nowhere. It depends on the local copyright rules and let's not mixing up copyright rules with technologies. We already have to declare if a file is a copy and to declare both the copyright for the artwork as well as the photograph or scan. -- ( ) @ : The relevance of for copyright is that (amongst other things) it indicates that the copyright status of the image will depend solely on the information for the wikidata item -- because there is nothing else about the image which could attract copyright.   P6243 is not a substitute nor a replacement for specific copyright statements on the image.   But it indicates (amongst other things) that it should be possible to check/assess their validity entirely from information on Wikidata.  ( ) The copyright status is of a scan of a 2D work is based on a US case ( ) and not a worldwide ruling.  In other countries it can be copyrighte for example in Germany.  It was extended to 3d-works by and limited to exact representations only by .  On Commons to keep representations even when they are copyrighted in the source country.  Using this property for a copyright status is therefore problematic.  -- ( ) Sorry but Commons should be independent on current legislation but instead use structured data. We can't say there is no copyrighton the pictures of 2D artowork never and nowhere. It depends on the local copyright rules and let's not mixing up copyright rules with technologies. We already have to declare if a file is a copy and to declare both the copyright for the artwork as well as the photograph or scan. -- ( ) @ : The relevance of for copyright is that (amongst other things) it indicates that the copyright status of the image will depend solely on the information for the wikidata item -- because there is nothing else about the image which could attract copyright.   P6243 is not a substitute nor a replacement for specific copyright statements on the image.   But it indicates (amongst other things) that it should be possible to check/assess their validity entirely from information on Wikidata.  ( ) The copyright status is of a scan of a 2D work is based on a US case ( ) and not a worldwide ruling.  In other countries it can be copyrighte for example in Germany.  It was extended to 3d-works by and limited to exact representations only by .  On Commons to keep representations even when they are copyrighted in the source country.  Using this property for a copyright status is therefore problematic.  -- ( ) @ : The relevance of for copyright is that (amongst other things) it indicates that the copyright status of the image will depend solely on the information for the wikidata item -- because there is nothing else about the image which could attract copyright.   P6243 is not a substitute nor a replacement for specific copyright statements on the image.   But it indicates (amongst other things) that it should be possible to check/assess their validity entirely from information on Wikidata.  ( ) The copyright status is of a scan of a 2D work is based on a US case ( ) and not a worldwide ruling.  In other countries it can be copyrighte for example in Germany.  It was extended to 3d-works by and limited to exact representations only by .  On Commons to keep representations even when they are copyrighted in the source country.  Using this property for a copyright status is therefore problematic.  -- ( ) The copyright status is of a scan of a 2D work is based on a US case ( ) and not a worldwide ruling.  In other countries it can be copyrighte for example in Germany.  It was extended to 3d-works by and limited to exact representations only by .  On Commons to keep representations even when they are copyrighted in the source country.  Using this property for a copyright status is therefore problematic.  -- ( ) Keep But remove copyright from it's scope and broaden to go beyond just artworks.  I'd also argue to broaden it to go beyond 2D.  If I upload a 3D scan of an object then that file is ""faithful"" digital representation of the object (at least once Commons supports textures).  Will there be lots of edge cases?  Of course!  But if we stop focusing on those I believe that the distinction between ""the item is somewhere in this image/file"" and ""the whole of this item (and nothing else) is in this image/file"" is pretty clear.  Every single image/file sharing a target will be extremely similar (close to identical) wheres there is no such guaranteed relation between images/files sharing a target.  / Keep As I have now outlined multiple times.  Repeatedly nominating this for deletion and failing to engage with everyone else is pretty disrespectful.  Please stop.  ( ) @ : It seems unfair to say that I'm ""failing to engage"" - although perhaps I am failing to understand.  I don't mean to be disrespectful at all, I want to see this murky situation made clearer at least.  Thanks.  ( ) @ : It seems unfair to say that I'm ""failing to engage"" - although perhaps I am failing to understand.  I don't mean to be disrespectful at all, I want to see this murky situation made clearer at least.  Thanks.  ( ) Very strong Keep , after giving it more thought, and after meeting and brainstorming with who has researched digital surrogates in the cultural sector.  Some thoughts and input below: Faithful digital representations of creative works are definitely conceptually different from other depictions of artworks.  Also having looked at GLAM files a lot over the years, I think a clear distinction between and is a good way to address this.  and indeed have structurally different repercussions, especially around authorship.  A basic way in which digital surrogates are different: they are meant to be faithful 'surrogates' of a work in digital form, and there is arguably no 'creative act' involved in their creation (outside of 'sweat of the brow' and the expertise needed for doing a quality digitization).  Hence authorship of digital surrogates needs to be described/displayed differently.  I accidentally found an illustrative example of this when looking at the Chrome browser extension by .  Compare these two cases: Faithful digital representations of creative works are definitely conceptually different from other depictions of artworks.  Also having looked at GLAM files a lot over the years, I think a clear distinction between and is a good way to address this.  and indeed have structurally different repercussions, especially around authorship.  A basic way in which digital surrogates are different: they are meant to be faithful 'surrogates' of a work in digital form, and there is arguably no 'creative act' involved in their creation (outside of 'sweat of the brow' and the expertise needed for doing a quality digitization).  Hence authorship of digital surrogates needs to be described/displayed differently.  I accidentally found an illustrative example of this when looking at the Chrome browser extension by .  Compare these two cases: Photo of a three-dimensional artwork.  The browser extension displays attribution information generated from wikitext; while it would be good to also display the creator of the sculpture there (Stephan Huber), it is especially fully correct and necessary to attribute the photographer, because he made a creative decision in how to show the artwork in the photo.  Compare with this textbook example of a digital surrogate, where it actually makes no sense to display the name of the uploader of the file and it would be more beneficial to have an attribution line that focuses on the artwork itself (e.g. a combo of title, date, painter, collection).  My point with this example is that, in order to provide more refined and correct attribution data to be used by tool builders, the distinction certainly makes sense.  I would strongly advise to use the property for all faithful digital representations of creative works, including photographs, maps, but also potentially 3D scans, digitizations of films and music recordings, etc.  Also use for faithful digital representations of works that are not PD yet but have been released under a Creative Commons or other free license.  So no 1:1 replication of the PD-Art template on Wikimedia Commons.  I recommend to use for all digital surrogates, if clearly intended to be 'precise and exact digitizations' of a document and creative work.  Examples: My point with this example is that, in order to provide more refined and correct attribution data to be used by tool builders, the distinction certainly makes sense.  I would strongly advise to use the property for all faithful digital representations of creative works, including photographs, maps, but also potentially 3D scans, digitizations of films and music recordings, etc.  Also use for faithful digital representations of works that are not PD yet but have been released under a Creative Commons or other free license.  So no 1:1 replication of the PD-Art template on Wikimedia Commons.  I recommend to use for all digital surrogates, if clearly intended to be 'precise and exact digitizations' of a document and creative work.  Examples: -> -> as stated above -> -> So this file is definitely not a digital surrogate (shadow, shows part of a wall of which the size was the photographer's decision) and should not use .  Use -> here.  I personally advise to introduce even more clarity by making a subproperty of and hence only using one of either or , so not both at the same time pointing to the same work (sorry @ : this will involve undoing some of your existing edits; I'll be happy to help clean it up because it's for a good cause!).  It will mean some extra complexity in terms of indexing for search, and in terms of building Lua-powered templates, but it is to the long-term benefit of much more consistency and clarity for partners and re-users.  I personally advise to introduce even more clarity by making a subproperty of and hence only using one of either or , so not both at the same time pointing to the same work (sorry @ : this will involve undoing some of your existing edits; I'll be happy to help clean it up because it's for a good cause!).  It will mean some extra complexity in terms of indexing for search, and in terms of building Lua-powered templates, but it is to the long-term benefit of much more consistency and clarity for partners and re-users.  Cheers, I 100% support Spinster's analysis (have already !voted keep above).  ( ) @ : This is an interesting analysis, thanks for posting it.  I'm still mulling it over, but a first thought is that you're making a distinction on the copyright side of things.  Couldn't that be solved using vs. , or otherwise improving the attribution aspect of the file?  A second thought is that perhaps = is an alternative way to do this (sorry James!!).  As you know, I'm playing with at the moment - that template doesn't use this property, and it already auto-invokes the Artwork template for paintings (the original purpose of this property), I'll continue playing with it to see how well it can cope with these examples too.  Thanks.  ( ) @ : I have indeed also mulled over the = scenario, but I don't think that's a good fit as a file is not so much a digital surrogate in its nature - it's a digital photograph or scan that has the role/function of digital surrogate for a specific creative work which is indeed a more specific relationship than .  I'd also argue it's about more than just copyright and authorship (which indeed need to be modelled separately), but also about how eventually information about files should be displayed and attributed.  So I stick with my insistence on keeping and making it a subproperty of .  Cheers!  +1 to have copyright modelled separately.  I am also wondering if we with qualifiers can explain why and how it is a digital representation.  For example the scan technology, colors and lighting used.  And how to deal with a file that is a digititalisation not of the original work, but of a photograph of that work?  For example .  Is a black and white version a representation and if so how should we qualify that?  -- ( ) I 100% support Spinster's analysis (have already !voted keep above).  ( ) I 100% support Spinster's analysis (have already !voted keep above).  ( ) @ : This is an interesting analysis, thanks for posting it.  I'm still mulling it over, but a first thought is that you're making a distinction on the copyright side of things.  Couldn't that be solved using vs. , or otherwise improving the attribution aspect of the file?  A second thought is that perhaps = is an alternative way to do this (sorry James!!).  As you know, I'm playing with at the moment - that template doesn't use this property, and it already auto-invokes the Artwork template for paintings (the original purpose of this property), I'll continue playing with it to see how well it can cope with these examples too.  Thanks.  ( ) @ : I have indeed also mulled over the = scenario, but I don't think that's a good fit as a file is not so much a digital surrogate in its nature - it's a digital photograph or scan that has the role/function of digital surrogate for a specific creative work which is indeed a more specific relationship than .  I'd also argue it's about more than just copyright and authorship (which indeed need to be modelled separately), but also about how eventually information about files should be displayed and attributed.  So I stick with my insistence on keeping and making it a subproperty of .  Cheers!  +1 to have copyright modelled separately.  I am also wondering if we with qualifiers can explain why and how it is a digital representation.  For example the scan technology, colors and lighting used.  And how to deal with a file that is a digititalisation not of the original work, but of a photograph of that work?  For example .  Is a black and white version a representation and if so how should we qualify that?  -- ( ) @ : I have indeed also mulled over the = scenario, but I don't think that's a good fit as a file is not so much a digital surrogate in its nature - it's a digital photograph or scan that has the role/function of digital surrogate for a specific creative work which is indeed a more specific relationship than .  I'd also argue it's about more than just copyright and authorship (which indeed need to be modelled separately), but also about how eventually information about files should be displayed and attributed.  So I stick with my insistence on keeping and making it a subproperty of .  Cheers!  +1 to have copyright modelled separately.  I am also wondering if we with qualifiers can explain why and how it is a digital representation.  For example the scan technology, colors and lighting used.  And how to deal with a file that is a digititalisation not of the original work, but of a photograph of that work?  For example .  Is a black and white version a representation and if so how should we qualify that?  -- ( ) +1 to have copyright modelled separately. I am also wondering if we with qualifiers can explain why and how it is a digital representation. For example the scan technology, colors and lighting used. And how to deal with a file that is a digititalisation not of the original work, but of a photograph of that work? For example . Is a black and white version a representation and if so how should we qualify that? -- ( ) ###Output: ",0
keep,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P5826:   consensus to keep -- ( ) consensus to keep -- ( ) Comment Isn't the reverse of ?  ( ) .  Keep A dedicated property seems justified.  And connected properties for dissenting and concurring opinions too.  ( ) .  Keep A dedicated property seems justified.  And connected properties for dissenting and concurring opinions too.  ( ) .  I agree with that doesn't seem to be appropriate here.  seems to be nearer to the intended meaning but seems to be a bit complex for this usecase.  Given that there are lots of legal cases I vote Keep and endorse creating additional properties for ""dissenting opinion by"" and ""concurring opinion by"".  ❪ ❫ Keep per both voters.  ( ) I disagree both with using this property and with the proposed solution of having point to a generic class with a qualifier.  We have thousands of pages on Wikisource associated with majority opinions of court cases.  These pages should be linked to Wikidata items, given P50 statements, and linked to the cases.  -- ( ) ###Output: ",1
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P7288:   no support for deletion -- ( ) no support for deletion -- ( ) Keep as there was a consensus to create − ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P598:   consensus to delete -- ( ) consensus to delete -- ( ) Delete .  I agree with above.  -- Keep It's a summary of all the militar units commanded. Now is in use a . The P39 shows the different position, but in military use to show only high ranks position, not one per one of its commanded units. ( ) Delete Too hard to translate, note that I'm the most ""hate"" user of ""XXX of"" properties. -- ( ) Delete store information in inverse or use , but for the latter one would have to create items for the positions.  ( ) Delete XXX of should be fixed by qualifiers not creating vandalism properties.  -- Delete Redundant with . See as an example. Also can only be used for independent commands, not for or / Delete redundant, as described above. -- ( ) ###Output: ",2
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P6433:   consensus to keep -- ( ) consensus to keep -- ( ) Maybe we can change the formatter URL to web.archive.org instead of deleting it.  Is the website properly archived?  +1 -- ( ) +1 -- ( ) ?  so maybe keep.  -- ( ) Keep and deprecate. Keep and deprecate. ( ) Keep and deprecate. -- Deprecate then Delete .  We have enough longstanding online databases of species to link to, so little value is lost in deleting one property pointing to one dead website.  ( ) Delete We must face the facts.  Keep Over 12000 uses and with WP links, there are certainly archives of the site.  — ( ) 22:44, 23 December 2019 (UTC) ( ) Keep shutdown of other site is not reason to delete information in own site.  ( ) Keep never delete - but possibly with a warning that the database linked to may be out of date ( ) ###Output: ",1
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Scoresway_ice_hockey_person_ID_(archived)_(P6064):   consensus to keep -- ( ) consensus to keep -- ( ) A little Keep per above.  -- ( ) Had never more than 50 uses .. I'd tend to delete this --- Keep Available at scoresway.us.  I changed the formatter URL accordingly.  ( ) I reverted my removals aswell.  ( ) I reverted my removals aswell.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P8102_(P8102):   Deleted , given the concerns raised about the creation on the proposal and here, and that the property has been unused (though also explicitly marked as such).  ( ) Deleted , given the concerns raised about the creation on the proposal and here, and that the property has been unused (though also explicitly marked as such).  ( ) Speedy is the exact term.  Premature creation, but since it is a property and it seems to be approved by the community… I add an opposition in the proposal to signify that it is not enough to count the ""green dots"" of the discussion section.  — ( ) Speedy delete per above, creator's error.  -- ( ) Keep if a better solution isn't found. Problems related to RegEx, Subject item and Domain have been solved. So, there is mainly one problem, the oppose votes, which focus mainly on ""48 is a very small number for a property like this"". I substantially agree, but I also think that NASA is a valuable source and that creating a new property is the best solution to link it. I resume what I said in : given that there are : e.g. : e.g. : e.g. : e.g. : e.g. : e.g. : e.g. : e.g. considering only Former (maybe also Management) and Active Astronauts, I don't see an economic way to have Former and Active Astronauts in the same property; so, my conclusion was that, being Former Astronauts the great majority, we could readapt old P2030 for Former Astronauts and create a new property P8102 for Active Astronauts. If no better alternative is found, I think that the property should be kept. -- Keep Now that the property exists I don't see that it hurts anything to keep it.  I would have agreed with the suggestion to wait, but neither of the ""negative"" comments explicitly stated they opposed creation, so I don't think the creator did anything wrong here, it was a judgment call.  NASA did recently accept several thousand applications to become astronauts - - so I do think the number will be higher soon.  ( ) speedy delete Created by wrong parameters, just re-create it.  -- ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P3231_(P3231):   Deleted Consensus for deletion.  ( ) Deleted Consensus for deletion.  ( ) Delete as replaced.  -- ( ) Delete but we should first warn the wikis which seem to be using this property @ : ( ) Last user (except for usage in comments with {{ }} ) is arzwiki. I tried to notify them , but this page is not very active, unfortunately. -- ( ) @ : Not getting an immediate response does not mean the page is not active, waiting the nomination result, @ : Please advice, Thanks.  ( ) Last user (except for usage in comments with {{ }} ) is arzwiki.  I tried to notify them , but this page is not very active, unfortunately.  -- ( ) @ : Not getting an immediate response does not mean the page is not active, waiting the nomination result, @ : Please advice, Thanks. ( ) @ : Not getting an immediate response does not mean the page is not active, waiting the nomination result, @ : Please advice, Thanks. ( ) Delete per nom. -- ( ) Delete per nom.  @ , , , , : I will delete this property if there is still no oposition.  Good for you?  ( ) But first, this property should be removed from all items that use it.  Could it be done by a bot?  ( ) Yes, no oposition.  But first, this property should be removed from all items that use it.  Could it be done by a bot?  ( ) Yes, no oposition.  Delete ( ) Delete -- ( ) @ :, I completed the cleanup, you can now proceed with deletion. -- ( ) @ : there are still that use this property.  ( ) @ : cleaned remaining statements.  -- ( ) @ : there are still that use this property. ( ) @ : cleaned remaining statements. -- ( ) @ : cleaned remaining statements.  -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P4883_(P4883):   Consensus to delete — Martin ( · ) Consensus to delete — Martin ( · ) has also been affected by this change.  Have replacement properties been created?  ( ) is there a way to do a 1:1 mapping to their new schema (if there is one)?  Looks like archive.org got most of them so at the very least move the property to pointing there.  ( ) I added an archive.org formatter so Keep until someone has a better idea.  ( ) A proposal on a new property can be found .  -- ( ) All of the in German Wikipedia have been changed to the new IDs and could be imported automarically to Wikidata. -- ( ) I added an archive.org formatter so Keep until someone has a better idea.  ( ) A proposal on a new property can be found .  -- ( ) All of the in German Wikipedia have been changed to the new IDs and could be imported automarically to Wikidata. -- ( ) A proposal on a new property can be found .  -- ( ) All of the in German Wikipedia have been changed to the new IDs and could be imported automarically to Wikidata. -- ( ) Question Have all the old IDs been transferred to their new ID of the new property, @ :?  — ( ) Answer All the ID of and have been transferred into their new ID of .  There is, in my opinion, no further obstacle to the deletion of the two deprecated properties — ( ) Answer All the ID of and have been transferred into their new ID of .  There is, in my opinion, no further obstacle to the deletion of the two deprecated properties — ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  has_part(s)_of_the_class_(P2670):   request withdrawn --- request withdrawn --- Keep These properties have different meanings, it makes no sense to delete one because the other exists.  Consider the example item from P527.  ( ) @ The only difference between the properties is whether the are used on classes or instances.  It seems like they have different definitions but this difference can be accounted for by only using (unless you can find a situation in which both ( and are needed).  can already be inferred by and the number of values.  You do not need here because there are only the 3 sporting parts of a triathlon to be concerned with.  ( ) I agree with you on , however if they have different domains then by definition they are different properties.  Yes, we could use one property and say that when used in different contexts it means different things, but that (to me) is a bad practice which is actually more complex.  Taken to a logical extreme, we could have one property that means 10 different things depending on the presence of other properties, but it's an overly complex model.  It makes more sense to me for the property to have a clear meaning regardless of other properties on the subject.  ( ) Yep, I totally see where you're coming from and agree.  I'll give the example that caused me to propose this deletion in the first place.  I think I misunderstand how should be used in particular instances.  For example, am I using correctly on ?  ( ) @ The only difference between the properties is whether the are used on classes or instances.  It seems like they have different definitions but this difference can be accounted for by only using (unless you can find a situation in which both ( and are needed).  can already be inferred by and the number of values.  You do not need here because there are only the 3 sporting parts of a triathlon to be concerned with.  ( ) I agree with you on , however if they have different domains then by definition they are different properties.  Yes, we could use one property and say that when used in different contexts it means different things, but that (to me) is a bad practice which is actually more complex.  Taken to a logical extreme, we could have one property that means 10 different things depending on the presence of other properties, but it's an overly complex model.  It makes more sense to me for the property to have a clear meaning regardless of other properties on the subject.  ( ) Yep, I totally see where you're coming from and agree.  I'll give the example that caused me to propose this deletion in the first place.  I think I misunderstand how should be used in particular instances.  For example, am I using correctly on ?  ( ) I agree with you on , however if they have different domains then by definition they are different properties.  Yes, we could use one property and say that when used in different contexts it means different things, but that (to me) is a bad practice which is actually more complex.  Taken to a logical extreme, we could have one property that means 10 different things depending on the presence of other properties, but it's an overly complex model.  It makes more sense to me for the property to have a clear meaning regardless of other properties on the subject.  ( ) Yep, I totally see where you're coming from and agree.  I'll give the example that caused me to propose this deletion in the first place.  I think I misunderstand how should be used in particular instances.  For example, am I using correctly on ?  ( ) Yep, I totally see where you're coming from and agree.  I'll give the example that caused me to propose this deletion in the first place.  I think I misunderstand how should be used in particular instances.  For example, am I using correctly on ?  ( ) Keep While it may be a bit confusing, it's clearly a different meaning and should be kept.  ( ) prevent the use of on items with prevent the use of on items with require items with to have require items with to have require values of to have require values of to have prevent values of from having prevent values of from being I have one uncertainty which is that an item can have both and .  It might make more sense to say ""must have""  (rather than prevent ).  ( )  @ Hhhhhhh I just had this discussion on Telegram regarding , but if an item is truly just an instance and not a class, it should not have .  The item needs to be fixed if that's the case.  ( )  @ Hhhhhhh I just had this discussion on Telegram regarding , but if an item is truly just an instance and not a class, it should not have .  The item needs to be fixed if that's the case.  ( )  @ : I'm not sure I follow where you are getting these constraints from.  is not a class, but has parts of the class .  is perfectly fine applied to individual instances in cases like this, in fact that was my understanding of its main purpose.  ( )  Yes, that statement is valid, but is an and has already has a statement .  I would prefer a classification system where the parts of a class are always classes and the parts of instances are always instances.  Describing the part-whole relationship at the highest classification level and only at the highest level is the most-appropriate so that it is not unnecessarily repeated  (thus maybe causing confusion)  for subclasses or instances  (unless, the subclasses have parts that are more-distinct).  Also, as a seasoned Wikidata editor, you've probably realized that on a class could be used to constrain the types of parts an instance of that class has.  Making sure the whole classification system is in the best order and has no confusing or incorrect / statements between levels of classes is essential for implementing this system in the future.  ( )  @ Oh and I forgot to mention that I do realize the use of on .  However, I don't find it's necessary because the classes of the parts of an instance can easily be found by querying what they are an instance of.  We don't need to specify it explicitly.  It's unnecessary and can cause confusion.  Also, that would mean that we could do that to specify the class of the parts of any instance, which given how many instances there are out there, would absolutely be unnecessary.  If we're going to establish conventions we might as well do it with the thought that they are going to and should be used where they're needed and only where they're needed.  The current flexibility in the usage of creates a system that is much too flexible and not always beneficial to documentation of parts of a class or instance because of the confusion it can cause.  ( )  @ : I think you are misunderstanding here  (and I agree this can be confusing).  is a class with exactly four instances: the four inner planets of our solar system.  is the only stellar system where those four planets are found, and that class is specifically a class associated only with , nothing else.  So it is not a question of classes only being allowed to use , non-classes like need this property also to describe this sort of relationship.  ( )  @ But you don't need the property.  You can find the classes of the parts of an instance  (in the case of , )  by looking at the parts or querying for them.  ( )  I wonder if you don't assume that Wikidata "" "".  In any case, I think we can close this deletion discussion as everybody seems to agree on keeping it.  --- I guess I don't assume it's complete?  I'm not sure exactly what you mean.  Ya you should close.  Do you want to continue this on your talk page @ ?  ( )  ""But you don't need the property.  You can find the classes of the parts of an instance  (in the case of Solar System  (Q544), inner planet  (Q3504248))  by looking at the parts or querying for them"".  I think the above comment assumes that these are present  (or Wikidata is complete in this regard)  --- @ I understand your point.  Okay, maybe we don't need to limit to classes.  But what I do want to stop is the use of on classes.  Can we agree on that and move forward with the appropriate constraints?  ( )  I don't think this is a trivial question and here is not really the place to discuss it.  --- Yes, that statement is valid, but is an and has already has a statement .  I would prefer a classification system where the parts of a class are always classes and the parts of instances are always instances.  Describing the part-whole relationship at the highest classification level and only at the highest level is the most-appropriate so that it is not unnecessarily repeated  (thus maybe causing confusion)  for subclasses or instances  (unless, the subclasses have parts that are more-distinct).  Also, as a seasoned Wikidata editor, you've probably realized that on a class could be used to constrain the types of parts an instance of that class has.  Making sure the whole classification system is in the best order and has no confusing or incorrect / statements between levels of classes is essential for implementing this system in the future.  ( )  @ Oh and I forgot to mention that I do realize the use of on .  However, I don't find it's necessary because the classes of the parts of an instance can easily be found by querying what they are an instance of.  We don't need to specify it explicitly.  It's unnecessary and can cause confusion.  Also, that would mean that we could do that to specify the class of the parts of any instance, which given how many instances there are out there, would absolutely be unnecessary.  If we're going to establish conventions we might as well do it with the thought that they are going to and should be used where they're needed and only where they're needed.  The current flexibility in the usage of creates a system that is much too flexible and not always beneficial to documentation of parts of a class or instance because of the confusion it can cause.  ( )  @ : I think you are misunderstanding here  (and I agree this can be confusing).  is a class with exactly four instances: the four inner planets of our solar system.  is the only stellar system where those four planets are found, and that class is specifically a class associated only with , nothing else.  So it is not a question of classes only being allowed to use , non-classes like need this property also to describe this sort of relationship.  ( )  @ But you don't need the property.  You can find the classes of the parts of an instance  (in the case of , )  by looking at the parts or querying for them.  ( )  I wonder if you don't assume that Wikidata "" "".  In any case, I think we can close this deletion discussion as everybody seems to agree on keeping it.  --- I guess I don't assume it's complete?  I'm not sure exactly what you mean.  Ya you should close.  Do you want to continue this on your talk page @ ?  ( )  ""But you don't need the property.  You can find the classes of the parts of an instance  (in the case of Solar System  (Q544), inner planet  (Q3504248))  by looking at the parts or querying for them"".  I think the above comment assumes that these are present  (or Wikidata is complete in this regard)  --- @ I understand your point.  Okay, maybe we don't need to limit to classes.  But what I do want to stop is the use of on classes.  Can we agree on that and move forward with the appropriate constraints?  ( )  I don't think this is a trivial question and here is not really the place to discuss it.  --- @ : I think you are misunderstanding here  (and I agree this can be confusing).  is a class with exactly four instances: the four inner planets of our solar system.  is the only stellar system where those four planets are found, and that class is specifically a class associated only with , nothing else.  So it is not a question of classes only being allowed to use , non-classes like need this property also to describe this sort of relationship.  ( )  @ But you don't need the property.  You can find the classes of the parts of an instance  (in the case of , )  by looking at the parts or querying for them.  ( )  I wonder if you don't assume that Wikidata "" "".  In any case, I think we can close this deletion discussion as everybody seems to agree on keeping it.  --- I guess I don't assume it's complete?  I'm not sure exactly what you mean.  Ya you should close.  Do you want to continue this on your talk page @ ?  ( )  ""But you don't need the property.  You can find the classes of the parts of an instance  (in the case of Solar System  (Q544), inner planet  (Q3504248))  by looking at the parts or querying for them"".  I think the above comment assumes that these are present  (or Wikidata is complete in this regard)  --- @ I understand your point.  Okay, maybe we don't need to limit to classes.  But what I do want to stop is the use of on classes.  Can we agree on that and move forward with the appropriate constraints?  ( )  I don't think this is a trivial question and here is not really the place to discuss it.  --- @ But you don't need the property.  You can find the classes of the parts of an instance  (in the case of , )  by looking at the parts or querying for them.  ( )  I wonder if you don't assume that Wikidata "" "".  In any case, I think we can close this deletion discussion as everybody seems to agree on keeping it.  --- I guess I don't assume it's complete?  I'm not sure exactly what you mean.  Ya you should close.  Do you want to continue this on your talk page @ ?  ( )  ""But you don't need the property.  You can find the classes of the parts of an instance  (in the case of Solar System  (Q544), inner planet  (Q3504248))  by looking at the parts or querying for them"".  I think the above comment assumes that these are present  (or Wikidata is complete in this regard)  --- @ I understand your point.  Okay, maybe we don't need to limit to classes.  But what I do want to stop is the use of on classes.  Can we agree on that and move forward with the appropriate constraints?  ( )  I don't think this is a trivial question and here is not really the place to discuss it.  --- I wonder if you don't assume that Wikidata "" "". In any case, I think we can close this deletion discussion as everybody seems to agree on keeping it. --- I guess I don't assume it's complete?  I'm not sure exactly what you mean.  Ya you should close.  Do you want to continue this on your talk page @ ?  ( )  ""But you don't need the property.  You can find the classes of the parts of an instance  (in the case of Solar System  (Q544), inner planet  (Q3504248))  by looking at the parts or querying for them"".  I think the above comment assumes that these are present  (or Wikidata is complete in this regard)  --- @ I understand your point.  Okay, maybe we don't need to limit to classes.  But what I do want to stop is the use of on classes.  Can we agree on that and move forward with the appropriate constraints?  ( )  I don't think this is a trivial question and here is not really the place to discuss it.  ---  I guess I don't assume it's complete?  I'm not sure exactly what you mean.   Ya you should close.  Do you want to continue this on your talk page @ ?  ( )  ""But you don't need the property. You can find the classes of the parts of an instance (in the case of Solar System (Q544), inner planet (Q3504248)) by looking at the parts or querying for them"".  I think the above comment assumes that these are present (or Wikidata is complete in this regard) --- @ I understand your point. Okay, maybe we don't need to limit to classes. But what I do want to stop is the use of on classes. Can we agree on that and move forward with the appropriate constraints? ( ) I don't think this is a trivial question and here is not really the place to discuss it. --- ""But you don't need the property. You can find the classes of the parts of an instance (in the case of Solar System (Q544), inner planet (Q3504248)) by looking at the parts or querying for them"".  I think the above comment assumes that these are present (or Wikidata is complete in this regard) --- @ I understand your point. Okay, maybe we don't need to limit to classes. But what I do want to stop is the use of on classes. Can we agree on that and move forward with the appropriate constraints? ( ) I don't think this is a trivial question and here is not really the place to discuss it. --- @ I understand your point.  Okay, maybe we don't need to limit to classes.  But what I do want to stop is the use of on classes.  Can we agree on that and move forward with the appropriate constraints?  ( ) I don't think this is a trivial question and here is not really the place to discuss it.  --- I don't think this is a trivial question and here is not really the place to discuss it. --- ###Output: ",0
keep,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P460:   Kept per consensus here.  There are open issues, but they would be better dealt with on the talk page or through an RfC.  Thanks.  ( ) Kept per consensus here.  There are open issues, but they would be better dealt with on the talk page or through an RfC.  Thanks.  ( ) Keep Subjective, but sometimes useful.  Eg - some hamlet have item as settlement and second as street.  According to some users are settlement and street different concepst which cannot be merged, accordin some others are both the same.  And whic other property use for ?  ( ) ""Sometimes useful"" is a weak argument.  ""Many times"" it is harmful.  For example there is a very passionate effort to claim personal names in different languages to be ""same as"".  If John is same (sorry ""said to be the same"") with Jean , then we can simply use the same logic to say English is said to be the same with French !  (BTW we can add the Turkish name Can to this couple, as it is pronounced the same way as John, although it means ""soul"", ""life"". :)  In the same line with the parenthesis, people tend to claim a ""sameness"" among names which are written   in a similar way.  In Turkish, my native language, we have the name Anıl , which means ""be remembered, be recalled""; a wish that parents make when they name their newborn, so that s/he would be remembered -as a good person- after her/his life adventure in this world.  It is not ""same"" nor ""said to be same as"" the name Anil which belongs to another culture and certainly has some meaning that I ignore.  I simply doubt it may mean ""be remembered"", does it?  Is there any user who knows the meaning of the name ""Anil"" in its native language?  I am also against the other property that claims ""name without diacritical marks"" etc nonsense.  ""Anil"" does not have any such relation of that kind with ""Anıl"".  BTW Anıl does not have any diacritical mark, either...  Look, classifying things, trying to make a databank means separating similar things, not putting different things into the same basket.  ""Similar"" means ""different"".  I hope I am clear enough.  -- ( ) Keep Subjective, but sometimes useful.  Eg - some hamlet have item as settlement and second as street.  According to some users are settlement and street different concepst which cannot be merged, accordin some others are both the same.  And whic other property use for ?  ( ) ""Sometimes useful"" is a weak argument.  ""Many times"" it is harmful.  For example there is a very passionate effort to claim personal names in different languages to be ""same as"".  If John is same (sorry ""said to be the same"") with Jean , then we can simply use the same logic to say English is said to be the same with French !  (BTW we can add the Turkish name Can to this couple, as it is pronounced the same way as John, although it means ""soul"", ""life"". :)  In the same line with the parenthesis, people tend to claim a ""sameness"" among names which are written   in a similar way.  In Turkish, my native language, we have the name Anıl , which means ""be remembered, be recalled""; a wish that parents make when they name their newborn, so that s/he would be remembered -as a good person- after her/his life adventure in this world.  It is not ""same"" nor ""said to be same as"" the name Anil which belongs to another culture and certainly has some meaning that I ignore.  I simply doubt it may mean ""be remembered"", does it?  Is there any user who knows the meaning of the name ""Anil"" in its native language?  I am also against the other property that claims ""name without diacritical marks"" etc nonsense.  ""Anil"" does not have any such relation of that kind with ""Anıl"".  BTW Anıl does not have any diacritical mark, either...  Look, classifying things, trying to make a databank means separating similar things, not putting different things into the same basket.  ""Similar"" means ""different"".  I hope I am clear enough.  -- ( ) ""Sometimes useful"" is a weak argument.  ""Many times"" it is harmful.  For example there is a very passionate effort to claim personal names in different languages to be ""same as"".  If John is same (sorry ""said to be the same"") with Jean , then we can simply use the same logic to say English is said to be the same with French !  (BTW we can add the Turkish name Can to this couple, as it is pronounced the same way as John, although it means ""soul"", ""life"". :)  In the same line with the parenthesis, people tend to claim a ""sameness"" among names which are written   in a similar way.  In Turkish, my native language, we have the name Anıl , which means ""be remembered, be recalled""; a wish that parents make when they name their newborn, so that s/he would be remembered -as a good person- after her/his life adventure in this world.  It is not ""same"" nor ""said to be same as"" the name Anil which belongs to another culture and certainly has some meaning that I ignore.  I simply doubt it may mean ""be remembered"", does it?  Is there any user who knows the meaning of the name ""Anil"" in its native language?  I am also against the other property that claims ""name without diacritical marks"" etc nonsense.  ""Anil"" does not have any such relation of that kind with ""Anıl"".  BTW Anıl does not have any diacritical mark, either...  Look, classifying things, trying to make a databank means separating similar things, not putting different things into the same basket.  ""Similar"" means ""different"".  I hope I am clear enough.  -- ( ) Keep but perhaps it should have a constraint requiring a source? I agree with that it seems to be overused right now for things that really are not the same concept. But for example sometimes we have two different items that may be for the same person, place, (or species as with ), but maybe not, and different sources disagree. In such a case this property really is needed. ( ) Comment Maybe it needs a better label. 'is ""the same"" as' here means that it's different. --- Comment the synonym list for this makes no sense to me.  If this property means ""this item is said to be the same as that item, but it's uncertain or disputed"" , then it is certainly not a property that means ""equivalent to"", ""similar to"" or ""the same as"".  In fact, it's the exact opposite: if it's truly ""equivalent"", then it's not ""said to be the same"".  It is the same.  What's actually happening is that this one property is smashing together multiple concepts: These two items are wrongly ""sometimes"" (by who? citation needed!) mistaken or conflated with each other.  This is a hard one to separate, because whether you're mistaking something for something else or conflating it really depends on whether the source ""saying it's the same"" knows the items are separate, so we can't easily tell from this end.  Possible examples (though arguable, as I say): ""Conflation"": and ; ""Mistaken"": and In ""some contexts"" (e.g. according to certain people/source) no distinction is drawn between them: and The two items are analogous items at different times (a historical equivalent): and One item is a subclass of another that only applies in ""some domain"": and One item is a ""local"" definition of the other: e.g. the time zones ( and are the same but GMT+2 isn't a class, so CEST can't be a subclass) One item is a part of or overlaps with to the other: and The two items are actually the same thing and should to be merged: and The two items are equivalent in some technical sense: Mathematical/logical (e.g. and ) These can also be possibly equivalent, but not proved : and (these two don't use P460).  Functional (e.g. and ) The two items are homographs in the same language: and The two items are cognates in different languages: and (i.e. most of the names) The two items are near-homographs in the same language that may be confused/mis-spelled mainly due to orthographic similarity rather than semantic: and The two item are ""false friends"" in different languages (i.e. they're homographs or near-homographs that are not cognates): and These two items are wrongly ""sometimes"" (by who? citation needed!) mistaken or conflated with each other.  This is a hard one to separate, because whether you're mistaking something for something else or conflating it really depends on whether the source ""saying it's the same"" knows the items are separate, so we can't easily tell from this end.  Possible examples (though arguable, as I say): ""Conflation"": and ; ""Mistaken"": and ""Conflation"": and ; ""Mistaken"": and In ""some contexts"" (e.g. according to certain people/source) no distinction is drawn between them: and The two items are analogous items at different times (a historical equivalent): and One item is a subclass of another that only applies in ""some domain"": and One item is a ""local"" definition of the other: e.g. the time zones ( and are the same but GMT+2 isn't a class, so CEST can't be a subclass) One item is a part of or overlaps with to the other: and The two items are actually the same thing and should to be merged: and The two items are equivalent in some technical sense: Mathematical/logical (e.g. and ) These can also be possibly equivalent, but not proved : and (these two don't use P460).  Functional (e.g. and ) Mathematical/logical (e.g. and ) These can also be possibly equivalent, but not proved : and (these two don't use P460).  These can also be possibly equivalent, but not proved : and (these two don't use P460).  Functional (e.g. and ) The two items are homographs in the same language: and The two items are cognates in different languages: and (i.e. most of the names) The two items are near-homographs in the same language that may be confused/mis-spelled mainly due to orthographic similarity rather than semantic: and The two item are ""false friends"" in different languages (i.e. they're homographs or near-homographs that are not cognates): and And some are just flat out wrong: and and Much of the time, it's hard to say exactly which category they fall into.  So, basically, it's an enormous mess of ~270k statements and there's no way to really tell what any given statement means.  I'd say ""migrate to correct statements then delete this one"" would be the right course of action, but I can't really see that happening.  Examples of correct statements might be ""cognate of"", ""mathematically equivalent to"", ""functionally equivalent to"", ""homograph of"", etc.  Proposal : Since stripping this property is unlikely to be practical given the huge usage, perhaps assigning a mandatory qualifier constraint and adding a set of qualifiers to establish what the ""sameness"" being claimed actually is .  For example: and : , qualified by → ""mathematical equivalence"".  and : , qualified by → ""cognate"".  and : , qualified by → ""mathematical equivalence"".  and : , qualified by → ""cognate"".  And all these roles must be subclasses of, I guess, .  Advantage of this: easy to query, semantically useful and one item can have many P460's with different qualfiers (e.g. is a homograph of , a cognate of and a mis-spelling of ) ( ) See for the meaning of the Indian given name Anil and for the Turkish given name Anıl .  ( Wind vs be remembered .) -- ( ) I think you've hit the nail on the head here and if we were thinking big we would go with more limited scope sub-properties for all of these cases.  I've said before elsewhere, but properties with a conditional meaning (interpreted differently depending on subject) are a ""bad data smell"" to me. ( ) See for the meaning of the Indian given name Anil and for the Turkish given name Anıl .  ( Wind vs be remembered .) -- ( ) See for the meaning of the Indian given name Anil and for the Turkish given name Anıl . ( Wind vs be remembered .) -- ( ) See for the meaning of the Indian given name Anil and for the Turkish given name Anıl .  ( Wind vs be remembered .) -- ( ) I think you've hit the nail on the head here and if we were thinking big we would go with more limited scope sub-properties for all of these cases.  I've said before elsewhere, but properties with a conditional meaning (interpreted differently depending on subject) are a ""bad data smell"" to me. ( ) My understanding of this property is that it's for two items, for which it is a matter of dispute whether or not the respective topic are actually the same thing as each other.  The given sources are those which say they're the same.  (If everyone agreed they were the same, it wouldn't be a separate item, it would just have an alias.)  The ""said to be"" is there because people seem to prefer (?) avoiding giving disputed statements without qualifying it in the property name, when possible.  Unfortunately, the property is currently misused in some areas.  I say Keep , clarify intended use, and clean up.  -- ( ) @ when you say clean up, what exactly does that entail?  Keeping track of which of over 1/4 million instances actually do refer to the concept of ""have disputed equivalence"", rather than one of a large palette of other conflated relationships, is going to be rather difficult, no?  The only way I can think of is to start adding qualifiers to items which have been verified to be valid.  At which point we might as well allow other qualifiers to capture the alternative senses.  ( ) @ when you say clean up, what exactly does that entail?  Keeping track of which of over 1/4 million instances actually do refer to the concept of ""have disputed equivalence"", rather than one of a large palette of other conflated relationships, is going to be rather difficult, no?  The only way I can think of is to start adding qualifiers to items which have been verified to be valid.  At which point we might as well allow other qualifiers to capture the alternative senses.  ( ) Keep per above ( ) keep immediatly — ( ) Keep This property's use is to document entities that are often thoughtfully mixed up in society.  This is culturally significant and therefore appropriate to document.  If you want to stop arbitrary usage (which I haven't seen much of really) I'd recommend requiring a reference.  ( ) @ you haven't addressed the issue that this is used for far more than just things ""thoughtfully mixed up in society"" (which I do not deny is a useful piece of data).  As it stands, the semantic content is of a given statement is minimal, because you cannot tell what the statement actually is supposed to mean .  Yes, a human can usually intuit it, but that's not what Wikidata is for.  ( ) @ you haven't addressed the issue that this is used for far more than just things ""thoughtfully mixed up in society"" (which I do not deny is a useful piece of data).  As it stands, the semantic content is of a given statement is minimal, because you cannot tell what the statement actually is supposed to mean .  Yes, a human can usually intuit it, but that's not what Wikidata is for.  ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P1969:   Deleting property — Martin ( · ) Deleting property — Martin ( · ) I don't know about the original proposal but it's used over 17,000 times and the site seems to be real (and in Dutch).  I see you're proposing the NL wikipedia page for deletion, but Wikidata criteria are a little different from Wikipedia's.  ( ) The website is real, yes.  But so is .  The say nothing about a condition or limitations, but I presume that there needs to be more about a website than just its existance before a property can be based on it?  ( ) Is the information on the website reliable or not?  ( ) I don't know.  It seems to be copied from IMDb, so, sure.  Is that all it takes?  Copy information from one database to start another one and have it made a property?  ( ) The website is real, yes.  But so is .  The say nothing about a condition or limitations, but I presume that there needs to be more about a website than just its existance before a property can be based on it?  ( ) Is the information on the website reliable or not?  ( ) I don't know.  It seems to be copied from IMDb, so, sure.  Is that all it takes?  Copy information from one database to start another one and have it made a property?  ( ) Is the information on the website reliable or not?  ( ) I don't know.  It seems to be copied from IMDb, so, sure.  Is that all it takes?  Copy information from one database to start another one and have it made a property?  ( ) I don't know.  It seems to be copied from IMDb, so, sure.  Is that all it takes?  Copy information from one database to start another one and have it made a property?  ( ) Thank you .  Can you confirm that no information will be lost if this property is deleted?  — Martin ( · ) Yes, assuming that is correct (list items with a director-ID but without a person-ID) and that the query returns 0 records right before the property is deleted.  ( ) Copy that, I think we can safely delete this property then — Martin ( · ) Yes, assuming that is correct (list items with a director-ID but without a person-ID) and that the query returns 0 records right before the property is deleted.  ( ) Copy that, I think we can safely delete this property then — Martin ( · ) Copy that, I think we can safely delete this property then — Martin ( · ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P5105_(P5105):   Consensus to merge to and delete — Martin ( · ) Consensus to merge to and delete — Martin ( · ) ( ) ( ) 21:38, 2 November 2013 (UTC) ( • • )-- 01:13, 3 November 2013 (UTC) (was Hym411) ( ) 06:32, 3 November 2013 (UTC) ( ) 08:28, 9 November 2013 (UTC) ( ) 12:36, 9 November 2013 (UTC) ( ) ( ) 13:59, 25 November 2013 (UTC) ( ) 12:31, 14 December 2013 (UTC) ( ) 21:48, 17 December 2013 (UTC) ( ) 16:30, 14 February 2014 (UTC) 17:39, 17 August 2014 (UTC) ( ) 21:34, 30 August 2015 (UTC) ( ) 16:13, 9 December 2015 (UTC) 18:39, 26 June 2016 (UTC) 22:48, 8 July 2016 (UTC) ( ) 07:32, 15 August 2016 (UTC) ( ) 16:36, 5 September 2016 (UTC) ( | ) 01:33, 10 November 2016 (UTC) ( ) 23:00, 1 February 2017 (UTC) ( ) 09:09, 2 February 2017 (UTC) ( ) 18:17, 21 May 2017 (UTC) ( ) 13:56, 9 June 2017 (UTC) 10:26, 18 June 2017 (UTC) ( ) 05:01, 28 August 2017 (UTC) ( ) 06:04, 22 September 2017 (UTC) ( ) 17:48, 3 June 2018 (UTC) ( ) 23:51, 13 July 2018 (UTC) ( ) 19:29, 17 December 2018 (UTC) ( ) 13:13, 21 May 2019 (UTC) ( ) 00:25, 1 May 2020 (UTC) ( ) 14:20, 26 July 2020 (UTC) ( ) 18:47, 30 July 2020 (UTC) ( ) 15:21, 29 August 2020 (UTC) ( ) 22:04, 20 December 2020 (UTC) ( ) 16:27, 5 September 2021 (UTC) ( ) 07:46, 3 September 2022 (UTC) ( ) 05:17, 14 October 2022 (UTC) ( ) 09:49, 10 August 2023 (UTC) ( ) 09:08, 07 September 2023 (UTC) 16:16, 21 November 2023 (UTC) ( ) 07:02, 16 December 2023 (UTC) ( ) 14:06, 15 May 2024 (UTC) ( ) 14:41, 31 May 2024 (UTC) ( ) 17:52, 4 August 2024 (UTC) ( ) Notified and especially, because it's used by , @ , : ^^ -- ( ) Delete after data migration.  Keep Wikidata have lot of external identifiers, why need deletion?  -- ( ) Delete @ : Because there's a more useful identifier as replacement. -- ( ) Delete per Andy.  This is an item property btw, not an external identifier property.  ( ) Delete after data migration.  Keep The general property explicitly says ""use subproperties where available"" and has constraints that conflict with their use.  No apparent benefit to generalisation over specificity so data migration would just be makework.  ( ) Delete The specific property (P5105) is largely redundant to the general property (P5606).  An argument could be made that the general property should be deleted instead and replaced with specific properties for each network, but here the relationship with the operator can be inferred from the station category items, so including the operator as part of the property is functionally unnecessary.  ( ) Keep per Thryduulf ( ) Keep clear scope.  Enables reports with @ :'s Krbot.   --- Delete replacement available, no need to create any subproperties for anything that don't affect URL schemes. -- Keep per above ( ) @ , : ""Enables reports with someone's bot"" isn't a valid keep reason, we can ask them on Github to request cancelling their relative codes.  -- ( ) @ , : ""Enables reports with someone's bot"" isn't a valid keep reason, we can ask them on Github to request cancelling their relative codes. -- ( ) Delete As values are only items, merge em back won't hurt anything.  -- Delete No need to fragment data into multiple properties. -- ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P5420_(P5420):   There is consensus that these two properties should be merged with a slight preference for keeping the older property — Martin ( · ) There is consensus that these two properties should be merged with a slight preference for keeping the older property — Martin ( · ) I guess the new property has a slightly larger scope.  Otherwise, I would have kept the earlier one.  --- Oppose deleting and Support deleting instead. It is better to remove the newer duplicate property than the older one, as it is more likely that the old property ID is used externally in e.g. SPARQL queries posted on other websites. -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  third-party_formatter_URL_(P3303):   No consensus .  There is consensus that the distinction between first-party and third-party links is not useful.  However there is not a consensus to delete this property shown in this discussion!  As the discussion has been open since 2020 I am closing it now.  If there is a clear plan for this property in future, then please start a new request — Martin ( · ) No consensus .  There is consensus that the distinction between first-party and third-party links is not useful.  However there is not a consensus to delete this property shown in this discussion!  As the discussion has been open since 2020 I am closing it now.  If there is a clear plan for this property in future, then please start a new request — Martin ( · ) Is there some Wikibase code change that allows that?  --- @ : Maybe the name should be modified, but I don't see the purpose of having multiple P1630's on a property. The Wikibase UI will only use one of them, and I'm not sure it currently correctly selects the preferred one (there's a delay in any case, so it's complex to check). The advantage of a separate P3303 is that it makes clear that the entity making use of it needs to do the formatting themselves, the Wikibase UI won't help. Merging with P1630 will confuse that. ( ) If Wikibase can select the preferred format over multiple claims, I'll support it. -- Keep It is important to distinguish primary 'official' formatter and the third party formatters.  But it would be nice to have a tool/gadget to display external links also from third-party formatters. -- ( ) Delete @ : No need to ""distinguish"", we should be neutral on every URL schemes. -- ( ) Delete We don't have a rule that can only be filled with official formatter urls.  If we want to store information about some formatter urls being official we can do that better explicitely via qualifiers.  In addition we can use the preferred rank to chose the formatter url that's used by default.  ❪ ❫ Can somebody test/confirm that Wikidata's UI does correctly select the preferred Formatter URL value, if there are several?  ( ) I thought deprecation is needed to avoid that a former P1630 value is being used, that is: one can't add a new value with preferred rank to have these selected (as we usually do).  --- FYI I added a preferred formatter URL a couple of days ago to and it DOES seem to have replaced the original one in the UI (after a few days to let it propagate). We might want to test some more, but it looks like maybe this issue is actually ok now. ( ) I thought deprecation is needed to avoid that a former P1630 value is being used, that is: one can't add a new value with preferred rank to have these selected (as we usually do). --- FYI I added a preferred formatter URL a couple of days ago to and it DOES seem to have replaced the original one in the UI (after a few days to let it propagate).  We might want to test some more, but it looks like maybe this issue is actually ok now.  ( ) FYI I added a preferred formatter URL a couple of days ago to and it DOES seem to have replaced the original one in the UI (after a few days to let it propagate).  We might want to test some more, but it looks like maybe this issue is actually ok now.  ( ) I feel like there is something important missing in this discussion.  There are multiple use cases at play:  1. The built-in functionality of linkifying the property value.  2. Secondary links to various more- or less- related websites/tools using the same identifier.  I completely agree the current official distinction between #1 and #2 (#1 is “first-party/official”, #2 is “third-party/unofficial”) is wrong (and that distinction is not even important or interesting) and does not match the current usage.  What we need is one linkifying URL template (OK, we could use the preferred rank for that), plus a potentially unbounded set of URL templates with an agreed-upon way to indicate where that URL leads.  I mean, is nice but in fact, I don’t really care.  What I’d like to have is a drop-down menu next to each statement, showing me the links to various online book databases, libraries, e-shops, whatever (now, for the specific case of ISBNs, we outsourced this job to which is the “official formatter” for ISBNs… funny, right?).  Ditto for DOIs, OIDs, MeSH codes, … So, sure, we might merge P1630 and P3303 and use the rank to mark the primary linkifier.  But I think it is not the greatest priority.  For now, I’d say Keep and rename both to indicate the distinction is not first-party/third-party, but auto-linkifier/additional links (cf. ArthurPSmith above).  Then, let’s use (or anything else) for each of these additional URLs, and then let’s build a gadget (or Wikibase core functionality) to use the data in the property.  That would be useful.  -- ( ) @ : I like this idea of a gadget to make these ""live"" - I think we'd need an additional qualifier though to label the links in a drop-down list, no?  ( ) @ : Yes, that’s exactly what I meant with the note about the qualifier.  Not because I’d consider P137 to be a great choice but it’s apparently already used for this, see e.g. , , , ( used as well, e.g. and have overlapping semantics with this, I guess.) -- ( ) Screenshot of the linking gadget OK, I created a prototype implementation of that and I’m fairly happy with the result. You can test it by to . -- ( ) @ : just noting that your suggested gadget sounds a little like , which shows these links even if you don't start from Wikidata.  -- ( ) It seems to me EE works “inversely” in a sense, doesn’t it?  I.e. on any page on Internet, it displayes whether it matches any formatter of any Wikidata property.  On the other hand, my gadget displays next to every external-id property on a Wikidata item page links to all corresponding formatter URLs.  I added a screenshot.  → -- ( ) @ : I like this idea of a gadget to make these ""live"" - I think we'd need an additional qualifier though to label the links in a drop-down list, no?  ( ) @ : Yes, that’s exactly what I meant with the note about the qualifier.  Not because I’d consider P137 to be a great choice but it’s apparently already used for this, see e.g. , , , ( used as well, e.g. and have overlapping semantics with this, I guess.) -- ( ) Screenshot of the linking gadget OK, I created a prototype implementation of that and I’m fairly happy with the result. You can test it by to . -- ( ) @ : Yes, that’s exactly what I meant with the note about the qualifier.  Not because I’d consider P137 to be a great choice but it’s apparently already used for this, see e.g. , , , ( used as well, e.g. and have overlapping semantics with this, I guess.) -- ( ) Screenshot of the linking gadget OK, I created a prototype implementation of that and I’m fairly happy with the result. You can test it by to . -- ( ) Screenshot of the linking gadget OK, I created a prototype implementation of that and I’m fairly happy with the result.  You can test it by to .  -- ( ) @ : just noting that your suggested gadget sounds a little like , which shows these links even if you don't start from Wikidata. -- ( ) It seems to me EE works “inversely” in a sense, doesn’t it?  I.e. on any page on Internet, it displayes whether it matches any formatter of any Wikidata property.  On the other hand, my gadget displays next to every external-id property on a Wikidata item page links to all corresponding formatter URLs.  I added a screenshot.  → -- ( ) It seems to me EE works “inversely” in a sense, doesn’t it?  I.e. on any page on Internet, it displayes whether it matches any formatter of any Wikidata property.  On the other hand, my gadget displays next to every external-id property on a Wikidata item page links to all corresponding formatter URLs.  I added a screenshot.  → -- ( ) @ : It also works from WD items, and it does show multiple outlinks (e.g. to Twitter/Keybase/Scholia/Unavatar) if it rates them high enough (usually when they have a or a matching language).  See this screenshot.  I haven't advertised this feature much - perhaps I should!  -- ( ) @ : It also works from WD items, and it does show multiple outlinks (e.g. to Twitter/Keybase/Scholia/Unavatar) if it rates them high enough (usually when they have a or a matching language).  See this screenshot.  I haven't advertised this feature much - perhaps I should!  -- ( ) @ : It also works from WD items, and it does show multiple outlinks (e.g. to Twitter/Keybase/Scholia/Unavatar) if it rates them high enough (usually when they have a or a matching language).  See this screenshot.  I haven't advertised this feature much - perhaps I should!  -- ( ) @ : It also works from WD items, and it does show multiple outlinks (e.g. to Twitter/Keybase/Scholia/Unavatar) if it rates them high enough (usually when they have a or a matching language).  See this screenshot.  I haven't advertised this feature much - perhaps I should!  -- ( ) Keep per Jklamo and Mormegil, whose comments I completely support. -- Delete Per Liuxinyu970226 and ChristianKl.  -- ( ) Placeholder Keep for now.  I use this as part of the decision making in , so have a preference for not doing extra work if there is a way of reconceiving of the difference between these two properties. -- ( ) Keep - I use and its excellent for a property like were we lack a ""EU"" formatter but maybe have formatters for some countries like - ( ) Keep ( ) ( ) ( ) Delete As others have pointed out isn't limited to first-party URLs, deletion of would therefore lead to more homogeneous data.  We could use and as qualifiers to distinguish the nature of each formatter-URL.  ( ) Delete As others have pointed out, this property can be replaced with a qualifier at no loss of functionality, and probably should.  ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P8279_(P8279):   Merge into and delete — Martin ( · ) Merge into and delete — Martin ( · ) @ : Comment .  Unfortunately, ag.ru and RAWG are not quite the same databases.  Yes, ag.ru uses the same and interface as RAWG, but the new version of Absolute Games is different in that it has editorial reviews from the old version ( , ), while RAWG does not ( ).  I'm not sure about the old database either, because if the new one has reviews from the old version, then it makes no sense to create a new property.  As for removing this particular property, I'm not sure if it's worth it as we can still use it as the old database by changing the formatter URL.  By the way, maybe we should also ask the members of the on ruwiki what they think of it, and which of these versions is preferable, the old one or the new one?  If we conclude that we don't need the new version, then we can delete it or rename Absolute Games ID to Absolute Games ID (old version)/Old.ag.ru ID and use RAWG database for the new games only.  Regards ( ) @ : looks like , while RAWG have over 625k games in database.  If we'll keep P8279, there would be 620k pairs of identical links.  I think deleting P8279 and creating property for old.ag.ru is more optimal solution.  If we're considering those reviews important.  ( ) @ : P8279 currently has a total of .  This is not so much and these links can be removed using .  In order not to create a separate property, we can use this one if we reach a consensus to rename it from Absolute Games ID to old.ag.ru ID  (if it can be done, of course) and changing the formatter URL from to .  What do you think?  As far as I can see, the colleague who originally proposed this property .  Regards ( ) @ , I'm not sure if it's okay to change a property midway like that.  And I'm also not sure wherther those reviews are important (we usually don't keep track of other review sources, like Polygon or PCGamesN, only databases with useful information).  If you're sure it's okay, I don't mind.  As I said before, keeping one property for RAWG and one property for old AG sounds reasonable for me. ( ) @ :  Okay, since the renaming option is not yet the best solution to the problem, I don't mind removing this property, and we can propose a new one.  Regards ( ) @ : looks like , while RAWG have over 625k games in database.  If we'll keep P8279, there would be 620k pairs of identical links.  I think deleting P8279 and creating property for old.ag.ru is more optimal solution.  If we're considering those reviews important.  ( ) @ : P8279 currently has a total of .  This is not so much and these links can be removed using .  In order not to create a separate property, we can use this one if we reach a consensus to rename it from Absolute Games ID to old.ag.ru ID  (if it can be done, of course) and changing the formatter URL from to .  What do you think?  As far as I can see, the colleague who originally proposed this property .  Regards ( ) @ , I'm not sure if it's okay to change a property midway like that.  And I'm also not sure wherther those reviews are important (we usually don't keep track of other review sources, like Polygon or PCGamesN, only databases with useful information).  If you're sure it's okay, I don't mind.  As I said before, keeping one property for RAWG and one property for old AG sounds reasonable for me. ( ) @ :  Okay, since the renaming option is not yet the best solution to the problem, I don't mind removing this property, and we can propose a new one.  Regards ( ) @ : P8279 currently has a total of .  This is not so much and these links can be removed using .  In order not to create a separate property, we can use this one if we reach a consensus to rename it from Absolute Games ID to old.ag.ru ID  (if it can be done, of course) and changing the formatter URL from to .  What do you think?  As far as I can see, the colleague who originally proposed this property .  Regards ( ) @ , I'm not sure if it's okay to change a property midway like that.  And I'm also not sure wherther those reviews are important (we usually don't keep track of other review sources, like Polygon or PCGamesN, only databases with useful information).  If you're sure it's okay, I don't mind.  As I said before, keeping one property for RAWG and one property for old AG sounds reasonable for me. ( ) @ :  Okay, since the renaming option is not yet the best solution to the problem, I don't mind removing this property, and we can propose a new one.  Regards ( ) @ , I'm not sure if it's okay to change a property midway like that.  And I'm also not sure wherther those reviews are important (we usually don't keep track of other review sources, like Polygon or PCGamesN, only databases with useful information).  If you're sure it's okay, I don't mind.  As I said before, keeping one property for RAWG and one property for old AG sounds reasonable for me. ( ) @ :  Okay, since the renaming option is not yet the best solution to the problem, I don't mind removing this property, and we can propose a new one.  Regards ( ) @ :  Okay, since the renaming option is not yet the best solution to the problem, I don't mind removing this property, and we can propose a new one.  Regards ( ) @ : By the way, there is of Ag.ru related to personalities of the gaming industry.  What should we do with this property?  Regards ( ) @ , I'd probably reorganize it into RAWG.io property as well.  As far as I see, some descriptions are translated to Russian (Gabe Newell: ), but most of them are completely identical (Jesper Kyd: ), no point in linking both.  @ , I'd probably reorganize it into RAWG.io property as well.  As far as I see, some descriptions are translated to Russian (Gabe Newell: ), but most of them are completely identical (Jesper Kyd: ), no point in linking both.  Moreover, AG and RAWG IDs are identical as well, right?  We usually keep only one property in that case as far as I'm concerned.  For instance, we don't have a separate property for GameRankings because it's the same to GameFAQs.  And we also don't have a property for SteamDB because it uses application ID from Steam.  Please correct me if I'm wrong.  ( ) @ : That's right, they are completely identical.  In this case, only one database should be used, and that is RAWG.  Regards ( ) Moreover, AG and RAWG IDs are identical as well, right?  We usually keep only one property in that case as far as I'm concerned.  For instance, we don't have a separate property for GameRankings because it's the same to GameFAQs.  And we also don't have a property for SteamDB because it uses application ID from Steam.  Please correct me if I'm wrong.  ( ) @ : That's right, they are completely identical.  In this case, only one database should be used, and that is RAWG.  Regards ( ) @ : That's right, they are completely identical.  In this case, only one database should be used, and that is RAWG.  Regards ( ) I don't have any specific comment.  Have no objection to any further decision.  -- ( | ) @ , : sorry about the slow response on this.  I just looked at a random example .  Changing the formatter link to produces a 404 error for me: So this can't be changed or perhaps I am misunderstanding your suggestion?  — Martin ( · ) @ , old.ag.ru had different IDs, but modern ag.ru has the same IDs to (that's basically two web interfaces for the same database).  My suggestion was to merge into basically, and Kirilloparma's suggestion was to re-organize to link at old.ag.ru (after we'll move all the current values to ).  Looks like noone minds both of these suggestions, so I can do the first part.  ( ) Yes please, do the merge.  There is consensus for that part.  I think perhaps the identifier for old.ag.ru should go through a new property proposal, if anyone thinks that would be worthwhile — Martin ( · ) @ , old.ag.ru had different IDs, but modern ag.ru has the same IDs to (that's basically two web interfaces for the same database).  My suggestion was to merge into basically, and Kirilloparma's suggestion was to re-organize to link at old.ag.ru (after we'll move all the current values to ).  Looks like noone minds both of these suggestions, so I can do the first part.  ( ) Yes please, do the merge.  There is consensus for that part.  I think perhaps the identifier for old.ag.ru should go through a new property proposal, if anyone thinks that would be worthwhile — Martin ( · ) Yes please, do the merge.  There is consensus for that part.  I think perhaps the identifier for old.ag.ru should go through a new property proposal, if anyone thinks that would be worthwhile — Martin ( · ) @ , I've cleared all links to , what to do next?  ( ) I guess we can go ahead and delete then — Martin ( · ) Done , thanks for helping with this — Martin ( · ) I guess we can go ahead and delete then — Martin ( · ) Done , thanks for helping with this — Martin ( · ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  individual_of_taxon_(P10241):   There is no consensus to delete this property based on this discussion.  However it is clear that a sizeable proportion of the Wikidata community feel that taxons are classes, and that these properties should be replaced by P31/P279.  As this would be a major change and affects more than a single property, it would be best addressed in a (if anyone has the inclination to start such a discussion) — Martin ( · ) There is no consensus to delete this property based on this discussion.  However it is clear that a sizeable proportion of the Wikidata community feel that taxons are classes, and that these properties should be replaced by P31/P279.  As this would be a major change and affects more than a single property, it would be best addressed in a (if anyone has the inclination to start such a discussion) — Martin ( · ) No, the taxa that are used in statements should suffice.  This is what I and others have done in the past: when creating an instance of a taxon, and the taxon isn’t a subclass of anything yet (which is easily seen thanks to a constraint violation), add a suitable statement to the taxon.  (It can be something fairly general, since we don’t need to duplicate the exact parent taxon hierarchy: I think I’ve used at times.)  Add a statement to the taxon, as above.  Okay, so create a link between them.  ( ) shows one possible way to link such items.  Ditto.  I don’t see why a new property is needed for this.  Delete I agree that we should use .  I don't think creating another subproperty is the solution to an issue caused by poor support for subproperties.  I also don't think we should model non-human living things in a way which is the opposite of what we do with other data (a lot of the suggestions I've seen of what we should use for instead of the species are things which would normally go in or ).  - ( ) Delete , agree with Nikki.  - ( ) Delete It's clear that taxonomies can be classified just like everything else without requiring a special property.  ( ) Keep For the following reasons:  1) The property has >11000 uses.  If replaced by P31, this will lead to 11000 constraint violations in property P31.  @ : is suggesting to circumvent this by adding to all taxa which are used as P31, which seems completely unsystematic to me.  Why would you want some taxa with P279 and some without it?  2) I leave it to local taxonomists to consider if it would even make semantic sense to use P31:Taxon to indicate that an individual animal is classified as a given taxon.  To me it doesn't.  Same with P279:taxon in taxa items as discussed above.  @ : with whom I discussed the P31/P279 logic just yesterday.  3) This problem was discussed just recently in Project chat and then you had the opportunity to discuss this in the property proposal.  By deleting it again, you'd be saboteering our work.  Why should someone create a new property ever again if there is a simple way for opponents to just wait a week after its creation, then nominate it for deletion - effectively demotivating everyone to propose large-scale changes... ( ) Why wouldn't it make semantic sense?  Taxon is a class of organisms and individual organism or animal is a specimen (instance) of some taxon after all.  To me it seems that considering the impact the property was created just too hastily.  @ : 1) I think this is an overestimate: not all of the 11000 uses would have been a constraint violation in P31.  For instance, you’ve edited some items I created, and I’m fairly confident those items’ P31 statements didn’t have constraint violations at the time.  Furthermore, while I don’t think constraint violations should be the only criterion for the validity of this property, I’d like to reiterate that some of your edits introduced constraint violations, a point which AFAICT you haven’t yet responded to.  2) I don’t have much to say on this except that using P31 for taxons makes a lot of sense to me, and apparently to others too.  3) I’m sorry that the discussions turned out this way – I would also have preferred to object to this property before it was created – but sometimes it happens.  Even if I had seen your project chat discussion (I don’t remember if I did or not), you never mentioned your property proposal there (you only wondered if a new property was warranted), so I probably wouldn’t have looked further into it.  (The weekly summary where the property proposal was included happened to be the – between the holidays and , I did not spend much time looking at Wikidata then.)  And while I sympathize with the demotivating effect of this deletion proposal (sorry), we can’t just let once-made decisions lock our data model forever in place, as you seem to suggest.  (I also don’t really agree that this was proposed as a large-scale change – even the property proposal doesn’t mention that you intended to not only add statements of this property, but also remove thousands of existing P31 statements.) ( ) @ As for (1) I've made effort to add P31 to all items migrated to P10241.  Some might have been accidentally left out but that's a simple thing to fix.  I've added a correct instance to your example ( ) 1) The property has >11000 uses.  If replaced by P31, this will lead to 11000 constraint violations in property P31.  @ : is suggesting to circumvent this by adding to all taxa which are used as P31, which seems completely unsystematic to me.  Why would you want some taxa with P279 and some without it?  2) I leave it to local taxonomists to consider if it would even make semantic sense to use P31:Taxon to indicate that an individual animal is classified as a given taxon.  To me it doesn't.  Same with P279:taxon in taxa items as discussed above.  @ : with whom I discussed the P31/P279 logic just yesterday.  3) This problem was discussed just recently in Project chat and then you had the opportunity to discuss this in the property proposal.  By deleting it again, you'd be saboteering our work.  Why should someone create a new property ever again if there is a simple way for opponents to just wait a week after its creation, then nominate it for deletion - effectively demotivating everyone to propose large-scale changes... ( ) Why wouldn't it make semantic sense?  Taxon is a class of organisms and individual organism or animal is a specimen (instance) of some taxon after all.  To me it seems that considering the impact the property was created just too hastily.  @ : 1) I think this is an overestimate: not all of the 11000 uses would have been a constraint violation in P31.  For instance, you’ve edited some items I created, and I’m fairly confident those items’ P31 statements didn’t have constraint violations at the time.  Furthermore, while I don’t think constraint violations should be the only criterion for the validity of this property, I’d like to reiterate that some of your edits introduced constraint violations, a point which AFAICT you haven’t yet responded to.  2) I don’t have much to say on this except that using P31 for taxons makes a lot of sense to me, and apparently to others too.  3) I’m sorry that the discussions turned out this way – I would also have preferred to object to this property before it was created – but sometimes it happens.  Even if I had seen your project chat discussion (I don’t remember if I did or not), you never mentioned your property proposal there (you only wondered if a new property was warranted), so I probably wouldn’t have looked further into it.  (The weekly summary where the property proposal was included happened to be the – between the holidays and , I did not spend much time looking at Wikidata then.)  And while I sympathize with the demotivating effect of this deletion proposal (sorry), we can’t just let once-made decisions lock our data model forever in place, as you seem to suggest.  (I also don’t really agree that this was proposed as a large-scale change – even the property proposal doesn’t mention that you intended to not only add statements of this property, but also remove thousands of existing P31 statements.) ( ) @ As for (1) I've made effort to add P31 to all items migrated to P10241.  Some might have been accidentally left out but that's a simple thing to fix.  I've added a correct instance to your example ( ) Why wouldn't it make semantic sense?  Taxon is a class of organisms and individual organism or animal is a specimen (instance) of some taxon after all.  To me it seems that considering the impact the property was created just too hastily.  @ : 1) I think this is an overestimate: not all of the 11000 uses would have been a constraint violation in P31.  For instance, you’ve edited some items I created, and I’m fairly confident those items’ P31 statements didn’t have constraint violations at the time.  Furthermore, while I don’t think constraint violations should be the only criterion for the validity of this property, I’d like to reiterate that some of your edits introduced constraint violations, a point which AFAICT you haven’t yet responded to.  2) I don’t have much to say on this except that using P31 for taxons makes a lot of sense to me, and apparently to others too.  3) I’m sorry that the discussions turned out this way – I would also have preferred to object to this property before it was created – but sometimes it happens.  Even if I had seen your project chat discussion (I don’t remember if I did or not), you never mentioned your property proposal there (you only wondered if a new property was warranted), so I probably wouldn’t have looked further into it.  (The weekly summary where the property proposal was included happened to be the – between the holidays and , I did not spend much time looking at Wikidata then.)  And while I sympathize with the demotivating effect of this deletion proposal (sorry), we can’t just let once-made decisions lock our data model forever in place, as you seem to suggest.  (I also don’t really agree that this was proposed as a large-scale change – even the property proposal doesn’t mention that you intended to not only add statements of this property, but also remove thousands of existing P31 statements.) ( ) @ As for (1) I've made effort to add P31 to all items migrated to P10241.  Some might have been accidentally left out but that's a simple thing to fix.  I've added a correct instance to your example ( ) @ As for (1) I've made effort to add P31 to all items migrated to P10241.  Some might have been accidentally left out but that's a simple thing to fix.  I've added a correct instance to your example ( ) Comment I also noticed these large scale changes to P31 values, and I find it a poor workaround to the problem that taxa items in the first place still don't make proper use of .  Generally, taxa are classes, and so every taxa should have P279 statement, as other class items normally do.  P279 value for taxa could be , or something a little less generic.  But ideally could be phased out eventually and P279 could be used to model taxonomic hierarchy, so that it could be properly combined with other hierarchies (e.g. indicate that all species of a family are carnivore species by simply setting the parent taxon as a subclass of carnivore class).  Not making proper use of P279 for taxa is a root of all sorts of deficiencies, e.g. see also comments .  Delete This is pretty clearly duplication of the semantic content of → ""some specific taxon, usually a species"", which should itself eventually be subclass of .  P31/P279* is the absolutely standard and, IMO, logical membership idiom used for hundreds of millions of items.  What is the actual need for this sub-property that cannot be achieved using that idiom?  If there's a good technical/ontological need for this sub-property, that's a pretty huge discovery, because it must also apply to most other ""instance"" items and would represent an end-to-end shake-up of the basic structure of Wikidata.  Not that that's necessarily a bad thing, but consistency is absolutely critical, and so if that's where taxa go, everything else should follow (notably, is also a deviation and starts getting metaphysical when you wonder what the difference is between ""being"" a writer and ""doing writing"") .  Buildings should have their claims pointing to subclasses of stripped out and replaced with a ""is a building of type"" property.  And so on.  Specifically, there should be a very clear path to transitioning to a new, more consistent, status quo than introducing a sub-property and changing only a small domain of items.  There's enough fragmentation, inconsistency and fuzzy modelling about as it is. ( ) Comment I wasn't part of the original discussion of this (I was pinged but didn't participate - I don't really have strong opinions on taxon-related items or properties).  However, can we fix the constraints on so that the value can have a statement with either or *any subproperty* of P279?  you have some familiarity with constraint logic, is this possible?  That would eliminate the need for the workarounds mentioned above.  ( ) I don’t think that’s possible, no. ( ) I'd rather say that subproperty support would be yet another workaround to the actual problem of taxon items lacking P279 statements.  I don’t think that’s possible, no. ( ) I'd rather say that subproperty support would be yet another workaround to the actual problem of taxon items lacking P279 statements.  Comment No strong feelings about it, but I do feel P31 suffices.  The ontological modelling of taxa is weird, though: it is a mix of people seeing it as a class and people seem it as a term.  treats taxa like terms, like lexemes, for example.  IMO, if we agree on Delete we are also agreeing that taxa should be modeled as classes (what I support) .  ( ) As I understand it, despite using the work ""synonym"", the property is referring to a , aka taxonomic synonym , which isn't a linguistic/lexical concept, but rather a specific statement that someone somewhere has said that two taxa are referring to the same organisms (taxonomy being a complete mess, historically, this happened quite a lot!).  It's more like a special case of with very specific semantics (completely unlike P460).  But taxa are very odd, since they have an entirely separate membership hierarchy to all other items.  ( ) Exactly this.  “…weird, though: it is a mix of people seeing it as a class and people seem it as a term”.  Taxa and nomina could be modeled separately.  (Or maybe there is a more elegant solution to handle both taxonomic concepts and naming?)  For example, the Pacific oyster has been classified as or .  It's still the same species concept, the circumscription hasn't changed.  But we don't have a single item for the concept of “pacific oyster”.  What has changed is the concept of the genus it belongs to: Crassostrea in the broader sense ( sensu lato ) includes Crassostrea sensu stricto and .  Those two senses of Crassostrea are distinct sets having different membership.  But because they have the same name “ Crassostrea ”, we only have one item .  Stepping up above the genus level, pacific oysters are still a type of oyster; Crassostrea s.l., Crassostrea s.s., and Magallana are all sub-taxa of family .  This example isn't some weird edge case: lumping and splitting parent taxa is just one of the many ways that names can change, and happens in taxonomy and nomenclature (two separate but related disciplines) all the time .  (In some ways, the distinction between taxa and nomina is akin to our separation of items and lexemes / .) ⁓ ( ) As I understand it, despite using the work ""synonym"", the property is referring to a , aka taxonomic synonym , which isn't a linguistic/lexical concept, but rather a specific statement that someone somewhere has said that two taxa are referring to the same organisms (taxonomy being a complete mess, historically, this happened quite a lot!).  It's more like a special case of with very specific semantics (completely unlike P460).  But taxa are very odd, since they have an entirely separate membership hierarchy to all other items.  ( ) Exactly this.  “…weird, though: it is a mix of people seeing it as a class and people seem it as a term”.  Taxa and nomina could be modeled separately.  (Or maybe there is a more elegant solution to handle both taxonomic concepts and naming?)  For example, the Pacific oyster has been classified as or .  It's still the same species concept, the circumscription hasn't changed.  But we don't have a single item for the concept of “pacific oyster”.  What has changed is the concept of the genus it belongs to: Crassostrea in the broader sense ( sensu lato ) includes Crassostrea sensu stricto and .  Those two senses of Crassostrea are distinct sets having different membership.  But because they have the same name “ Crassostrea ”, we only have one item .  Stepping up above the genus level, pacific oysters are still a type of oyster; Crassostrea s.l., Crassostrea s.s., and Magallana are all sub-taxa of family .  This example isn't some weird edge case: lumping and splitting parent taxa is just one of the many ways that names can change, and happens in taxonomy and nomenclature (two separate but related disciplines) all the time .  (In some ways, the distinction between taxa and nomina is akin to our separation of items and lexemes / .) ⁓ ( ) Comment Is a named individual of the species and/or the subspecies ?  From a nomenclatural perspective the names Giraffa reticulata and Giraffa camelopardalis reticulata refer to the same thing, because they have the same .  Adding different values of to them ( Giraffa / Giraffa camelopardalis ) would make no sense.  From a taxonomic perspective both belong to the (sometimes monotypic ) genus .  Giraffa is a name which refers to different taxon concepts (!= ) up to 4 recognized species (eg. , , , ).  is not a replacment for as suggested in the past and here again.  We do not model taxa.  We do model according to the different and their relationship.  -- ( ) @ : All of your above mentions examples have more than one issue. E.g. is a in the taxonomy of . -- ( ) should be better somehow related to . -- ( ) is/was a modeled as ... -- ( ) This view that we model taxon names, not taxa, does not reflect reality really.  In general, current taxon items are explicitly set as instances of , while is given as merely an attribute to a taxon, taxon (not its name) has etc.  Some dissonance to that also exist in some items, but then this just needs to be cleared up eventually, keeping in mind that Wikidata is an ontological database.  Any taxon as class warrants some P279 statement as well.  If you want to model taxon names in particular, then you should probably set up this project in Lexeme namespace (see ).  It isn't clear what are you trying to polemize about with this giraffe example.  What you say applies to P171 as much as it applies to P279, and a class with one subclass in itself shouldn't be a problem.  You also say that ""examples have more than one issue"", but your subsequent response doesn't explain in any way what the issues are, as far as I can see.  Contrary to your claims, Sunny the dog in particular isn't a dog breed, one's an instance of some breed which in turn is of some taxon (its subclass), and Moja the gorilla is an individual organism (as well as a true instance of some taxon) not a Wikimedia list article nor a group of organisms (if that's what you thought was).  I do not discuss this with you .  -- ( ) I'm fairly sure you can't provide any behavioural evidence to this baseless claim. @ : All of your above mentions examples have more than one issue. E.g. is a in the taxonomy of . -- ( ) should be better somehow related to . -- ( ) is/was a modeled as ... -- ( ) This view that we model taxon names, not taxa, does not reflect reality really.  In general, current taxon items are explicitly set as instances of , while is given as merely an attribute to a taxon, taxon (not its name) has etc.  Some dissonance to that also exist in some items, but then this just needs to be cleared up eventually, keeping in mind that Wikidata is an ontological database.  Any taxon as class warrants some P279 statement as well.  If you want to model taxon names in particular, then you should probably set up this project in Lexeme namespace (see ).  It isn't clear what are you trying to polemize about with this giraffe example.  What you say applies to P171 as much as it applies to P279, and a class with one subclass in itself shouldn't be a problem.  You also say that ""examples have more than one issue"", but your subsequent response doesn't explain in any way what the issues are, as far as I can see.  Contrary to your claims, Sunny the dog in particular isn't a dog breed, one's an instance of some breed which in turn is of some taxon (its subclass), and Moja the gorilla is an individual organism (as well as a true instance of some taxon) not a Wikimedia list article nor a group of organisms (if that's what you thought was).  I do not discuss this with you .  -- ( ) I'm fairly sure you can't provide any behavioural evidence to this baseless claim. This view that we model taxon names, not taxa, does not reflect reality really. In general, current taxon items are explicitly set as instances of , while is given as merely an attribute to a taxon, taxon (not its name) has etc. Some dissonance to that also exist in some items, but then this just needs to be cleared up eventually, keeping in mind that Wikidata is an ontological database. Any taxon as class warrants some P279 statement as well. If you want to model taxon names in particular, then you should probably set up this project in Lexeme namespace (see ). It isn't clear what are you trying to polemize about with this giraffe example. What you say applies to P171 as much as it applies to P279, and a class with one subclass in itself shouldn't be a problem. You also say that ""examples have more than one issue"", but your subsequent response doesn't explain in any way what the issues are, as far as I can see. Contrary to your claims, Sunny the dog in particular isn't a dog breed, one's an instance of some breed which in turn is of some taxon (its subclass), and Moja the gorilla is an individual organism (as well as a true instance of some taxon) not a Wikimedia list article nor a group of organisms (if that's what you thought was). I do not discuss this with you . -- ( ) I'm fairly sure you can't provide any behavioural evidence to this baseless claim.  I do not discuss this with you .  -- ( ) I'm fairly sure you can't provide any behavioural evidence to this baseless claim. I'm fairly sure you can't provide any behavioural evidence to this baseless claim. We now have editors deleting existing statements using this property, which I think is premature until this deletion proposal is resolved. and are two examples. This is not fair to the original proposer. ( ) -- ( ) @ Sure, this qualifier-based solution would also be possible, I'm just warning it's less elegant because it doesn't allow multiple values with different circumstances such as in .  ( ) It shows only that it is not necessary to randomly drop in statements at taxon items to resolve the constraints.  A sperate property is allway a better solution.  -- ( ) -- ( ) @ Sure, this qualifier-based solution would also be possible, I'm just warning it's less elegant because it doesn't allow multiple values with different circumstances such as in .  ( ) It shows only that it is not necessary to randomly drop in statements at taxon items to resolve the constraints.  A sperate property is allway a better solution.  -- ( ) @ Sure, this qualifier-based solution would also be possible, I'm just warning it's less elegant because it doesn't allow multiple values with different circumstances such as in .  ( ) It shows only that it is not necessary to randomly drop in statements at taxon items to resolve the constraints.  A sperate property is allway a better solution.  -- ( ) It shows only that it is not necessary to randomly drop in statements at taxon items to resolve the constraints. A sperate property is allway a better solution. -- ( ) Not randomly, all taxons items, just like any other class items, are expected to have P279 statement (see above).  Plus @ : it seems that Wikidata doesn't allow Fair Use, so I doubt if this property can be legally kept.  ( ) Not randomly, all taxons items, just like any other class items, are expected to have P279 statement (see above).  Plus @ : it seems that Wikidata doesn't allow Fair Use, so I doubt if this property can be legally kept.  ( ) Not randomly, all taxons items, just like any other class items, are expected to have P279 statement (see above).  Plus @ : it seems that Wikidata doesn't allow Fair Use, so I doubt if this property can be legally kept.  ( ) Not randomly, all taxons items, just like any other class items, are expected to have P279 statement (see above).  Plus @ : it seems that Wikidata doesn't allow Fair Use, so I doubt if this property can be legally kept.  ( ) Not randomly, all taxons items, just like any other class items, are expected to have P279 statement (see above).  Plus @ : it seems that Wikidata doesn't allow Fair Use, so I doubt if this property can be legally kept.  ( ) Actually it would probably be doable too, using two independent statements.  I'm taking it back.  Your solution is an option, definitely better than using taxon names as values in P31 itself.  ( ) Actually it would probably be doable too, using two independent statements.  I'm taking it back.  Your solution is an option, definitely better than using taxon names as values in P31 itself.  ( ) Actually it would probably be doable too, using two independent statements.  I'm taking it back.  Your solution is an option, definitely better than using taxon names as values in P31 itself.  ( ) Keep Solution using is quite poor - hard to query and creating constraint violations.  -- ( ) Comment Anyway, in case the decision to migrate back to P31 prevails,  I would prefer if the current usage of taxa in P31 is cleaned up before migration, because most of them have nothing to do with individual organisms. See for items which currently include taxa among their P31 statements. Please don't create chaos where measures to introduce order were taken, even if you don't agree with the way it's been done.-- ( ) Keep For arguments see above -- ( ) Delete Too hard to understand and for translation, better to propose more smartphone-like properties.  -- ( ) presumably you commented on the wrong discussion? what does this have to do with smartphones? ( ) presumably you commented on the wrong discussion? what does this have to do with smartphones? ( ) Keep i don't understand how you propose replacing this with ? Do you want to make every taxon also a subclass? That seems like a big change. Can't vote delete until this is answered. ( ) It's answered in the original post and in subsequent posts. The change that we currently face is/was to replace P31, not the other way around. Taxons are classes and the classification of classes on Wikidata normally relies on P279, so why wouldn't we add P279 statements to every taxon? In fact, this issue probably would have been fixed ages ago, if a few users (or maybe one user) weren't determined to remove P279 statements from taxons, like , for unclear reason. As you know this problem was „fixed ages ago“ via . -- ( ) „ “ becomes to .  What is a taxonomic subclass of ?  Anything equal or below ?  Or taxonomic - according to a source - related?  -- ( ) Well, in this example you could have removed only P31 misuse, but for an unclear reason you also removed valid P279 statement, which is the problem here. Given P31 misuse in taxon item is irrelevant here. Also, I don't know what ""problem"" exactly you have in mind that was fixed via P171, but it definitely wasn't the one we are facing here. Regardless of P171, taxons as classes, in general Wikidata item classification scheme, still warrant P279 statements as well. What is a (taxonomic) subclass of ? I don't quite understand why you ask and what this have got to to do with previous discussion. Comment As Lucas noted, P31 wasn't working as he didn't notice before that ""Methuselah (Q590039) isn't linked to Pinus longaeva (Q1116374) at all as far as I can see.""  The property actually fixes items in a field that was poorly modeled with . This is similar to the way we do it with , and other aspects. In general, if need to be a expert in a field to determine the correct P31, than it's probably not good modeling (IMHO). --- It's answered in the original post and in subsequent posts.  The change that we currently face is/was to replace P31, not the other way around.  Taxons are classes and the classification of classes on Wikidata normally relies on P279, so why wouldn't we add P279 statements to every taxon?  In fact, this issue probably would have been fixed ages ago, if a few users (or maybe one user) weren't determined to remove P279 statements from taxons, like , for unclear reason.  As you know this problem was „fixed ages ago“ via .  -- ( ) „ “ becomes to .  What is a taxonomic subclass of ?  Anything equal or below ?  Or taxonomic - according to a source - related?  -- ( ) Well, in this example you could have removed only P31 misuse, but for an unclear reason you also removed valid P279 statement, which is the problem here. Given P31 misuse in taxon item is irrelevant here. Also, I don't know what ""problem"" exactly you have in mind that was fixed via P171, but it definitely wasn't the one we are facing here. Regardless of P171, taxons as classes, in general Wikidata item classification scheme, still warrant P279 statements as well. What is a (taxonomic) subclass of ? I don't quite understand why you ask and what this have got to to do with previous discussion. As you know this problem was „fixed ages ago“ via . -- ( ) „ “ becomes to .  What is a taxonomic subclass of ?  Anything equal or below ?  Or taxonomic - according to a source - related?  -- ( ) Well, in this example you could have removed only P31 misuse, but for an unclear reason you also removed valid P279 statement, which is the problem here. Given P31 misuse in taxon item is irrelevant here. Also, I don't know what ""problem"" exactly you have in mind that was fixed via P171, but it definitely wasn't the one we are facing here. Regardless of P171, taxons as classes, in general Wikidata item classification scheme, still warrant P279 statements as well. What is a (taxonomic) subclass of ? I don't quite understand why you ask and what this have got to to do with previous discussion. Well, in this example you could have removed only P31 misuse, but for an unclear reason you also removed valid P279 statement, which is the problem here. Given P31 misuse in taxon item is irrelevant here. Also, I don't know what ""problem"" exactly you have in mind that was fixed via P171, but it definitely wasn't the one we are facing here. Regardless of P171, taxons as classes, in general Wikidata item classification scheme, still warrant P279 statements as well. What is a (taxonomic) subclass of ? I don't quite understand why you ask and what this have got to to do with previous discussion. Comment As Lucas noted, P31 wasn't working as he didn't notice before that ""Methuselah (Q590039) isn't linked to Pinus longaeva (Q1116374) at all as far as I can see.""  The property actually fixes items in a field that was poorly modeled with . This is similar to the way we do it with , and other aspects. In general, if need to be a expert in a field to determine the correct P31, than it's probably not good modeling (IMHO). --- Keep Yes the change was very poorly communicated.  I understood about it after some people started complaining to me about broken queries and missing data.   That said I support the new property.  Adapting my broken queries to the change actually made them simpler and faster.  I think that, given the universal character (and scale) of the Wikidata Knowledge Graph it makes sense to unload as much as possible from specifics about a given field.  Similar to , I approve the prospect of being able to rely on something like and a dedicated property instead of having to filter out which of the types I am looking for.   -- ( ) Delete . Taxons are classes, we don't need a subproperty of just for taxons. P31 should accept P171 as equivalent to its superproperty. -- ( ) ###Output: ",0
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P4538:   Nomination withdrawn — Martin ( · ) Nomination withdrawn — Martin ( · ) Property has 464 uses.  @ : is there any archive available that we can link to?  — Martin ( · ) Wait a minute.  Can it be.  . .  I think is online again.  The web.archive replacement in WD was misleading.  Okay, if that's so the property may not be of much use, but we can keep it just the same.  -- ( ) Wait a minute. Can it be. . . I think is online again. The web.archive replacement in WD was misleading. Okay, if that's so the property may not be of much use, but we can keep it just the same. -- ( ) ###Output: ",0
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P10808:   Don't need to delete ( ) Don't need to delete ( ) Seems use of this property have started in some qualifyers.  No longer asking deletion.  ● ● ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P1076:   Done @ , : ( ) Done @ , : ( ) Any issue with making it a redirect?  (assuming that's applicable here, which I realize may not be the case) ( ) I'm not sure if it's technically possible but given the fact that some IDs now redirect to others persons I fear that this will only create confusion.  As of today I have again removed any use of this property as main statements and references and have also modified the labels and description of the property to reflect that it shouldn't be used.  -- ( ) And, because you just removed them instead of updating them, thereby leaving uncited statements, I have to dig through all your edits from the past year. ( ) I did in fact update them, save for a handful that I overlooked. -- ( ) I'm not sure if it's technically possible but given the fact that some IDs now redirect to others persons I fear that this will only create confusion.  As of today I have again removed any use of this property as main statements and references and have also modified the labels and description of the property to reflect that it shouldn't be used.  -- ( ) And, because you just removed them instead of updating them, thereby leaving uncited statements, I have to dig through all your edits from the past year. ( ) I did in fact update them, save for a handful that I overlooked. -- ( ) And, because you just removed them instead of updating them, thereby leaving uncited statements, I have to dig through all your edits from the past year.  ( ) I did in fact update them, save for a handful that I overlooked.  -- ( ) I did in fact update them, save for a handful that I overlooked. -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P6615_(P6615):   ( ) Notified ( ) No citable reliable source [""zitierfähige Quelle"" in German].  Please delete.  -- ( ) @ : What do you mean with ""No citable source""? -- ( ) In the sence of .  But merging is ok with me.  -- ( ) @ : We are not on Wikipedia, reliability is not a requirement for external identifiers (otherwise we should remove every property about social networks, other wiki websites, including Wikimedia Commons, etc.). -- ( ) @ : What do you mean with ""No citable source""?  -- ( ) In the sence of . But merging is ok with me. -- ( ) @ : We are not on Wikipedia, reliability is not a requirement for external identifiers (otherwise we should remove every property about social networks, other wiki websites, including Wikimedia Commons, etc.).  -- ( ) In the sence of . But merging is ok with me. -- ( ) @ : We are not on Wikipedia, reliability is not a requirement for external identifiers (otherwise we should remove every property about social networks, other wiki websites, including Wikimedia Commons, etc.).  -- ( ) @ : We are not on Wikipedia, reliability is not a requirement for external identifiers (otherwise we should remove every property about social networks, other wiki websites, including Wikimedia Commons, etc.). -- ( ) Support Good idea, like solution makes sense.  -- ( ) Support merging. -- @ : do you propose to also merge , , , , , , ?  If so, please can you tag them with {{ }} ?  — Martin ( · ) Yes, I proposed to merge all these properties.  I will tag them soon.  ( ) @ : I've just did it.  -- ( ) Yes, I proposed to merge all these properties. I will tag them soon. ( ) @ : I've just did it. -- ( ) @ : I've just did it.  -- ( ) Support -- ( ) Support merging all the properties.  -- ( ) Thank you for tagging the other properties Horcrux, which Kethyga promised to do but did not — Martin ( · ) Thank you for tagging the other properties Horcrux, which Kethyga promised to do but did not — Martin ( · ) @ , , , , : @ , : Should one of the existing properties be used for the general Vikidia property or should we request creation of a new one to avoid confusion? -- ( ) IMO a new one should be created.  -- ( ) See -- ( ) IMO a new one should be created.  -- ( ) See -- ( ) Done Clear consensus for deletion, data has been migrated to -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P3809:   Support ( ) Support - ( ) Support -- ( ) Support Support -- ( ) Support -- Removing the redundant statements would be okay for me. -- ( ) Do it ( ) @ , , : Okay then, the removal of P10863 values has begun.  ( ) ...and it has finished.  ( ) @ , , : Okay then, the removal of P10863 values has begun.  ( ) ...and it has finished.  ( ) Done Clear consensus for deletion.  -- ( ) ###Output: ",0
no_consensus,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P4981:   Delete per nom.  -- Done Consensus for deletion because of the unclear usage of this property. Could be undeleted if someone has an idea how this property should be used. -- ( ) ###Output: ",2
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P12600:   @ , , :-- ( ) Would your bot have time to move the identifiers if necessary? @ :-- ( ) Support after migration is completed ( ) I changed my mind.  – ( ) Would your bot have time to move the identifiers if necessary?  @ :-- ( ) Support after migration is completed ( ) I changed my mind.  – ( ) I changed my mind.  – ( ) Support ( ) Oppose .  Sorry, I don't understand the reason.  When All the Tropes identifier was originally created, I did not even know that it was a Mirahese project.  It is a problem of discoverability: other editors also won't know that to add ""All the Tropes"" they need to add Mirahese.  Calling it obsolete is like calling all prefix-based redirectors like identifiers.org, DOI or even superior to original websites.  ( ) don't you think the discoverability problem can be solved by adding ""All the Tropes ID"" as an alias to the property?  ( ) don't you think the discoverability problem can be solved by adding ""All the Tropes ID"" as an alias to the property?  ( ) @ , , : a seperate property has the advantage of being more stable .  Should the All the Tropes community should decide to migrate away from Mirahese (migrations in and out of wiki farms happen, I hear), this property can be changed to resolve to a different url: problem solved.  I propose: lets Keep this property and consider it a .  Furthermore, lets avoid redundancy by using the more precise property where possible, employing constraints.  this approach can be applied going forward – ( ) I dont see the advantage.  If ATT moves farm, we can simply migrate the ID'a to the new farm identifier ( ) I dont see the advantage.  If ATT moves farm, we can simply migrate the ID'a to the new farm identifier ( ) Keep per Shisma.  ( ) Not done No consensus for deletion.  -- ( ) ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P2086:   Notified -- ( ) this is just a too well-known and established property within the mathematical community (even only on the small talk level) to be deleted.  Why can not somebody write a bot/script to get the relevant data from mathscinet?  ( ) this is just a too well-known and established property within the mathematical community (even only on the small talk level) to be deleted.  Why can not somebody write a bot/script to get the relevant data from mathscinet?  ( ) The fact that's it's unstable is not enough to justify deletion, Wikidata can handle evolution over time through ""date"" qualifier for example.  We handle such datas as city number of inhabitants already, by adding a date qualifier.  We can afford getting multiple values.  Oppose For deceased researchers, the Erdős number will (eventually) become static.  For living researchers, having a script to update the number would be great, but even without that, I think that periodic dated updates for would be good enough to be useful, or at least interesting.  — Oppose It's not an identifier, stability is not an issue.  ( ) Oppose It's also eventually stable anyway, as individual mathematicians go to meet theie peers in Mathematical Valhalla, where no-one ever runs out of chalk or blackboard space, so you don't have to worry about a number than continues to change forever.  Changes in Erdős number are also of historical interest.  But that's not the primary reason, it's that it's really fucking cool .  Not done , no consenous for deletion.  -- ###Output: ",0
deleted,"###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P11456_and_Property:P11457:   Delete - with a reference linking to iTunes seems sufficient to say what the genre is according to iTunes.  - ( ) Done .  -- ###Output: ",0